Anlaß zu dieser kleinen Untersuchung war der Versuch, ein neues Programm [1] unter verschiedenen Umgebungen auszutesten. Da dieses Programm mit einigen neuen und interessanten Eigenschaften ausgestattet war und unter anderem den Aufruf der erst ab AES V1.3 implementierten Funktion fsel_exinput - gekoppelt an eine Versionsabfrage - enthielt, begaben wir uns also zu einem Bekannten, der eine Entwicklerversion des TOS 1.4 installiert hatte, das ja AES V1.3 enthalten sollte.

Doch obwohl wir alle ganz sicher waren, TOS 1.4 wirklich vor uns zu haben, griff die Abfrage offensichtlich nicht, und es war leider nichts mit dem erwarteten fsel_exinput!

Um diesem merkwürdigen Effekt auf die Spur zu kommen, setzte ich mich hin und schrieb ein kleines Assembler-Programm, das mir alle Versionsnummem und -daten der wichtigen Betriebssystemteile ausgeben würde. Die Überlegungen hierzu sowie zu den von ATARI bzw. Digital Research benutzten Formaten zusammen mit den Ergebnissen der Untersuchungen verschiedener mir bekannter TOS-Versionen möchte ich den geneigten ‘Atarianern’ nicht vorenthalten. Außerdem schienen mir nun, nachdem der ATARI ST inzwischen in ein - für Computer - schon ‘reifes Alter’ gekommen ist. Reflektionen zur Geschichte und Entwicklung seines Betriebssystems angebracht.

Das TOS

Das Betriebssystem des ATARI ST wurde ursprünglich in den USA bei Digital Research Inc. (DRI), den Schöpfern von CP/M und GEM, entwickelt und besteht aus mehreren Teilen, die aufeinander aufbauen: ‘TOS’ (The Operating System [2]), bestehend aus BIOS (Basic Input Output System), XBIOS (Extended BIOS) und GEMDOS (GEM Disk Operating System), stellen das ‘eigentliche’ Betriebssystem dar [2;7]. Darauf aufgesetzt ist GEM (Graphic Environment Manager), das wiederum aus VDI (Virtual Device Interface) und AES (Application Environment Services) besteht und beim ATARI ST, im Gegensatz zum PC-GEM, ein integraler Teil des Betriebssystems im weiteren Sinne ist - übrigens einer der Gründe, weshalb das ST-GEM vom Rechtsstreit zwischen Apple und DRI unberührt blieb. Dieser Auffassung entsprechen auch die Einteilung der auf dem ST lauffähigen Programme nach ihrer jeweiligen Oberfläche in TOS-Anwendungen und GEM-Applikationen, die Namensgebung der entsprechenden Extender und schließlich die Aufmachung der Copyright-Box im Desktop. Oft wird aber auch das ST-Betriebssystem als Ganzes unter dem Namen TOS zusammengefaßt, z.B. in [3]. Wie dem auch sei, das TOS trägt eine Versionsnummer und ein Entstehungsdatum, von den Teilen des Betriebssystems sind außerdem GEMDOS und AES mit gesonderten Versionsnummern versehen, die sich mit Hilfe spezieller Funktionen abfragen lassen. Dazu später mehr. Doch kommen wir nun zu dem Teil, in dem die meisten interessanten Informationen zu diesem Betriebssystem abgelegt sind, und das ist:

Der ‘TOS-Header’...

... oder TOS-Programmkopf, denn das TOS ist ja schließlich nichts anderes als ein Programm, und zwar das Programm, das gestartet wird, wenn wir den ST einschalten, und das dann die ganze Zeit läuft - im Vordergrund oder, wenn andere Programme oder ‘Applikationen’ laufen, im Hintergrund. Wie kommen wir nun an diese interessanten Informationen heran?

Das TOS befindet sich bei den meisten STs in einem 192 kByte großen ROM (Read Only Memory), bis auf einige frühe Versionen dieses Rechners (260 ST, 520 ST und 520 ST+), die stattdessen nur ein sogenanntes Boot-ROM haben - eine 16 kByte große Miniausgabe, die den ST gerade einmal dazu befähigt, das ‘richtige’, d.h. vollständige TOS von Diskette nachzuladen (Näheres dazu und zu den Daten des Boot-ROMs weiter unten). Das ROM beginnt beim ST an der Adresse $FC0000.

