Einblick in die System - Variablen, Teil 3

Auf unserer Rundreise durch das Betriebssystem befassen wir uns zum letzten Mal mit den Systemvariablen. Dabei lernen Sie unter anderem alle Variablen für die Verwaltung der Video-Hardware und der Massenspeicher kennen.

Die Systemvariable »palmode« ($448.W) repräsentiert die Bildwiederholfrequenz in den farbigen Auflösungen. Der Wert 0 steht für 50 Hz, der Wert 1 für 60 Hz. In $44c.W liegt die Systemvariable »sshiftmd«. Sie enthält die aktuelle Videoauflösung. Die Werte entsprechen der XBIOS-Funktion »Getrez«. Beachten Sie in diesem Zusammenhang, daß Computer wie der Atari TT mehr Auflösungen besitzen und sich somit der Wertebereich erweitert. »Saubere« GEM-Programme sollten deshalb eine andere Methode benutzen, um die Auflösung in Frfahrung zu bringen: Nach Öffnung einer Virtual Workstation (VDI-Funktion »v_opnvwk«) erhalten Sie in intout[0], intout[1] und intout[13]/intout[39] die Rasterbreite, Rasterhöhe und Anzahl der Farben des geöffneten Gerätes zurück.

In welcher Auflösung befinden Sie sich, wenn Sie von Monochrom nach Farbe umschalten? Diese Frage klärt die Systemvariable »defshiftmod« ($44a.W). Bei 0 befinden Sie sich nach dem Umschalten in der niedrigsten, bei 1 in der mittleren Auflösung.

Damit Sie und das Betriebssystem auch ohne langwierige XBIOS-Aufrufe stets wissen, wo eigentlich der Bildschirmspeicher liegt, hält sich TOS die Systemvariable »_v_bas_ad« ($44e.L). Genau genommen enthält »_v_bas_ad« die logische Bildschirmbasis. Dorthin erfolgen alle Grafikausgaben. Daneben existiert noch die physikalische Bildschirmbasis; dies ist die Adresse, welche die Video-Hardware tatsächlich darstellt. Vorteil: Der physikalische ist sichtbar, während der logische Bildschirm gerade aufgebaut wird. Somit erhalten Sie flimmerfreie Animationen, wie es in vielen Spielen üblich ist. Die physikalische Basis hält sich das Betriebssystern in keiner Systemvariable. Allerdings existiert »screenpt« ($45e.L), die indirekt die physikalische und logische Bildschirmadresse auf die dort hineingeschriebene Adresse setzt. Indirekt deswegen, weil diese Systemvariable laufend vom VBI aus überprüft wird. Ist sie ungleich Null, so liest die VBI-Routine die Adresse aus und setzt die beiden Bildschirmbasen.

Neben »screenpt« überprüft der VBI noch die Systemvariable »colorptr« ($45a.L). Steht dort ein Wert ungleich Null, so interpretiert ihn die VBI-Routine als Zeiger auf eine Farbtabelle und setzt die Farben entsprechend der Tabelle.

Stellt das Betriebssystem fest, daß der Anwender zwischen Farb- und Monochrom-Monitor umgeschalten hat, macht der Computer einen Reset. Doch dieses Verhalten läßt sich über die Systemvariable »swv_vec« ($46e.L) steuern. An die dort eingetragene Adresse springt das Betriebssystem - oder genauer gesagt: die VBI-Routine -, nachdem ein Monitorwechsel stattgefunden hat und nachdem die neue Auflösung über »defshiftmod« gesetzt wurde. Normalerweise zeigt der »swv_vec«-Vektor direkt auf den Betriebssystembeginn (Offset $1e) - hier startet TOS mit dem Reset. Um etwa zu verhindern, daß TOS das laufende Programm bei einem Monitorwechsel unterbricht, verwenden Sie in GFA-Basic folgende Befehle:

    SDPOKE &H700, &H4e75    ! rts
    SLPOKE &H46e, &H700 ! setze swv_vec

Eigene Massenspeicher programmieren

Das BIOS des Betriebssystems nutzt die Vektoren »hdv_bpb« ($472.L), »hdv_rw« ($476.L) und »hdv_mediach« ($47e.L) als Zeiger auf die Funktionen »Getbpb«, Rwabs« und »Mediach«. Um etwa eine RAM-Disk oder einen Harddisk-Treiber zu schreiben, muß der Programmierer nicht das Betriebssystem verändern, sondern lediglich die drei Vektoren umbiegen und das der neuen Laufwerksnummer entsprechende Bit in »drvbits« ($4c2.L) setzen. In Listing 1 sehen Sie die für eine RAM-Disk-Verwaltung angepaßten drei neuen Routinen. Auf der Diskette finden Sie unter »RAMDISK.S« den vollständigen Quelltext.

