TOS-Daten

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.

Offset Format Bezeichnung Bedeutung
$02 word os_version TOS-Versionsnummer
$04 long os_start TOS-Startadresse
$08 long os_base TOS-Header-Adresse
$0C long osjmembot Anfangsadresse des freien Speichers
$18 long os_gendat TOS-Erstellungsdatum im BCD-Format
$1E word os_gendatg das gleiche im GEMDOS-Format, erst seit dem TOS vom 20.11.1985

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]:

Bit 0...4 Tag, von 1...31 
Bit 5...8 Monat, von 1...12 
Bit 9..15 Jahr seit 1980, von 0...119, d.h. bis 2099

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.

TOS Datum Name Bytes Sprache Art GEMDOS AES os_base os_start os_membot
0.0 - Das Boot 16384 englisch ROM - - - - -
1.0 20.06.85 Mushroom 207128 deutsch RAM 0.13 1.01 $5000 $501 E $19C00
1.0 20.11.85 - 197744 deutsch RAM 0.19 1.2 $6100 $6120 $1A900
1.0 20.11.85 - 196526 franz. RAM 0.19 1.2 $6100 $6120 $1A950
1.0 06.02.86 Altes 196480 deutsch RAM 0.19 1.2 $6100 $6120 $1A950
1.0 06.02.86 Altes 196608 deutsch ROM 0.19 1.2 $FC0000 $FC0020 $6100
1.2 22.04.87 Blitter 196608 deutsch ROM 0.19 1.2 $FC0000 $FC0030 $8900
1.4 18.05 88 Beta-Test 195282 englisch RAM 0.21 1.3 $AC00 $AC30 $2140C
1.4 08.08.88 Developer 196550 deutsch RAM 0.21 1.04 $AD00 $AD30 $2140C
1.4 22.02.89 Rainbow 196608 deutsch ROM 0.21 1.4 $FC0000 $FC0030 $611C
1.4 06.04.89 Rainbow 196608 deutsch ROM 0.21 1.4 $FC0000 $FC0030 $611C
1.6 19.06.89 STE 196608 deutsch ROM 0.21 1.4 $E00000 $E00030 $611C

Tabelle 2: TOS-Daten im Vergleich

*--------------------------------------------------
* test for aes initialization, TOS, GEMDOS & AES 
* versions etc. (c) MAXON Computer GmbH 1989
* -------------------------------------------------
start:   bra.s    action
* -----------------------------------------------------
* write word (max 5 decimal places) in d0 as 
* decimal ASCII to string in a1

dec_w:   move.w   #3,d1                ;4 dec. places
         move.l   #10000,d2            ;4 dec. places
yeah:    divu     #10,d2
         ext.l    d0                   ;ready for div
         divu     d2,d0
         addi.b   #$30,d0              ;to ASCII
         move.b   d0,(a1)+             ;write to strg.
         swap     d0
         dbf      d1,yeah

         rts

* ----------------------------------------------------
* kill leading or trailing zero in string

zero:    cmpi.b   #$30,-1(a1)          ;'0' ?
         bne.s    leave

         move.b   #$20,-1(a1)          ;SPC
leave:   rts

* ----------------------------------------------------
* write long in d0 as hex to string in a1

wrthex:  moveq    #7,d1                ;loop for 8 nibbles
nibble:  rol.l    #4,d0                ;get nibble
         move.l   d0,d2
         andi.b   #$0f,d2              ;mask
         addi.b   #48,d2               ;add '0' for
         cmpi.b   #57,d2               ;>9?
         ble.s    wrt_it

         addq.b   #7,d2                ;'A'..'F'
wrt_it:  move.b   d2,(a1)+             ;write to string 
         dbf      d1,nibble

         rts

