 Fehlerkorrekturen im neuen TOS V 1.4
 ====================================


Das neue Betriebssystem besitzt ein wesentlich berarbeitetes Desktop und ein
um einiges besseres AES - Grund genug, mit seiner Installation zu liebugeln -
wenn da nicht das GEMDOS wre, dessen Programmierer in der Vergangenheit fr
einige berraschungen gut waren...

Als Besitzer des wohl mittlerweile bekanntgewordenen KAOS - dem fehlerkorri-
giertem Blitter-TOS (im Bezug auf das GEMDOS) - bin ich, was die Zuverlssig-
keit des TOS angeht, ziemlich verwhnt, zumal man als Festplattenbesitzer diese
nicht gern (weil das BS es nicht anders kann) nur mit 2 Sektoren/Block parti-
tionieren will - meine Festplatte ist auf 8 Sektoren/Block ausgelegt, was eine
ziemlich hohe Datenrate ermglicht. Doch nun kommt TOS 1.4 - wie sieht es also
damit aus ?
Um es vorweg zu sagen: die GEMDOS-Programmierer scheinen aus ihrem Dornrschen-
Schlaf erwacht (geworden) zu sein - im GEMDOS wurde eine Menge berarbeitet.
Trotzdem ist noch einiges unschn und ein wenig noch fehlerbehaftet. Grund
genug, sich darum zu kmmern.
Was also wurde getan ?

Nun, zum einen wurde die (von der Konzeption bereits stark verbesserte) Datei-
Verwaltung optimiert - dort waren bereits fast alle Fehler beseitigt.
Durch eine Neuprogrammierung des Disk-Managers in handoptimiertem Assembler
statt in C (der Digital-Research C-Compiler ist insgesamt so mies geblieben)
konnte eine weitere Geschwindigkeitssteigerung erreicht werden. Dieses fllt
besonders bei der Verwendung von mehreren Disk-Puffern auf - Harddisk-Caches
lohnen sich jetzt also voll ! Der zweite grere Komplex war der Dispatcher - 
jener Teil also, der sich um die I/O-Umlenkung kmmert, zusammen mit den
zeichenorientierten Funktionen.
Die einzelnen Verbesserungen in Kurzbersicht:
1) Disk-Manager (nicht die bergeordneten Funktionen)