Die Schlüsselfunktion ist »hdv_rw«. Sie liest eine bestimmte Anzahl von Sektoren vom Massenspeicher oder schreibt diese darauf. Die nötigen Parameter übergibt das Betriebssystem der Funktion auf dem Stack (siehe Tabelle 1). So sollten Sie dabei stets die Laufwerksnummer zuerst auswerten. Denn ist diese ungleich Ihrer eigenen, so müssen Sie unverzüglich die ursprüngliche »hdv_rw«-Routine anspringen. Aus diesem Grund eignet sich hier das XBRA-Protokoll (siehe Listing) besonders gut. Um Informationen über die angeschlossenen Massenspeicher zu erhalten, nutzt das Betriebssystem die Funktion »Getbp« und somit indirekt »hdv_bpb«. Als Ergebnis erhält es die Adresse auf einen sogenannten »BIOS Parameter Block« - kurz BPB - (siehe Tabelle 2) zurück. Listing 1 verbiegt »hdv_bpb« auf »mybpb«. Darin prüft das Programm zuerst, ob die RAM-Disk angesprochen wird. Wenn ja, dann gibt es die Adresse des konstanten BPB »protobpb« zurück.

Den dritten Vektor »hdv_mediach« nutzt das Betriebssystem, um festzustellen, ob in dem bestimmten Laufwerk in der Zwischenzeit eine Diskette gewechselt wurde. Das Ergebnis ist entweder 0 (Diskette nicht gewechselt), 1 (Diskette vielleicht gewechselt) oder 2 (Diskette gewechselt). Die RAM-Disk aus Listing 1 gibt stets den Wert 0 zurück. Beim Thema Massenspeicher-Verwaltung darf auch die Systemvariable »punptr ($516.L) nicht fehlen. Diese zeigt auf die sogenannte »Physical Unit Strukture«, die wichtige Daten über die angeschlossenen Festplatten und deren Partitionen enthält. Normalerweise legt der aktive Harddisk-Treiber (»AHDI«) »CBHD« etc.) die PUN-Struktur an. Leider kocht jedoch jeder Festplatten-Treiber sein eigenes Süppchen. Seit AHDI (»Atari Harddisk Driver«) 3.00 gibt es jedoch seitens Atari den AHDI-Standard, auf den ich mich im folgenden beziehe. Die Strukturkomponenten und wie Sie die Struktur erhalten, ersehen Sie aus Listing 2.

Der Struktureintrag »puns« enthält die Anzahl der vom Harddisk-Treiber gefundenen Fest- und Wechselplatten. In »pun« finden Sie zu jedem logischen Laufwerk die entsprechende ACSI-Gerätenummer. Dabei bedeutet der Wert $FF, daß der Treiber das entsprechende Gerät ignoriert. In »part_start« finden Sie für jede Partition den Startsektor auf der Platte. »p_max_sector« enthält schließlich die größte auftretbare Sektorgröße für BIOS-Sektoren.

Doch bevor Sie diese Informationen aus der PUN-Struktur auswerten, sollten Sie sicherstellen, daß sie auch im Sinne des AHDI 3.0-Standards gültig sind. Dazu dienen die beiden Einträge »p_cookie« und »p_cookptr«. »p_cookie« sollte die Zeichenkette »AHDI« enthalten und »p_cookptr« sollte auf »p_cookie« zeigen. Um endgültig sicher zu gehen, können Sie zudem die Versionsnummer »p_version« auf größer/gleich 3.0 testen.

Die Cache-Technik des GEMDOS

Auch das GEMDOS des Betriebssystems hält zwei äußerst wichtige Zeiger im Systenivariablen-Bereich: »_bufl[0]« ($4b2.L) und »_bufl[1]« ($4b6.L). Sie zeigen auf zwei Listen von Buffer Control Blocks (BCBs). Die BCBs verwendet CEMDOS um gelesene Sektoren vom Massenspeicher im RAM abzulegen und somit einen erneuten Zugriff auf diese Sektoren zu beschleunigen. Diese Technik nennt man auch »Caching« oder »Puffern«.

Den Aufbau eines BCBs finden Sie in Tabelle 3. Jeder BCB verwaltet einen Sektor. Die Verkettung der BCBs zu einer Liste erfolgt jeweils über den ersten Eintrag »next«, der auf den nächsten BCB zeigt. Besteht die Liste etwa aus zehn BCBs, so puffert GEMDOS zehn Sektoren.

