Allgemeines

Gleichzeitig mit der Auslieferung des MEGA ST hat Atari auch eine neue Version des Betriebssystems vorgestellt. Die sechs Roms aus dem MEGA ST enthalten in 192 KByte das komplette TOS. Um eine weite Verbreitung des neuen TOS zu ermöglichen, ist es auch im alten ST-Modell einsetzbar, da es automatisch erkennt, um welchen Rechner es sich handelt. Wir wollen näher darauf eingehen, in welchen Teilen das Betriebssystem Änderungen erfahren hat und welche Teile neu hinzugekommen sind.

Das TOS hat die Versionsnummer 1.2 mit Datum vom 22.4.1987. In den ausgelieferten Geräten in der Bundesrepublik befindet sich die deutsche Version, die sich durch einen modifizierten Tastaturtreiber und deutsche Texte von der amerikanischen Version unterscheidet. Es ist (fast) kompatibel zum alten TOS, d. h., alle sauber geschriebenen Programme sollten auch laufen.

Auf den ersten Blick gibt es folgende Neuerungen: Verbesserte Benutzerfreundlichkeit des Desktop, Beschleunigung der Grafik durch den Blitter, Verwaltung der residenten Uhr, Erweiterung von Betriebssystem-Funktionen, Beseitigung einiger Fehler, Optimierung in Bezug auf Programmlänge und Geschwindigkeit.

Dieser Artikel stützt sich im wesentlichen auf eigene Untersuchungen und nicht auf das von Atari herausgegebene Dokumentationsblättchen, da es Atari scheinbar nicht möglich ist, vollständige Informationen über das Betriebssystem zur Verfügung zu stellen.

Wir werden hauptsächlich über das BIOS und das GEMDOS berichten. Die Erweiterungen und Ergänzungen des BIOS (ausgenommen der Bildschirm-Treiber) sind (hoffentlich) vollständig beschrieben. Am GEMDOS wurden außer den bei „Uhrzeit und Datum“ und „Optimierungen“ beschriebenen Kleinigkeiten keine Änderungen vorgenommen. Am GEM und Desktop wurde erheblich mehr geändert, doch liegen hier erst wenige Erkenntnisse über die internen Veränderungen vor. Die detaillierteren Informationen richten sich hauptsächlich an solche Leser, die schon über Programmierkenntnisse des TOS verfügen. Zum vollen Verständnis der Erklärungen zur Speicher- und Programmverwaltung sei auf den Artikel „TOS intern“ im neuen ST-Sonderheft verwiesen.

Speicherbelegung

Das neue TOS reserviert sich vom RAM zusätzliche 10496 Byte für den eigenen Bedarf, wovon allein 10000 Byte für die Vergrößerung des internen GEMDOS-Speichers gebraucht werden. AES und Desktop benötigen 256 Bytes zusätzlich, der Rest wird für einige zusätzliche BlOS-Variablen für die neuen Fähigkeiten des TOS gebraucht. Im einzelnen zeigt die Systemvariable savptr ($4A2) nach dem Reset weiterhin auf $93A, die BIOS- und GEMDOS-Variablen gehen bis $88A2 (dies wurde auf $8900 aufgerundet) und die AES/Desktop-Variablen reichen bis $CA00.

Die Aufteilung der 192 kB ROM hat sich ebenfalls geändert. Um im ROM Platz für die neuen Blitter- und Uhrzeit-Routinen zu bekommen, mußte irgendwo gespart werden. Die naheliegenden Möglichkeiten wie Verwendung der „Short-Adressierung“ beim Zugriff auf die Systemvariablen und die Peripherie-Bausteine, das Streichen überflüssiger, d. h. nicht benutzter Routinen, Neuprogrammierung der verschwenderischen Hardcopy-Routine usw. wurden nicht genutzt. Einige BIOS-Routinen wurden ein klein wenig umgeschrieben, aber das macht nur wenige Bytes Ersparnis aus. BIOS und GEMDOS sind durch die kleinen Ergänzungen um einige Bytes länger geworden.