Hier wurde, wie bereits gesagt, durch eine Neuprogrammierung in Assembler
sehr viel an Ausfhrzeit eingespart, was den Gesamtdurchsatz des Systems
noch einmal erhht.
2) Schreib-Lese-Hauptfunktion
Durch eine Fehlerbeseitigung in dieser Funktion ist es jetzt ohne irgend-
welche Schwierigkeiten mglich, Medien mit mehr (oder weniger) als 2 Sektoren/
Block zu verwalten. Festplattenbesitzer wird es freuen.
3) Medium-Erkennung
Durch eine vollstndige Neuprogrammierung dieser Funktion wird eine nahezu
perfekte Fehlererkennung durchgefhrt - Disk-Formate, die das ursprngliche
TOS unweigerlich in Jenseits schickten, werden jetzt zurckgewiesen. Das 
Desktop meldet hierbei 'Ungltiges Laufwerk', ebenso natrlich die DOS-
Funktionen.
4) Datentrger allgemein
Durch einen logischen Fehler, der sich bis ins TOS 1.4 fortgeschleppt hat,
werden immer 2 Blcke zu wenig verwaltet, was dazu fhrt, da z.B. eine
Diskette mit 2 Sektoren/Block 2 KByte weniger Speicherplatz zur Verfgung
stellt, als auf ihr vorhanden sind ! Dieser Fehler ist behoben. Man kann
jetzt den Datentrger ganz beschreiben. Dieser Fehler ist altbekannt.
Bleibt anzumerken, da die so beschriebenen Disketten auch von jedem
anderen TOS gelesen werden knnen ! MS-DOS kommt natrlich ebenso damit
klar - dort gibt es diesen Fehler natrlich nicht... (siehe Formatieren)
5) Datei-Verwaltung
In Anlehnung an KAOS habe ich es mir nicht nehmen lassen, die Einhaltung
der Open-Modi zu berwachen. Das heit, da man eine Datei, die man nur
zum Lesen geffnet hat (Modus 0) nicht beschreiben kann (Fwrite). Dem
Original-TOS ist das egal. Ebenso kann man eine nur zum Schreiben (Modus 1)
geffnete Datei nicht lesen (Fread). Beides ist nach wievor mit dem Modus 2
mglich. Wozu gibt es solche Modi sonst ??? Ein ungltiger Modus liefert
wie ein o.a. Regelverstoss die Fehlermeldung 'Zugriff verweigert'.
Weiterhin drfen nun offene Dateien nicht mehr gelscht werden ! Diese
sehr unsaubere und schwere Fehler heraufbeschwrende Eigenschaft hatte
das TOS mit Absicht von den Programmierern erhalten. Dieses ist aber
meiner Meinung nach zu viel des 'Guten'. Als Nebeneffekt dieser Ein-
schrnkung knnen Dateien jetzt nicht mehr durch 'Kopieren auf sich
selbst' zerstrt werden. Zuwiderhandeln wird mit einem Fehlercode
'Zugriff verweigert' (-36) bestraft.
6) Datei-Suche
Durch einen Fehler in der Suchmuster-Auswertung wurden immer noch Dateien
mit gesetztem Archiv-Bit als normale Dateien 'verkauft' - Auf MS-DOS-Dis-
ketten erschien z.B. die Disketten-Kennung als normale Datei, die System-
Dateien tauchten ebenfalls auf. Durch die Behebung dieses Fehlers treten
endlich normale Verhltnisse ein.
7) Programm-Ausfhrung
Die zum Laden und Relozieren eines Programms dienende Funktion wurde von
Atari zwar grndlich berarbeitet - es bleiben bei einem Fehler keine
offene Dateien zurck - einige Unzulnglichkeiten gab es aber noch.
Die jetzige Funktion ist nicht nur wesentlich schneller (fllt leider kaum
ins Gewicht), sondern auch sehr penibel was die Fehlererkennung angeht.
Es drfte jetzt schwer fallen, eine nicht-Programm-Datei zu starten (was
natrlich zu einem Zusammenbruch fhren wrde). Auch werden Relokations-
Tabellen mit mehr als 32 KByte ohne Fehler verarbeitet. Ungerade Relozierungs-
werte werden jetzt nicht mit 3 Bomben geahndet - der Code 'ungltiges
Programm-Format' wird zurckgeliefert.
>>>Achtung<<< Durch diese sehr sorgfltige Fehlerberprfung kann es bei
einigen Programmen mit fehlerhafter Relokationstabelle zu einer Ausfhr-
Verweigerung kommen ! Der Fehlercode (-66) wird vom Desktop als TOS-Fehler
35 gemeldet. Sagrotan schimpft auch ber solche Programme. Wer den Linker,
der diesen Fehler produziert, kennt, wende sich bitte an mich. Mir sind 
bisher aber nur 2 Programme mit diesem Fehler bekannt - Omikron BASIC V 3.0
(welch Ironie !) und A-Copy V 1.2. Der Fehler lsst sich einfach beheben - 
ein 0-Byte an das Programm anhngen und die Datei-Lnge um 1 erhhen.
Bleibt noch zu sagen, da jetzt auch vollkommen positions-unabhngige
Programme laufen - einige Linker erzeugten nicht die korrekte Tabelle
fr diesen Fall. Auch solche Programme werden als nicht-relokatibel
erkannt und gestartet.
8) Bomben
Der Bomben-Generator liefert jetzt den Code -69 zurck (nicht 1). Das
bewirkt, da die Terminierungs-Ursache als Fehlererkannt werden kann, was
im Desktop im Falle von GEM-Anwendung durch die Ausgabe eines TOS-Fehlers
geschieht. Man kann somit in Ruhe die Bomben zhlen - fr Kenner eine 
praktische Sache.
9) Der Dispatcher, oder: 'jetzt geht es los'
Wie allseits bekannt sein drfte, funktionierte die I/O-Umlenkung bis
zum Blitter-TOS berhaupt nicht. Hier wurde einiges getan, leider nicht
genug. Deshalb habe ich den Dispatcher vllig neu geschrieben, was einmal
dazu fhrt, da er nun so funktioniert, wie man es von ihm erwartet, zum
anderen springt dabei eine nicht unerhebliche Geschwindigkeits-Steigerung
heraus.

