Was Entwickler wissen müssen: Die Programmierung des TT (Teil 1)
Der TT ist eine echte Herausforderung an Programmierer. Damit diese auch gut gewappnet sind, hat Atari das TT-Betriebssystem umfassend an die neue Hardware angepaßt. Hier erfahren Sie, wie Programme über das neue TOS den TT voll ausnutzen.
Die erste Hürde bei der Programmanpassung an den TT ist der neue Prozessor 68030, den der Mathecoprozessor 68882 tatkräftig unterstützt. Bei der Anpassung sollten Sie beachten, daß der 68030 zwei Cachespeicher besitzt, einen Befehls- und einen Datencache. Durch seinen Cache-Speicher führt der Prozessor die Prozessoranweisungen und Datenzugriffe extrem schnell aus. Dies sollten Sie bei Verwendung von Zeitschleifen nie vergessen. Das Problem ergibt sich etwa bei Time-Out-Zählern. Nutzen Sie für solche Zwecke in Zukunft auf jeden Fall die Timer bzw. den 200 Hz-Zähler. Dadurch, daß der 68030 ein Zusatzwort bei Exceptions auf den Stack legt, verschieben sich die Stackparameter um ein Wort. Sie sollten deswegen bei eigenen Trap-Handlern nie von einer absoluten Distanz auf dem Stack ausgehen. Das TT-TOS besitzt zu diesem Zweck eine neue Systemvariable namens »_longframe«. Sie umfaßt ein Wort und liegt ab $59e.
Ist sie ungleich Null, so arbeitet der Computer mit einer CPU, die das erweiterte Stackformat verwendet (TT).
Wie bereits der STE, so verwendet auch der TT DMA-gesteuerten Sound. Einziger Unterschied zum STE: Bit 6 im Port A des PSG-Chips dient als Schalter dafür, ob der Sound zusätzlich über die im TT eingebauten Lautsprecher ertönen soll.
Der TT besitzt insgesamt sechs Videoauflösungen: die drei des STs und drei neue: ST-LOW (320x200, 16 Farben), ST-MEDIUM (640x200, vier Farben), ST-HIGH (640x400, zwei Farben), TT-LOW (320x480, 256 Farben), TT-MEDIUM (640x480, 16 Farben) und TT-HIGH (1280x960, monochrom). In dieser Reihenfolge erhalten Sie über die »Getrez«-Funktion die Auflösungen 0 bis 5 zurück. Aus Kompatiblitätsgründen sollten Sie allerdings nicht mit »Getrez« arbeiten. Ein weitaus sicherere Informationsquelle ist das VDI, von dem Sie bei Öffnen einer Workstation die Anzahl der vorhandenen Farben und die Bildschirmausmaße über das »work_out«-Feld erhalten.
Die Farbpalette des TT ist wie beim STE organisiert: für die Grundfarben Rot, Grün und Blau gibt es jeweils 4 Bit. In der ST-kompatiblen Farbtabelle ab $ff8240 ist das höchste Bit jedes Nibbles das niedrigste Bit der entsprechenden Grundfarbe. Im TT gibt es eine zweite, TT-eigene Farbtabelle mit 256 Einträgen. Sie liegt ab $ff8400. Darin sind die 4 Bit für jede Grundfarbe in ihrer natürlichen Reihefolge geordnet. In den 16- und 4-Farben-Modi ist die TT-eigene Farbtabelle in 16 Bänke untergliedert, wobei nur eine gleichzeitig aktiv ist. Diese wird in die ST-kompatible Farbtabelle hineingespiegelt.
Neue Speichermodelle
Der TT ist der erste einer geplanten ST-kompatiblen Computerserie, die zwei RAM-Arten verwenden: das ST-kompatible und das nicht ST-kompatible RAM, das sog. »alternative« RAM. Ersteres läßt sich neben dem Prozessor auch vom Video-Chip und vom DMA-Sound (Direct Memory Access) ansprechen - wie eben auf dem ST auch. Das alternative RAM ist ausschließlich dem Prozessor zugänglich. Dies hat den Vorteil, daß er keine Wartezyklen einlegen muß und somit bedeutend schnellere Speicherzugriffe leistet, so auch den Burst-Fill zum schnellen Füllen des Prozessorcache. Spezialchips wie etwa ACSI-DMA (für ST-Festplatten und -Geräte) und SCSI-DMA (für SCSI-Geräte) sind nicht in der Lage, direkt auf das alternative RAM zuzugreifen. Im TT gibt es noch einen dritten RAM-Typ, das VME-RAM. Dies ist allerdings an dieser Stelle nicht interessant, da es vornehmlich für VME-Bus-Erweiterungen gedacht ist. Soll ein Programm auch im alternativen RAM lauffähig sein, so muß der Programmierer folgende Regeln beachten:
- Das Programm darf den Bildschirm nicht ins alternative RAM verlegen oder DMA-Sound darin abspielen
- Das Programm darf über keinen DMA-Treiber Daten von oder ins alternative RAM verschieben, es sei denn, der DMA-Treiber ist in der Lage, beide RAM-Arten zu bedienen.
- Programme dürfen keinesfalls DMA-Operationen direkt durchführen. Dazu sind die speziellen DMA-Treiber da.
Neue Informationen im Programmheader
Da die Programmierer diese Einschränkungen noch nicht kannten, brechen viele der bisherigen Programme die aufgestellten Regeln. Deshalb behandelt GEM-DOS frühere Programme normalerweise wie auf einem ST, d. h. das Betriebssystem versperrt ihnen den Zugriff auf das alternative RAM. Ist allerdings sicher, daß ein Programm nicht gegen die obigen Regeln verstößt, so kann es durch geringe Modifikationen im Programmheader auch auf's alternative RAM zugreifen.
Bereits das Rainbow-TOS ordnete einem der im Programmheader reservierten Langwörter eine besondere Bedeutung zu. Ist Bit 0 dieses Langworts (Offset $16) gesetzt, so löscht GEMDOS beim Laden des Programmes lediglich den BSS-Bereich anstatt den gesamten Speicher. Dieses Langwort wurde in TOS 3.0 mit zwei weiteren Flags ausgestattet (siehe Tabelle).
Ist Bit 1 gelöscht, so lädt GEMDOS das Programm unbedingt in das ST-RAM. Ist Bit 2 gelöscht, so ordnet GEMDOS bei Speicherbelegungen mittels »Malloc« dem Programm ausschließlich ST-RAM zu. Ist eines (oder beide) dieser Bits gesetzt, so erhält das Programm bei der entsprechenden Operation (Programm laden, Speicherbelegung) auch alternatives RAM.
Für viele Programme ist »ausreichend Speicher« ein relativer Begriff. Das eine Programm legt beispielsweise mehr Wert darauf, schnell zu arbeiten (alternatives RAM), anstatt viel Arbeitsspeicher zu besitzen und ist mit »ausreichend Speicher« von 256 KByte zufrieden. Für ein anderes Programm könnte es dagegen wichtiger sein, viel Arbeitsspeicher zu besitzen - auch wenn dieser langsamer ist (ST-RAM).
Um den verschiedenen Anforderungen nachzukommen, gibt es ab TOS 3.0 ein neues Feld im Programmheader namens »TPAsize« (siehe Tabelle). Darin sind die Speicheranforderungen des Programms festgehalten. Ist das »Programmlade«-Bit gelöscht, so ignoriert GEMDOS das Feld und lädt das Programm in ST-RAM. Falls das Bit gesetzt ist und mehr alternatives RAM als ST-RAM frei ist, lädt GEMDOS das Programm in das alternative RAM, ohne das Feld zu beachten.
GEMDOS beachtet das Feld erst, wenn das »Programmlade«-Bit gesetzt und weniger alternatives RAM als ST-RAM frei ist. In diesem Fall besagt »TPAsize«, wieviel alternatives RAM das Programm benötigt. Diese Angabe plus die Programmgröße (Text-, Daten-und BSS-Segment) ergibt den gesamten Speicherbedarf. Ist so viel frei, dann lädt GEMDOS das Programm in das alternative RAM, ansonsten in das ST-RAM.
Das »TPAsize«-Feld gibt in 128 KByte Schritten an, wieviel alternatives RAM ausreichend ist. Das Feld umfaßt die höchsten 4 Bit des Programmflag-Langworts. Die Speichergröße ergibt sich aus dem Feldwert mal 128 KByte plus 128 KByte und liegt somit im Bereich 128 KByte (0) und 2 MByte (15).
Das zweite neue Bitflag im Programmkopf gibt an, ob bei Speicherbelegungen über »Malloc« GEMDOS das alternative RAM miteinbeziehen soll. Für neue, TT-kompatible Programme stellt das GEMDOS eine neue Funktion namens »Mxalloc« (Funktionsnummer $44) zur Verfügung (siehe »neue GEMDOS-Funktionen«).
Die neuen GEMDOS-Funktionen
GEMDOS 0x44: Mxmalloc
long Mxmalloc(amount,mode); long amount; word mode;
Funktionsweise: »Mxmalloc« ersetzt für TT-kompatible Programme die Speicherbelegungs-Funktion »Malloc« (0x48). Dabei bestimmen Sie über »mode«, welchen RAM-Typ Sie benötigen:
| mode | Bedeutung |
|---|---|
| 0 | nur ST RAM |
| 1 | nur alternatives RAM |
| 2 | egal, ST-RAM bevorzugt |
| 3 | egal, alternatives RAM bevorzugt |
Ergebnis: Wie bei »Malloc«.
Die neuen grafikorientierten XBIOS-Funktionen
Achtung: Alle hier aufgeführten Funktionen beziehen sich ausschließlich auf den TT und können sich auch in zukünftigen Atari-Computer noch ändern.
XBIOS 80: _EsetShift
word _EsetShift[shftModel]
word shftMode;
Funktionsweise: Diese Funktion setzt die TT-Shiftmodus-Register auf den Wert »shftMode«. Die Belegung dieses Registers finden Sie im Bild. Als Ergebnis liefert die Funktion stets den alten Wert des Shiftmodus-Registers zurück.
Anmerkung: Diese Funktion konfiguriert die aktuelle Bank, den Grafikmodus, das Grau- und das »Schmier«-Flag. Mit den felgenden Funktionen können sie diese auch individuell einstellen. Deswegen sollten Sie »_EsetShift« so selten wie möglich verwenden.
XBIOS 81: _EgetShift
word _EgetShift []
Funktionsweise: Liefert die aktuelle Einstellung des Shiftmode-Registers (siehe Bild) zurück.
XBIOS 82: _EsetBank
word _EsetBank[bankNum]
word bankNum;
Funktionsweise: Setzt die Bank »bankNum« (0-15) als aktive TT-Farbtabelle (CLUT). Diese Funktion spiegelt ebenfalls die aktive Farbtabelle in die ST-kompatible Farbtabelle ab $ff8240. Als Ergebnis liefert die Funktion die bisher aktive Banknummer zurück. Ist »bankNum« negativ, so bleibt das Hardware-Register unverändert.
XBIOS 83: _EsetColor
word _Esetcolor[colorNum,color]
word colorNum,color;
Funktionsweise: Setzt die Farbe mit der absoluten Nummer »colorNum« in der TT-Farbtabelle auf »color«. Als Ergebnis erhalten Sie die alte Farbe zurück. Ist »color« negativ, so bleibt das Farbregister unverändert.
XBIOS 84: _EsetPalette
void _EsetPalette[colorNum,count,palettePtr]
word colorNum,count;
long palettePtr;
Funktionsweise: Setzt die Farbwerte mehrerer aufeinanderfolgender TT-Farbregister. »colorNum« bezeichnet das erste zu setzende Farbregister und »count« gibt die Anzahl der Register an. Die Farben liegen in einem Wortfeld, auf das »palettePtr« zeigt.
XBIOS 85: _EgetPalette
void _EgetPalette[colorNum,count,palettePtr]
word colorNum,count;
long palettePtr;
Funktionsweise: Kopiert die Inhalte von aufeinanderfolgenden TT-Farbregistern in das Wortfeld »palettePtr«. »colorNum« ist das erste zu kopierende Farbregister, »count« entspricht der Anzahl. Beachten Sie, daß »palettePtr« auf eine gerade Adresse liegen muß.
XBIOS 86: _EsetGray
word _EsetGray[switch]
word switch;
Funktionsweise: Über diese Funktion bestimmen Sie, wie der Video-Chip die TT-Farbtebelle (CLUT) interpretieren soll. Ist »switch« Null, so verwendet der Video-Ship die Inhalte der Farbregister als Farbdaten, d. h. jeweils 4 Bit für die drei Grundfarben. Ist »switch« ungleich Null, so ignoriert der Video-Chip das obere Byte der Farbregister und das untere Byte repräsentiert eine von 256 Graustufen. Die Funktion gibt stets den alten »switch«-Wert zurück. Ist »switch« negativ, so bleibt das Hardware-Register unverändert.
XBIOS 87: _EsetSmear
word _EsetSmear[switch]
word switch;
Funktionsweise: Schaltet den Video-»Schmier«-Modus an bzw. aus. Unter »schmieren« (engl, smear) ist beim TT der Effekt gemeint, daß bei der Bilddarstellung die Farbnummer 0 durch die letzte Farbnummer ungleich 0 ersetzt wird. Ist »switch« Null, so ist die Darstellung normal, anderenfalls kommt es zum Schmiereffekt.
PROGRAMMHEADER-IMFORMATIONEN
| Bit | Bedeutung |
|---|---|
| 0 | Fastload-Flag |
| 1 | Programm-Lade-Flag |
| 2 | Malloc-Flag |
| 3-11 | unbenutzt |
| 12-15 | TPAsize (0-15) |
Tabelle. Das Langwort mit Offset $16 im Programmkopf gibt Auskunft, wie TOS das Programm und seine Speicherzuordung behandeln soll
Martin Backschat