Nun ist es endlich soweit - die von vielen lang erwartete neue Version unseres Lieblings-Betriebssystems TOS ist fertig. Das neue TOS 1.4 wurde auf der Düsseldorfer ATARI-Messe offiziell vorgestellt und endgültig freigegeben. Dies ist Grund genug, es auch unseren Lesern vorzustellen.

TOS 1.4 hört auch auf den Decknamen “Rainbow TOS", da das ATARI-Zeichen in der “Desktop info"-Dialogbox in einer farbigen Animation (nur im Farbmodus) zu sehen ist, die wohl an einen Regenbogen erinnern soll (engl. “rainbow" = Regenbogen). Diese offizielle Version datiert vom 6.4.1989 und ist damit zu unterscheiden von den “Beta-Versionen" des Jahres 1988 und dem “Messe-TOS" vom 22.2.1989, das auf der letzten CeBIT zu sehen war.

Erfreulicherweise gibt es für Software-Entwickler auch eine Dokumentation, in der Änderungen, Fehler und besondere Programmierhinweise aufgeführt sind. Diese Doku ist zwar nicht ganz vollständig und fehlerfrei, aber bietet wesentlich mehr, als man sonst von ATARI gewohnt ist. Überhaupt ist die Unterstützung der Software-Entwickler besser geworden, als sie es früher einmal war. Trotzdem konnte ich es nicht lassen, mir das TOS (speziell BIOS und GEMDOS) ein wenig unter der Lupe anzusehen, sprich zu disassemblieren und recompilieren.

Heute möchte ich Ihnen die Ergebnisse bezüglich des BIOS mitteilen, und zwar in drei Stufen: für Anwender, Programmierer und die TOS-Spezialisten, die ihren Computer bis in die letzten Eingeweide kennen möchten. In den nächsten Ausgaben der ST Computer beschäftige ich mich dann intensiv mit den Neuerungen beim GEMDOS, in Anlehnung und als Ergänzung zur GEMDOS-Serie “Auf der Schwelle zum Licht" (ST 1/88-11/88). Auf die für Nicht-Programmierer interessanteren Verbesserungen am Desktop wird in dieser Zeitschrift an anderer Stelle eingegangen.

Für den Anwender

Kommen wir also zunächst zu den Änderungen, die für den Anwender interessant sind. Bekanntlich gibt es die sogenannten boot-fähigen Disketten, d.h. Disketten, von denen beim Reset automatisch ein kleines Programm geladen wird, das allerlei nützliche Dinge tun kann. Dazu zählen z.B. der “TOS-Loader" von ATARI, mit dem ein RAM-TOS von Diskette gebootet werden kann, Programme, die einem das Einstellen der Systemuhr erlauben oder Hinweise über die Diskette ausgeben (Aladin). Es gibt vor allem bei Spielen sogar Boot-Sektor-Programme, die gleich das eigentliche Programm starten (Auto-Start-Disketten). Am verbreitetsten unter den Boot-Programmen sind aber wohl die “Boot-Sektor-Viren", über die wohl schon genug geschrieben wurde.

Das Laden und Starten dieser Boot-Programme geschah aber bisher nur beim Kaltstart (d.h. nach dem Einschalten des Rechners) oder wenn keine weiteren boot-fähigen Laufwerke vorhanden waren (Harddisk, EPROM-Disk, reset-residente RAM-Disk). Dies ist nun anders, da jetzt bei jedem Reset auf jeden Fall versucht wird, ein Boot-Sektor-Programm von Laufwerk A: zu laden. Dies vereinfacht die Benutzung der oben erwähnten Auto-Start-Disketten, erhöht aber auch die Virengefahr. Ferner sollte man nun immer eine Diskette in A: haben, wenn man nicht von Diskette bootet, da der Boot-Vorgang sonst unnötig lange dauert (wegen des versuchten Zugriffs auf eine nicht vorhandene Diskette).

Beim Booten von Harddisk (oder anderen DMA-Geräten) wird nun beim Lesen des Boot-Sektors ein zweiter Versuch gemacht, falls beim ersten ein Fehler auftrat. Ausgenommen ist der Fall, daß keine Harddisk angeschlossen ist; dann wird weiterhin nur ein Leseversuch gemacht.

Eine wichtige und schwierige Aufgabe des TOS ist die sichere Erkennung von Diskettenwechseln, da sonst sehr leicht Daten auf Disketten zerstört werden können. Bei Benutzung eines physikalischen Laufwerks als zwei logische Laufwerke, was zur bekannten häufigen Aufforderung “Bitte Disk X: in Floppy A: einlegen" führt, konnte es passieren, daß ein Diskettenwechsel nicht erkannt wurde, wenn er und die Bestätigung dieser Aufforderung sehr schnell (unter 1,5 Sekunden) erfolgten. Dieser Mangel ist nun behoben.

Auch an der Tastaturbehandlung wurde einiges geändert. So kann ein Reset nun endlich durch Tastendruck, nämlich durch CONTROL-ALTERNATE-DELETE, ausgelöst werden. Dabei wird ein Warmstart durchgeführt, d.h. reset-residente RAM-Disks usw. bleiben erhalten. Auch ein Kaltstart ist möglich, wenn zusätzlich noch die rechte SHIFT-Taste gedrückt wird. Dabei wird fast der gesamte Speicher gelöscht, so daß dies vorher gut überlegt sein will.

Die Tastenwiederholung wurde leicht modifiziert. Wenn man eine Taste gedrückt hielt (z.B. ’a’), bis die Tastenwiederholung ansprach, und dann eine weitere betätigte (z.B. ’s’), erschien nur ein 's', und die Tastenwiederholung blockierte, bis mindestens eine der Tasten losgelassen und eine weitere gedrückt wurde. Nun wird auch das ‘s’ automatisch wiederholt, bis eine weitere Taste gedrückt wird, usw.

Für den Programmierer

Auch für den Programmierer gibt es einige Neuigkeiten. Da wären zunächst einmal eine geänderte und eine neue XBIOS-Funktion. Die neue XBIOS-Funktion Floprate (Nummer 41) erlaubt das Ermitteln und Verstellen der Floppy-Seek-Rate (Spurwechselzeit), und zwar für jedes Laufwerk einzeln. Dies ging bisher nur mit bestenfalls halblegalen Methoden (s. [1], Kapitel 8.2.). Warum ATARI die XBIOS-Nummer 40 unbenutzt gelassen hat, bleibt wohl ein Geheimnis. Die Deklaration in C sieht so aus:

Für die Nicht-C-Programmierer: Die Funktion hat zwei 16-Bit-Integer-Parameter und liefert einen 32-Bit-Integer-Wert zurück. Der erste Parameter drive gibt das Laufwerk an (0 oder 1, andere Werte sind zu vermeiden), der zweite die neue Seek-Rate. rate ist dabei genauso wie die Systemvariable i ($440) kodiert. Werte von 0 bis 3 stehen dabei für Seek-Raten von 6, 12, 2 bzw. 3 Millisekunden.

Die XBIOS-Funktion Rsconf wurde erweitert und besser dokumentiert. Übergibt man als ersten Parameter (Baud-Rate) den Wert -2, liefert die Funktion die mit Rsconf eingestellte Baud-Rate zurück. Wenn der MFP-Chip durch direkten Zugriff programmiert wird, bemerkt dies

Rsconf nicht und liefert einen falschen Wert. Die restlichen Parameter sind bei diesem Aufruf beliebig.

Rsconf hat laut ATARI-XBIOS-Dokumentation keinen Rückgabewert, aber schon immer wurden die MFP-Register UCR, TSR, RSR und UDR vor dem Rsconf zurückgeliefert (außer bei einer “Baud-Rate” von “-2”). Dabei sind alle vier Register in einem Langwort zusammengepackt (UCR im höchstwertigen Byte, usw.). Die Rainbow-TOS-Dokumentation segnet diese nun ab, doch spricht sie dabei von den Registern SCR, UCR, RSR und TSR. Diese Bezeichnungen wären auch sinnvoller, da dies die Register sind, die man mit Rsconf auch setzen kann.

Protobt soll “IBM-kompatiblere” Boot-Sektoren erzeugen. Die einzige Änderung, die ich feststellen konnte, ist ein verändertes Media-Byte im Boot-Sektor bei einseitigen 80-Track-Disketten. Statt $F8 steht hier nunmehr $F9, obwohl eigentlich unter PC-DOS $F8 vorgesehen ist ([1]). Da ich zu wenig von PC-DOS verstehe, kann ich nicht sagen, ob das ein neuer Fehler oder tatsächlich eine Verbesserung ist. Um volle MS-DOS-Kompatibilität zu erreichen, sollen die ersten drei Bytes im Boot-Sektor $E9,$00,$4E sein. Der eigentliche Fortschritt besteht aber in einer verbesserten Formatierroutine des Desktops, die das Media-Byte in der FAT und die ersten drei Bytes im Boot-Sektor richtig setzt.

Die “Bömbchen”-Routine, die unerwartete Exceptions “behandelt”, terminiert das aktive Programm nun mit Pterm(-1) statt mit Pterm(0), so daß das übergeordnete Programm 0x0000ffff von Pexec zurückbekommt.

Eigene Tastatur-Interrupt-Routinen standen immer vor dem Problem, “normale” Tastendrücke von aus mehreren Bytes bestehenden “Paketen” (z.B. Maus-Bewegungs-Paket) unterscheiden zu müssen. Am Offset $24 ab dem von Kbdvbase zurückgelieferten Zeiger fand sich in allen TOS-Versionen ein Byte-Flag, das anzeigt, ob gerade ein aus mehreren Zeichen bestehendes “Paket” vom Tastaturprozessor erwartet wird. Ab nun ist seine Lage (dieser Offset) offiziell dokumentiert.

Eigene Tastatur-Interrupt-Routinen. die sich in den ikbdsys-Vektor einklinken und Tastendrücke einer “Sonderbehandlung” unterziehen wollen, sollten Bytes nur berücksichtigen, wenn das Flag Null ist.

Es wird vom BIOS auf ungleich Null gesetzt, wenn ein Header-Byte eines “Paketes” empfangen wurde, und ist wieder Null, wenn der Empfang des “Pakets” beendet ist. Wenn man das Flag abfragen möchte, bevor man seine Interrupt-Routine installiert, sollte man zuerst solange warten, bis es Null wird, dann das Interrupt-Level (IPL) der CPU auf 7 setzen. und, falls das Flag nun schon wieder gesetzt ist, den IPL wieder zurücksetzen und erneut warten. Ansonsten kann ikbsys neu gesetzt und der IPL restauriert werden. So schlägt es ATARI vor. Ich würde zusätzlich noch eine Timeout-Abfrage einbauen, um eine Endlosschleife zu verhindern, falls das “Paket” aus irgendwelchen Gründen nicht vollständig gesendet wird bzw. ankommt.

Hier noch einige Erklärungen zur verbesserten Diskettenwechselerkennung, die oben schon erwähnt wurde. Bei jedem Diskettenzugriff merkt sich das BIOS die aktuelle Systemzeit. Die Mediach-Routine meldet nun, wenn es eigentlich einen “unsicheren” Wechselstatus festgestellt hat, trotzdem ein “kein Wechsel”, wenn seit dem letzten Zugriff nicht mehr als eine bestimmte maximale Zugriffszeit vergangen ist. Es geht also davon aus, daß “schnelle” Diskettenwechsel (kürzer als die maximale Zugriffszeit) nicht möglich sind. Dies spart das zu häufige Lesen des Boot-Sektors bei schreibgeschützten Disketten (wo ein unsicherer Status ständig auftritt).

Bisher wurde zur Zeitmessung der 200-Hz-Zähler (_hz_200) benutzt, nun wird frclock genommen (warum nur?). Daher ist die maximale Zugriffszeit jetzt von der Bildwiederholfrequenz abhängig. Sie liegt bei 1.2 s, 1,37 s bzw. 1,64 s für 71 Hz, 60 Hz bzw. 50 Hz Bildwiederholfrequenz (bisher immer 1,5 s). Daher wird in hdvjnit die interne Variable für die maximale Zugriffszeit auf 82 statt bisher 300 gesetzt. Die eigentliche Verbesserung besteht nun darin, daß die gemerkte letzte Zugriffszeit beim Wechsel zwischen den logischen Laufwerken A: und B: nach der Aufforderung “Bitte Disk X: in Floppy A: einlegen” auf Null gesetzt wird. Damit liefert Mediach nach einem solchen Wechsel nun auf jeden Fall den wahren Diskettenwechselstatus zurück; bisher wurde also bei einer Wechselzeit unter 1,5 s der Wechsel von Mediach nicht gemeldet.

BIOS-Listing wesentlich geänderter Routinen

Listings wesentlich geänderter Routinen

Die folgenden Änderungen sind von ATARI nicht dokumentiert worden, aber trotzdem wahr.

Die ESC Y-Funktion des VT52-Emulators zum Setzen der Cursor-Position kontrolliert nun den Spalten- und Zeilenparameter. Bei Werten größer als die maximale Spalte bzw. Zeile wird der Maximalwert benutzt. Bisher wurden beliebige Koordinaten “geschluckt”. Negative Werte werden weiterhin nicht abgefangen.

Die XBIOS-Funktion Gettime blieb bisher in einer Endlosschleife hängen, wenn das vom Tastaturprozessor angeforderte Uhrzeit-Paket nicht ankam. Nun erfolgt nach einer Sekunde ein Timeout, und Gettime liefert dann Null zurück.

Die über die IOREC-Strukturen verwalteten I/O-Puffer für Tastatur, RS232 und Midi durften nur maximal 32 kB groß sein. Jetzt sind sogar 64 kB erlaubt.

Für Leute, die eigene Interrupt-Routinen über die Kbdvbase-Vektoren midisys und ikbdsys einhängen, hat TOS 1.4 noch eine Überraschung parat. Vom BIOS werden die Register D0-D3, A0-A3 und A5 gerettet, so daß man annehmen konnte, daß man diese Register selbst nicht retten muß (dokumentiert ist die Programmierung solcher Interrupt-Routinen ja nirgends). Wer nun A5 verändert hat, guckt ab TOS 1.4 in die Röhre, da A5 nach Beendigung der eigenen Routinen immer Null sein muß. Dies kommt durch die Code-Optimierungen zustande, die ATARI vorgenommen hat.

Neue garantierte Systemvariablen gibt es eigentlich keine. “Eigentlich” heißt, daß die in früheren TOS-Versionen unbenutzte Systemvariable $59E (Wort) beim Reset zwar gelöscht, aber sonst nirgendwo im TOS angesprochen wird. Noch merkwürdiger ist, daß bei der Beta-Version an dieser Stelle stattdessen noch die Systemvariable _bootdev ($446) gelöscht wurde, wozu das auch immer gut sein sollte. Falls dies nicht einfach Unsinn ist, könnte es höchstens sein, daß $59E von einem anderen ATARI-Programm noch benötigt wird (ähnlich dem punptr des Harddisk-Treibers), wer weiß.

Der system header block, der am Anfang des TOS zu finden ist (die Systemvariable _sysbase ($4f2) zeigt darauf), ist nun offiziell dokumentiert (s. Abb. 1). Eine genauere Erläuterung findet sich in [4].

Neu ist allerdings die Dokumentation zu den Konfigurations-Bits. Bit 0 steht hier für NTSC- bzw. PAL-Fernsehnorm, Bits 1 bis 15 beinhalten eine Länderkennung (s. Abb. 2).

Für die Benutzung von p_run aus dem OS-Header ist es wichtig, die Adresse unter TOS 1.0 zu kennen. Bei allen TOS-Versionen außer der spanischen (!) lautet sie $602C, bei der spanischen $873C.

Abb. 1: Der “OS-header” (OSHEADER)

Alte und neue Fehler

Leider hat ATARI einige Fehler im BIOS immer noch nicht beseitigt. BIOS/XBIOS-Aufrufe aus Interrupt-Routinen heraus sind immer noch gefährlich, da die Interrupts während des Rettens der Register in die BIOS save area weiterhin nicht gesperrt werden (s. hierzu [2]).

Der Boot Device-Fehler besteht noch immer. Beim Erstellen der Ur-Environment-Strings wird das Boot-Laufwerk fälschlich mit ‘move.b $446,d0' statt ‘move.w $446,d0’ ermittelt. Beim Laden der Auto-Ordner-Programme ist an einer Stelle eine Stack-Korrektur immer noch falsch (addq #6 statt add #12), was in ungünstigen Fällen zum Absturz führen kann.

Einige Fehler wurden nun zum Feature deklariert, d.h. man muß mit ihnen leben bzw. sie umgehen, wobei auch hier ATARI hilfreich zur Seite steht:

Die Ausgabe-Status-Routinen (Bcostat) für Tastaturprozessor und MIDI-Schnittstelle waren und bleiben vertauscht. Bcostat(4) liefert also nun offiziell den MIDI-und Bcostat(3) den IKBD-Status. Witzigerweise ist dies in der TOS-Doku genau verkehrt herum, also so wie es eigentlich sein sollte, angegeben!

screenpt wird nach dem Setzen der neuen Bildschirmadresse in der VBL-Routine nicht gelöscht. Dies führt zu Komplikationen, wenn parallel mit Setscreen gearbeitet wird (s. [4]). ATARI empfiehlt hier, entweder nur jeweils eine Möglichkeit zu benutzen, oder vor dem Aufruf von Setscreen screenpt auf Null zu setzen. Da aber ein vorher gelaufenes Programm schon screenpt benutzt haben könnte, bleibt einem wohl nichts anderes übrig, als screenpt bei jedem Setscreen zu löschen!

Programme, die sich in den resvector eingehängt haben, können zwar mit 'jmp (a6)’ ins BIOS zurückspringen, doch müssen sie sich dann vorher aus resvector aushängen, da sie sonst erneut aufgerufen werden. Daher hatte ATARI in der Dokumentation zur Beta-Test-Version des TOS 1.4 garantiert, daß ‘jmp $24(a6)’ zum Sprung ins BIOS nach der resvector-Abfrage führt (siehe [4]). Dies ist in der TOS 1.4-Doku wieder verschwunden, vermutlich weil sich damit nur jeweils ein Programm in resvector installieren kann. Nun wird eine andere Methode vorgeschrieben, nach der sich jedes Programm bei der Installation seiner Reset-Routine resvector und resvalid merken soll, um diese Werte, wenn es über resvector aufgerufen wird, wieder zurückzusetzen. Dadurch können mehrere Programme auf diese Weise resident gemacht werden, allerdings müssen sie sich nun auch beim Reset aushängen!

TOS 1.4 sollte dafür sorgen, daß Zeit und Datum zumindest beim Reset nicht verlorengehen, indem es ausnutzt, daß der Tastaturprozessor die Zeit beim Reset nicht vergißt. Für ST-Benutzer, die über keine eingebaute Uhr verfügen, wäre dies eine Erleichterung, da sie die Uhr nur einmal nach dem Einschalten stellen müßten (z.B. mit dem Kontrollfeld-Accessory). Nur wenn die Uhr beim Warmstart nicht sinnvoll eingestellt ist, würde sie auf den bekannten Default-Wert (hier 6.4.1989) gesetzt. Beim Warmstart wird also zunächst geprüft, ob eine eingebaute MEGA-Uhr vorhanden ist, um ihr gegebenenfalls die Priorität zu geben. Diese Abfrage ist falsch programmiert, so daß stets angenommen wird, daß eine MEGA-Uhr vorhanden ist, und somit niemals die Zeit aus der Tastaturprozessor-Uhr übernommen wird. Dokumentiert ist dieses offensichtlich geplante Feature übrigens auch nicht. Vielleicht deshalb, weil man bei ATARI den Fehler nicht finden konnte?!

Abb. 2: Länderkennungen

Beim Überarbeiten der Rsconf-Funktion des XBIOS schlich sich leider ein Fehler ein, der dazu führt, daß der Handshake-Modus sich nicht richtig setzen läßt. Auch ATARI hat dies erkannt und bietet daher ein Patch-Programm, das diesen und einen weiteren Fehler in shel_find korrigiert. Dieser Patch liegt reset-resident von $600-$800 und wird von einem AUTO-Ordner-Programm installiert.

Die TOS-Dokumentation behauptet, das Setzen von ‘RTS/CTS’ würde zum Abschalten jeden Handshakes führen. Für mich sieht das eher so aus, als würde das Setzen von ‘XON/XOFF’ zum Abschalten und das Setzen von ‘RTS/CTS‘ zum Aktivieren von ‘XON/XOFF‘ führen, ich konnte dies aber nicht genau verifizieren. Auch das Patch-Programm liegt mir zur Zeit nicht vor, so daß ich über dessen Funktionsfähigkeit nichts sagen kann.

Kommentiertes BIOS-Listing

Für die Spezialisten unter Ihnen möchte ich noch direkt auf die Änderungen im BIOS eingehen. Generell wurden einige Optimierungen vorgenommen. Der Zugriff auf Systemvariablen wird nun noch häufiger mit der Adressierungsart “Adreßregister indirekt mit 16-Bit-Offset” (bei gelöschtem Adreßregister) statt “absolut lang” vorgenommen. Diese Methode wird außerdem jetzt auch bei den I/O-Adressen ab $FF8000 benutzt. Daraus darf man wohl schließen, daß ATARI immer noch keinen Assembler verwendet, der die “absolut kurz”-Adres-sierung beherrscht. Weiterhin wurden jetzt einige (aber noch nicht alle) “MOVE.X #0,..’’-Befehle durch “CLR.X ..” ersetzt, und andere Kleinigkeiten wurden geschickter programmiert. Prinzipielle Optimierungen gibt es sonst keine.

Zur Analyse habe ich das BIOS bis auf die Hardcopy-Routine disassembliert und mehr oder weniger gründlich mit dem des TOS 1.2 verglichen. Im abgedruckten Listing finden sich alle Routinen, an denen inhaltliche Änderungen vorgenommen wurden (markiert durch ***). Ausgenommen sind nur einige Teile, bei denen lediglich Kleinigkeiten verändert wurden, die hier im Text erwähnt werden. Die Tabelle umfaßt die Anfangsadressen aller wichtigen Routinen, was - zusammen mit einem BIOS-Listing des TOS 1.2, z.B. [3] - eine gute Orientierungshilfe bietet.

Noch nicht erwähnt habe ich bisher einige Kleinigkeiten. In der VBL-Routine wurde zweimal die Monochrommonitor-Detect-Leitung direkt am MFP abgefragt. Da sie sich zwischen den beiden Abfragen geändert haben könnte, wird der MFP nur noch einmal angesprochen; das zweite Mal wird der beim ersten Mal gemerkte Zustand getestet.

Bei der Ausgabe eines Zeichens über die Centronics-Schnittstelle werden alle Interrupts gesperrt, während der Strobe gesendet wird. Damit wird verhindert, daß der Strobe wesentlich länger als üblich (zu lange?) dauern kann.

Beim Test, ob die Hardware-Uhr des MEGA ST vorhanden ist, wird nun auch ein Bus-Error abgefangen. Normalerweise gibt es zwar keinen Bus-Error, wenn auf den Adreßbereich der MEGA-Uhr zugegriffen wird, obwohl diese gar nicht vorhanden ist, aber vielleicht gibt es hier Ausnahmen oder Fehlfunktionen, denen hiermit abgeholfen werden soll.

In den Blitter-Routinen um BUdschirmtreiber die Nummer 0 bis 2) gibt es Schleifen, die warten, bis der Blitter seine Arbeit beendet hat. Bisher sahen die so aus:

Nun wird folgendes gemacht:

Der Unterschied besteht darin, daß bei tas das Testen und Setzen des Bits 7 des Zieloperanden in einem nicht-unterbrechbaren Schreib-Lese-Zugriff des 68000 erfolgt. Beim bset könnte zwischen dem Testen und Neustarten des Blitters z.B. der DMA-Chip die Kontrolle über den Prozessor-Bus übernehmen. Sicherer ist die Verwendung von tas auf jeden Fall: ob es auch praktische Konsequenzen hat. weiß ich nicht.

Ein letztes Wort

So das war’s für heute. Auch wenn ich das BIOS relativ gründlich durchgearbeitet habe, ist dazu sicherlich noch nicht das letzte Wort gesprochen. Warten wir’ s also ab. Festzuhalten bleibt, daß einige wichtige Punkte geändert oder verbessert wurden, anderes unverständlicherweise beim alten geblieben ist. Auch die TOS-Dokumentation ist ganz brauchbar und informativ. Ich kann das “Rainbow-TOS” nur empfehlen, da es einige ganz entscheidende Vorteile bietet, die hier nicht deutlich wurden, da sie hauptsächlich GEMDOS und Desktop betreffen. Bei dieser Gelegenheit möchte ich noch erwähnen, daß ich seit einiger Zeit auch in der MAUS-Mailbox Aachen (0241/154...) zu erreichen bin (bzw. im angeschlossenen MAUS- und FIDO-Net), falls Sie noch Fragen zur GEMDOS-Serie oder dem TOS im allgemeinen haben sollten.

Alex Esser

Literatur:

[1] Brod/Stepper: “Scheibenkleister II". MAXON 1989
[2] Esser: "EXTKEY-Tastaturbelegung einmal anders”, ST-Computer 4/89
[3] Brückmann/Englisch/Gerits: "ST intern", Data Becker 1987
[4] Esser: "Die Systemvariablen des TOS”, ST-Computer 11-12/88