* ----------------------------------------------------
action:  move.l   4(sp),a0             ;basepage addr
         lea      mystk,a1             ;end of code
         move.l   al,sp                ;new sp
         suba.l   a0,a1                ;prog length

         move.l   a1,-(sp)             ;newsize
         move.l   a0,-(sp)             ;block
         clr      -(sp)                ;filler
         move.w   #$4A,-(sp)           ;Mshrink
         trap     #1                   ;GEMDOS
         lea      $C(sp),sp

         lea      tos_dat(pc),a4       ;header msg
         bsr      print

         pea      sysinfo(pc)
         move.w   #$26,-(sp)           ;Supexec
         trap     #14                  ;XBIOS
         addq.l   #6,sp

         movea.l  a0,a3                ;save sysbase

         lea      os_base(pc),a4
         lea      18(a4),a1
         move.l   8(a3),d0             ;get os_base
         bsr      wrthex
         bsr      print                ;display addr of os_base

         lea      os_start(pc),a4
         lea      18(a4),a1
         move.l   4(a3),d0             ;get os_start

         bsr      wrthex
         bsr      print                ;display addr of os_start

         lea      os_memb(pc),a4
         lea      18(a4),a1
         move.l   $C(a3),d0            ;get os_membot
         bsr      wrthex
         bsr      print                ;display addr of os_membot

         lea      tosver(pc),a4        ;message string
         lea      13(a4),a1            ;position to be patched
         move.b   2(a3),d0             ;get 1st byte
         addi.b   #$30,d0              ;to ASCII
         move.b   d0,(a1)              ;write it there
         addq     #2,a1                ;position to be patched 
         move.b   3(a3),d0             ;get 2nd byte
         addi.b   #$30,d0              ;to ASCII
         move.b   d0,(a1)              ;write it there
         bsr      print                ;display TOS vers number

         lea      bcd_date(pc),a4
         lea      16(a4),a1
         lea      $18(a3),a0
         move.b   (a0)+,d0             ;get month
         bsr      bcd_conv
         bsr      bcd_conv
         addq.l   #1,a1
         move.b   (a0)+,d0             ;get day
         bsr      bcd_conv
         bsr      bcd_conv
         addq.l   #1,a1
         move.b   (a0)+,d0             ;get 1st half of year
         bsr      bcd_conv
         bsr      bcd_conv
         move.b   (a0)+,d0             ;get 2nd half of year
         bsr      bcd_conv
         bsr      bcd_conv
         bsr      print                ;display TOS BCD date

         cmpi.b   #$1E,7(a3)           ;oldest TOS version ?
         beq.s    next

         lea      dos_date(pc),a4
         lea      16(a4),a1            ;position to be patched 
         move.w   $1E(a3),d3           ;get GEMDOS coded date
         move.w   d3,d0
         andi.w   #$1F,d0              ;get day
         bsr      decimal
         addq     #1,a1
         lsr      #5,d3                ;get month to position
         move.b   d3,d0
         andi.b   #$F,d0               ;get month
         bsr      decimal
         addq     #1,a1
         lsr      #4,d3                ;get (year-1980) into position
         move.b   d3,d0
         andi.w   #$7F,d0              ;get (year-1980) 
         addi.w   #1980,d0             ;year
         bsr      dec_w
         bsr      print                ;display TOS DOS date

next:    move     #$30,-(sp)           ;Sversion
         trap     #1                   ;GEMDOS
         addq.l   #2,sp

         tst      d0
         beq.s    close

         move.w   d0,d7                ;save version no 
         lea      dosver(pc),a4        ;message string
         lea      12(a4),a1            ;position to be patched
         bsr      decimal
         rol      #8,d7
         move.b   d7,d0                ;get highbyte
         addq     #1,a1                ;advance position
         bsr      decimal
         bsr.s    print                ;display GEMDOS version
         moveq    #10,d0               ;opcode appl_init
         move.l   #$00010000,d1        ;input to control array 
         bsr.s    aes
         lea      global,a6
         move     4(a6),d4             ;ap_id
         bmi.s    close                ;function failure->end prg

         move.w   (a6),d5              ;ap version
         beq.s    not_inst

         lea      inst(pc),a4          ;message string
         lea      12(a4),a1            ;position to be patched
         rol      #8,d5
         move.b   d5,d0                ;get highbyte
         bsr.s    bcd_conv             ;1st nibble
         bsr      zero                 ;kill zero
         bsr.s    bcd_conv             ;2nd nibble
         addq     #1,a1                ;advance position to be patched
         rol      #8,d5
         move.b   d5,d0                ;get lowbyte
         bsr.s    bcd_conv             ;1st nibble
         bsr.s    bcd_conv             ;2nd nibble
         bsr      zero                 ;kill zero