»_bufl[0]« enthält den Zeiger auf eine BCB-Liste, welche die FAT-Sektoren der Massenspeicher puffert. Die FAT ist ein Datenbereich, der Informationen über die Lage der Cluster aller Dateien auf dem Massenspeicher enthält. »_bufl[1]« zeigt auf eine BCB-Liste, die zur Pufferung von Inhaltsverzeichnis- und Datensektoren dient. Normalerweise verwendet GEMDOS pro Liste je zwei BCBs bzw. zwei Sektoren. Um die Listen zu erweitern, müssen Sie lediglich drei Schritte durchführen:

Aus $4b2 oder $4b6 den Zeiger auf den Listenbeginn lesen und diesen Zeiger auf die eigene Listenerweiterung umbiegen (Kette von BCBs). Zuletzt setzen Sie den »next«-Zeiger in der letzten BCB-Struktur der Listenerweiterung auf den alten Listenbeginn.

In den neuen BCBs müssen Sie nur die »next«-, »drive«- und »buffer«-Einträge initialisieren; den Rest erledigt GEMDOS für Sie. Setzen Sie »next« auf den nächsten BCB und »drive« auf $ffff. Bei »buffer« taucht ein Problem auf. Wie groß ist überhaupt ein Sektor? Ganz einfach: normalerweise 512 Byte, es sei denn, die PUN-Struktur (»punptr«) gemäß AHDI-Standard existiert. In diesem Fall ergibt sich die Sektorgröße aus dem Eintrag »p_max_sector«. Listing 3 ist eine C-Prozedur, welche die benötigte Sektorgröße für Sie berechnet.

Der Vollständigkeit halber finden Sie in Tabelle 4 die noch nicht vorgestellten Systemvariablen. Diese sind abgesehen von Spezialanwendungen - nicht weiter interessant, so daß wir sie lediglich mit einer kurzen Erklärung versehen. Im nächsten Teil unserer Rundreise durch das Betriebssystem beschäftigen wir uns dann intensiv mit dem GEMDOS. (ah)

Literatur
Die Programmierung rund um Massenspeicher Brod, Stepper, »Scheibenkleister II - Massenspeicher am ST“, Eschborn: MAXON Computer GmbH, 1989, ISBN 3-927065-00-5

    hdv_bpb $472    ; getbpb-Vektor
    hdv_rw  $476    ; RWABS-vektor
    hdv_medich  $47e    ; mediach-Vektor
    secs = 1024     ; = 512 KB groesse (secs+18)*512
    ramdrv = 15     ; P:
    ...
        move.l  hdv_bpb, o_bpb
        move.l  #mybpb, hdv_bpb
        move.l  hdv_rw, o_rw
        move.l  #myrabs, hdv_rw
        move.l  hdv_mediach, o_media
        move.l  #mymedia, hdv_mediach
    ...
    ; mybpb
        dc.b    „XBRATOSD“
    o_bpb:
        dc.l    0
    mybpb:
        move.w  #ramdrv, d0 ; ist Ramdisk
        cmp.w   4(sp),d0    ; gemeint?
        beq newbpb
        move.l  o_bpb, a0
        jmp (a0)
    newbpb:
        move.l  #protobpb, d0
        rts
    ; myrwabs
        dc.b    „XBRATOSD“
    o_rw:
        dc.l    0
    myrwabs:
        move.w  #ramdrv, d0
        cmp.w   14(sp), d0
        beq newrw
        move.l  o_rw, a0
        jmp (a0)
    newrw:
        moveq   #O, d0
        move.w  12(sp),d0   ; secno
        lsl.l   #8, d0  ; * 512
        lsl.l   #1, d0  ; offset
        move.l  6(sp), a0
        move.w  10(sp), d1  ; seccnt
        subq.w  #1, d1
        move.l  puffer, a1
        add.l   d0, a1
        move.w  4(sp), d0   ; rw-flag
        btst    #0, d0
        beq copysec
        exg a0, a1  ; Quelle/Ziel vertauschen
    ; mymedia
        dc.b    „XBRATOSD“
    o_media:
        dc.l    0
    mymedia:
        move.w  #ramdrv, d0
        cmp.w   4(sp), d0
        beq newmedia
        move.l  o_media, a0
        jmp (a0)
    newmedia:
        moveq   #0, d0
        rts
    protobpb:       ; konstante BPB-Struktur
        dc.w    512, 2, 1024, 7, 5, 6, 18, secs/2, 0, 0, 0