Doch nun nur ja nicht etwa frech ins ROM ‘gepeekt’! Denn schließlich muß das ‘aktive’ TOS ja gar nicht dort liegen. Es kann ja auch eine andere Version des TOS von Diskette nachgeladen worden sein, oder wir haben es gar mit einem der neuen STEs zu tun, bei denen das ansonsten kompatible TOS an der Adresse $E00000 liegt! Und wer weiß, was die Zukunft noch alles bringen wird. Also holt man sich die Adresse des TOS-Headers korrekterweise aus der garantierten Betriebssystemvariablen _sysbase ($4F2).

Dort liegen nun die uns hier interessierenden Daten an den Offsets, die man Tabelle 1 entnehmen kann (die Bezeichnungen wurden aus [3] übernommen):

Die drei Variablen osjbase, os_start und osjnembot habe ich eigentlich nur aufgenommen, um einmal zu verfolgen, wie sich die Lage des Betriebssystems im Laufe der Zeit und der fortschreitenden Versionsnummern immer weiter zu höheren Adressen hin verschoben hat, und wie auch der TOS-Header - schon zweimal -vergrößert, der OS-Pool [7] dann jedoch wieder verkleinert wurde.

Tabelle 1: Offsets aus der Betriebssystemvariablen _sysbase

Die TOS-Version

Da ist sie nun endlich, die TOS-Versionsnummer, verschwenderisch kodiert in einem Wort, jedes Byte eine Dezimalstelle enthaltend, und zwar so, wie ein M68000-Prozessor so etwas im Speicher abzulegen pflegt! Im höherwertigen Byte steht nämlich die Vorkomma- und im niederwertigen die Nachkommastelle. Man könnte dies sonst etwas ungewöhnliche Format als decimal byte fixed, also etwa ‘Dezimal-Byte in Festkommadarstellung’ bezeichnen. Das Wort $0102 z.B. ist also als Version 1.2 zu interpretieren, bekannter vielleicht unter dem Namen ‘Blitter-TOS’. Der Vorteil ist hierbei, daß man es sehr einfach in ASCII wandeln kann, und im Hexdump ist es eben auch gut zu erkennen. Was die ‘Verschwendung’ betrifft so sind - oder waren - so viele TOS-Versionen wahrscheinlich auch gar nicht geplant. Hoffentlich reicht’s beim jetzigen Entwicklungstempo bis zum Jahre 2099! Und damit kommen wir auch schon zum...

...TOS-Datum...

oder genauer TOS-Erstellungsdatum. Dies liegt im TOS-Header gleich zweimal - in verschiedenen Formaten - vor. Erst einmal als Langwort im Format BCD (Binary Coded Decimal) fixed, also etwa BCD-Festkommaformat. Die Kodierung ist MM/DD/YYYY, \m angelsächsischen Format. $04221987 wäre also zu interpretieren als 04/22/1987 oder in unserer Schreibweise als 22.4.1987, das ist wieder das Datum des allseits bekannten Blitter-TOS’. Die Umwandlung des BCD-Formats, bei dem jedes Nibble (Halbbyte) eine Dezimalziffer enthält, ist relativ einfach zu bewerkstelligen, und außerdem läßt sich die Information direkt aus dem Hexdump ablesen.

Das gleiche Datum ist noch einmal am Offset $1E als Wort in GEM-DOS- Kodierung abgelegt, allerdings -soweit mir bekannt - erst ab der TOS-Version vom 20.11.1985, als der TOS-Header zum erstenmal erweitert wurde, vorher begann hier schon der Code des Betriebssystems. Diese sog. GEMDOS-Kodierung ist die gleiche, die von den beiden GEMDOS-Funktionen Tsetdate und Tgetdate verwendet wird. Hier ist das Datum äußerst sparsam binär kodiert in den 16 Bits untergebracht, und zwar in folgender Form [4;5]:

Das schon erwähnte Datum des ‘Blitter-TOS’ erscheint hier in der Form $0E96, die Dekodierung ist also durch Bit-Schieben und Maskieren zu besorgen. Warum braucht man nun zweimal das gleiche Datum in verschiedenen Formaten? Ein Grund für diese Redundanz könnte gewesen sein, daß man sich eine vorher vorhandene Umwandlungsroutine ersparen wollte, um so das Ganze zu kürzen und schließlich in den 192 kByte ROM unterbringen zu können. Das war nämlich am Anfang ein ziemliches Problem für die TOS Entwickler.

TOS im RAM

Beim ST liegt das TOS ja, wie bereits erwähnt, an der Adresse $FC0000 im ROM, bis auf die Modelle eben, die hier nur ein sogenanntes ‘Boot-ROM’ haben. Diese müssen das TOS von Diskette nachladen, und es wird dann natürlich im RAM angelegt. Der Ablauf ist wie folgt: Das Boot-ROM initialisiert das System und sucht dann nach dem sog. Boot-Loader auf dem Boot-Sektor der System-Diskette. Dies ist ein kleines Programm, das die Systemdatei namens TOS.IMG an die Adresse $40000 (=256k) in den Speicher lädt. Hieraus kann man schon ersehen,daß die Mindestbestückung des ST mit RAM 512k betragen muß.(Ursprünglich geplante Auslegung in [5].) Dann wird die Startadresse von TOS.IMG (IMG = Image = Abbild) angesprungen. Hier befindet sich nun nicht etwa der TOS-Header, nein, liebe ST-Freunde, das wäre ja auch zu einfach (und zu unflexibel, dann würde man nämlich für jede Version einen anderen Boot-Lader brauchen!), es ist der sog. Relocator (RELOCRL) [8]. Dies ist wieder ein kleines Programm, das jetzt die Kontrolle übernimmt und das TOS.IMG (minus sich selbst) an seinen endgültigen Platz kopiert. Das TOS.IMG ist - wie die Kennung schon besagt - eine sog. ‘Image-Datei’, d.h. ein Abbild, das genau auf die absolute Adresse gelinkt wurde, an der es nachher im Speicher steht. Das hat den Vorteil, daß die darin enthaltenen absoluten Adressen nicht mehr reloziert werden müssen. Nun wird die Startadresse angesprungen, und das so aktivierte TOS erledigt den Rest der Initialisierung bis zum Erscheinen des beliebten GEM-Desktops oder einer Command-Shell.

Wie man sich leicht denken kann, unterscheiden sich die Abläufe während der Initialisierungsphase im RAM-TOS und ROM-TOS um einiges, deshalb ist es auch nicht möglich, sich ein TOS.IMG ins ROM zu brennen - von Copyright- Bedenken einmal abgesehen. Außerdem werden dort, wo das ROM-TOS Strukturen ins RAM kopiert, um sie da modifizieren zu können, beim RAM-TOS praktischerweise, und um Arbeitsspeicher zu sparen, diese Strukturen innerhalb des IMG selbst verändert. Das TOS.IMG gehört somit zur Gruppe der selbstmodifizierenden Programme, und so etwas ist im ROM nun einmal nicht zu verwirklichen! Ob RAM- oder ROM-TOS erzeugt werden soll, wird beim Systemhersteller ganz einfach durch das Linken unterschiedlicher Module erreicht, und die stehen ja nur den Systemprogrammierern der ATARI Corp. zur Verfügung.

