TOS-ACC: Multi-Accessory im Quelltext, Teil 3

In diesem Teil unseres Projekts widmen wir uns zunächst einer tiefgreifenden Änderung im Programmaufbau. Diesbezüglich gehen wir ausführlich auf die Installation und Nutzung des »Cookie-Jar« ein. Im Rahmen neuer Tools für das TOS-Accessory besprechen wir außerdem die Konfiguration der seriellen und parallelen Schnittstelle.

Anders als beim Film, in dem Regisseure die Spannung durch Vorenthalten wichtiger Informationen bis zum Schluß aufrechterhalten, geht es bei uns gleich richtig los. Hier also die Vorstellung der neuen Tools. Als da wären das Einstellen der seriellen Schnittstelle, wie auch des Druckers und die Aufteilung des Accessories in einen residenten Teil und einen Accessory-Teil. Dies ist notwendig, um die Auflösung nach Belieben zu ändern, ohne gleich einen Reset durchführen zu müssen. Besonders letztere Erweiterung verlangt eine krasse Veränderung der in den beiden vorherigen Ausgaben des TOS-Magazins vorgestellten Quelltexte. Durch das ständig wachsende Angebot an Grafikkarten, dem damit in Verbindung stehenden Preisverfall und, nicht zu vergessen, der weiteren Verbreitung des TT, würde eine Umfrage unter den Atari-Besitzern, wie oft sie denn die Bildschirmauflösung wechseln, etwa folgendes offenbaren: »Immer? - Nein. Nicht immer, aber immer öfter.« - So fühlen wir uns also verpflichtet, diesem Trend Rechnung zu tragen.

Doch wo soll das Problem liegen? Schließlich haben wir in [1] ausführlich beschrieben, wie man Programme auflösungsunabhängig schreibt.

Das stimmt auch, nur hat die Sache im Zusammenhang mit Accessories noch einen Haken: Bei einem Auflösungswechsel wird nämlich kein Reset durchgeführt, sondern lediglich das AES neu initialisiert. Das wäre nicht weiter tragisch, wenn da nicht die »Vektorverbiegungen« des TOS-Accessory wären. Nachdem das »alte« Accessory aus dem Speicher entfernt wurde, zeigen alle umgelenkten Vektoren wild in den Speicher. Die Auswirkung auf die Betriebssicherheit des Rechners läßt sich leicht ausmalen. Dies ist auch der Grund, weshalb Atari allen Accessories per Dekret verboten hat, Systemvektoren zu verbiegen.

Die Lösung besteht nun darin, keine Vektoren im Accessory zu verbiegen. Da aber das TOS-Accessory erst durch die Vektorverbiegungen seine Existenzberechtigung erhält (schließlich sind die verschiedenen Tools dadurch erst realisierbar), muß es neben der »Ex-und-hopp«-Methode noch einen anderen Weg geben. Dieser läßt sich auch finden, nur ist der Aufwand dafür nicht gerade bescheiden. Wir trennen das Accessory in zwei Teile: Ein AUTO-Ordner-Programm, das die Vektoren verbiegt, und ein »gesäubertes« Accessory-Programm. Zusätzlich brauchen wir noch eine Schnittstelle, über die die beiden Programme kommunizieren. Zum Glück gibt es dafür seit dem STE-TOS eine ganz elegante Art, die sogenannten »Cookies«. Mit der Einführung des STE-TOS hat Atari die Cookies auch rückwirkend für ältere Versionen definiert.

Exkurs in Sachen Cookies

Die Systemvariable »_p__cookies« bei Adresse $5A0 zeigt dabei auf einen »Cookie Jar« (engl.: Plätzchen oder Keksschale, einer Liste von Cookies). Ist diese Variable Null, existieren keine Cookies. Da auch die »älteren« TOS-Versionen bei einem Kaltstart diese Variable auf Null setzen, unterscheiden sich ältere von neueren TOS-Versionen nun darin, daß die älteren eben keine Cookies haben.

Prinzipiell darf jetzt jedes Programm ein Cookie in die Cookie-Liste eintragen, wobei ein solches aus zwei Langworten besteht. Mit dem ersten Langwort sollte sich das Cookie identifizieren. Wenn ein Programm also ein bestimmtes Cookie aus der Liste sucht, muß es das erste Langwort mit dem Gesuchten vergleichen. Atari hat alle Cookies, die mit einem Unterstrich beginnen, für sich reserviert (»_CPU« =0x5F435055 oder »_VDO« = 0x5F56444F).

Das zweite Langwort hat je nach Art des Cookies eine andere Bedeutung, die natürlich beim Anlegen eines eigenen Cookies selbst festzulegen ist.

Eine Ausnahme macht noch das »Null-Cookie«. Dieses ist immer das letzte in der Liste. Das zweite Long-Wort enthält dabei die Anzahl der Einträge im Cookie-Jar. Hier sieht man, daß auf keinen Fall gewährleistet ist, daß noch Platz für ein weiteres Cookie in der Liste ist. Sollte dies der Fall sein, muß das Programm mindestens soviel Speicher reservieren, daß alle bisherigen Cookies und das eigene darin Platz haben. Atari rät allerdings, im voraus gleich für weitere 8 Cookies Platz zu schaffen. Dann kopiert man alle alten Cookies in den Speicher, fügt das eigene an, und schließt mit dem Null-Cookie ab. Das zweite Long-Wort des Null-Cookie muß die neue Größe des Cookie Jar enthalten. Zum Schluß verbiegen Sie die Variable _p_cookies auf den neu angelegten Speicherbereich.

