We BREAK for nobody

Der TT besitzt erfreulich viele zusätzliche Schnittstellen. Jedoch: Die bislang veröffentlichten Betriebssystem-Versionen 3.01 und 3.05 steuern diese falsch an: Die SCC-Ports erzeugen keine BREAK-Signale.

Die Schnittstellenvielfalt der TTs provoziert bei Neulingen zunächst einmal wildes Herumspielen. Doch nach der ersten Euphorie zeigt sich schnell: Kaum ein Programm steuert die neuen Ports korrekt an. Das liegt zunächst einmal in der Natur der Sache: Die neuen Schnittstellen haben neue Gerätekennungen, die den älteren TOS-Versionen nicht bekannt waren. Dort gab es nur eine einzige RS232-Schnittstelle, die in einem 25-Pin SUB-D-Stecker herausgeführt war. Sie hatte die GEMDOS-Gerätekennung »AUX:«, ihre Standardhandlenummer für BIOS-calls: 1. Anstelle zusätzlicher Gerätenummern hat sich Atari für die 9poligen Schnittstellen des Mega STEs und TTs etwas besonders Trickreiches einfallen lassen: Das BIOS-Gerät 1 ist softwareseitig umschaltbar. Es wird als Gerät 1 also nicht immer die gleiche, sondern die jeweils aktuell eingestellte Schnittstelle angesprochen. Das erlaubt es Ihnen, mit bereits vorhandener Software die Zusatzports anzusprechen.

Wenn Sie beispielsweise einen Videotext-Decoder, ein Fax-Gerät und ein Modem am TT betreiben möchten, brauchen Sie nicht bei jeder neuen Anwendung ein Kabelgewirr umzustöpseln, ein CPX-Modul läßt Sie die gerade angesprochene Schnittstelle wählen. Vor dem Start der betreffenden Sende- oder Empfangssoftware müssen Sie folglich nur noch ein paar Mausklicks hinter sich bringen.

Dennoch wäre diese Lösung allein noch nicht zufriedenstellend. Schließlich ist der TT ein rechenstarkes Gerät, eine Parallelanwendung böte sich geradezu an. Damit könnte beispielsweise im Hintergrund ein Programm vom einen Port empfangen, während Sie sich auf dem anderen den Videotext ansehen. Dazu braucht man kein Multitasking. Entsprechende Accessories könnten das schon heute. Nun muß man den Grad der Parallelisierung unterscheiden: Zum einen der Empfang eines DFü-Accessories parallel zu einem laufenden Hauptprogramm, das seinerseits weder Daten empfängt noch sendet. Zum anderen ist der gleichzeitige Empfang zweier Schnittstellen durch unabhängige Software denkbar. Ersteres wäre schon durch bisherige Software zu lösen. Uns ist zwar derzeit kein sauber geschriebenes Accessory bekannt, das so etwas könnte, aber vorstellbar ist es.

Der Parallelbetrieb zweier Schnittstellen hingegen ist mit der aktuellen Software nicht möglich. Deshalb sind alle vier, respektive zwei (beim Mega STE) seriellen Ports zusätzlich zum gemappten Nr. 1 noch direkt ansprechbar. Dabei wird dann ein Gerät doppelt angesprochen: zum einen als Gerät Nr. 1 und zum anderen durch seine Direktkennung (6 und aufwärts). Mit wenigen Anpassungen werden die Programmierer auch einen Schnittstellen-Parallelbetrieb bewerkstelligen - erste Ansätze sind schon erkennbar.

Zur Praxis: Wie realisieren die neuen TOS-Versionen das Umschalten? Die dazu nötige XBIOS-Erweiterung heißt »Bconmap()«, trägt die Kennung 44 und ist seit TOS 2.xx und 3.xx implementiert. Ihre Deklaration:

long Bconmap (int devno);

Nach dem Aufruf gilt »devno« als gesetzte, nunmehr aktuelle Modemschnittstelle. Ein Aufruf von

olddev = Bconmap (7);