Ein TOS.IMG von einem Speichermedium nachladen kann aber nicht nur das dazu bestimmte ursprüngliche Boot-ROM, diese Möglichkeit ist auch beim normalen ROM-TOS - gleich welcher Version - vorgesehen. Der Ablauf ist der gleiche, es braucht nur beim Start des ST eine sog. Systemdiskette mit Boot-Lader und TOS.IMG eingelegt zu sein. Nach dem Laden übernimmt dann das ‘gebootete’ TOS die Kontrolle über den ST. Das hat aber nicht etwa nostalgische Gründe! Wenn man noch Programme hat, die wegen ‘spezieller’ Programmierung auf dem aktuellen ROM-TOS nicht laufen wollen, könnte man z.B. eine ältere Version des Betriebssystems als TOS.IMG booten. Oder man hat noch ein ‘altes’ TOS im ROM und möchte gern die Vorteile der jeweils neuesten Version genießen: Dann bootet man eben das neue TOS vom Massenspeicher. Denn es geht inzwischen nicht nur mit TOS.IMG und Boot-Lader von Diskette (langsam!), sondern auch mit Hilfe von Ladeprogrammen im Auto-Ordner z.B. von der Festplatte oder RAM-Disk (schnell bis sehr schnell!). Und es muß auch nicht immer ein TOS.IMG sein: Mir ist z.B. auch eine Version des ‘Blitter-TOS’, von dem m.E. nie ein .IMG im Umlauf war, bekannt, die mit Hilfe einer speziellen Relozierdatei (da hat sich jemand viel Arbeit gemacht!) und eines Laders im AUTO-Ordner gebootet wurde. Oder man denke an das KAOS [6], ein modifiziertes ‘Blitter-TOS’ mit einer auf MS-DOS gestylten Version des GEMDOS, das auf ähnliche Weise - allerdings an das zu diesem Zweck verschobene phystop, was leider die Möglichkeiten ziemlich einengt - geladen wird.

Auf jeden Fall, da es - wie auch sonst im Leben - nichts umsonst gibt, muß der ‘Luxus’ eines wie auch immer gebooteten TOS bezahlt werden, und zwar in bar mit ca. 200 kByte RAM.

GEMDOS

Das GEMDOS ist das DOS des TOS, oder, wie der Name (s.o.) schon sagt, eigentlich des GEM (Computersprach‘ - grauslich Sprach’!). Es trägt eine besondere, von der TOS-Version unabhängige Versionsnummer, die sich mit der Funktion _S_version erfragen läßt. Angeliefert wird von dieser Funktion ein Wort im Format byte reversed, binary fixed oder auch Intel binary fixed, kurzum ein binär kodierter Festkommawert mit vertauschten Bytes [4;5]. An diesem für M68k-Prozessoren ‘haarsträubenden’ Format kann man auch mal wieder sehen, was in den Köpfen der GEMDOS-Entwickler herumgeisterte, als sie das System entwarfen, und auch sonst ist ja sattsam bekannt [2;7], mit welch anderem System der Befehlssatz von GEMDOS die meisten Übereinstimmungen aufweist, und auf welcher Prozessorfamilie eben das läuft. Wundem wir uns also nicht weiter! Um wieder unser beliebtes Blitter-TOS als Beispiel anzuführen, der Wert $1300 ist also zu interpretieren als V 0.19, und diese Angabe bekommt man z.B. auch, wenn man im COMMAND.PRG (aus dem alten Entwicklungspaket) oder einer ähnlichen Text-Shell die Version des Betriebssystems abfragt. Daraus entnehme ich übrigens, daß die Kodierung der Versionsnummer binär und nicht etwa als BCD zu interpretieren ist, das ist nämlich in [4;5] nicht explizit angegeben. Die gleiche Versionsnummer bekam man übrigens auch schon beim TOS 1.0 vom 6.2.1986 geliefert, es war wohl alles mehr oder weniger beim alten geblieben. Die älteste GEMDOS-Versionsnummer, die ich zu sehen bekam, war - im Widerspruch zu [4] - V 0.13, aus dem deutschen ‘Pilz-TOS’ (so genannt, weil es statt der heutzutage üblichen Bomben Pilze ausgibt) vom 20.6.1985. Im TOS 1.4 vom 6.4.1989 ist - wie auch in den davor liegenden Testversionen - die GEMDOS-Version V 0.21 enthalten.

AES

Das oder die AES ist oder sind die oberste Schicht des Betriebssystems, auf der dann das GEM-Desktop als grafische Shell läuft. Als Teil des GEM von DRI geschaffen, trägt es (ich bleibe mal beim auch im Amerikanischen eingebürgerten Singular) auch wieder eine gesonderte und unabhängige Versionsnummer. Diese Nummer erhält man üblicherweise beider Anmeldung einer Applikation - so heißen GEM-Programme - als ersten Eintrag im sog. global-Array, mit dem Namen ap_version.