Doch woher stammt der benötigte Platz? Zum einen wurden der BIOS-Bildschirm-Treiber, Line A und das VDI gründlich überarbeitet. Dabei wurde teilweise optimaler programmiert, viele Routinen sind kaum wiederzuerkennen. Außerdem wird jetzt beim Zugriff auf die BIOS/Line A/VDI-Variablen platzsparender verfahren (Registerindirekt- statt Absolut-Adressierung), dies spart pro Zugriff immerhin 2 Bytes. Da in diesem Teil die sehr langen Blitter-Routinen untergebracht sind, sind Line A und VDI trotz der Optimierungsmaßnahmen noch 4,4 kB länger geworden. Erstaunlicherweise wurden im AES/Desktop ca. 3,6 kB eingespart. Wie das erreicht wurde, ist noch unbekannt. Hier wurden aber offensichtlich ebenfalls größere Änderungen vorgenommen, wie man an den sichtbaren Auswirkungen sieht.

Optimierungen

Neben der Verkürzung des TOS wurden auch einige zeitliche Optimierungen vorgenommen:

Das Löschen des Speichers beim Einschalten des Rechners wurde um 19 % beschleunigt, bei 4 MB dauert dies aber immer noch ca. 1,7 Sekunden.

Beim Laden eines Programms wird der restliche freie Speicher gelöscht. Dies war sehr langsam, aber die dadurch entstandene Pause von 1,9 s (bei einem „leeren“ ST) fiel wegen der Nachlaufzeit der Floppy nicht so auf. Bei 4 MB-Rechnern traten allerdings unangenehm lange Pausen beim Starten eines Programms auf. Das TOS hat jetzt eine sehr schnelle, 6 mal schnellere Speicher-Löschroutine, so daß die Zeit für das Speicherlöschen bei einem „leeren“ 4 MB-ST „nur“ 1,4 s dauert. Bei künftigen TOS-Versionen und „Super-STs“ mit noch mehr RAM sollte sich Atari allerdings überlegen, ob das Löschen des Speichers nicht ganz weggelassen werden sollte, da es eigentlich überflüssig ist (bei sauber geschriebenen Programmen); es reicht nämlich, nur das BSS-Segment des geladenen Programms zu löschen.

Das Bildschirm-Löschen des BIOS und VDI wurde mit der gleichen Routine beschleunigt (11,3 ms statt 18 ms).

Durch die Überarbeitung des Bildschirm-Treibers und des GEM sind die meisten Bildschirmausgaben schneller geworden.

Beseitigung von Fehlern

Mit der Erstellung einer neuen TOS-Version hatte Atari eine gute Gelegenheit, Fehler zu beseitigen. Dies wurde leider nur teilweise genutzt, es wurden nämlich nur einige Fehler im BIOS (und wohl auch im GEM) behoben. An das von Digital Research stammende GEMDOS haben sich die Programmierer von Atari wohl nicht herangetraut, denn dort wurde kein einziger Fehler beseitigt, obwohl es mehr als genug davon gibt. Auch im BIOS gibt es noch Fehler, die nicht beseitigt wurden.

Zum GEMDOS gibt es nur zu sagen, daß die Größe des internen GEMDOS-Speichers von 3000 auf 8000 Words erhöht wurde. Dies hat zur Folge, daß die „Fehler“ in der Speicherverwaltung und im Zusammenhang mit vielen Ordnern, die ja eigentlich gar keine Programmierfehler sind, sondern „nur“ aus Speicherplatzmangel entstehen, behoben sind.

Doch nun zu den Änderungen im BIOS:

In der Reset-Routine wurde die fehlerhafte Abfrage des PAL/NTSC-Flags aus dem TOS-Header korrigiert. Bei Farbdarstellung ist der Default-Wert für die Bildwiederholfrequenz bei der deutschen TOS-Version jetzt also 50 Hz.

Der Bildschirm wird jetzt zu Beginn des Speicherlöschens beim Einschalt-Reset gelöscht und nicht erst danach.

Die nicht benutzten Auto-Interrupt-Vektoren 1,3,5 und 7 waren bisher Undefiniert. Nun werden solche Interrupts, die eigentlich gar nicht auftreten können, ignoriert.

Wenn beim Lesen oder Schreiben ein Fehler auftritt, wird die Operation mehrmals wiederholt, bevor mit einer Fehlermeldung abgebrochen wird. Wenn eine ganze Gruppe von Sektoren hintereinander geschrieben oder gelesen wird, war bisher die Anzahl der Versuche auf die ganze Gruppe bezogen. Konnte also der erste Sektor z. B. erst nach dem dritten Versuch gelesen werden, so wurde beim zweiten Sektor schon nach dem ersten Versuch abgebrochen. Nun gibt es bei jedem Sektor drei Versuche. Die Korrektur dieses Fehlers hat weiterhin zur Folge, daß das BIOS den Floppy-Controller nun alle Sektoren einzeln lesen läßt und den „multiple read“-Befehl nicht mehr verwendet.