Alle zeichenorientierten Funktionen lassen sich nun umleiten, sei es in
eine Datei oder auf ein anderes Gert.

Die Status-Funktionen liefern auch in diesem Fall ein korrektes Ergebnis.
Alle Ein/Ausgabe-Funktionen (Cconout, Cconin) liefern eine 0 bei Misserfolg
(Datei-Ende z.B.) bzw. den Zeichencode oder die Anzahl ausgegebener Zeichen.
TOS 1.4 war hier sehr inkonsequent.
Die serielle Schnittstelle wird nun auch mit dem DOS-internen Puffer bedient.
Somit gehen keine Zeichen mehr bei einer Umlenkung verloren ! Ebenso kann
durch ein Ctrl-C von der seriellen Schnittstelle bei den dafr vorgesehenen
Funktionen ein Programm-Abbruch erreicht werden.

Alle Funktionen arbeiten so, wie es in der Digital-Research-Beschreibung von
GEMDOS (und die Leute sollten es ja wissen !) steht.

Cconin liest von STDIN und schreibt nach STDOUT (!), Cconrs bricht nur
im Falle eines Return/NL ab und verweigert berzhlige Eingaben mittels
Warnton.

>>>Anmerkung<<< Bei Cconrs werden nicht n sondern n-1 Zeichen eingelesen !
Das letzte Zeichen ist immer ein CR ! So steht es geschrieben, so soll es
sein ! Gleiches gilt fr Fread(CON,...), mit Ausnahme von n = 1, wobei
nur ein Zeichen gelesen wird.
Bei einem Ctrl-C wird '^C' nebst Zeilenvorschub ausgegeben - MS-DOS lsst
grssen.

Die Funktionen des Zeilen-Editors,
  ^R: Zeile neu ausgeben
  ^U: Zeile verwerfen
  ^X: Zeile lschen
funktionieren richtig. Steuerzeichen bringen die Bildschirmposition nicht
mehr durcheinander.