Die Abfrage der AES-Version ist übrigens ein probates Mittel, um festzustellen, ob das AES vorhanden und initialisiert ist, z.B. bei Programmen, die sowohl auf der sog. TOS-Oberfläche als auch als GEM-Applikationen laufen sollen. Der Test auf ap_id, also die vom AES vergebene Applikationsnummer, bringt hier nämlich nichts, da sie für die Hauptapplikation üblicherweise Null ist. Dazu muß man wissen, daß das AES entweder noch nicht - während der Abarbeitung des AUTO-Ordners - oder auch nicht mehr -nach der Ausführung von Puntaes (XBIOS 39) bei RAM-TOS - installiert sein kann.

Das Format der Versionsnummer ist BCD fixed, also BCD-Festkommawert. Für die im ‘Blitter-TOS’ enthaltene Version des AES hat ap_version den Wert $0120, somit zu interpretieren als V 1.2. Auch im sog. ‘alten’ TOS vom 6.2.1986 hatte das AES schon diese Versionsnummer, was wohl heißt, daß sich da nichts oder zumindest nichts weiter Interessantes geändert hat.

Der Patch

Nachdem nunmehr die Voraussetzungen zu weiterer Erkundung geschaffen waren, begab ich mich wieder zu jenem Bekannten, um dort mein Programm auf seine Entwicklerversion des TOS 1.4 loszulassen. Es handelte sich übrigens um die Version vom 8.8.88 (schönes Datum!), die mit einer Alertbox Launch TOS ausgerüstet war. Das TOS hatte natürlich die Version 1.4, das GEMDOS die Version 0.21 und - man staune - das AES die Version 1.04! Also eine Rückentwicklung? Nein, das konnte nicht sein! Da mußte sich jemand geirrt und die Formate oder Versionsnummern verwechselt haben.

Wo war nun aber die AES-Versionsnummer im TOS abgelegt? Als Hilfe hatte ich erfahren, daß sie nicht etwa, wie von mir zuerst vermutet, in einer Tabelle steht, sondern vielmehr als immediate in einem Langwort zusammen mit ap_count in das global-Array geschrieben wird. Das bewußte Langwort $01040001 war leicht zu finden: Es kommt nämlich glücklicherweise nur ein einziges Mal im ganzen TOS vor! Der dazugehörige Befehl erwies sich als move.l #$01040001 ,(a0)+ oder im Hexdump $20FCO1040001. Nachdem nun dieser Wert vernünftig (z.B. in $01300001 oder $01400001) geändert und das System neu gebootet war, durften wir uns am einwandfreien Arbeiten der Funktion fsel_exinput erfreuen.

AES-Versionsnummern

Die kleinste AES-Versionsnummer, die ich beobachten konnte, war 1.01 und stammt wieder aus besagtem alten ‘Mushroom-TOS’ vom 20.6.1985. Das sog. ‘Beta-Test TOS’ vom 18.5.1988 enthielt AES V1.3, am fortgeschrittensten sind das TOS 1.4 vom 22.2.1989, das erste sog. ‘Rainbow-TOS’ - nach den Farben, die wie ein Regenbogen das ATARI-Symbol durchlaufen - und dessen Nachfolger vom 6.4.1989, dort trägt das AES die Versionsnummer 1.4.

Vielleicht sollte man noch anmerken, daß es auch zur Zeit auf dem ATARI ST noch höhere AES-Versionsnummern geben kann, diese gehören dann aber nicht mehr zum TOS, sondern sind - gebootete - Aufsätze auf das TOS, wie z.B. die Portierung von GEM 2.0 der Firma ABC, in der das AES die Versionsnummer 2.1 oder neuerdings auch 2.2 trägt.

TOS-Versionsnummern

