Programmiererecke: IKBD - dein Freund und Helfer
Die Programmierung des »IKBD«-Chips der TOS-Computer scheint vielen Fachleuten immer noch ein Buch mit sieben Siegeln zu sein. Dabei ists einfacher als es scheint.
Kurz nach der Veröffentlichung von »XBOOT«, einem Programm, das »GEM-Komfort« im AUTO-Ordner bietet, fragten mehrere Leser, wie es denn möglich sei, die Maus schon vor der Initialisierung von GEM einzusetzen. Abgesehen davon, daß XBOOT dazu Line-A-Routinen benutzt, über deren Zweckmäßigkeit lange diskutiert wurde, gibt es eine vollkommen »legale« Methode, Mausbewegungen auch ohne Betriebssystemroutinen auszuwerten. Die Lösung ist der »Intelligent Keyboard«-Chip (kurz KBD) jeder ST- und TT Tastatur. Dieser Prozessor wertet unabhängig vom übrigen System Tastatur-, Maus und Joystick-Ereignisse aus.
Dazu verwendet er ein eigenes Betriebssystem, das uns jedoch nicht weiter zu interessieren braucht. Wichtig ist nur, daß der IKBD-Chip auch dann noch arbeitet, wenn das eigentliche Betriebssystem TOS beschädigt oder noch gar nicht vollständig installiert ist. Diese Konstellation tritt beispielsweise beim Booten auf: BIOS, XBIOS, GEM-DOS und, solange sie noch unterstützt werden, Line-A-Dispatcher sind installiert. Um nun die Maus-Ereignisse auszuwerten, muß man die vom IKBD-Chip gemeldeten Events selbst überprüfen. Dazu klinken Sie eine entsprechende Routine erst einmal in den entsprechenden Tastaturvektor. Einen Zeiger auf die »KBDVECS«-Struktur, in der Sie alle IKBDVektoren finden, erhalten Sie nach dem Aufruf der »Kbdvbase«-Funktion (XBIOS 34). In dieser Struktur tauschen Sie (selbstverständlich nach dem XBRA-Verfahren) die bisherige Routine durch eine eigene aus. Falls Sie also Maus-Ereignisse auswerten möchten, ersetzen Sie den Wert in »mousevec« (Offset $10) durch die Adresse Ihrer eigenen Routine. Ihre Routine erhält nun bei jedem Maus-Ereignis im Adreßregister A0 einen Zeiger auf ein REL_MOUSE-Paket, in dem alle wichtigen Daten aufgeführt sind:
typedef struct
{
char header;
char dx, dy;
}REL_MOUSE;
Dabei enthalten die unteren beiden Bits in »header« den aktuellen Zustand der Maustasten, »dx« und »dy« enthalten die Veränderung der Mausposition in X- und Y-Richtung seit der letzten »Paketlieferung«. Mit diesen Werten läßt sich ein eigener Mauszeiger bewegen. Unser Assemblerlisting verdeutlicht die Vorgehensweise.
Damit ist aber die Kapazität des IKBD-Programms noch lange nicht ausgereizt: Dem IKBD-Chip können auch Datenstrings zugesandt werden, die ihn in einen anderen Betriebsmodus umschalten, woraufhin er andere Datenpakete liefert. Dazu benutzen Sie am einfachsten die OS-Funktion »Ikbdws()« (XBIOS 25). Mit unserem Beispiellisting bewehrt, sollte es Ihnen jedoch nicht schwerfallen, eigene Tastaturtreiber zu schreiben.
TT-Speicherverwaltung
In den November- und Dezember-Ausgaben des ST-Magazins beschrieben wir die Aufgabe der kürzlich dokumentierten Bits im Programmheader [2], [3]. Nun hat sich bei näherer Untersuchung herausgestellt, daß Bit 2 (»memory allocation in TT-RAM«) im GEM-DOS nur ungenügend berücksichtigt wird: Bei Speicheranforderungen von Accessories wird es vollkommen vernachlässigt.
Erinnern wir uns: Das erweiterte RAM des TT taugt für verschiedene Operationen nicht. Beispielsweise kann der Videoshifter auf diesen Speicher nicht zugreifen und der DMA-Soundchip ist nicht in der Lage, hier liegende Samples abzuspielen. Deshalb lädt das TT-TOS alle Programme grundsätzlich ins STRAM, in den Speicherbereich, der in der Hardware weniger beschränkt ist, in dem Programme jedoch langsamer arbeiten, weil der MC68030 einige Wartezyklen mehr einlegen muß. Programme, die auf die erweiterten Fähigkeiten des ST-RAM verzichten können, lassen sich als solche kennzeichnen. Sie lädt das TOS dann ins TTRAM, sofern dort genug Platz vorhanden ist. Ähnlich verfährt das OS mit angeforderten »Malloc()«-Speicherblöcken: Grundsätzlich erhält das Programm ausschließlich ST-RAM-Blöcke, außer es wird entsprechend gekennzeichnet.
Die Kennzeichnung, die im Programmheader im long »ph_res2« vorgenommen wird, funktioniert auch bei Programmen hervorragend - nicht aber bei Accessories. Denn während Bit 1, das die Programm-Relozierung ins TT-RAM erlaubt, einwandfrei arbeitet, hat Bit 2 für Accessories keine Bedeutung. Vielmehr richtet sich die Herkunft der »Malloc()«-Blöcke nach den Spezifikationen des gerade laufenden Hauptprogrammes. Wenn dieses sich mit Speicherblöcken aus dem TT-RAM zufriedengibt, dann erhalten auch alle Accessories ihre Speicherblöcke aus dem TT-RAM, sofern davon noch ausreichend vorhanden sind. Ansonsten erhalten alle Accessories Speicherblöcke im ST-RAM.
Bildschirm maßlos
Dieses Verfahren wirkt sich selbstverständlich auch auf Accessories aus, die nach dem im November vorgeschlagenen Verfahren residente Speicherblöcke anfordern [4]. Da der TOS 3.1-Desktop grundsätzlich mit TT-RAM arbeitet, erhalten auch alle Accessories, die während seiner Laufzeit Speicher allozieren, Blöcke aus dem TT-RAM und können deshalb beispielsweise keinen DMA-Sound von dort aus abspielen. So bleibt es am Programmierer, bei vorhandenem TT-RAM die Funktion »Mxalloc()« zu verwenden, um die Herkunft der Speicherblöcke zweifelsfrei sicherzustellen.
Es wirkt wohl leicht befremdlich, wenn Programmierer im Jahre 6 nach GEM immer noch nicht in der Lage sind, die aktuelle Bildschirmgröße korrekt zu ermitteln.
In einem Artikel schlägt ein Autor nämlich vor, die XBIOS-Funktion Getrez() (XBIOS 4) zur Feststellung der momentanen Auflösung zu verwenden. Dazu sei an dieser Stelle gesagt, daß diese Methode äußerst unsauber ist. Atari schreibt dazu in der TT-Dokumentation [5]:
»The existence of the new video modes will reveal the lazy programming practices of developers who make assumptions about the screen, like its resolution, the number of colors available, and the size of the screen image in memory.«
Im Klartext: Annahmen bezüglich fester Bildschirmgrößen oder der Farbdarstellungen sind nichtig.
Atari schreibt weiter:
»Even writing »resolution-independent« code which calls Getrez() is not good enough, since Getrez() will return values for the new modes which were impossible (and therefore unanticipated) on an ST.«
Das heißt, jedes neue Gerät kann neue Auflösungen benutzen und deshalb werden unbekannte Getrez()-Werte zurückgegeben. So ists beim TT geschehen. Doch auch wenn Getrez() bekannte Werte zurückliefert, bedeutet das noch lange nicht, daß eine Standardauflösung benutzt wird. Niemand garantiert, daß ein ST-Bildschirm immer 32 KByte und ein TT-Screen immer 150 KByte groß ist. Diverse Grafikkarten produzieren bekannte Getrez()-Resultate, verwenden aber eigene Auflösungen.
Deshalb möchten wir an dieser Stelle noch einmal die drei sichersten Verfahren zur Feststellung der aktuellen Auflösung auflisten:
- Das VDI teilt dem Programm schon beim Öffnen der virtuellen Workstation mit, welche Maße der Bildschirm hat. Die Werte finden Sie in work_out[0] und work_out[1]. Die Anzahl der Farbebenen (Planes) liefert die vq_extnd()-Funktion in work_out[4].
- Das AES besitzt zum Feststellen einer Fenstergröße eine eigene Routine. Da der Bildschirmhintergrund immer das Fenster mit der Nummer 0 ist, läßt sich die Größe problemlos mit wind_get(0, WORK_XYWH, &dummy, &dummy, &breite, &hoehe); ermitteln. Die Anzahl der Planes finden Sie im global-Feld in global[10].
- Einige Programme (beispielsweise Interruptroutinen) dürfen keine AES- oder VDI-Aufrufe tätigen. Ihnen bleibt nichts anderes übrig, als sich in den negativen Line-A-Variablen nach der Bildschirmgröße zu erkundigen. Die Line-A-Routinen sollen in späteren TOS-Versionen verschwinden. Da die »Initialization«-Funktion ($A000) aber nichts als einen Zeiger in A0 liefert, und ansonsten überhaupt nichts bewirkt, ist diese Funktion ziemlich sicher. Die Ausmaße des Bildschirms erhalten Sie in -$2(A0); (int BYTES_LIN) und -$4(A0); (int V_REZ_VT) Die Anzahl der Planes und sämtliche vq_extnd()-Werte befinden sich in der Tabelle int INQ_TAB[45] ab Offset -$30E relativ zur Line-A-Basis.
Prozessortest
Mit diesen Informationen ist es leicht, eine <Alternate> - <Help> -Hardcopy-Routine zu schreiben, die ganz im Gegensatz zum vorgestellten Programm auf jedem Monitor und auf allen Auflösungen funktioniert. Es ist interessant zu beobachten, wie jetzt, da der TT in größeren Stückzahlen produziert wird, die Programmierer erneut dieselben Fehler begehen wie in den Anfangszeiten der STs. So erschien kürzlich ein Programm, das anhand der TOS-Versionsnummer den Computer und den Prozessortyp, auf dem das Programm lief, bestimmt haben wollte. Davor sei gewarnt! Die OS-Versionsnummer gibt darüber keinerlei Aufschluß. Vielmehr läßt sich die verwendete Maschine nur sicher anhand der »_MCH«-Einträge im »Cookie-Jar« feststellen [6], [7]. Im »_CPU«-Cookie bestimmt man unabhängig davon den verwendeten Prozessor, denn wer sollte Atari daran hindern, einen ST mit einem »68020er-Piggyback« laufen zu lassen? Sollten die Cookies aus irgendwelchen Gründen fehlen, dann bleibt Ihnen noch ein anderes Verfahren: Sie lassen einen Befehl ausführen, den der MC68000 nicht kennt, dafür aber beispielsweise der MC68010. Falls ein unbekannter Befehl auf einem 68000er ausgeführt werden soll, erzeugt dieser eine »Illegal-Opcode«-Exception, die man durch das Verbiegen des entsprechenden Exception-Vektors abfangen kann. Andernfalls ist kein 68000er verwendet worden. So kann man nach und nach jeden Prozessor vom MC68000 bis zum MC68040 austesten.
Wo liegt das Betriebssystem?
Irrig ist auch die Annahme, das TOS müßte sich an irgendeiner festen Stelle befinden. Das Betriebssystem der STEs liegt nämlich an anderen Adressen als das der STs! Und auch hier ist keine absolute Sicherheit gewährleistet, schließlich kann es sich auch um ein ladbares OS im RAM handeln. Einen wirklich sicheren Zeiger auf die Anfangsadresse einer OSHeader-Struktur erhalten Sie nur in »_sysbase« auf Adresse $4F2. In dieser Struktur finden Sie in »os_start« (Offset $8 in der OS-Header-Struktur) die Adresse, an der das Betriebssystem beginnt. Die Länge des TOS ist bislang nicht sicher feststellbar.
Download 'automaus.s' (3,5 KB)
Literaturverweise
[1] H.-D. Jankowski, J. Reschke, D. Rabich: »Atari ST Profibuch«, 2. Auflage, Seiten 766ff., Sybex Verlag 1989.
[2] J. Reschke, »Medley im TT-RAM«, ST-Magazin 11/90, Seiten 66f., Markt & Technik Verlag.
[3] L. Prüßner, »Datenwirbel«, ST-Magazin 12/90, Seiten 124f., Markt & Technik Verlag.
[4] L. Prüßner, »GEM-Verkehrsplanung: Aktion sauberer Bildschirm«, ST-Magazin 11/90, Seiten 68ff., Markt & Technik Verlag.
[5] »The TT030 Companion: Developers Notes For The Atari TT030«, Atari Corp. Sunnyvale 1990.
[6] »STE TOS Release Notes«, Atari Corp. Sunnyvale 1990.
[7] J. Reschke, »Vorhang auf für die Keksdose«, ST-Magazin 3/90, Seiten 62f., Markt & Technik Verlag.
Laurenz Prüßner uw