Die Gerte 'CON:','AUX:','PRN:' werden auch dann von Fopen/Fcreate erkannt,
wenn sie nicht nur gross oder nur klein geschrieben werden. Es darf auch ein
ganzer Pfadname angegeben werden, z.B. d:\emil\franz\PrN: wird als Drucker
erkannt. Ein neues Gert, das Null-Device 'NUL:' ist hinzugekommen, was
ja auch von MS-DOS bekannt ist. Es wird weiterhin berprft, ob man versucht,
eine Datei mit dem Namen eines Gertes zu versehen (Frename, Dcreate). In
einem solchen Fall wird der Fehlercode 'Zugriff verweigert' (-36) zurck-
geliefert, da solche Dateien nicht mehr geffnet werden knnen, eben weil
ja das Handle eines Gertes bei Fopen zurckgeliefert wrde !
>>> Anmerkung <<< Fr alle die, die es noch nicht wissen: Diese Gerte
haben negative Handles !!! Um sie von einem Fehler zu unterscheiden, muss
man Fopen/Fcreate als LONG (!) betrachten ! Dieses ist brigens auch im
Original-TOS der Fall. Turbo-C z.B. betrachtet sie als INT, was falsch ist.
Andere negative Handles fhren nicht mehr zum Systemzusammenbruch !
Wie bereits gesagt - um diese Korrekturen anzubringen, wurde der gesamte
zeichenorientierte Teil neu geschrieben. Weitere Einzelheiten wrden hier
zu weit fhren.
10) Media-Change
Bei einem Disketten-Wechsel werden jetzt auch die zugehrigen Standard-Pfade
ALLER Prozesse (auch der Eltern-Prozesse) aufgegeben !!! Dieser Fehler, der
bei Atari wohl immer noch vllig unbekannt ist, bewirkt einen vllig
unkontrollierten Zugriff auf Standard-Pfade, was besonders Wechselplatten-
Besitzer in arge Bedrngnis fhrt (kennt jemand einen ?).
11) Die Formatier-Funktion
Wie jedermann weis gibt es im neuen TOS eine neue Formatier-Funktion. Sie
liefert jetzt MS-DOS-kompatible Disketten. Leider wird das Datum der
Disketten-Kennung falsch angelegt, so da einige DOS-Funktionen meinen,
es handele sich wahrscheinlich nicht um eine DOS-Diskette. Nun ja.
Die Formatier-Funktion wurde vllig neu geschrieben. Sie erzeugt nicht nur
vollstndig kompatible DOS-Disketten, sondern, und jetzt kommt's:
Disketten knnen einmal mit 9 Sektoren/Spur formatiert werden, wie blich.
Durch Drcken der Alternate-Taste beim Anklicken von 'FORMAT' wird die
Diskette aber mit 10 Sektoren/Spur formatiert !!! Dieses Format ist vllig
im grnen Bereich ! Keine Angst also vor den 800 KByte ! Allerdings sollte
man solche Disketten nicht MS-DOS unterjubeln...

