Atarium: Vorhang auf für die Keksdose
Ein neues Verfahren, um Informationen im System zu veröffentlichen.
Atari achtete bei der Entwicklung des TT auf die Hardwarekompatibilität zum ST. Die Inkompatibilitäten zwischen dem bewährten 68000- und dem neuen 68030-Motorola-Prozessor sind zwar gering, aber nicht zu verhindern - die Entwickler der PAK (Austausch-Karte mit 68020-Prozessor) wissen ein Lied davon zu singen.
Ein Problem haben die Softwareentwickler bei Atari bereits im TOS 1.6 des STE in den Griff bekommen: Die leidigen Line-F-Aufrufe im AES sind verschwunden - mit dem Resultat, daß das AES deutlich schneller und nur geringfügig größer geworden ist. Ein anderes Problem ist jedoch schwieriger zu umschiffen: Bei TRAPs legt der 68030er 2 Byte mehr auf den Stack als der 68000er. Ein Programm, das auch auf dem TT oder mit 68020ern ausgerüsteten STs laufen soll und eigene TRAP-Dispatcher installieren möchte, muß sich also zunächst darüber informieren, auf welchem Prozessor es läuft. Praktisch wäre natürlich eine Systemvariable, die genau dies anzeigt. Und tatsächlich haben die Programmierer in Sunnyvale daran gedacht und eine bislang unbenutzte Systemvariable für diesen Zweck reserviert. Bereits unter TOS 1.6 testet der Computer beim Einschalten, welcher Prozessor eingesetzt ist und berücksichtigt dies dann auch bei allen TRAP-Dispatchern. TOS 1.6 sollte also in der im STE eingebauten Version auch auf dem 68020 und dem 68030 laufen. Gleiches gilt selbstverständlich für die Vorversion des TOS 3.0, die Besucher der Atari-Messe auf den ausgestellten TTs bereits begutachten konnten. Und auch neue Versionen von Atari-Systemsoftware, beispielsweise der Diablo-Emulator, benutzen diese Systemvariable.
Traurig aber wahr: Atari hat sich leider nicht die Mühe gemacht, diese Systemvariable zu dokumentieren - die Gründe dafür sind mir ziemlich schleierhaft. Es handelt sich offenbar um ein Versehen von Atari. Deshalb hole ich an dieser Stelle die Dokumentation nach: Der verwendete Prozessor legt bei Traps 6 Byte auf den Stack, wenn die Systemvariable (16 Bit) bei Adresse $59E Null ist, ansonsten 8 Byte. Dank dieser Angabe ist es einfach, seine eigenen Trap-Dispatcher portabel zu halten.
Im Zuge des frischen Winds bei Atari haben sich die Entwickler im TOS 1.6 nicht nur darauf beschränkt, kleinere Fehler zu beseitigen und die veränderte Hardware des STE anzusprechen. Diese Änderungen beschränken sich allerdings nur auf die gestiegene Zahl der Farbtöne. Wie schon erwähnt, ist TOS 1.6 nun offenbar 68030-fest.
Ganz neu und dazu noch abwärtskompatibel zu allen alten TOS-Versionen ist der nagelneue »Cookie Jar« (zu deutsch »Keksdose«). Was hat es damit auf sich? Was ist ein »Cookie«? Ein Cookie ist in der Atari-Nomenklatur ein Identifikationscode, der für alle Programme verschieden sein sollte und genau das gleiche Format wie eine XBRA-Kennung hat - 4 Byte, die eine ASCII-Zeichenfolge ergeben sollten. Daher mein Aufruf, künftig alle verwendeten Cookies bei mir zu melden, damit ich sie an de XBRA-Liste anfügen kann. Apropos XBRA-Kennungen, legen Sie bei der Registrierung künftig bitte eine Liste der verbogenen Vektoren und eine Angabe für die Bezugsquelle des Programms bei. Jeder Cookie enthält einen 32-Bit-Wert, den das jeweilige Programm beliebig nutzen kann - z. B. als Zeiger auf eine Struktur oder auf einen String. Hierzu drei Anwendungsbeispiele:
-
MACCEL2, der Mausbeschleuniger von Atari, trägt in den Cookie Jar einen Zeiger auf eine interne Struktur ein, mit deren Hilfe Sie im laufenden Betrieb seine Parameter verstellen können. MACCEL2 benutzt allerdings einen Cookie, der nicht aus ASCII-Zeichen besteht - wohl deshalb, weil MACCEL2 vor der Definition des Cookie Jars entstanden ist.
-
Gemini, der Shareware-Desktop, trägt ab Version 1. 1 seine Kennung GMNI ein. Damit unterstützt es andere Programme dabei, festzustellen, ob Gemini resident ist. Der Wert des Cookies ist vorläufig unbenutzt, sozusagen also ein »binärer« Cookie.
-
Das BIOS trägt ab TOS 1.6 die sogenannten System-Cookies ein, mit deren Hilfe Sie z. B. feststellen, was für ein Videochip installiert ist. Dazu jedoch später mehr.
Nun zum Format des Cookie Jar: Der Zeiger bei Adresse $5A0 (»_p_cookies«) ist entweder Null - dann ist noch kein Cookie Jar installiert - oder er zeigt auf eine Tabelle von Paaren von 32-Bit-Werten. Im ersten Eintrag der Paare steht jeweils die Identifikation in Form von vier ASCII-Zeichen und im Anschluß der Wert des Cookies.
Beachten Sie dabei, daß Identifikationen, die mit dem Zeichen »_« beginnen, ausschließlich für Atari reserviert sind. Das Ende der Liste zeigt ein »Nullcookie« an ($00000000), der als Wert die maximale Anzahl von Einträgen im Cookie Jar enthält. Ab TOS 1.6 installiert das BIOS automatisch einen Cookie Jar mit einer Reihe von vordefinierten Einträgen (siehe Textkasten).
Was macht man nun, wenn man noch kein TOS 1.6 besitzt? Auch hierzu gibt uns Atari in den »STE TOS Release Notes« einen Hinweis. Ist »_p_cookies« noch Null, dann müssen Sie eben selbst einen leeren Cookie Jar anlegen, wie es z. B. auch MACCEL2 macht. Da TOS-Versionen unter 1.6 »_p_cookies« beim Reset noch nicht initialisieren, müssen Sie ferner selbst dafür sorgen. In Listing 1 demonstrieren wir die von Atari vorgeschlagene Methode zur Verwendung des Reset-Vektors.
Wie trägt man nun einen eigenen Cookie in die Liste ein? Dazu stellen Sie am besten erst einmal fest, wie lang die Liste eigentlich ist. Um dies herauszufinden, suchen Sie vom Beginn der Liste an nach dem Nullcookie, dessen Wert die Länge der Liste angibt. Da nun eben dieser Nullcookie auch das Ende der Liste anzeigt, müssen Sie im Prinzip dort Ihren eigenen Cookie hineinkopieren und den Nullcookie um einen Eintrag weiterschieben.
Ist die Liste allerdings schon voll, dann bleibt nichts anderes übrig, als Platz für eine neue und längere Liste zu belegen, die alten Einträge dorthin zu kopieren und »_p_cookies« die neue Adresse zuzuordnen. Dies funktioniert logischerweise nur in Programmen, die sich nach ihrem Aufruf mittels »Ptermres()« resident im Speicher verankern. Daher sollten Sie beispielsweise in Accessories die Finger von »_p_cookies« lassen, denn diese werden bei einem Wechsel der Bildschirmauflösung neu geladen. Wenn Sie schon dabei sind, schaffen Sie gleich mehr Platz als für einen zusätzlichen Cookie.
Da die Cookie Jar-Liste im Speicher verschiebbar ist, sollte kein Programm bei Zugriffen auf die Cookie-Jar einmal bestimmte feste Adressen benutzen: Schließlich könnte auch jemand auf die Idee kommen, die Cookies zu verschieben oder in irgendeiner Weise umzusortieren, denn auch das ist erlaubt.
Bleibt noch die Frage offen: Wie entfernt man einen Cookie wieder? Leider reicht es nicht, einfach den bestehenden Eintrag zu löschen, denn was soll schon ein leerer Eintrag darstellen? Also kommen Sie nicht umhin, alle folgenden Cookies einschließlich des Nullcockies innerhalb des Cookie Jar um einen Eintrag nach vorne zu kopieren. Das ist zwar nicht sonderlich bequem, aber so oft werden Sie einen Cookie ja normalerweise nicht entfernen.
Wesentlich einfacher ist es natürlich, lediglich den Wert eines Cookie-Jar-Eintrags abzufragen. Im Listing 2 finden Sie dazu eine Beispielfunktion in ANSI-C. Bleibt die Frage, was aus dem XBRA-Verfahren wird, nachdem Atari Amerika mit dem Cookie Jar endlich selbst etwas in diese Richtung auf die Beine gestellt hat?
-
Das XBRA-Verfahren ist und bleibt eine ideale Methode, um Ketten von vektorverbiegenden speicherresidenten Programmen zu verwalten. Das Verfahren bedeutet für den Programmierer praktisch keinen zusätzlichen Arbeitsaufwand und sollte deshalb wie bewährt weiterbenutzt werden.
-
Der Cookie Jar ist vor allem dann von Vorteil, wenn ein Programm Informationen im System »öffentlich« zugänglich machen möchte - wie z. B. MACCEL2 seine Schnittstelle zum Ändern der Konfiguration. Das XBRA-Verfahren funktioniert hierfür nur, wenn sich auch wirklich alle Programme daran halten. In solchen Fällen ist der Cookie Jar deutlich besser geeignet.
Ein Nachtrag zur Januar-Ausgabe 1/90, in der wir über den Fehler beim Anlegen von virtuellen Workstations im VDI berichteten: Karsten Isakovic - Autor der Hyperscreen-Software - hat ein Patch-Programm geschrieben, das den Fehler korrigiert. Das Programm »VDI_FIX.ARC« finden Sie beispielsweise in der Mailbox Maus Münster.
(ba)
Quellennachweis:
[1] STE TOS Release Notes, Atari Corporation, 11.10.1989
Listing 1: Dieses Assembler-Programm demonstriert die Initialisierung und den Umgang mit dem Cookie Jar.
Listing 2: So fragen Sie einen bestimmten Cookie in C ab.
Tabelle 1: Seit dem TOS 1.6 des STE installiert das BIOS den CookieJar im System
| Übersicht aller vom BIOS installierten Cookies | |
| _CPU |
Hat den Wert 0, 10, 20 oder 30 für Computer mit 68000, 68010, 68020 und 68030. |
| _VDO | Versionsnummer der Videohardware. Erstes Wort ist der Vorkommawert, das zweites Wort der Nachkommawert. Bislang definiert: 0, 0: ST 1, 0: STE 2, 0: TT |
| _SND | Bit-Tabelle, die die vorhandenen Soundmöglichkeiten beschreibt. Bit 0: GI/Yamaha-Soundchip wie in bisher allen bekannten Computern. Bit 1: Stereo-DMA-Sound (wie beim STE und dem TT). |
| _MCH | Beschreibt den benutzten Computertyp (erstes Wort: Stelle vor dem Komme,
zweites Wort: Stelle nach dem Komma). Belegung: 0, 0: 520, 1040ST und ähnliche |
| _SWI | Werte der »Konfigurationsschalter«, falls vorhanden. |
| _FRB | Da das »FastRAM« des TT für normale DMA-Transfers nicht benutzbar ist, legt, das BIOS auf diesem Computer einen 64 KByte großen Puffer an, dessen Adresse sie hier vorfinden. |
Julian F. Reschke