Atarium: Medley im TT-RAM
Bereits vor der Markteinführung der TT-Rechnerreihe von Atari stand für Eingeweihte fest, daß eine beachtliche Zahl von ST-Programmen Probleme mit dem Elite-Rechner bekommen würde: In erster Linie unsauber programmierte Software, die auch auf einem ST mit Grafikkarte kaum lauffähig ist.
Von dieser Kritik ausgenommen sind hardwarenahe Programme, wie z.B. »Templemon« und »Sysmon«, von denen erste Testversionen bereits vorliegen. Drei verschiedene RAM-Gattungen im TT verursachen aber immer wieder kleinere Probleme.
Das Grafiksystem, »ACSI-DMA« und »DMA«-Sound arbeiten ausschließlich in einem RAM-Bereich, der voll kompatibel zum gewohnten ST-RAM ist Die Neuentwicklung von Atari ist mit 2 oder 4 MByte dieses RAMs ausgestattet. Die CPU teilt sich den Zugriff auf das eigentliche TT-RAM (Fast-RAM) mit fast keinem anderen Chip. Es ist als »Nibble-Mode« ausgelegt und gestattet dem 68030er, seinen Cache im »Burst-Modus« zu füllen. Der »DMA«-Betrieb ist über den »SCSI«-Bus gewährleistet. Grafik, »DMA-Sound« und »ACSI-DMA« hingegen nicht. Weiteres RAM kann auch über den »VMEbus« angeschlossen werden. Dieser Speicher ist jedoch langsamer als das Fast-RAM
Die aktuellen TT-Versionen stellen eine bunte Mischung von Speicherkonfigurationen bereit: Neben Geräten mit 4 MByte ST-RAM, gibt es Konfigurationen mit 2 MByte ST-RAM und 4 MByte Fast-RAM. Zusätzlich sind TTs mit 2 MByte ST-RAM und 6 MByte Fast-RAM aufgetaucht.
Interessant ist es nun, festzustellen, in welchem RAM eine existierende Adresse liegt: Wenn die obersten 8 Bit der Adresse gleich Null sind, befindet sie sich im ST-RAM. Folglich existiert im ehemaligen 24-Bit-Adreßraum nur ST-kompatibler Speicher. Vor einer Beschreibung der Auswirkungen des geteilten RAM auf die Software, eine Reihe Zahlen: Zum Test wurde eine große Textdatei mit dem Programm »LHARC« komprimiert. Im ST-RAM ein Vorgang, der stattliche 31,8 Sekunden beansprucht. Das Fast-RAM bewältigt die gleiche Arbeit in nur 23,5 Sekunden. Bei ausgeschaltetem CPU-Cache erhöhen sich diese Zeiten auf 56,8 bzw. 36,8 Sekunden. Die Zeitvorteile, die sich durch das Fast-RAM ergeben sind erheblich: Allerdings laufen unsauber programmierte (ebenso wie auch wenige sauber programmierte) Programme, nicht über diesen Speicher. Zur Vermeidung von Schwierigkeiten läßt sich eine allgemeine Regel aufstellen: Programme sollten nicht
- die Anfangsadresse des Bildspeichers auf eine Adresse im Fast-RAM setzen
- DMA-Sound aus dem Fast-RAM erzeugen
- ACSI-DMA über das Fast-RAM abwickeln (dies gilt z. B. für Festplattentreiber und Treiber für die Atari-Laserdrucker).
Wie hat nun Atari-Programmierer Allan Pratt dieses Problem gelöst? Bereits seit TOS 1.4 kann man durch ein reserviertes Feld im Programmkopf festlegen, wie das Programm von Pexec() geladen wird. Es handelt sich dabei um das »Fastload-Bit«. Dieses Konzept wurde konsequent beim TT-TOS 3.1 (GEM-DOS 0.25) weiterverfolgt [1]. Mit einem weiteren Bit kann man festlegen, ob das Programm im Fast-oder ST-RAM gestartet werden darf. Normalerweise ist dieses Bit nicht gesetzt. Ohne Eingriff nutzt kein Programm das Fast-RAM des TT. Ein weiteres Bit erlaubt Speicheranforderungen aus dem Fast-RAM (Malloc()-Anforderungen). Es gibt durchaus Programme, die im Fast-RAM laufen, falls der mit »Malloc()« angeforderte Speicher im ST-RAM liegt.
Regulierung durch Dateikopf
Nicht ganz unproblematisch ist, wenn das ST-RAM mehr Speicher bereitstellt als das Fast-RAM. In diesen Fällen benötigt GEMDOS zusätzliche Informationen. Zur Problemlösung hat Atari das »TPA-Größen-Feld« in den obersten 4 Bit des »Long« eingerichtet. Dort liegen auch die anderen drei Flags. Das Größenfeld wird nur dann ausgewertet, wenn Programme ins Fast-RAM geladen werden dürfen und mehr ST-RAM als Fast-RAM vorhanden ist. Die 4 Bit (Wert 0-15) werden dann folgendermaßen analysiert: Der Speicherplatz, den das Programm mindestens benötigt, wird mit der Formel »(Wert + 1) x 128 KByte« ermittelt. Sind diese 4 Bit gelöscht, kann davon ausgegangen werden, daß nicht mehr als 128 KByte im Fast-RAM gebraucht werden.
GEMDOS addiert die ermittelte Größe zu den Größen der drei Programmsegmente »Text«, »Data« und »BSS« und entscheidet, ob das Programm ins Fast-RAM geladen wird. Sind alle 4 Bit gesetzt, kommt man über die Auswertung der Formel auf einen Wert von 2 MByte. Daß dies nicht durch neue GEMDOS-Funktionen, sondern über den Dateikopf geregelt wird, hat zwei Gründe: TT-Besitzer können ältere Programme auch am neuen Rechner optimal nutzen. (Trotzdem sollten Entwickler bei neuen Programmversionen Flags passend setzen). Wichtig ist auch, daß die neuen Flags eindeutig Eigenschaften des jeweiligen Programms beschreiben und nichts mit dem aufrufenden Programm zu tun haben.
Beim TT-TOS kann innerhalb eines Programms die Speicherinstallierung beeinflußt werden. Das Verfahren ist jedoch nur bei wenigen Programmen interessant. Etwa bei Laserdruckertreibern, die direkt den »DMA«-Transfer über die »ACSI«-Schnittstelle vornehmen. Hier bietet sich an, den Treiber im Fast-RAM zu allozieren und nur den Puffer für den DMA-Transfer im ST-RAM zu reservieren. Dafür gibt es ab GEMDOS-Version 0.25 (mit »Sversion()« testen!) die Funktion »Mxalloc()«, bei der der Speichertyp genau angegeben werden kann.
Noch ist nicht offiziell dokumentiert, wie GEMDOS die Informationen aus dem Programm-Header detailliert weiterverarbeitet. Nachforschungen des Turbo-Assembler-Entwicklers Markus Fritze ergaben, daß es in diesem Zusammenhang einen neuen Pexec()-Modus #7 gibt. Die Flags werden innerhalb der Basepage festgehalten. Mehr dazu, wenn es die endgültigen Release Notes zum TOS 3.1 erscheinen.
Ausgezeichnete Ausgangslage
Unklar bleibt weiterhin, wie man das RAM auf einer »VMEbus«-Karte vom normalen Fast-RAM unterscheidet. Prinzipiell sind beim VME-RAM, im Gegensatz zum Fast-RAM, keine »SCSI-DMA«-Zugriffe möglich. Der Zugriff auf den Speicher ist generell langsamer. Unwahrscheinlich, daß ausgerechnet der VME-Slot für eine Speichererweiterung benutzt wird - immerhin kann man den TT auch mit einfacheren Mitteln bis auf 26 MByte erweitern.
Soviel zum Fast-RAM des TT. Den meisten Messebesuchern dürfte eine Demonstration entgangen sein, die für die ST/TT-Programmierung mehr Auswirkungen haben kann, als bisherige Verbesserungen am Betriebssystem: Auf einem TT war farbige Schrift aus bekannten Schriftenfamilien in beliebigen Drehwinkeln zu sehen. Die Hauptarbeit verrichtete dabei kein Programm, sondern ein »FSMGDOS« (Font Scaling Mechanism GDOS), dessen Entwicklung zum Jahreswechsel abgeschlossen sein soll. Verschiedene Methoden zur Einbindung von Zeichensätzen ins Betriebssystem halten momentan die gesamte Branche in Atem. Wünschenswert ist, daß, unabhängig von Bildschirmen und Druckern, gleiche Zeichensätze benutzt werden können. Microsoft und Apple beabsichtigen gemeinsam ein Format zu entwickeln. Auch Postscript-Entwickler Adobe hat mittlerweile, um seine Marktbedeutung halten zu können, das Geheimnis seines Font-Formats gelüftet. Ohne viel Aufsehens arbeitet Atari an einer neuen GDOS-Version, in der die von Ultrascript bekannte Font-Technologie wie bei Ultrascript zum Einsatz kommt. Wichtige Merkmale sind: Zusätzlich zu den bekannten Rasterzeichensätzen können frei skalierbare Ultrascript-Zeichensätze verwendet werden. Bei der Konfiguration werden die Zeichengrößen bereits festgelegt. Denn viele Programme stürzen ab, wenn man ihnen einen Zeichensatz in beliebig vielen Größen vorsetzt. Neue Programme können über eine neue VDI-Funktion alle Zeichensätze in allen Größen und Rotationswinkeln ansprechen. Mit neuen Druckertreibern kann auch FSMGDOS alle Zeichen in optimaler Auflösung zu Papier bringen. Zusätzlich zeichnet das neue GDOS auch Bezierkurven. Die unterstützt auch das neue »AMCGDOS 4.0«, das von der Hamburger Firma »Scilab« in Verbindung mit »Scigraph 2.0« geliefert wird. Wenn man in Zukunft tatsächlich auf allen VDI-Geräten Ultrascript-Zeichensätze in verschiedenen Größen benutzen kann, hat Atari eine ausgezeichnete Ausgangslage. »Microsoft«, »Apple« und »NM« sind diesmal anscheinend auch nicht weiter als die Entwickler aus Sunnyvale.
(em)
Quellennachweis:
[1] The TT Companion - Developer's Notes for the Atari TT 030, Atari Corporation 1990
Abbildung 1: Neue Definition der Programmflags
Bit 0: Fastload-Flag wie in TOS 1.4 (GEMDOS 0.21), beim Laden des Programms wird nur die BSS und nicht die gesamte TPA gelöscht.
Bit 1: Das Programm wird nach Möglichkeit in das Fast-RAM geladen.
Bit 2: Malloc()-Aufrufe des Programms werden nach Möglichkeit mit RAM aus de. Fast-RAM befriedigt.
Bit 3-27: Reserviert
Bit 28-31: TPA-Größenfeld (0-15 bedeutet: Programm belegt 128K - 2048K)
Anmerkung: ab Version 1.2 des Shareware-Desktops Gemini kann man dort die Programmflags mittels 'chmod' einstellen! Registrierte Gemini-Anwender bekommen Gemini 1.2 automatisch zugesandt.
Abbildung 2: die neue GEMDOS-Funktion Mxalloc
Funktionsnummer: 0x44 (68)
void *Mxalloc (long amount, int mode);
Mxalloc funktioniert genau wie Malloc, der zusätzliche Parameter bedeutet:
mode Bedeutung
0 nur aus dem ST-RAN
1 nur aus dem Fast-RAM
2 egal, aber lieber aus dem ST-RAM
3 egal, aber lieber aus dem Fast-RAM
Für 'amount = -1' wird die Größe des größten Speicherblocks geliefert, den man in dem entsprechenden Modus erhalten kann. Mxalloc() ist genau dann verfügbar, wenn die GEMDOS-Version (mit Sversion() ermitteln) größer oder gleich 0.25 ist.
Julian F. Reschke