Listing 1. Die Hauptbestandteile einer typischen RAM-Disk typedef struct { int puns; unsigned char pun[16]; unsigned long partstart[16]; long P_cookie; long *P_cookptr; unsigned int P_version; unsigned int P_max_sector; } PUNINFO;

PUN_INFO *GetPunPtr(void)
{
    PUN_INFO *P;
    long oldsp;

    oldsp = Super(0L);
    P = *((PUN_INFO **)(0x516L));
    Super((void*)oldsp);

    if (P && (P->P_cookie == 0x41484449L) &&
       (P->P_cookptr & (P->P_cookie)) &&
       (P->P_version >= 0x300))
        return P;   /* punptr war gueltig */
    return 0L;
}

int getBCBSize()
{
    PUN_INFO *p:
    if (( p = GetPunPtr()) != 0L)
        return p->P_max_sector;
    return 512;
}

Listing 2. Die Funktion »GetPunPtr« liest die vom AHDI-kompatiblen Festplatten-Treiber angelegte PUN-Struktur aus

int getBCBSize()
{
    PUN_INFO *p;
    if ((p = GetPunPtr()) != 0L)
        return p->P_max_sector;
    return 512;
}

Listing 3. Als Erweiterung zu Listing 2 erhalten Sie mit »getSize« die für die Buffer Control Blocks (BCBs) nötige Sektorgröße

Offset Länge Bedeutung
4(SP) WORD Lese (0)/Schreib (1)-Flag
6(SP) LONG Pufferadresse
10(SP) WORD Anzahl der Sektoren
12(SP) WORD Startsektor
14(SP) WORD Laufwerksnummer

Tabelle 1. Diese Belegung weist der Stack beim Aufruf von hdv_rw auf

Offset Länge Bedeutung
0 RECSIZ Sektorgröße in Byte
2 CLSIZ Clustergrüße in Sektoren
4 CLSIZI3 Clustergröße in Byte
6 RDLEN Wurzelverzeichnislänge in Sektoren
8 FSIZ Größe der FAT in Sektoren
10 FATREC erste Sektornummer der zweiten FAT
12 DATREC Nummer des ersten Datensektors
14 NUMCL Anzahl der Datencluster
16 BFLAGS 0: 12-Bit-FAT 1: 16-Bit-FAT

Tabelle 2. Aufbau der BIOS Parameter Block-Struktur (BPB)

Offset Name Bedeutung
0 next Zeiger auf nächsten BCB
4 drive Laufwerksnummer oder A
6 typ Puffertyp (0:FAT, 1:Verzeichnis, 2:Daten)
8 rec interne GEMDOS-Sektornummer
10 dirty Änderungsflag <>0 - geändert)
12 dmd Zeiger auf Drive Media Deskriplor
16 buffer Zeiger auf den Sektorpuffer

Tabelle 3. Aufbau eines Block-Control-Blocks (kurz BCB)

Spezielle Systemveriablen

o o o
$48e.4L themd 4 Langworte für Ur-Memory-Deskriptor
$49e.2W __md 2 Worte für zusätzliche Memory Deskriptoren
$4a2.L savptr Zeigt auf BIOS-Puffer für Prozessregister
$4ac.W save_row Puffer für Cursorzeile
$4ao.L sav_context Zeigt auf Exception-Pufferspeicher
$4ba.L hz_200 200 Hz-Zähler
$4be.L the_env Voreinstellung der Programmumgebung (Environment)
$4f6.L _shell_p Zeigt auf eine Shell-Routine, die Kommando-Zeilen verarbeitet
$506.L prt_stat Zeigt auf Routine, die den Druckerstatus holt
$50a.L prt_vec Zeigt auf Druckausgabe-Routine
$50e.L aux_stat Zeigt auf Routine, die RS232-Status holt
$512.L aux_vec Zeigt auf RS232-Ausgabe-Routine
$51e.8L bconst_ptrs 8 Zeiger für jedes BIOS-Gerät auf Routinen, die den Eingabestatus holen
$53e.8L bconin_ptrs 8 Zeiger für jedes BIOS-Gerät auf Routinen, die ein Zeichen einlesen
$55e.8L bcostat_ptrs 8 Zeiger für jedes BIOS-Gerät auf Routinen, die den Ausgabestatus holen
$57e.8L bconout_ptrs 8 Zeiger für jedes BIOS-Gerät auf Routinen, die ein Zeichen ausgeben

Tabelle 4. Diese Systemvariablen sind nur für Spezialanwendungen interessant
Martin Backschat


Links

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