      Ohne Handbremse
      Atari bootet mit OMTI

Mit einer Festplatte und einem OMTI-Kontroller kann 
man sich viel Leistung fr den Atari erschlieen. 
Und das fr wenig Geld. Doch was kostet ist der 
Bootvorgang. Nach jedem Reset ist wieder warten 
angesagt, bis alle Accessories und Programme aus 
dem Autoordner von der langsamen Diskette geladen 
wurden. Mit ein paar Programmen kann der Atari sich 
aber auch alleine den Festplattentreiber von 
derselbigen laden.


Das geschilderte Problem drfte eigentlich jedem 
Benutzer einer Atari/Festplattenkombination bekannt 
sein. Fr einen einzigen Systemstart am Tag ist die 
Handbremse in Form einer Startdiskette kein 
sonderliches Manko. Die Bombenleger unter den 
Assemblerprogrammierern werden aber fr jeden der 
zahllosen Totalabstrze mit einem Diskettenboot 
nicht unter zwanzig Sekunden bestraft, was 
sptestens ab dem dreizigsten Reset langsam als 
nervig empfunden werden drfte.

Eine Lsung fr die Atari-Harddisk und hnliche war 
schon vor gut einem halben Jahr in der c't zu 
finden [1]. Fr den OMTI-Kontroller fehlt im TOS 
jedoch eine geeignete Routine um sich das 
Treiberprogramm von selbst aus dem Sumpf, bzw. von 
der Festplatte zu ziehen. Da die alte DMABOOT-
Routine im ROM-TOS sowieso fr die "Billiglsung" 
[3] nicht mehr bentigt wird, kann sie problemlos 
durch eine neue ersetzt werden.

      Die neue Startbahn ...

Der neue DMABOOT-Lader findet zweckmigerweise 
sein neues Zuhause, wo vorher die alte Routine zu 
finden war. Dies ist in der deutschen ROM-TOS 
Version vom 6.2.86 der Bereich von $fc04a8 bis 
$fc0575. Es war zwar etwas mhsam das Programm in 
den sprlich vorhandenen Platz hinein zu zwngen, 
doch lassen sich durch die Benutzung aller Register 
mit Register- beziehungsweise indirekter 
Adressierung etliche Bytes einsparen. Dadurch 
leidet natrlich die bersichtlichkeit und 
Wartbarkeit der einzelnen Programmteile, da man 
fast alle Register nicht mehr verndern darf.

Die Routine setzt als erstes den Kontroller zurck 
und ldt dann den Bootsektor in die zweite Hlfte 
des 1 KByte groen Diskbuffer des TOS, dessen 
Adresse in der Systemvariable _DSKBUFP ($4c6) zu 
finden ist. Die erste Hlfte des Diskbuffer sollte 
brigens nicht benutzt werden, da er spter whrend 
der Initialisierungsphase des Festplattentreibers 
HDBIOS [3] belegt wird. Nach dem Ladevorgang wird 
noch die Prfsumme des Bootsektors errechnet und 
bei bereinstimmung mit einer "magischen Zahl" wird 
das erste Byte des Bootsektors angesprungen.

Es drfte hoffentlich jedem klar sein, da die neue 
DMABOOT-Routine ein ROM-Patch ist. Somit ist der 
Besuch bei dem hilfsbereiten Bekannten mit dem 
EPROMmer natrlich mal wieder unerllich ! Wie man 
sich die EPROM-Dateien erstellt bleibt dem findigen 
Leser anheimgestellt (Tip: wenn man in [2] sucht, 
wird man brigens auch fndig).

Wenn die ROMs sowieso gendert werden, kann man
eigentlich noch die sechzehn Bytes fr das 
Bitmuster der "Bomben" ndern (die Dinger gehren 
weder auf den Bildschirm, noch woanders hin). Wie 
wr es denn mal mit einem "Keep-Smiling-Face"-
Muster ?

      ... fhrt in den Bootsektor

Eigentlich knnte das Ladeprogramm im Bootsektor 
doch bis auf die Leseroutine mit dem aus Heft 8/87 
bereinstimmen, oder ? Leider hat der OMTI-
Kontroller zwei kleine, aber Programmplatz 
fressende Unterschiede zum Atari-Kontroller: 
Erstens mssen die logischen Sektornummern in 
physikalische Zylinder-, Kopf- und Sektornummer 
umgerechnet werden, was nun nicht allzuviel Platz 
bentigt. Strender ist dagegen, da der Kontroller 
noch nicht "wei" wie gro denn die Platte ist und 
deshalb vorsichtshalber von nur zwei Kpfen 
ausgeht. Ohne eine Initialisierung ist somit die 
Festplatte nicht ohne Einschrnkung nutzbar. Doch 
pat eine zustzliche Kontrollerinitialisierung 
leider nicht mehr in den schon gerammelt vollen 
Bootsektor hinein.