Beim Lesen eines Sektors von Diskette werden jetzt zusätzlich vom Floppy-Controller gemeldete CRC-Fehler erkannt, sie wurden bisher ignoriert.

Wenn bei einem Diskettenzugriff ein CRC-Fehler erkannt wurde, lieferte das BIOS die Default-Fehlermeldung, das sind -10 (Schreibfehler) oder -11 (Lesefehler), anstelle der eigentlich vorgesehenen Fehlermeldung -4 (CRC-Fehler). Umgekehrt lieferte es einen CRC-Fehler, wenn der Default-Fehler auftreten sollte. Dieser Fehler ist nun behoben.

Die RS232-Routinen waren wohl so fehlerhaft, daß sich kleine Korrekturen nicht mehr lohnten. Sie wurde nämlich komplett neu programmiert. Ob die RS232-Schnittstelle jetzt richtig funktioniert, konnte noch nicht eindeutig festgestellt werden.

Beim Reset wird der Tastaturprozessor nur noch mit der Byte-Folge $80, $01 statt $80, $01, $12, $1A initialisiert. Außerdem wird danach eine Pause von ca. 0,18 s eingelegt.

Beim Senden eines Bytes an den Tastaturprozessor wird ca. 5,2 ms lang gewartet, nachdem er als empfangsbereit erkannt wurde.

Die Systemvariable drvbits ($4C2) wird nun in der Reset-Routine gelöscht. Damit werden alle zusätzlichen Laufwerke wie RAM-Disks usw. beim Reset ordnungsgemäß abgemeldet.

Neue TOS-Funktionen

Das BIOS wurde um eine Funktion für den Blitter erweitert. Der Funktionsumfang von GEMDOS, VDI und AES wurde nicht vergrößert, insbesondere die im alten TOS nicht implementierten VDI-Funktionen des PC-DOS-GEM fehlen weiterhin. Allerdings ist es nicht auszuschließen, daß einzelne Funktionen erweitert wurden, ähnlich wie die Formatier-Funktion des BIOS (s. u.).

Die von der GEMDOS-Funktion Sversion gelieferte GEMDOS-Versionsnummer ist weiterhin $1300.

Der Blitter

Der Blitter ist bekanntlich ein in die MEGA-STs eingebauter neuer Custom-Chip, der die Grafik erheblich beschleunigt. Die Treiber-Routinen sind in den Grafik-Kern des ST (Line A und BIOS-Bildschirm-Treiber) integriert, so daß alle Programme, die ihre Grafik durch die vorgesehenen TOS-Funktionen (die letztlich alle auf den Grafik-Kern zurückgreifen) auf den Bildschirm bringen, automatisch in den „Genuß“ des Blitters kommen. Programme, die die Grafik ohne Unterstützung durch das TOS erzeugen, werden also durch den Blitter nicht beschleunigt.

Der Blitter belegt die Adressen ab $FF8A00. Da bei den alten STs ein Zugriff auf diesen Bereich zu einem Bus Error führt, kann das TOS erkennen, ob ein Blitter eingebaut ist, indem es Blitter-Register ausliest und sich merkt, ob ein Bus Error auftritt.

Intern hat das TOS eine Liste mit 10 Sprungvektoren für 10 elementare Grafik-Funktionen wie z. B. „ein Zeichen auf dem Bildschirm ausgeben“. Jede BIOS-Bildschirm-Treiber- oder Line A-Funktion führt nun indirekte Sprünge über diese 10 Sprungvektoren aus, wann immer eine elementare Grafik-Funktion gebraucht wird. Die 10 Funktionen existieren je zweimal, einmal mit und einmal ohne Verwendung des Blitters. So kann durch einfaches Auswechseln der Sprungliste der Blitter aktiviert und deaktiviert werden.

Um den Grafik-Kern von Programmen aus „umzuschalten“, wurde die XBIOS-Funktion 64 namens Blitmode implementiert. Ihr wird ein Word-Parameter übergeben, der folgende Werte annehmen darf:

Parameter = -1:
Die Funktion gibt den Blitter-Status zurück. Ein gesetztes Bit 1 gibt an, daß überhaupt ein Blitter vorhanden ist, es sich also um einen MEGA-ST handelt. Ein gesetztes Bit 0 zeigt an, daß der Blitter auch tatsächlich aktiv ist, d. h. vom Grafik-Kern des TOS benutzt wird. Bei den alten STs sind Bit 0 und 1 dementsprechend immer Null. Die anderen Bits haben keine Bedeutung.

Parameter = 0:
Der Blitter wird ab jetzt nicht mehr vom TOS benutzt. Außerdem gibt die Funktion den Blitter-Status vor dem Abschalten des Blitters zurück.

Parameter = 1:
Der Blitter wird aktiviert. Falls gar keiner vorhanden ist, ändert sich natürlich nichts. Hier wird ebenfalls der Blitter-Status vor der Aktivierung zurückgeliefert.

Das BIOS schaltet den Blitter übrigens beim Reset in jedem Fall ab.

Es bleibt zu hoffen, daß diese neue Funktion möglichst bald in die Bin-dings der Compiler aufgenommen wird.

Uhrzeit und Datum

Bekanntlich sind die neuen Mega-Ataris mit einer residenten Uhr ausgerüstet. Dabei handelt es sich aber nicht um die Uhr des Tastaturprozessors, sondern Atari hat einen eigenen Uhrenchip eingebaut.

Er liegt an den ungeraden Adressen ab $FFFC21. Bei den alten STs ergibt ein Zugriff keinen Bus Error, sondern $FF. Das TOS erkennt das Vorhandensein des Uhrenchips, indem es Register auf bestimmte Werte überprüft.

Diese Hardware-Uhr muß nun mit der softwaremäßigen, interruptgesteuerten Systemuhr des GEMDOS, die für die in Diskettenverzeichnissen eingetragene und von Programmen angezeigte Zeit zuständig ist, ständig übereinstimmen.

Beim Reset wird die Systemuhr nach der Hardware-Uhr gestellt, falls sie vorhanden ist.

Wenn die Systemuhr mit den GEMDOS-Funktionen Tsettime oder Tsetdate gestellt wird, wird die Hardware-Uhr ebenfalls gestellt. Bei den alten STs wird dabei die Uhr des Tastaturprozessors auf die neue Zeit gesetzt. Dies war beim alten TOS nicht der Fall, dort wurde die Tastaturprozessor-Uhr von GEMDOS überhaupt nicht benutzt. Diese kleine Inkompatibilität wird allerdings bei bestehenden Programmen kaum etwas ausmachen.

Tgettime und Tgetdate lesen in jedem Fall die Systemuhr aus. Die XBIOS-Funktion #22 (Settime) bzw. #23 (Gettime) setzt bzw. liest bei den MEGA-STs nun die neue Hardware-Uhr, bei den alten STs wird wie beim alten TOS die Tastaturprozessor-Uhr angesprochen. Bei-den neuen STs kann die Tastaturprozessor-Uhr also gar nicht mehr benutzt werden, außer natürlich mit direkten Kommandos an den Tastaturprozessor. Bei den alten STs hat Settime beim alten und neuen TOS keinerlei Einfluß auf die Systemuhr, bei den neuen STs wird bei jedem Programmende (Pterm) die Hardware-Uhr in die Systemuhr übertragen. Programme, die die über das XBIOS angesprochene Uhr bisher für eigene Zwecke gebraucht haben, verstellen also bei den neuen STs die Systemuhr!

Erweiterte Disk-Formatier-Funktion

Die XBIOS-Funktion 10 (Spur formatieren) wurde erweitert. Die folgende neue Aufrufmöglichkeit ist:

Flopfmt (puffer, sectlist, dev, spt, track, seite, -1, magic, virgin)

Die Parameter puffer, dev, spt, track, Seite, magic, virgin haben die übliche Bedeutung. Der „Interleaving-Faktor“ -1 führt dazu, daß ’sectlist’ (nomalerweise unbenutzt) als Zeiger auf eine Tabelle mit soviel Sektornummern (words), wie ’spt’ angibt, interpretiert wird. Die Spur wird aus den in dieser Fiste angegebenen Sektoren in der spezifizierten Reihenfolge zusammengesetzt. Man kann also die Nummern und Reihenfolge der Sektoren vollkommen frei wählen. Wenn die Diskette später mit den normalen BIOS-Funktionen gelesen werden soll, muß man natürlich darauf achten, daß jede Sektornummer von 1 bis spt genau einmal vorkommt.