Der Formatier-Vorgang kann (wie auch das Kopieren/Lschen) mittels UNDO
abgebrochen werden. Es kann vorkommen, da man UNDO mehrmals drcken muss,
da das Desktop ebenfalls auf einen Tastendruck wartet und manchmal die
Taste wegschnappt.
12) BIOS-Korrekturen
Hier wurden ebenfalls einige Korrekturen durchgefhrt, die aber nur kurz
erlutert werden sollen.

 - Rwabs weigert sich bei noch nicht eingelesenem Bootsektor seine
   Ttigkeit zu verrichten. Im Original wurde ein einseitiges Format
   angenommen, was meist dazu fhrte, da der Schreib/Lese-Kopf mit
   voller Wucht gegen den Anschlag sauste und dort einen hllischen Krach
   machte - sehr ungesund brigens fr das Laufwerk !

 - Protbt liefert bei ungltigem Typ-Parameter nicht mehr Mll.
   Weiterhin wurde das Disketten-Format dem von MS-DOS angepasst,
   was bewirkt, da auf einer 2-seitigen Diskette 2 KByte mehr
   Platz finden - ohne Risiko, versteht sich !

 - alle bergeordneten Disk-Funktionen wurden neu und in Assembler
   geschrieben (statt C). Sie laufen um einiges schneller ab
 
 - Getbpb ist jetzt auch sehr pingelig gegenber falschen Disk-Formaten.
   Es werden nur noch einwandfreie Disketten akzeptiert.

   Anmerkung: Wer einen Disketten-Wechsel simulieren mchte kann das
   wie folgt tun: Rwabs wird mit einem Puffer-Zeiger von 0 aufgerufen.
   In diesem Fall wird die Sektor-Anzahl als neuer Media-Change-Status
   bernommen !!! Das gilt aber nur fr die Disk-Laufwerke !!!
   Diese Besonderheit gibt es schon sehr lange, sie ist nur nirgendwo
   dokumentiert...

 - Rsconf enthielt einen Fehler, den es beim Blitter-TOS noch nicht
   gab - endlich mal was ganz neues ! Und zwar konnte das Handshake
   mit RTS/CTS (Modus 2) nicht mehr eingestellt werden ! Dieser
   Fehler ist behoben, ebenso die falsche Baudraten-Einstellung bei
   50 bzw. 75 Bd, die 80 bzw. 120 Bd lieferte. Dieser Fehler existiert
   schon seit Menschengedenken (fast jedenfalls); man sollte Atari 
   'mal schreiben !
 
   Anmerkung: Ab TOS 1.4 kann man mit Rsconf(-2,...) die eingestellte
   Baudrate abfragen !

 - VBL-Interrupt-Server
   Der Interrupt-Server enthielt einen Fehler: ein Wechsel der Bild-
   schirmadresse mit Setscreen() bewirkte, da in jedem VBL durch
   ein vergessenes Rcksetzen des screenptr der Bildschirmstart
   immer aufs neue gesetzt wurde ! Jetzt wird ebenso wie mit dem
   colorptr verfahren. Weiterhin werden ungltige VBL-Slots (also
   ungerade Startadresse, negative Werte) nicht ausgefhrt, was zu
   einem Crash fhrte, sondern als der VBL-Queue rausgeschmissen.

 - Boot-Device
   Das Boot-Device wird nun korrekt im Environment eingetragen. Damit
   steht dort nach einem Festplatten-Boot korrekterweise 'PATH=C:\',
   was ebenfalls bis heute (durch den AHDI, der das mit viel Code-
   Aufwand hingipst) bei Atari unbekannt sein drfte.

 - System-Datum
   Im TOS 1.4 war wohl vorgesehen, da bei fehlender Echtzeituhr das
   (resetfeste) Datum/Zeit des Tastatur-Prozessors bernommen wird.
   Nur leider (welch Ironie !) schlich sich ein Fehler ein, so das
   wiederum immer das DOS-Erstellungsdatum nebst mitternchtlicher
   Arbeitsstunde bernommen wurde. Der Fehler ist beseitigt, der
   Tastaturprozessor kommt zu seinem Recht.

 - AUTO-Ordner
   Durch Drcken der Control-Taste beim Hochfahren kann jetzt ein
   Starten der AUTO-Ordner-Programme verhindert werden. Somit
   kann man auf einer Diskette mit einem selbst-startenden Programm
   noch andere Programme unterbringen (fr Spiele sehr interessant).

   Weiterhin sei angemerkt, da die Extension der AUTO-Programme
   von .PRG auf .TOS gendert wurde. Dieses hat den einfachen
   Grund, da es sich ja um TOS-Applikationen handelt, die bei
   einem spteren Anklicken im Desktop flschlicherweise als
   GEM-Applikationen gestartet werden !

 - Software-Reset
   In Anlehnung an MS-DOS hat Atari die Tastenkombination Ctrl-Alt-Del
   fr einen Warmstart eingefhrt. Drckt man dazu noch die rechte
   Shift-Taste, so wird ein Kalststart durchgefhrt. Leider erfolgte
   diese Tastenabfrage NACH einer Abfrage des Tastatur-Puffers, was dazu
   fhrte, da bei vollem Puffer auch kein Warm/Kaltstart mehr mglich
   war. Jetzt wird auf jeden Fall erst diese Tastenkombination ab-
   gefragt.




  Um das neue TOS fr jedermann zugnglich zu machen, habe ich viel
  Zeit investiert, um aus der Original ROM-Version eine lauffhige
  RAM-Version zu erstellen. Es ist gelungen. Sie setzt jedoch einen
  Recher mit (genau) 1 MByte voraus, da das TOS immer ab Adresse
  $D0000 gebootet wird. Andere Versionen knnen aber ebenfalls
  bereitgestellt werden.

  Gelesen im WDR Kom-Com

  MRT
  
   Originalfassung von Robert Schaffner.
 
 Vernderte Texte die sich im Umlauf befinden entsprechen teilweise 
 nicht mehr meiner Orginalfassung und sollten besser gelscht werden.
 
 Insbesondere z.B: REPS.LZH
                 : REPA.LZH
                 : REPA_ST.LZH
                 
 Robert Schaffner @ OF2 (MausNet)