Ist noch keine Cookie-Liste vorhanden (__p_cookies enthält den Wert Null) verfahren Sie analog. Allerdings übernimmt man dann die Verantwortung, _p_cookie nach einem Reset auf Null zurückzusetzen (über den Resetvektor »_resvector« - 0x42A).

Da der neue Speicherplatz immer zur Verfügung stehen muß, leitet sich daraus ab, daß es nur residenten Programmen gestattet ist, ein neues Cookie zu installieren.

Nachdem also klar ist, daß alle Interrupt-Routinen in das AUTO-Ordner-Programm auszulagern sind, stellt sich die Frage, ob nicht gleich noch ein bißchen mehr dorthin soll, um eventuell auf das Accessory verzichten zu können. So ließe sich zum Beispiel der Bildschirmschoner ganz auslagern. Nur zum Einstellen bemühen wir dann das Accessory.

Unser neues Cookie mit dem wohlklingenden Namen »TAcc« (0x54416363 für das erste Long-Wort) zeigt auf eine Struktur, die neben den Parametern der verschiedenen Tools auch Zeiger auf Standard-Funktionen enthält. Spricht man diese Funktionen über die Zeiger an, läßt sich so Platz sparen, da sich die Funktionen von beiden Programmen benutzen lassen, obwohl sie nur in einem Programm vorhanden sind. Daß dies allerdings auch eine gefährliche Gratwanderung ist, zeigt der Umstand, daß nicht sicher ist, ob auch wirklich beide Programme installiert sind. Fehlt dem Accessory zum Beispiel das AUTO-Ordner-Programm, muß es mindestens die Funktionen für eine entsprechende Fehlermeldung selbst enthalten.

Keine Regel ohne Ausnahme

Da das AES beim Aufrufen der AUTO-Ordner-Programme noch nicht initialisiert ist und sich auf der anderen Seite das AES bei jedem Auflösungswechsel neu installiert, muß also der Accessory-Teil den AES-Vektor verbiegen. Damit wären endgültig alle Hürden der auflösungsunabhängigen Programmierung genommen.

RS-232 Konfiguration

Vom Atari-Kontrollfeld her sicherlich jedem bekannt, ist die RS-232 Konfiguration. Grund genug, diese Option in Umfang und Bedienerfreundlichkeit mindestens gleichwertig in das TOS-Accessory aufzunehmen.

Auf der Suche nach einer passenden Betriebssystem -Funktion (BIOS, XBIOS, GEMDOS) rollen wir das Problem von hinten auf: Nachdem auf einer Checkliste alle nicht in Frage kommenden Funktionen durchgestrichen wurden, ziehen wir die XBIOS-Funktion »Rsconf()« heran. Sie erwartet folgende Parameter (siehe auch Tabelle):

longRsconf( int speed, intflowctl, int ucr, intrsr, int tsr, int scr );

Die Parameter »ucr«, »rsr« und »tsr« entsprechen exakt den MFP-Registern (Multi Funktion Peripheral) mit den gleichen Namen. Uns interessiert dabei nur der Aufbau von ucr, da man mit den anderen beiden Parametern direkt in die Übertragung eingreift, was nur Sinn macht, wenn man etwa Funktionen wie »Bconin(AUX:)« selbst schreiben möchte.

Der Parameter scr ist ebensowenig von Bedeutung, weil man mit ihm nur angibt, welches Synchron-Zeichen (nur im Synchron-Modus) sich Sender und Empfänger während der Sendepausen verschicken. Wen es genauer interessiert, der erfährt in (2] mehr darüber.

Mit etwas Geschick bringt man sogar die Einstellungsmöglichkeiten in Form von selektierbaren oder ausschließenden (RADIO-)Buttons im Tool-Fenster unter. Lediglich die Baudraten-Einstellung geschieht mit Hilfe einer Liste (der erlaubten Baudraten) und leicht modifizierten Slider-Funktionen.

Drucker-Einstellung

Noch zügiger läßt sich die Drucker-Einstellung verwirklichen. In jeder Beschreibung der XBIOS-Funktion »SetprtO« sind alle relevanten Informationen hierzu aufgelistet |3]. Da jedem Parameter genau ein Bit gewidmet wurde und folglich jeder Parameter nur zwei verschiedene Zustände (Fin/Aus) einnimmt, ist die Benutzerfreundlichkeit automatisch garantiert. Das Tool der nächsten Ausgabe ist eine schnelle und resetfeste RAM-Disk. (ah)

Literaturhinweise:

[1] J. Lietzow: »Individuell«, TOS-Magazin, ICP-Verlag, Ausgabe 1/92, Seite xy

[2] Jankowski, Rabich, Reschke: »Atari ST Profibuch«, Sybex. 7. Auflage 1989, Seite 723ff, ISBN 3-88745-563-0

[3] Jankowski, Rabich, Reschke: »Atari ST Profibuch«, Sybex, 7. Auflage 1989, Seite 106, ISBN 3-88745-563-0

speed Baud
0 19200
i 9600
2 4800
3 3600
4 2400
5 2000
6 1800
7 1200
8 600
9 300
10 200
11 150
12 134
13 110
14 75
15 50
flowctl Handshake
0 ohne Handshake
1 XON/XOFF (^ S/^ Q) Software-Handshake
2 RTS/CTS Hardware-Handshake
3 Modus 1 1 2

Tabelle. Die Parameter für Rsconf()


Jürgen Lietzow
Aus: TOS 02 / 1992, Seite 82

Links

Copyright-Bestimmungen: siehe Über diese Seite