Erweiterter TOS-Header

Der TOS-Header, der gleich am Anfang des TOS liegt, enthält 4 zusätzliche Adressen, so daß der Rest des TOS um 16 Byte verschoben ist. Er sieht nun folgendermaßen aus:

Bei Version 1.0 sind Schwierigkeiten mit dem internen GEMDOS-Speicher aufgetreten, da nur 6000 Bytes dafür reserviert waren. Deshalb ist das Problem mit Festplatten aufgetreten, wenn diese sehr viele Ordner enthielten, und auch die Funktion Malloc konnte nur sehr sparsam benutzt werden, da jedes Anlegen eines Speicherbereichs einen Eintrag in der internen GEMDOS-Speicherliste benötigt, die schnell überfüllt war. Beim TOS 1.2 besitzt der GEMDOS-Speicher nun eine Größe von 16000 Bytes, was für normale Anwendungen ausreichend sein sollte.

’mifl’ dient der Erweiterung des internen GEMDOS-Speicherbereichs, falls 8000 Words immer noch nicht genug sein sollten. Interessanter wäre die Adresse des Memory Parameter Block gewesen, da dann Programme die legale Möglichkeit gehabt hätten, die Speicherverwaltung zu manipulieren.

FC0024 dc.l $000E61 Adresse der BIOS-Variablen 'kb_shift'

’kb__shift’ (Byte) enthält den Status der Sondertasten der Tastatur, wie ihn auch die BIOS-Funktion 11 (Kbshift) liefert. Damit ist es möglich, eigene Tastatur-Interrupt-Routinen zu schreiben, die den Tasten-Status benötigen und ändern wollen. Direkt im Anschluß an ’kb_shift’ liegen noch weitere Tastatur-Variablen, allerdings ist nicht bekannt, ob deren relative Adressen zu ’kb__shift’ von Atari für spätere TOS-Versionen garantiert sind. Deswegen werden sie hier nicht angegeben.

FC0028 dc.l $0087CE Adresse der GEMDOS-Variablen ’act_pd’

’act_pd’ ist der Zeiger auf den Prozeß-Deskriptor des aktiven Prozesses. Hiermit bieten sich neue Möglichkeiten, Multi-Tasking zu realisieren, da GEM-DOS dies prinzipiell ermöglicht. Beim Umschalten zwischen zwei Programmen müßte ’act_pd’ immer auf den aktiven Prozeß gesetzt werden, dann würden sich alle GEMDOS-Kommandos für Speicherverwaltung, Diskettenoperationen usw. automatisch immer auf den richtigen Prozeß beziehen! Verschiedene Programme können gleichzeitig Speicherbereiche belegen, eigene Dateipfade und Dateien haben usw. Nur die Zeichen-orientierte Peripherie wäre allen gemeinsam. Dann müßte man nur noch GEM die gleichzeitige Verwaltung mehrerer Haupt-Applikationen beibringen...

FC002C dc.l 0 ;reserviert?

Beim Reset wird eine Kopie des TOS-Headers im RAM angelegt. Diese Kopie wird so modifiziert, daß beim Sprung auf ihren Beginn ein Reset im ROM ausgeführt wird, genau wie wenn man den TOS-Header im ROM direkt anspringt. Dies wird erreicht, indem der BRA-Befehl des Headers auf einen JMP-nach-Reset-Befehl (unmittelbar vor dem Header) führt. Weiterhin wird das PAL/NTSC-Flag (relative Adresse $1C) mit dem Default-Systemdatum (relative Adresse $1E) überschrieben, es fragt sich nur, wozu. Außerdem sind nach dem Header noch 16 Bytes freigelassen worden.

Die BIOS-Variablen sysbase ($4F2) wird ebenfalls beim Reset auf diese TOS-Header-Kopie gesetzt. Damit haben Module im EPROM-Port die Möglichkeit, den TOS-Header zu verändern und anschließend in die normale Reset-Routine zurückzuspringen. In der Reset-Routine werden nämlich verschiedene Daten aus dem Header benutzt. Es ist allerdings zwecklos, die drei neuen Variablen-Adressen zu manipulieren, da BIOS und GEMDOS direkt auf die durch sie bezeichneten Variablen zugreifen. Erst nach dem Abarbeiten des AUTO-Ordners und vor dem Start des GEM oder eines C OMMAND.PRG mittels der cmdload-Option des Bootsektors, wird sysbase wieder auf den TOS-Header im ROM gesetzt. Somit haben also auch Programme im AUTO-Ordner die Möglichkeit, den TOS-Header zu manipulieren, es fragt sich nur, was das an dieser Stelle noch nutzt. Weiterhin wird vor dem Laden eines COMMAND.PRG der Cursor nicht mehr eingeschaltet.

