Noch eine Stärke des neuen TOS

Programmiererecke: Wie TOS 1.4 Programme schneller lädt. Außerdem: eine universelle XBRA-Routine.

Die Vorteile, mit denen Atari sein überarbeitetes »TOS 1.4« bewirbt, überzeugen: eine bessere Fileselector-Box, Abhilfe beim 40-Ordner-Problem, Dateitransfer, beschleunigte Ein- und Ausgaberoutinen und erweiterte BIOS-, XBIOS- und GEMDOS-Funktionen. Was noch keiner erwähnte: Durch eine kleine Änderung im Programm-Header lädt das neue TOS auch Programme schneller.

Wie wir bereits in der Juli-Ausgabe berichteten [1], geht das Laden eines Programmes folgendermaßen vor sich: Zunächst öffnet das TDS die entsprechende Datei. Sofern genug freier Speicher zur Verfügung steht, lädt das Betriebssystem nun die einzelnen Segmente in den Speicher. Als nächsten Schritt legt das Betriebssystem das »Block Storage Segment« (BSS) an. Anschließend berechnet es den restlichen freien Speicher und löscht diesen. Dadurch ist gewährleistet, daß jedes neu geladene Programm auf ein leeres BSS und leere »Malloc«-Blöcke zugreifen kann. Dies geschah bei älteren TOS-Versionen noch mittels der langsamen »clr«-Befehle. Später ersetzten die Entwickler diese durch schnellere Routinen, beispielsweise mit »moveq«-Anweisungen oder, wie im TOS 1.4, mittels »movem«. Atari hat die Löschalgorithmen ständig verbessert, dennoch beansprucht ein Löschvorgang relativ viel Zeit. Der heutige, wohl endgültige Algorithmus benötigt zum Löschen des Speichers eines Mega ST 4 immerhin noch etwa eine Sekunde. Diese Prozedur wiederholt sich nach jedem Ladevorgang.

Eine oder zwei Sekunden sind nicht viel Zeit; doch vor allem während des Ladens der Auto-Ordner-Programme und der Accessories macht sich diese »tote« Zeit bemerkbar. Nun werden Sie sich wahrscheinlich fragen, warum Atari nicht gänzlich auf das Löschen verzichtet. Diese Frage beantwortet Ken Vailinger von Atari Development in Kalifornien so: »Wenn wir auf das Löschen des freien Restspeichers gänzlich verzichten, so kann es zu Fehlern kommen, denn leider gehen einige Programme einfach davon aus, daß sie auf einen leeren Speicher zugreifen können. Obwohl wir diese Eigenschaft des TOS nie dokumentiert haben, war es doch immer so und es wird auch immer so bleiben, das hat Tradition.« [2]

Der »File-Booster«

Trotzdem gibt es Fälle, in denen das Löschen unnötig ist: Bei eben den Programmen im »AUTO«-Ordner und Accessories. Deswegen hat Atari ein neues FIag geschaffen, durch das Sie bestimmen, ob nach dem Ladevorgang der Restspeicher gelöscht werden soll oder nicht. Diesen Flag finden Sie im Programm-Header, den Sie im Bild sehen. Bisher galt »ph_res2« als reserviertes Longword, das grundsätzlich den Wert 0 aufweist. Sie finden dieses Longword in den Bytes 22 - 25 (hexadezimal $16 - $19) relativ zum Anfang des Programm-Headers. Ab TOS 1.4 verhindern Sie den Löschvorgang nach dem Laden des Programms, indem Sie dieses Flag auf den Wert 1 setzen. Dies sollten Sie allerdings nur mit Programmen machen, bei denen Sie wirklich sicher sind, daß diese nicht von einem leeren Restspeicher ausgehen. Bei Programmen im »AUTO«-Ordner oder Accessories funktioniert es problemlos. Mit unserem GFA-Basic-Programm können Sie in ausführbaren Dateien das »ph_res2«-Flag setzen oder löschen. Dies funktioniert nicht nur mit ».PRG«-Dateien und Accessories, sondern auch bei ».TOS«- nd »TTP«-Anwendungen. Das Programm untersucht nach dem Start zunächst, ob Sie überhaupt mit der neuen TOS-Version 1.4 arbeiten. Dazu bedient es sich der GEMDOS-Routine »Sversion«. Stellt das Programm fest, daß es sich bei dem benutzten GEMDOS um eine frühere Version handelt, so gibt es eine entsprechende Bemerkung aus. Das Setzen oder Löschen des »Fast-Load-Flags« - diese Bezeichnung stammt übrigens nicht von uns, sondern von Vailinger selbst - hat dann keine Auswirkungen auf die Ladegeschwindigkeit.