go_on:   bsr.s    print
         bsr.s    bconin

         moveq    #19,d0               ;appl_exit
         move.l   #$00010000,d1        ;input to control array
         bsr.s    aes
         move     (a6),d5              ;return value

close:   clr      -(sp)
         trap     #1

* -------------------------------------------------
not_inst:lea      missing(pc),a4
         bra      go_on
* -------------------------------------------------
aes:     lea      contrl,a0
         move     d0,(a0)              ;opcode
         movep.l  d1,3(a0)             ;fill parameter array 
         move.l   #aespb,d1            ;addr table
         move     #$C8,d0              ;AES
         trap     #2                   ;GEM
         rts
* -------------------------------------------------
* string output to console: modelled after 
* Cconws, string addr in A4

print:   move.b   (a4)+,d0             ;string addr
         beq.s    return
         move     d0,-(SP)             ;char
         move     #2,-(sp)             ;con
         move     #3,-(sp)             ;Bconout
         trap     #13                  ;BIOS
         addq.l   #6,sp

         bra      print
return:  rts
* -----------------------------------------------
bconin:  move     #2,-(sp)             ;con
         move     #2,-(sp)             ;bconin
         trap     #13
         addq.l   #4,sp
         rts
* ------------------------------------------------
* convert bcd-byte in d0 to 2 position decimal 
* ascii - write to string in a1

bcd_conv:rol.b    #4,d0                ;get nibble
         move.b   d0,d1
         andi.b   #$F,d1               ;mask
         addi.b   #$30,d1              ;to ASCII
         move.b   d1,(a1)+             ;write char to string
         rts

* ------------------------------------------------
* convert byte in d0 to 2 position decimal ASCII 
* - write to string in a1

decimal: andi.l   #$FF,d0              ;byte only of interest here, .l for div! 
         cmpi.b   #9,d0                ;single
         bls.s    single

         divu     #10,d0               ;get tens
         bsr.s    chgform              ;output
         swap     d0                   ;get units
chgform: add.b    #48,d0               ;to ASCII
         move.b   d0,(a1)+             ;write char to string
         rts

single:  move.b   #' ',(a1)+           ;leading zero
         bra      chgform              ;output

* ------------------------------------------------
sysinfo: movea.l  $4F2,a0              ;sysbase
         rts
* ------------------------------------------------
aespb:   dc.l     contrl,global,intin,intout,addrin,addrout

* the following are fixed structs after each label, XX etc are to be patched

inst:    dc.b     13,10,' AES V XX.XX resident ',13,10,0

missing: dc.b     13,10,' AES not (yet?) resident ',0

dosver:  dc.b     13,10,' GEMDOS V XX.XX resident ',0

tosver:  dc.b     13,10,' TOS    V  X.X  resident ',0

bcd_date:dc.b     13,10,' TOS BCD date MM/DD/YYYY ',0

dos_date:dc.b     13,10,' TOS DOS date DD.MM.YYYY ',0

os_base: dc.b     13,10,' os_base   $00XXXXXX ',0

os_start:dc.b     13,10,' os_start  $00XXXXXX ',0

os_memb: dc.b     13,10,' os_membot $00XXXXXX ',10,0

tos_dat: dc.b     27,'E'
         dc.b     13,10,’ TOS VERSION INF MAXOnN Computer 89 ',10,0

* ------------------------------------------------
         bss
         even
contrl:  ds        5

global:  ds       15

intin:   ds       16

intout:  ds        7

addrin:  ds.l      3

addrout: ds.l      1

         ds.l     50

mystk:   ds.b      1

* ------------------------------------------------


Links

Copyright-Bestimmungen: siehe Über diese Seite