Neue Systemvariablen

Es sind einige neue „legale“ Systemvariablen hinzugekommen, die ohne weiteres benutzt werden dürfen, da deren Adressen auch bei zukünftigen TOS-Versionen gleich bleiben.

$51A ist ein dritter ’memvalid’-Wert. Er wird genau wie ’memvalid’ ($420) und ’memval2’ ($43A) beim Ermitteln der Speicherkonfiguration gesetzt (hier auf $5555AAAA). Wenn beim Reset alle drei Variablen ihren festen „Magie-Wert“ noch enthalten, wird nicht mehr der ganze Speicher gelöscht, und die Speicherkonfiguration wird übernommen. Wozu diese dritte Variable gut sein soll, ist unklar.

Die BIOS-Funktionen Bconstat, Bconin, Bcostat und Bconout werden jetzt über indirekte Sprünge aufgerufen. Die Sprungvektoren liegen für die vier Funktionen in der obigen Reihenfolge ab $51E, $53E, $55E bzw. $57E. Dabei sind bei jeder Funktion 8 (statt bisher 6) Geräte erlaubt. So springt das BIOS z. B. bei einem Bconin (2) über den Vektor $546. Die neuen Geräte 6 und 7 tun nichts, denn die Vektoren zeigen auf Leer-Funktionen. Durch die Einführung dieser Vektoren erleichtert sich z. B. die Programmierung von Drucker-Spoolern o. ä. Außerdem besteht die Möglichkeit, neue Geräte in eigenen Programmen zu definieren.

Änderungen des Desktop (AES)

Auf dem MEGA ST mit Blitter besitzt der DESKTOP einen Menüeintrag, mit dem der Blitter wahlweise ein-oder ausgeschaltet werden kann. Beim normalen Atari sieht der DESKTOP bis auf die Copyrightzeile genauso aus wie beim TOS 1.0. Die Änderungen, die wir bisher festgestellt haben, sind folgende:

Beim Kopieren eines Files auf gleicher Ebene in sich selbst (klingt kompliziert, passiert aber leicht, wenn man ein ICON ein bißchen bewegt und wieder losläßt, so daß der DESKTOP kopieren will) war bisher das File zerstört. Bei der neuen Version bleibt das File erhalten.

Die Pfeile, mit denen die Slider bewegt werden, besitzen jetzt eine automatische Wiederholfunktion, wenn man mit der Maus auf sie zeigt und den linken Mausknopf gedrückt hält. Diese Änderung ist auch bei anderen Programmen, die mit Fenstern arbeiten, aktiv, so daß wahrscheinlich der Eventmanager des AES jetzt etwas anders funktioniert.

Die witzigen Fehler, wie Aufhängen des Event Managers, wenn man ein Icon schnell mit Doppelklick in die Menüzeile schiebt oder die Umschaltung in den vergrößerten 6A6 Font bei Benutzung eines angemeldeten Laufwerks mit der Kennung (Paragraph) sind noch mit in die neue Version gewandert.

Verbessert wurde wahrscheinlich die Auswertung der Rechteckliste beim Redraw. Der Redraw erfolgt im allgemeinen flüssiger als bisher.

Die Benutzung eines Unterstrichs ist jetzt bei allen Dialogboxen ohne Probleme möglich. Je nachdem, wie ein Edit-Feld definiert war, führte es bisher zum Absturz.

Ein Wermutstropfen zum Schluß: Beim Arbeiten mit dem neuen TOS wurde ein selbst geschriebener Harddisktreiber verwendet (der von Atari fragt zwecks Erweiterung der Speicherliste das TOS-Datum ab). Innerhalb dieser Zeit wurde dreimal das Inhaltsverzeichnis einer Partition mit dem Inhaltsverzeichnis einer normalen Diskette aus dem Laufwerk A: überschrieben. Die Ursache ist bisher noch nicht geklärt, die Wirkung war die Zerstörung einer Woche Arbeit. Bleibt zu hoffen, daß dies nicht an dem neuen TOS liegt...

Alex Esser/Oliver Joppich (a little bit)