Zunächst erscheint eine Dateiauswahlbox auf dem Bildschirm, mit der Sie das gewünschte Programm auswählen. Sobald Sie den Namen des betreffenden Programms eingegeben haben, testet der »FileBooster«, ob die angewählte Datei existiert und ob sie über einen Programm-Header verfügt, Daraufhin liest das Programm das »ph_res2«-Flag und gibt Ihnen dessen derzeitigen Status aus. Das Programm fragt Sie nun, ob Sie das Flag setzen oder löschen wollen. Das Programm bearbeitet daraufhin gemäß Ihrer Angabe das Flag und schreibt es ins Programm zurück. Sie beenden das Programm entweder durch das Anklicken des »Abbruch«-Knopfes in der Datei-Auswahlbox oder durch Bejahen der entsprechenden Abfrage. # Eine universelle XBRA-Routine

Vor einiger Zeit erreichte uns die Bitte aus der Leserschaft, doch einmal eine universell zu benutzende XBRA-Routine vorzustellen. Dieser Bitte kommen wir an dieser Stelle gern nach. Unser kurzes XBRA-Unterprogramm übernimmt die gesamte Installation für Sie. Rufen Sie die Routine nur im Supervisormodus auf. Dies gewährleistet einen Zugriff auf alle Speicherbereiche des RAMs, also auch auf alle Systemvektoren, für die das XBRA-Verfahren hauptsächlich gedacht ist. Am einfachsten benutzen Sie dazu die XBIOS-Routine »Supexec«. Der Aufruf sieht in Assembler folgendermaßen aus:

pea XBRA    ; XBRA ist der Anfangslabel des Unterprogrammes
move.w  #$26, -(sp) ; XBIOS 38 (»Supexec«)
trap    #14
addq.l  #6, sp  ; Stackkorrektur

Zuvor benötigt unsere Routine aber noch zwei Parameter, um ihre Aufgabe durchzuführen. Der erste ist die Adresse des Vektors, an dem das Unterprogramm die einzuklinkende Routine installieren soll. Diese Adresse übergeben wir im Adreßregister a3 an die XBRA-Routine. Außerdem müssen Sie die Adresse der einzuklinkenden Routine angeben. Direkt vor dieser Routine muß sich die bekannte XBRA-Struktur befinden. Die Adresse dieser Routine übergeben Sie im Adreßregister a4 an das XBRA-Unterprogramm. In Assembler sieht das so aus:

move.l  Vektor, a3
lea Neurout, a4

Nun stellen wir fest, ob das neue Programm sich bereits im Speicher befindet, oder ob das XBRA-Programm es gerade erst installiert hat. Dies erfahren wir durch den Rückgabewert d0. Nach Abschluß der XBRA-Routine enthält es entweder den Wert -1 oder 0. Wir erhalten den Wert 0, wenn unser Unterprogramm die einzuklinkende Routine gerade installiert hat. Das Datenregister d0 enthält den Wert -1, wenn bereits ein Programm mit der gleichen Erkennungsnummer den zu prüfenden Vektor belegt hat. Nun steht eigenen XBRA-Installationen nichts mehr im Wege. Bitte vergessen Sie nicht, Ihre XBRA-IDs bei Julian Reschke zu melden. Damit verhindern Sie, daß fremde Programme die gleiche Kennung wie Sie verwenden. (ba) [1] Laurenz Prüßner, »Auf dern Weg zum Programmierprofi«, ST-Magazin 7/1989, Seiten 56ff., Markt & Technik Verlag AG. [2] Scott Foust, »TOS 1.4 / Atari Corp. Conferences at WOA Show/Disneyland Hotel«, B.A.C.E.Line Vol.7 / No. 6, June 1989, B.A.C.E. publications / Allan Fillmore, 228 Plymouth Avenue, Bakersfield, California, 93308. USA.

Listing 1: Eine universelle XBRA-Routine in Assembler

; Universelle XBRA-Routine
; Geschrieben von Laurenz Prüssner am 4.7.1989
;
; Sprache: Assembler
; Ass.: GFA-Assembler 1.3
;
; Aufruf durch >>Supexec<< (XBIOS 38) an Label >>XBRA<<
;
; Param.übergaben: a3 die Adr. d. zu prüfendern Vektors
;                  a4 die Adr. d. einzuklinkenden Rout.
; Rückgabe in d0 und zwar: 0 Installiert
;                         -1 schon im System vorhanden
; Grüße an Markus, Sören und alle Midimaze-Fanatiker,
; an Claudio, Hühni, Vanessa, die Firma mit dem „O“.
;

XBRA:
    movea.l (a3), a5    ; Startadresse der Routine holen

Kette:
    move.l  a5, d7  ; Register d7 zur Zero-Flag-Kontrolle
    beq.s   Install ; mißbrauchen. a5=0 -> Kettenende.
    cmpi.l  #‘XBRA‘, -12(a5)    ; XBRA-Struktur gefunden?
    bne.s   Install ; Wenn nicht, dann gleich installieren
    move.l  -8(a4), d7  ; Ist es die gleiche Routine?
    cmp.l   -8(a5), d7
    beq.s   Found   ; Ja!
    movea.l -4(a5), a5  ; Nein!
    bra.s   Kette   ; Wenn nicht, weiterfahren.

