Atarium: Neues TOS und neue Kekse

Man glaubt es kaum: Atari hat zumindest einen Teil seiner Hausaufgaben gemacht. Die TTs sind wieder lieferbar und jetzt von Haus aus mit HD-Laufwerken und einer neuen Betriebssystem-Version ausgestattet.

TOS 3.06 (bzw. TOS 2.06 für die ST- und STE-Geräte) verfügt über eine Reihe von Detailverbesserungen. Leider gibt es noch keine schlüssigen Unterlagen über die Veränderungen im neuen GEMDOS (Version 0.20) und im neuen GEM (3.2). Immerhin wurden viele Detailverbesserungen vorgenommen, die die Arbeit ein bißchen vereinfachen.

Das fängt schon beim Starten des Systems an: vom Atari-Logo und der optischen Information über Speichertest und Festplatten-Delay haben Sie sicherlich schon gelesen. Neu ist auch, daß jetzt im Normalfall in »TT-Mittel-Auflösung« gebootet wird (für Spiele, die »ST-Gering« erwarten, gibt es die ALT-Taste). Sehr schön auch der Einfall, daß sich jetzt die Abarbeitung der AUTO-Ordner-Programme, der Accessories und der Desktop-Informationsdateien per Tastendruck (Control) verhindern läßt.

Die Diskettenbehandlung wurde ebenfalls überarbeitet: so merken es jetzt die Floppyroutinen erheblich schneller (etwa in 1/3 der Zeit), wenn gar keine Diskette eingelegt ist. Bei der Diskettenwechsel-Erkennung wird nun zusätzlich mit FAT-Checksummen gearbeitet, so daß die Erkennung jetzt endlich auch in Grenzfällen einwandfrei funktionieren müßte. Neu ist auch, daß Medien mit nur einer FAT benutzt werden können. Solche Disketten werden von einigen MS-DOS-Formatierprogrammen erzeugt. Ob nun auch Disketten mit einem Sektor pro Cluster offiziell unterstützt werden, war leider noch nicht zu erfahren.

Natürlich ist es schön, daß Atari wieder mal etwas am TOS gemacht hat und diese Verbesserungen nun auch wieder den Besitzern älterer Geräte zukommen lassen will. Dennoch sind allerlei Dinge eben nicht gemacht worden, so daß keinerlei Grund besteht, in Euphorie auszubrechen oder gar von der »Beseitigung aller bekannter Fehler älterer TOS-Versionen« zu sprechen.

Der nunmehr freigegebene HD-Support im TOS hat uns auch einen neuen Cookie gebracht, der Informationen über den vorhandenen Floppycontroller enthält (siehe Abb. 2). Der »_FDC«-Cookie gibt an, welche Art von Floppyhardware im System vorhanden ist. Natürlich wurde er so definiert, daß er auch auf älteren Systemen.nachträglich installiert werden kann.

Wichtig ist, daß damit noch keinerlei Aussage gemacht ist, ob auch entsprechende Laufwerke angeschlossen und passende Disketten eingelegt sind! Der Cookie gibt nur an, daß Hardware und Betriebssystem die Ansteuerung entsprechender Laufwerke erlauben!

Wenn der _FDC-Cookie angibt, daß HD-Betrieb möglich ist, ergeben sich folgende Erweiterungen für bestehende XBIOS-Aufrufe:

Daneben darf man sich auch darauf verlassen, daß die BIOS-Aufrufe »Rwabs()«, »Getbpb()«, »Mediach()« und die XBIOS-Aufrufe »Floprd()« und »Flopwrite()« entsprechend funktionieren. Diese Informationen dürften speziell für Autoren von Diskformatierern und für Hersteller von HD-Erweiterungen interessant sein.

Ebenfalls neu ist die endgültige Fassung der Netzwerkspezifikation ([1]), die nicht mit dem 1989 von Atari Deutschland beschlossenen Standard übereinstimmt - leider hat sich das noch nicht überall herumgesprochen (siehe [2]).

Die Netzwerkspezifikation sieht zwei neue Cookies vor. Der »_FLK«-Cookie informiert darüber, daß die GEMDOS-Filelocking-Funktion »Flock()« (GEMDOS 92) vorhanden ist. Die Definition dieser Funktion entspricht haarscharf der des entsprechenden MS-DOS-Aufrufs. Der »_NET«-Cookie trägt Informationen über das installierte Netzwerk.

Die Trennung zwischen beiden Cookies ist sehr sinnvoll: File-Locking kann auch ohne Netzwerke sinnvoll sein (Multitasking!) und nicht jedes Netzwerk unterstützt File-Locking.

Alle Entwickler von Netzwerken und netzwerkfähigen Programmen sollten sich an den Entwicklersupport in Raunheim wenden und die entsprechenden Informationen anfordern, nur so kann diese sinnvolle Spezifikation auch Erfolg haben. Beschämend ist allerdings, daß auf der Atari-Messe noch nicht einmal das Atari-eigene Netzwerk zum eigenen Standard kompatibel war.

Nicht von Atari, sondern von mehreren deutschen Entwicklern stammt die Definition eines Standardverfahrens zur PMMU-Programmierung. Urheber sind die Programmierer Uwe Seimet (virtuelle Speicherverwaltung »OUTSIDE«, Vertrieb »Maxon«) und Alexander Herzlinger (virtuelle Speicherverwaltung »VRAM«, Vertrieb »OverScan«).

Durch die Normung des »PMMU«-Cookie soll also künftig Ordnung herrschen, wo bislang mit einiger Wahrscheinlichkeit Abstürze drohten - Zugriffe auf die PMMU wollen nun mal koordiniert sein. Nähere Informationen können bei den beiden Autoren angefordert werden.

Schön, daß sich zwei Konkurrenten auf ein gemeinsames Verfahren einigen konnten. Weiter so! (uw)

Adressen:

Alexander Herzlinger, Overscan GbR, Santisstraße 166, D-W1000 Berlin 48

Uwe Seimet, Maxon Computer, Schwalbaeher Straße 52, D-W6236 Eschborn

Literatur:

[1] Mike Fulton: "Specification for GEMDOS File Sharing & Record Locking«, ATARI.RSC - The Atari Developer's Resource April-May 1991, Seite 13 (Vol. IV, Issue 2)

[2] Martin Backschat: "Per Anhalter durch das Betriebssystem - Dem GEMDOS auf der Spur, Teil 3, TOS-Magazin 9/1991

Der _FDC-Cookie

Name des Cookies: _FDC

Oberstes Bytes: 0 Normale Schreibdichte, 720K bzw. 360K

1 High Density, 1.44 MByte (HD) 2 Extra-high Density, 2.88 MByte (ED)

> 2 reserviert

Die restlichen drei Bytes geben darüber Auskunft, wer den Cookie gesetzt hat.

Definiert sind bislang:

Wenn der Cookie nicht gesetzt ist, sollte man von normaler Schreibdichte ausgehen.


Julian F. Reschke
Aus: ST-Magazin 01 / 1992, Seite 118
Links
Copyright-Bestimmungen: siehe Über diese Seite