      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.

