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


Links

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