macht also Modem-Port 2 zum aktuellen Port (wie oben beschrieben, beginnen die Schnittstellennummern bei 6, nachfolgend 0 (Drucker), 1 (aktuelle serielle Schnittstelle), 2 (Konsole), 3 (Midi-Port), 4 (IKBD) und 5 (Konsole ohne Emulationen). Als Rückgabewert erhalten Sie in »olddev« das bisher als Device Nr. 1 gemapte Gerät.

Setzen Sie für »devno« den Wert »-1«, so erhalten Sie das bisherige Setup, ohne eine neue Schnittstelle zu setzen. Der »devno«-Wert »-2« hat eine ganz besondere Bedeutung. Bei einem »Bconmap (-2);«-Call erhalten Sie als long einen Zeiger auf die folgende Struktur zurück:

typedef struct
{
	MAPTAB *maptab;
	int maptabsize;
} BCONMAP;

Der Zeiger »maptab« wiederum zeigt auf ein Array folgender Strukturen:

typedef struct
{
	int   (*bconstat) ();
	long  (*bconin)   ();
	int   (*bcostat)  ();
	void  (*bconout)  ();
	long  (*rsconf)   ();
	IOREC *iorec;
} MAPTAB;

Insgesamt umfaßt das Array so viele MAPTAB-Strukturen wie in »maptabsize« der BCONMAP-Struktur angegeben. Wie unschwer zu erkennen ist, umfaßt die MAPTAP-Struktur Zeiger auf die Funktionen »Bconstat()«, »Bconin()«, »Bcostat()«, »Bconout()«, »Rsconf()« sowie einen Zeiger auf die »Iorec«-Tabelle. Für jeden seriellen Port müssen also eigene Funktionen zur Verfügung 'stehen. Ein »maptabsize«-Wert von 4 bedeutet also, daß vier serielle Schnittstellen und insgesamt neun Standarddevices (0-5 nach alter Dokumentation, 6-9 für die seriellen Schnittstellen) zur Verfügung stehen.

Einfache Einbindung

Mit minimalem Aufwand können also auch zusätzliche Schnittstellentreiber ins System eingebunden werden, es ist nur die MAPTAB-Struktur in einen größeren Speicherbereich zu kopieren und zu ergänzen. Anschließend sind die daraus resultierenden Werte in der BCONMAP-Struktur zu ändern.

Ataris eigene »Bconmap()«-Dokumentation [1] besagt, daß »Bconmap()« auf TOS-Versionen, denen die Funktion unbekannt ist, den Wert 44 (Hex. $2c) zurückliefert. Das ist leider falsch und Atari hat dies erkannt - ein paar Absätze weiter erfahren Sie, wie es richtig gemacht wird. Dennoch bleibt ein Relikt aus dieser Zeit erhalten: Für den unwahrscheinlichen Fall, daß ein Programm den 38. Treiber einbindet, müssen zwei (!!!) Einträge in der MAPTAB-Struktur reserviert und nur die letztere davon benutzt werden. Das ist zwar angesichts der Fehldokumentation ziemlicher Blödsinn, muß aber so hingenommen werden.

Zurück: wie erkennt ein Programm, ob »Bconmap()« im TOS implementiert ist. Einige Quellen schlagen vor, die TOS-Versionsnummer zu testen. Dies ist sicherlich ein ähnlich ungeeignetes Verfahren wie Ataris eigene Fehldokumentation. Schließlich hindert niemand einen Hard- oder Softwareentwickler daran, eigenhändig »Bconmap()« zu implementieren. Somit wäre selbst TOS 1.0 in der Lage, »Bconmap()« zu verarbeiten, vorausgesetzt entsprechende Hard- und Software ist vorhanden. Die einzige wirklich funktionierende Methode ist die Verwendung eines illegalen device-handles: Ein Aufruf von

Bconmap (0);

führt auf einem System, das keinen »Bconmap()«-call kennt, zu der Fehlermeldung durch den unbekannten Funktionsaufruf. Es wird ein Wert ungleich 0 (long) zurückgegeben. Auf einem System, das »Bconmap()« verarbeiten kann, führt obiger Aufruf zur Rückmeldung, ein unbekanntes Gerät sei angesprochen worden, es gibt den Wert 0 (ebenfalls als »long« zu bewerten) zurück.

Ein Problem zeigt sich im Alltagsbetrieb: Viele Programme greifen zur Manipulation der seriellen Schnittstelle direkt auf die Hardware zu - beispielsweise um ein BREAK-Signal zu senden. Solche Programme haben nun erhebliche Schwierigkeiten mit dem neuen Computer: Stellen Sie sich ein Terminalprogramm vor, das über die dritte serielle Schnittstelle empfängt (per CPX-Modul auf diesen Port umgemapt), sein BREAK-Signal aber direkt auf die Hardware zugreifend erzeugt, nämlich auf Port 1. Dadurch kann es das System erheblich durcheinanderbringen. Manche Empfangsgeräte brechen nach dem Empfang des BREAK-Signals den Empfang ab und kehren in den Kommandomodus zurück (z. B. manche Videotext-Empfänger). Dies führt dann zu ungeahnten Problemen, schlimmstenfalls zum Verlust bereits empfangener Daten. Bekanntlich ist die serielle Schnittstelle durch die TOS-Routine Rsconf() zu konfigurieren. Sie wird ebenso wie der Iorec()-Aufruf durch Bconmap() umgemapt und bezieht sich deshalb immer auf das aktuelle Gerät Nr. 1. Unser erstes Listing demonstriert, wie Sie auf Gerät 1 sauber ein BREAK-Signal erzeugen.

Sauberer Weg

Seit der Implementation von »Bconmap()«, also seit TOS 2.xx, wirkt Rsconf(), ebenso wie Iorec() immer auf die gerade als Gerät Nr. 1 gemapte Schnittstelle. Um einen ganz bestimmten Port zu konfigurieren, müssen Sie also kurzzeitig auf diesen Port ummapen, Rsconf() benutzen und anschließend zurückmapen. Sie sollten darauf achten, daß während des Ummapens keine Daten ausgelesen werden. Ein zweites Beispiellisting demonstriert, wie Sie auf einem Port wahlfrei ein BREAK-Signal erzeugen.

Zurück zur Realität der Atari-TOSse. Die dortigen RS232-Konfigurationsroutinen sind fehlerhaft, weshalb Atari beizeiten das Patchprogramm »SERPTCH« veröffentlicht hat, das die Fehler beseitigen soll. Dummerweise hat man bislang vergessen, dem TOS beizubringen, auch auf den Schnittstellen, die nicht von einem der MFPs, sondern dem SCC getrieben werden, ein BREAK zu erzeugen, das »TSR«-Byte im Rsconf()-Aufruf wird vom SCC-Treiber größtenteils ignoriert. Beim Setzten eines Wertes reagiert TOS überhaupt nicht, beim Auslesen wird er falsch ermittelt - Bit 2 anstelle von Bit 3 »UND«-verknüpft. Das Resultat ist ein bedeutungsloser Wert, der aufgrund des vollkommen verschiedenen Aufbaus von Zilog- und Motorola-Chips auch noch falsch gesetzt ist.

Atari schreibt zwar in der TT-Dokumentation [1], daß jeder Bconmap-Treiber zumindest das BREAK-Bit im TSR auswerten sollte, man hat es aber schlichtweg vergessen. Der Hochgeschwindigkeitscontroller SCC 8530 kann zwar problemlos BREAK-Signale für beide Schnittstellen erzeugen [2] TOS ordnet dies jedoch nicht an.

Anbei einige Assemblerzeilen, die demonstrieren, daß auch die SCC-Schnittstellen keine Probleme mit den BREAK-Signalen haben, wenn sie auch vollkommen anders angesprochen werden als bei den MFPs.

Unsere Assemblerzeilen sollen jedoch kein Aufruf zur erneuten hardwareabhängigen Programmierung sein. Gerade bei den SCC-Ports, von denen einer beim Atari TT als LAN-Schnittstelle mitbenutzt wird, muß von einer Direktprogrammierung dringendst abgeraten werden. Die SCC-Register können aufgrund der unterschiedlichen Adressierung nur geschrieben, nicht aber ausgelesen werden.

Das bedeutet, daß jede Veränderung in einem der Register vom Treiber protokolliert werden muß. Und genauso macht es Ataris Rsconf()-Treiber auch. Bei einer Direktprogrammierung wäre die Datenkonsistenz nicht mehr gewährt, die RAM-Kopie des Registerinhalts würde mit den tatsächlich gesetzten Bits nicht mehr übereinstimmen. Atari ist informiert, wir hoffen, ein fehlerbereinigtes TOS oder zumindest ein Patchprogramm von Atari zu bekommen.

(uw)

Literatur:

[1] Atari Corp., Sunnyvale: The TT030 Companion: Developer's Notes For The Atari TT030,1990.

[2] Zilog Inc., Campbell: Z80C30 CMOS Z-Bus SCC / Z85C30 CMOS SCC Serial Communications Controller, Advance Product Specification, October 1986.

Listing 1: Dieses Programm erzeugt sauber ein BREAK auf Gerät 1
Laurenz Prüßner


Aus: ST-Magazin 12 / 1991, Seite 68

Links

Copyright-Bestimmungen: siehe Über diese Seite