Install:
    move.l  (a3), -4(a4)    ; Routine Installieren
    move.l  a4, (a3)
    moveq.l #0, d0  ; Flag in d0 setzen
    rts

Found: moveq.l #-1, d0 ; Flag in d0 auf #-1 setzen rts

Listing 2: Mit File-Booster bestimmen Sie, ob der ST nach dem Laden den Restspeicher löscht

´* ************************************************************* *
´* File-Booster                                                  *
´*                                                               *
´* Geschrieben am 23.7.1989 von Laurenz Prüssner                 *
´*                                                               *
´* Dieses Programm setzt in Programmen phres2 oder löscht        *
´* selbiges. Bei Rechnern mit TOS 1.4 verhindert dies ein        *
´* Löschen des Restspeichers                                     *
´*                                                               *
´* Dank an Neta Fillmore & B.A.C.E.                              *
´* ************************************************************* *
´
´* ************************************************************* *
´* Erst einmal GEMDOS-Version testen                             *
´* ************************************************************* *
a% = GEMDOS(48)
´ Neuere Version?
IF a% < &H1500
    PRINT „Sie benutzen noch nicht TOS “
    PRINT „1.4 oder eine neuere Version.“
    PRINT
    PRINT „Demzufolge kann es Ihnen“
    PRINT „eigentlich egal sein, ob“
    PRINT „ph_res2 gesetzt ist oder“
    PRINT „nicht.“
ELSE
    PRINT „Sie benutzen eine TOS-“
    PRINT „Version, auf die ph_res2“
    PRINT „Einfluß hat.“
ENDIF
PRINT
´
´* ************************************************************* *
´*  Programmauswahl                                              *
´* ************************************************************* *
PRINT „Welches Programm soll ich“
PRINT „bearbeiten?“
PRINT
PRINT „Mögliche File-Extensions:“
PRINT
PRINT „.PRG“
PRINT „.ACC“
PRINT „.TOS“
PRINT „.TTP“
FILESELECT „\*.*“,““, a$
´
´* Abbruch getippt? *
IF a$=““
    END
ENDIF
IF NOT EXIST (a$)
    ´* Programm überhaupt vorhanden? *
    PRINT „Programm gibt‘s nicht!“
ELSE
    CLR a%
    OPEN „U“, #1, a$
    IF LOF(#1) < &H1C
        ´* Hat die Datei einen Header? *
        PRINT „Das ist kein Programm!“
    ELSE
        BGET #1, VARPTR(a%)+2, 2
        IF a% <> &H601A
            ´* „ph_branch“ vorhanden? *
            PRINT „Das ist kein Programm!“
        ELSE
            SEEK #1, &H16
            BGET #1, VARPTR(a%), 4
            IF a%=0
                ´* Schon gesetzt?
                PRINT „Flag leer.“
                PRINT „Setzen (J/N)?“
                a$=CHR$(INP(2))
                IF a$=“Y“ OR aS=“j“
                    SEEK #1, &H19
                    OUT #1,1
                ENDIF
            ELSE
                PRINT „Flag gesetzt.“
                PRINT „Löschen (J/N) ?“
                a$ = CHR$ (INP(2))
                IF a$=“J“ OR a$=“j“
                    SEEK #1, &H19
                    OUT #1, 0
                ENDIF
            ENDIF
        ENDIF
    ENDIF
    CLOSE  #1
ENDIF
´
´* Programm jetzt beenden?
´
PRINT „Nochmal (J/N)?“
a$=CHRS(INP(2))
IF a$=“J“ OR a$=“j“
    RUN
ENDIF
END

So ist der Programm-Header unter TOS 1.4 aufgebaut

Der Programm - Header
Änderungen des TOS 1.4 wurden berücksichtigt.

Byte Name Funktion
$00 - $01 ph_branch MC 680x0 - Befehl zum Sprung an den Programmanfang. Hier MagiC-Word mit dem Wert $601A
$02 - $05 ph_tlen Die Länge des TEXT-Segmentes
$06 - $09 ph_dlen Die Länge des DATA-Segmentes
$0A - $0D ph_blen Die Länge des BSS
$0E - $11 ph_slen Die Länge der Symboltabelle
$12 - $15 ph_res1 Derzeit noch reserviert und demzufolge immer 0
$16 - $19 ph_res2 Seit TOS 1.4 ein Flag, welches verhindert, daß der ungenutzte Restspeicher gelöscht wird.
$1A - $1B ph_flag Laut Atari auch reserviert & normalerweise 0


Laurenz Prüßner


Links

Copyright-Bestimmungen: siehe Über diese Seite
Classic Computer Magazines
[ Join Now | Ring Hub | Random | << Prev | Next >> ]