Somit scheidet die Mglichkeit den Treiber als ein 
normales Programm in eine Partition zu schreiben 
und von dort laden zu lassen aus. Reserviert man 
sich allerdings den ersten (= nullten) Zylinder von 
der Festplatte fr die Bootprogramme ist das 
Platzproblem auch schon gelst. Ein Pluspunkt liegt 
brigens in dem schon vorgestellten Treiber HDBIOS: 
Er ist frei verschiebbar, wodurch man sich das 
Relozieren auch noch schenken kann.

BOOTLOAD ist der erwhnte Bootlader und startet 
eigentlich nur den Festplattentreiber. Da ja ein 
direktes Laden und Starten noch nicht mit einem 
Betriebssystemaufruf zu erledigen ist, mu dem TOS 
die Arbeit des Ladens abgenommen werden. Dazu wird 
erst eine Basepage erzeugt, ein Programm (i.A. 
HDBIOS) ohne den Programmkopf aus der ersten Spur 
hinter die Basepage geladen und dann ausgefhrt. 
Das zu ladende Programm mu sich dazu ab dem Sektor 
eins in der ersten Spur befinden. Die Lnge des 
Treiberprogramms in Sektoren wird brigens in 
BOOTLOAD bei dem Label PRG_LEN angegeben. Hierbei 
kann auch eine zu groe Lnge angegeben werden, da 
die wirkliche Lnge aus dem Programmkopf entnommen 
wird.

Zum Abschlu wird noch Laufwerk c: als Bootlaufwerk 
angemeldet. Gegebenenfalls kann aber bei dem Label 
BOOTDRV eine andere Laufwerksnummer gegeben werden. 
Mchte man fr die weiteren Warmstarts einen 
Diskboot ausschlieen, der generell noch vor der 
Routine DMABOOT ausgefhrt wird, kann die 
Systemvariable _BOOTDEV ($446) auch auf das 
eigentliche Bootlaufwerk gesetzt werden.

In dem Listing ist die betreffende Zeile allerdings 
auskommentiert, weswegen nach einem Reset weiterhin 
versucht wird von Diskette zu booten. Gerade in der 
Experimentierphase sollte man sich diesen 
Noteinstieg freilassen. So hat man die Mglichkeit 
mit einem gebooteten RAM-TOS und nachgeladenem 
Festplattentreiber einen defekten Bootlader doch 
noch durch ein funktionierendes(!) Programm zu 
ersetzen.

      Ein einfacher Generator

Nachdem man sich schon selbst um die Aufteilung und 
Erstellung der Dateien fr den EPROM-Brenner 
kmmern mu stellt sich dann auch die bange Frage 
"Wie bekomme ich denn nun Bootlader und 
Festplattentreiber an ihre vorgesehenen Pltze ?". 
Die Antwort lautet (nein, diesmal nicht 42 
sondern): BOOTGEN.

Dies pfiffige Progrmmchen kann beim Aufruf mit 
zwei Parametern versorgt werden: mit "b 
Dateiname.erw" wird das angegebene Programm in den 
Bootsektor geschrieben. Das Bootprogramm mu 
brigens frei verschieblich (PC-relativ) sein und 
darf nur das TEXT-Segment enthalten.

Der andere Aufruf betrifft, richtig geraten, den 
Festplattentreiber. Mit "t dateiname.erw" wird das 
gewnschte Programm ab Sektor eins in die erste 
Spur kopiert. Es darf maximal sechzehn Sektoren (= 
8 KByte) lang sein. Die ganz hastigen Benutzer 
knnen auch beide Parameter auf einmal angeben und 
mit einem Aufruf Bootlader und Treiberprogramm auf 
der Platte versenken. Danach darf natrlich keine 
Partition mehr auf Zylinder null anfangen.

Getreu dem Motto "Was schon geschrieben wurde kann 
weiterhin benutzt werden!" ist BOOTGEN.C ebenfalls 
mit den Programmen CBIND und HDBIOS aus [3] zu 
linken.

Zum Schlu einen Tip fr die Softwarebastler: 
Tauscht man in den Funktionen RD_SECT und WR_SECT 
die drei Funktionsaufrufe durch einen passenden 
BIOS-Aufruf RWABS (Sektoren lesen/schreiben von/auf 
Disk) aus, lassen sich recht einfach auch nette 
Bootprogramme auf die Diskette schreiben. Dann 
werden natrlich auch die ersten drei 
Funktionsaufrufe in der main-Funktion zum 
Initialisieren der Leseroutinen in HDBIOS nicht 
mehr bentigt.


!!! Listing 1 (dmaboot.s): Neu gegen alt; ein ROM-
    Patch der DMABOOT-Routine bedient den jetzt den 
    OMTI-Kontroller.

!!! Listing 2 (bootload.s): Dem TOS mu beim Laden 
    des Harddisktreibers krftig auf die Sprnge 
    geholfen werden.

!!! Listing 3 (bootgen.c): Bootlader und 
    Festplattentreiber werden mit BOOTGEN in einem 
    Startzylinder versteckt.


