Programmierecke: der Carrier-Detektiv: Verbindung erkannt - Gefahr gebannt
Viele von Ihnen, die Datenfernübertragung betreiben, kennen das Problem: Genau diejenige Mailbox ist regelmäßig stundenlang besetzt, die Sie am liebsten anwählen. Besitzer von Modems lassen ihre Maschinen stundenlang wählen, während Sie selbst sich längst mit anderen Dingen beschäftigen. Doch ein Problem stellt sich auch hier: Sie dürfen unter keinen Umständen den Moment verpassen, in dem das Modem die Verbindung zum angewählten Computer herstellt. Verpassen Sie diesen Augenblick, so legt der angewählte Computer, der im Fachjargon als Host bezeichnet wird, nach einer bestimmten Zeitspanne auf und unterbricht die Verbindung. Das kostet Sie nicht nur 23 Pfennige, sondern oft auch mehrere Stunden entnervten Neu-wählens. Denn höchstwahrscheinlich hat ein anderer gerade in dem Moment eine Verbindung zum Host aufgebaut, in dem er Sie aus dem System »geworfen« hat.
Kurzum: Es muß gewährleistet sein, daß Sie den Moment nicht verpassen, in dem die Verbindung zustande kommt.
Unser »Carrier-Detector« hilft Ihnen dabei. Sobald Ihr Modem eine Verbindung zum angewählten Computer aufbaut, empfängt es von diesem einen Pfeifton. Dieser Pfeifton, auch »Carrier« genannt, variiert je nach Sende- und Empfangsnorm sowie der Geschwindigkeit, mit der die Datenfernübertragung stattfindet. Das Modem setzt in diesem Moment einen Pin in der Empfangsleitung des Computers. Damit macht es den Computer darauf aufmerksam, daß es den Carrier empfängt. Diese Leitung liegt an der genormten 25poligen RS232- Schnittstelle am Pin 8 (DCD). In diesem Moment empfängt der MFP 68901-Chip im ST das »Carrier-Detect«-Signal und löst einen Interrupt des Inter-rupt-Levels 6/1 aus, sofern dieser Interrupt erlaubt ist. Die Vorgehensweise kommt Ihnen bekannt vor? Stimmt, bereits in unserer April-Ausgabe [1] stellten wir ein Programm vor, das ähnlich eingreift.
Unser »Carrier-Detector« begnügt sich aber nicht mit einer Alert-Box, wie das oben erwähnte Programm, sondern beginnt augenblicklich ohrenbetäubend zu klingeln. So bekommen Sie die Meldung auch dann mit, wenn Sie sich z. B zwischenzeitlich ein gutes Buch zu Gemü-te führen oder über demselben eingeschlafen sind. Auch belegt unser Programm keinen der wertvollen »Accessory-Slots«, von denen GEM nur sechs zur Verfügung stellt und mit denen Sie daher sparsam umgehen müssen.
Der Wächter liegt ständig im Speicher bereit
Das Programm liegt nach dem einmaligen Installieren resident im Speicher und installiert sich selbst nur einmal. Versuchen Sie, das Programm ein weiteres Mal zu installieren, teilt es Ihnen mit, daß es sich schon im Speicher befindet. Zum Verbiegen der Systemvektoren bedient sich auch dieses Programm des bekannten XBRA-Protokolls. Auch andere Programme können daher unseren »Carrier-Detector« identifizieren. Als XBRA-Identitätscode verwendet es die Buchstabenkombination »LPCD«.
Das Programm verbiegt aber nicht nur den MFP-Interruptvektor, sondern installiert sich selbst größtenteils im »Vertical Blank Interrupt«.
Nun werden Sie sich sicher fragen: »Warum arbeitet denn nicht das gesamte Programm im 'Carrier-Detect-Interrupt', sondern belegt auch noch einen VBI-Eintrag?«.
Dies hat mehrere Gründe: Zunächst einmal ist die Ausgabe von Zeichen im Interrupt-Level 6 mit großen Problemen verbunden. Aufrufe von BIOS- oder XBIOS-Funktionen gestalten sich im Interrupt-Level 6 außerordentlich unzuverlässig. Außerdem sind während der Abarbeitung des »Carrier Detect Interrupts« sämtliche Interrupts des Betriebssystems gesperrt. So auch die Interrupts für die Tastaturabfrage und das Klingelzeichen. Dies hat zur Folge, daß das System keine Tastatureingaben mehr erkennt und auch keine Töne mehr erzeugen kann. Aber es gibt noch einen weiteren, viel wesentlicheren Grund: Weil wir für das Hauptprogramm den VB1 gewählt haben, laufen andere Programme problemlos weiter, ohne daß selbst ein aktivierter Interrupt den gesamten Programmablauf stört. Da der »Carrier Detector« aus reinem MC68000-Assembler-Code besteht, ist er zudem sehr schnell. Stellen Sie sich beispielsweise einmal ein Rechenprogramm vor, das der Interrupt unterbricht und somit am Weiterrechnen hindert. So vernichtet der Interrupt unter Umständen die Rechenarbeit von Stunden, oder verhindert zumindest ein Weiterrechnen bis zum Abschalten des Klingelsignals. Unser VBI-Programm verlangsamt die Bearbeitung von anderen Programmen zwar etwas dafür laufen diese aber weiter, auch während unser »Carrier-Detector« klingelt.
Sparsam im Zeltverbrauch
Der »Carrier-Detector« verbraucht, sofern kein »Carrier-Detect-Interrupt« aufgetreten ist, fast überhaupt keine Systemzeit. Tests mit dem Speed-Tester »Quick Index« (siehe Seite 72) ergaben, daß das Programm im inaktiven Zustand deutlich weniger als l Prozent der Prozessorzeit verbraucht.
Tritt nun ein »Carrier-Detect-Interrupt« auf, weil eine Verbindung via Modem aufgebaut ist, so setzt die kurze MPF-Inter-ruptroutine das Flag »Jouh«. Danach schaltet sie sich selbst wieder ab und fährt mit der Abarbeitung des unterbrochenen Programmes fort. Nun erkennt das VBI-Programm, daß ein passender Interrupt aufgetreten ist, und beginnt zu klingeln.
Beim nächsten Vertical Blank Interrupt »besorgt« sich unser Hauptprogramm mehr Prozessorzeit. Diese gibt Ihnen später die Gelegenheit, das Klingeln abzuschalten. Etwa 48 Prozent der Prozessorzeit belegt das aktivierte Programm im monochromen Darstellungsmodus, etwa 34 Prozent im Farbmodus falls außer dem VBI-Programm und »Quick Index« kein weiteres Programm aktiv ist. Diese Differenz kommt dadurch zustande, daß der ST den Vertical Blank Interrupt im monochromen Modus etwa 72mal pro Sekunde auslöst, im Farbmodus aber nur SOmal. Im monochromen Modus bearbeitet der Atari unser Programm rund ein Drittel mal öfter als im Farbmodus.
Wenn Ihnen diese Rechenzeitbelastung zu hoch erscheint, ändern Sie im Assembler-Listing den Wert, den der ST kurz vor der Verzögerungsschleife mit dem Label »Verzögerung« in sein Register dO lädt. Wollen Sie ganz auf eine Verzögerung verzichten, so entfernen Sie die gesamte Routine »Verzögerung«. Dies führt aber zu Problemen, auf die wir gleich eingehen werden.
Das durchgehende Klingeln schalten Sie ab, indem Sie eine der Tasten < Control >, <Shift> oder < Alternate> kurz antippen. Halten Sie eine andere Taste längere Zeit gedrückt, so erzielen Sie denselben Effekt, doch funktioniert dies nur einwandfrei in Zusammenarbeit mit der oben erwähnten Verzögerungsschleife. Verkürzen Sie die Verzögerungszeit oder entfernen Sie die Verzögerungsschleife ganz, dann kommt es unter Umständen zu Problemen. Das Programm erkennt in diesem Fall die Tastatureingaben nicht mehr einwandfrei, ohne sich in die Tastaturabfrage-Routine des TOS einzuklinken. Ein Verbiegen dieser Routine ist durchaus möglich, jedoch würde der Effekt den Programmieraufwand nicht rechtfertigen. Wenn Sie dennoch eine solche Routine programmieren möchten, gehen Sie wie folgt vor:
Sobald das VBI-Programm erkennt, daß das Flag »Jouh« gesetzt ist, muß es die Adresse der Tastaturroutine erfragen. Dazu bedienen Sie sich der XBIOS-FunktionNr. 34(»Kbdv-base«). Nun erhalten Sie in Register dO einen Zeiger auf einen Block mit den Adressen der verschiedenen Tastatur-Abfrageprogramme. Damit klinken Sie Ihre eigene Tastaturroutine mittels XBRA-Protokoll in eines dieser Unterprogramme ein. Da- zu hängen Sie Ihr eigenes Programm beispielsweise in die TOS-Routine »ikbdsys«, deren Startadresse Sie 32 Speicherzellen (hexadezimal $20) hinter der der Tabellenbasis finden. Nachdem der Anwender das Klingeln per Tastendruck abgeschaltet hat, muß Ihr Programm die Routine auf ihre ursprüngliche Adresse zurückbiegen.
Ausgabe über TOS-Routinen
Unser Programm weist vielleicht auch noch ein weiteres Problem in der Zusammenarbeit mit anderen Programmen auf. In der Praxis tritt dieser Fehler zwar äußerst selten auf, dennoch sei er hier erwähnt, damit das Programm Sie nicht später negativ überrascht.
Die Verträglichkeit zu anderen Programmen ist leider nicht hundertprozentig gewährleistet. Denn zur Erzeugung des Klingelsignals benutzt unser Programm die originalen TOS-Aus-gaberoutinen, wie es sich für ein ordentlich entworfenes Programm gehört. Im Gegensatz zu beispielsweise dem TOS-Problemkind »Tempus«, das eigene Ausgabeprogramme benutzt.
Dazu bedient sich unser Programm der BIOS-Routine Nr. 3 (»Bconout«). Dies allein genügt aber noch nicht, um ernsthafte Probleme zu schaffen. Die Problematik offenbart sich erst mit der Benutzung von Programmen, die die eingebaute VT-52 -Terminal-Emulation verwenden. Dies trifft für viele Programme zu, die Texte auf dem Bildschirm ausgeben, beispielsweise die Textausgabe-Routine des GEM-Desktops oder Terminalprogramme. VT-52 - Steuercodes bestehen aus mindestens zwei Zeichen. Das erste dieser Zeichen ist dabei immer ein »Escape«, das ASCII-Zeichen Nr. 27 (hexadezimal $1B). Danach folgt nach VT-52 -Norm ein weiterer Buchstabe, der die eigentliche Funktion bestimmt und eventuell weitere Parameter. Nun könnte es theoretisch passieren, daß ein Programm das ASCII-Zeichen Nr. 27 ausgibt, damit eine Emulationssequenz einleitet, dann aber durch den VBI unterbrochen wird. Jetzt gibt die VBI-Routine ein Klingelzeichen aus und kehrt zum unterbrochenen Programm zurück, das versucht, die Emulationssequenz fortzuführen. Da die VT-52-Emulation aber schon das Klingelzeichen erhalten hat, gilt die Emulationssequenz als beendet. Deshalb interpretiert die TOS-Routine das vom unterbrochenen Programm gesendete Steuerzeichen als einen normalen Buchstaben und gibt dieses auch als ein Zeichen aus, führt also keine Steuersequenz durch.
Kollisionen sind selten
Ein Beispiel: Ein Programm will den Cursor um eine Zeile aufwärts bewegen. Zu diesem Zweck gibt es die Zeichenfolge 27, 65 (hexadezimal $1B, $41) aus, die Terminal-Emulation interpretiert »Esc-A« nach VT-52 Norm als »Cursor up«. Jetzt stellen wir uns eine Unterbrechung durch das VBI-Programm während des Aus-druckens vor. Dann kann die Ausgabe so aussehen: 27 (hexadezimal $1B). Jetzt tritt die Unterbrechung auf und die VBI-Routine gibt das Klingelzeichen 7 (hexadezimal $7) aus. Dieses Zeichen interpretiert der VT-52 Emulator jedoch als den fehlenden Funktionscode. Damit gilt die Terminal-Emulation als abgeschlossen. Jetzt kehrt die Interruptroutine zum unterbrochenen Programm zurück. Dieses gibt nun seinerseits noch den eigentlichen Funktionscode 65 (hexadezimal $41) aus. Nun erscheint, da die Terminal-Emulation bereits beendet ist, der Buchstabe »A« (das normale ASCII-Zeichen Nr. 65) auf dem Bildschirm.
Glücklicherweise ist die Wahrscheinlichkeit für solche Kollisionen sehr gering. Selbst bei einer Mehrfachinstallation des Programmes, die normalerweise durch das XBRA-Verfahren verhindert wird, konnten wir keine allzu hohe Fehlerquote feststellen. Im Normalbetrieb tritt der Fehler durchschnittlich etwa bei jedem 100. Emulations-Aufruf auf. Dies ist eine Fehlerquote, die für unsere Zwecke noch erträglich ist. Außerdem klingelt das Programm ja ohnehin nur so lange, bis Sie es durch einen Tastendruck abschalten, so daß der Betrieb eines Termi-nalprogrammes in der Praxis völlig reibungslos abläuft. Nicht nur mit allen gängigen Terminalprogrammen, sondern auch mit Terminal-ähnlichen Accessories, wie dem »Flash!«-Abkömmling »Shadow« (siehe dazu auch das Bild), gestaltet sich die Zusammenarbeit des »Car-rier Detectors« problemlos, (ba)
Schon wieder ein Druckfehler
Mal wieder hat der Fehlerteufel zugeschlagen, mal wieder will es keiner gewesen sein. Wie dem auch sei, aus irgendwelchen, uns nicht ersichtlichen Gründen, hat jemand einen Satz in der Programmiererecke der Ausgabe 7/89 ins Gegenteil verkehrt. Dort lesen Sie auf Seite 58, daß wir die Länge von »ph__flag« falsch angegeben hätten, dabei hatten wir dessen Länge überhaupt noch nicht erwähnt. Richtig hätte es heißen müssen, daß die Autoren des Atari-Profibuchs die Länge dieses Flags falsch angaben. Statt der angegebenen 4 Byte beträgt der Wert in Wirklichkeit 2 Byte.