Grundlagen: Das XAcc-Protokoll für Accessories und GEM-Programme
Mit nur wenig mehr Programmieraufwand steigert man die Funktionalität von Accessories und Programmen, so daß sie garantiert einen »glänzenden« Eindruck hinterlassen
Durch ihre ständige Einsatzbereitschaft sind die Accessories zu den beliebtesten Sammlerobjekten unter den Atari-Besitzern aufgestiegen. Zur Zeit erfahren die Accessories einen erneuten Aufwärtstrend, weil immer mehr von ihnen das »XAcc-Protokoll« unterstützen und mit Funktionen aufwarten, die bisher für fast unmöglich gehalten wurden. Als Beispiel für Programme, die das Protokoll unterstützen, seien hier nur »That‘s Address« und »That‘s Write« erwähnt.
Das XAcc-Protokoll
Bei XAcc handelt es sich um eine genormte Kommunikationsbrücke zwischen Accessories und dem Hauptprogramm. Vor allem anderen garantiert das Protokoll ein konfliktfreies Austauschen von Textdateien, Textausschnitten, Befehlen aller Arten (etwa Tastatur-Befehlen) oder sogar Bildern zwischen den Programmen. Obwohl die Spezifikation des XAcc-Protokolls noch nicht abgeschlossen ist und auch bislang der Segen von Atari fehlt, findet es unter den Schreiberlingen immer größeren Anklang.
In Anbetracht der hohen Anforderungen ist der Aufbau relativ einfach. Um den Overhead eines jeden Accessories, welches das XAcc-Protokoll unterstützt, nicht unnötig aufzublähen und auf der anderen Seite trotzdem eine große Funktionalität mit individuellen Ansprüchen zu gewährleisten, ist das Protokoll in drei Verständigungsstufen (Stufe 0 bis Stufe 2) gegliedert. Darüber hinaus dürfen die Programme, sofern sie sich kennen, eigene, private Mitteilungen verschicken,
Die Grundvoraussetzungen für ein lebhaftes Schwätzchen unter den Programmen sind durch die Funktionen appl_read() und appl_write() des AES gegeben. Ausgehend von der Tatsache, daß das Hauptprogramm immer die Applikationsnummer Null erhält, stellt sich das Accessory per appl_read() bei diesem erst einmal vor.
Stufe 0
Da ein Accessory bei Beginn wie am Ende eines Hauptprogrammes eine AC_CLOSE-Meldung vom AES erhält, muß es im Anschluß daran eine Meldung gemäß Tabelle 2 an das Hauptprogramm schicken. Um sicherzustellen, daß das Accessory auch ein Auto-Start-Programm (ab TOS 1.4) über seine Existenz unterrichtet, verschickt es die gleiche Meldung zusätzlich zu Programmstart (des Accessories). Als Antwort auf diese ACC_ID-Meldung schickt das Hauptprogramm seinerseits eine ACC_ID-Meldung an das Accessory. Msgbuf(6) und msgbuf(7) haben dann keine Bedeutung und sind für private Zwecke frei. Darauf schickt das Hauptprogramm noch jeweils eine ACC_ACC-Meldung (Tabelle 3) an die bisher angemeldeten Accessories. Diese stellen sich dann wiederum beim Neuankömmling mit einer ACC_ID-Meldung persönlich vor, womit nun alle Programme untereinander bekannt wären.
Nach diesem formellen Teil, der schließlich zu jeder intakten Beziehung gehört, kann nun der Plausch so richtig beginnen. Dabei tritt gleich eine weitere Parallele zur Realität auf. Manche Programme kennen sich nämlich schon vom Namen her, und kommunizieren deshalb viel intensiver als andere. Dazu dienen alle Mitteilungen oberhalb von 0x800, deren Bedeutung allerdings nur diesen Programmen bekannt ist. Denn die Mitteilungen von 0x800 und aufwärts stehen speziell den Programmen bereit, die mit den »Standard-Mitteilungen« alleine nicht auskommen.
Als weiterer Schritt wird eine kleine Schwäche des »Event-Managers« des AES ausgebügelt. Das XAcc-Protokoll sorgt nämlich auch für eine Mitteilung an das Hauptprogramm, wenn ein Accessory ein Fenster öffnet oder über das Desk-Menü aktiviert wurde. Gleiches gilt beim Schließen eines Accessory-Fensters. In Tabelle 4 sind die Meldungen, die das Accessory an das Hauptprogramm schickt, beschrieben.
Stufe 1
Diese Stufe erlaubt nun das Austauschen von Texten und Tastatur-Codes. Dazu dienen die beiden Meldungen ACC_TEXT und ACC_KEY wie in Tabelle 5 und 6 beschrieben. Alle empfangenen Daten, auch die aus Stufe 2, sind mit einer ACC_ACK-Meldung (siehe Tabelle 7) zu quittieren und vom Sender bis zur Quittierung nicht zu verändern. Da der Empfänger in irgendeiner Weise auf ankommende Daten reagieren muß - zumeist durch Anzeige der Daten in einem Fenster - ist es ratsam, vor dem Versenden ein eventuell aktives Fenster zu schließen, so daß das Fenster des Empfängers aktiv ist.
Wichtig ist außerdem, darauf zu achten, daß der Sender mindestens die gleiche Stufe unterstützt. Die notwendigen Informationen darüber hat man ja bei der Bekanntmachung erhalten.
Noch ein Wort zum Text verschicken. Ein Text darf alle druckbaren Zeichen enthalten (ASCII-Code => 32) und muß mit Null terminiert sein. Außerdem sind die Steuerzeichen TAB (0x09), LF (0x0A) und CR (0x0D) erlaubt.
Stufe 2
Die zweite Stufe ist hauptsächlich für Grafikprogramme und Anwendungen, die mit Grafiken umgehen, interessant. In Tabelle 8 sind die Verfahren zum Austausch von Image- und Metadateien beschrieben.
Auf gleiche Weise lassen sich aber auch beliebige andere Daten weiterreichen. Dazu benutzt man dann die privaten Mitteilungen oberhalb von 0x800. Da solche Mitteilungen natürlich nicht genormt sind, müssen sich Empfänger und Sender namentlich kennen, also sicher wissen, daß das Gegenüber die Daten richtig interpretiert. (ah)
Tabelle 1. Die Meldungen der drei Protokoll-Stufen
| Das XAcc - Protokoll | |
| Stufe 0 | |
| ACC_ID | = 0x400 |
| ACC_OPEN | = 0x401 (nicht zu verwechseln mit AC_OPEN) |
| ACC_CLOSE | = 0x402 (nicht zu verwechseln mit AC_CLOSE) |
| ACC_ACC | = 0x403 |
| Stufe 1 | |
| ACC_ACK | = 0x500 |
| ACC_TEXT | = 0x501 |
| ACC_KEY | = 0x502 |
| Stufe 2 | |
| ACC_META | = 0x503 |
| ACC_IMG | = 0x504 |
| Tabelle 2. Identifikationsmeldung eines Accessories und analog dazu die eines Hauptprogramms | |
| msgbuf[0] | ACC_ID |
| msgbuf[l] | ap_id des Absenders (hier also die des Accessories) |
| msgbuf[2] | Länge der Meldung - 16, hier also 0 |
| msgbuf[3] | Versionsnummer, im unteren Byte die Protokollstufe, die vom Accessory noch verstanden wird |
| msgbuf[4/5] | Zeiger auf den Namen des Accessories (statisch *), Motorola-Format) |
| msgbuf[6] | Menünummer (menu_id). -1 für keinen Eintrag. Bei mehreren Einträgen muß die Meldung mehrmals verschickt werden. |
| msgbuf[7] | reserviert |
*) Statisch bedeutet, daß der Inhalt dieser Adresse dem Hauptprogramm immer zur Verfügung steht.
| Tabelle 3. Mit dieser Meldung macht das Hauptprogramm die Accessories untereinander bekannt | |
| msgbuf[0] | ACC_ACC |
| msgbuf[1] | apid des Absenders (also des Hauptprogramms) |
| msgbuf[2] | Länge der Meldung - 16, abhängig von der Protokoll-Stufe |
| msgbuf[3] | Versionsnummer und Protokoll-Stufe des Accessories |
| msgbuf[4/5] | Zeiger auf Namen des Accessories |
| msgbuf[6] | Menünummer des Accessories (menu_id) |
| msgbuf[7] | apid des Accessories |
| Tabelle 4. Meldung des Accessories an das Hauptprogramm, wenn dieses aktiviert oder deaktiviert wurde | |
| msgbuf[0] | ACC_OPEN/ACC_CLOSE |
| msgbuf[1] | apid des Absenders (Accessory) |
| msgbuf[2] | Länge der Meldung - 16 |
| msgbuf[3]-[7] | frei |
| Tabelle 5. Meldung zum Versenden eines Textes | |
| msgbuf[0] | ACC_TEXT |
| msgbuf[1] | apid des Absenders |
| msgbuf[2] | Länge der Meldung - 16 (hier also 0) |
| msgbuf[3] | nicht benutzt |
| msgbuf[4+5] | Zeiger auf den Text |
| msgbuf[6]-[7] | frei |
| Tabelle 6. Meldung zum Versenden eines Tastendruckes | |
| msgbuf[0] | ACC_KEY |
| msgbuf[1] | apid des Senders |
| msgbuf[2] | Länge der Meldung - 16 (hier also 0) |
| msgbuf[3] | Scan- und Ascii-Code (wie von evnt_keybd()) |
| msgbuf[4] | Sondertasten-Status (wie von Kbshift()) |
| msgbuf[5]-[7] | frei |
| Tabelle 7. Meldung, die den Datenempfang quittiert | |
| msgbuf[0] | ACC_ACK |
| msgbuf[1] | apid des Absenders |
| msgbuf[2] | Länge der Meldung - 16 (hier also 0) |
| msgbuf[3] | 0: Empfangene Daten wurden ignoriert, sonst 1 |
| msgbuf[4]-[7] | frei |
| Tabelle 8. Meldung zum Versenden von IMG- oder META-Daten | |
| msgbuf[0] | ACC_META/ACC_IMG |
| msgbuf[l] | apid des Absenders |
| msgbuf[2] | Länge der Meldung - 16 (hier also 0) |
| msgbuf[3] | 1 für den letzten Teil der Daten, sonst 0 |
| msgbuf[4+5] | Zeiger auf Daten |
| msgbuf[6+7] | Länge der Daten (LangWort, Motorola-Format) |
Jürgen Lietzow