Die kleinste TOS-Versionsnummer hat natürlich das Boot-ROM, auch bekannt als ‘Das Boot' [8], nämlich 0.0. Die ersten vollständigen TOS-Versionen bis einschließlich der bei uns wohl am weitesten verbreiteten (ROM und RAM) und oft als ‘Altes TOS' bezeichneten Version vom 6.2.1986 tragen die Versionsnummer 1.0. Dann kommt das oben schon erwähnte ‘Blitter-TOS' mit der Versionsnummer 1.2, interessanterweise im neuesten mir bekannten ‘Diagnostic' von ATARI als ‘OS Version #2' bezeichnet. Die neueste Ausgabe ist z.Z. das ebenfalls schon erwähnte ‘Rainbow-TOS' V 1.4 vom 6.4.1989. Dies soll auch, wie man auf der ATARI-Messe in Düsseldorf vernehmen konnte, die ‘zunächst' endgültige Version sein, die dann auch im Fachhandel auf ROMs zur Nachrüstung erhältlich sein wird.

Die Daten verschiedener TOS-Versionen, derer ich habhaft werden konnte, sind der besseren Übersicht halber noch einmal in Tabelle 2 zusammengefaßt.

TOS 1.6, ein an die veränderte und erweiterte Hardware des STE angepaßtes TOS 1.4, ist auf dem ST nicht lauffähig und ist daher in diesem Zusammenhang uninteressant. Allerdings sollten alle ST-Programme auch auf dem STE laufen können.

Auf dem ATARI TT konnte man auf der Messe ja schon einige Programme laufen sehen. Das daraufinstallierte sog. TT-TOS soll, wie man bei ATARI in Düsseldorf vernahm, ein auf die Hardware des TT zugeschnittenes TOS 1.4 sein, aber der TT läßt ja noch auf sich warten. Welche Perspektive bietet sich nun uns Anwendern und Programmierern? ATARI hat angekündigt, das ST-Betriebssystem in Zukunft stärker als bisher mit Information und Dokumentation zu unterstützen - und das wurde zum Teil im Zusammenhang mit der Entwicklung der hier besprochenen neuen Versio-nen ja auch schon verwirklicht [9; 10; 11 ]. Warten wir’s ab, was die Zukunft noch alles bringen wird! Auf jeden Fall wage ich die Prognose, daß dem ATARI ST, dieser vielseitigen Maschine mit ihrem faszinierenden Betriebssystem, noch viele Jahre interessanter Entwicklung bevorstehen.

Bernd Rosenlecher

Quellen:

[1] Wolfram Roisch. METADUMP APP, Programm und Assembler-Quelltext, 1989

[2] Tim Oren, Professional GEM, Column #15, Antic Publishing, 1986

[3] Jankowski, Reschke, Rabich. ATARI ST Profibuch, Düsseldorf 1988

[4] London Dyer, ATARI GEMDOS Reference Manual. ATARI Corp. April, 1986. In den Erläuterungen zu Sversion wird die Ausgabe vom 29.5.85 als first disk-based' und die vom 20.11.85 als first ROM-based' bezeichnet - es handelt sich hier natürlich um amerikanische Ausgaben - und beide sollen die GEMDOS-Versionsnummer $1300. d.i. V 0.19, tragen.

[5] The GEMDOS Programmer's Guide, Digital Research Inc. 1985

[6] Andreas Kromke, Das wahre GEMDOS. c't 11/88 S. 194 ff. Dem im KAOS V 1.2.3 enthaltenen GEMDOS wurde von seinem Autor die Versionsnummer V 0.21 erteilt.

[7] Kramer,Riebl,Hübner. Das TOS-Listing, Band 1, Hannover 1988

[8] London Dyer. A Hitchhiker's Guide to the BIOS. ATARI Corp. August. 1985

[9] TOS Release Notes. ATARI Corp., 1988, oft zitiert doch leider immer noch nicht allgemein zugänglich!

[10] RAINBOW TOS Release Notes, ATARI Corp., August. 1989. brandneu, s.o.!

[11] HMH (Hrsg.). SYSTEM_1.INF. US-Infos zum ATARI ST. Hamburg 1989. Bisher ca. 50 kByte Infos von ATARI und DRI Systemprogrammierern aus Usenet & anderen elektron. Quellen, auf Anfrage gegen Unkostenbeitrag auf Diskette erhältlich.

Mein Dank gilt Herrn K.W. Quinckardt. Hamburg, der mir freundlicherweise seine reichhaltige Sammlung von originalen ATARI ST-Systemdisketten zur Auswertung zur Verfügung stellte.

Tabelle 2: TOS-Daten im Vergleich