GSX ohne Geheimnisse

Martin Kotulla
Zu den wohl bestgehüteten Geheimnissen von Digital Research gehören Informationen über die Grafikerweiterung GSX. Wer beispielsweise einen Schneider CPC 6128 erwirbt, erhält zwar zu CP/M Plus noch einige ominöse Dateien, deren Bedeutung jedoch weitgehend im dunkeln bleibt.
c't lüftet nun den Schleier des Schweigens um GSX unter CP/M Plus und CP/M-86.

Es war einmal in Amerika. Da entwickelte im Jahre 1973 ein damals noch recht unbekannter Universitätsprofessor namens Gary Kildall auf einem PDP-10-Computer (von Digital Equipment) ein Betriebssystem für den zu dieser Zeit brandneuen Prozessor 8080 von Intel. Kildall nannte sein Werk 'Control Program for Microcomputers', heute besser bekannt unter der Abkürzung 'CP/M'. Der Chip-Hersteller Intel, dem Kildall CP/M zuerst zur Vermarktung anbot, zeigte kein Interesse. Denn dort war man noch auf Time-Sharing-Computer eingeschworen und sah überhaupt nicht ein, warum jeder einzelne Computerbenutzer einen eigenen Computer mit einem eigenen Single-User-Betriebssystem bräuchte ...

Kildall gab trotz dieses Rückschlags nicht auf und gründete die Firma Digital Research, die die Vermarktung von CP/M übernehmen sollte. Der Rest ist wohlbekannt. Digital Research (DRI) mauserte sich zum für lange Zeit größten Anbieter von Betriebssystemen. Springen wir weiter ins Jahr 1983. Bis dahin waren die meisten Bürocomputer 8-Bit-Maschinen mit dem Betriebssystem CP/M 2.2. Und die meisten Benutzer dachten beim Namen 'Digital Research' allenfalls noch an Control-C und 'BDOS-Error: R/O'.

Es war also für Kildalls Mannen höchste Zeit, eine verbesserte Version von CP/M auf die Beine zu stellen. CP/M Plus, auch nach der Versionsnummer schlicht CP/M 3.0 genannt, war geboren. Viele der Kritikpunkte an der Version 2.2 waren gegenstandslos geworden. Eigentlich hätten alle jubeln müssen: taten es aber nicht. Denn Digital Research hatte die Entwicklung hin zu 16-Bit-Prozessoren reichlich verschlafen. So standen damals bereits in vielen Büros IBM PCs oder einige der allerersten Kompatiblen. Auch die etwa zeitgleich von Digital Research veröffentlichte Betriebssystem-Erweiterung GSX verkaufte sich unter dem Eindruck der schleppenden Verbreitung von CP/M Plus nicht gerade blendend.

Da außerdem CP/M-86, das Betriebssystem für Rechner auf Basis der 8086/8088-Prozessoren weitgehend von MS-DOS verdrängt wurde, sah es für Digital Research nicht allzu rosig aus. GSX wurde wohl mehr oder weniger als Fehlinvestition abgeschrieben. CP/M wanderte als Betriebssystem für Bürocomputer in die Mottenkiste... und feierte ein Jahr später Wiederauferstehung in Form einer Beipack-Diskette mit CP/M 2.2 beim Amstrad/Schneider CPC 464. Es erfreut sich seitdem bei Benutzern der Schneider CPCs wachsender Beliebtheit, bietet es doch Zugang zu wirklich professioneller Software.

Da war es dann nur logisch, daß Amstrad dem Nachfolgemodell CPC 6128 ein dem größerem Speicher adäquates Disketten-Betriebssystem mitgab: CP/M Plus. Und beim Textverarbeitungssystem und Nebenbei-Computer Joyce ist CP/M Plus sogar das einzige verfügbare Betriebssystem.

Versetzen wir uns nun in die Rolle des geneigten CP/M-Plus-Anwenders. Da inspiziert er seine beiden Systemdisketten und findet so einige Dateien, die er nirgends richtig einordnen kann. Dazu gehören Files mit der Namenserweiterung .PRL, eine Programmdatei mit dem Namen GSX.SYS und ein transientes Programm GENGRAF.COM. Irgendwie findet der Benutzer dann heraus, daß diese Dateien etwas mit einem Programmsystem mit dem geheimnisvollen Namen GSX zu tun haben müssen. Das Benutzerhandbuch ist aber auch nicht allzu auskunftsfreudig und beschränkt sich im wesentlich darauf, eine Beispielgrafik 'Karls Taschengeld in Pfennigen' zu zeigen. Das spornt natürlich den Forscherdrang ungemein an.

Doch niemand scheint Informationen über dieses wahrlich geheimnisvolle Grafikprogramm GSX zu besitzen, geschweige denn herausgeben zu wollen.

Schneider hat wie so oft keine Ahnung, bei Digital Research blitzt man ab, und in der Fachliteratur-Szene findet man auch nichts Konkretes. Über Umwege kommt man dann doch noch zu einer GSX-Dokumentation, sei es auch zu einem horrenden Preis. Und der Benutzer ist so klug als wie zuvor. Denn verständlich oder gar didaktisch sind die beiden Handbücher 'GSX Programmer's Guide' und 'GSX User's Guide' wahrlich nicht aufgebaut. Spätestens hier macht sich dann ganz leise der erste Frust bemerkbar.

Doch halt! Mit den entsprechenden Informationen versehen, kann man aus GSX eine Menge herausholen.

Zuerst einmal zur Begriffsklärung: GSX steht, das haben Sie vielleicht schon erraten, für 'Graphics System EXtension'.

Eine grafikorientierte Betriebssystem-Erweiterung ist GSX also. GSX ist zwar eigentlich der Vorläufer des 16-Bit-Betriebssystem-Aufsatzes GEM, bietet aber leider nicht den ach so komfortablen GEM-Desktop mit Windows, Mäusen, Icons und so weiter. Selbstprogrammieren ist also angesagt. Vereinzelt werden aber auch schon Programme für den CPC 6128 und Joyce angeboten, die die GSX-Grafikfähigkeiten ausnutzen.

GSX wurde so programmiert, daß Computer mit völlig unterschiedlicher Grafik-Hardware ohne Änderungen am Programmcode von Grafikanwendungen annähernd gleiche Grafiken erstellen können - soweit dies eben bei den verschiedenen Bildschirmauflösungen und Farbtönen möglich ist.

Das bedeutet ganz einfach, daß ein Grafikprogramm auf standardisierte Schnittstellen in GSX zurückgreifen kann. Die Aufgabe von GSX ist dann eigentlich 'nur' noch, die Grafikbefehle der jeweiligen Hardware verständlich zu machen.

GSX ist damit, vom Prinzip her betrachtet, auf derselben Logik aufgebaut wie das CP/M-Betriebssystem selbst. Auch das läßt sich ohne großen Aufwand auf mehr oder weniger unterschiedlichen Computern implementieren, sofern nur gewisse Grundbedingungen gegeben sind.

Das gedankliche Konzept der Trennung von systemunabhängigen und hardware-spezifischen Programmsegmenten hat Digital Research ebenso von CP/M übernommen. Das BDOS von CP/M ist bei allen Rechnern identisch, lediglich das BIOS muß an den Computertyp individuell angepaßt werden.

Ähnlich funktioniert das auch bei GSX. Hier heißt der unverändert funktionsfähige Teil GDOS (Graphics Device Operating System), die Low-Level-Routinen wurden hingegen in das GIOS (Graphics Input/Output System) hineingepackt.

So bietet das GDOS einem Grafikprogramm komplexe Funktionen wie etwa das Zeichnen von Linien oder das Ausfüllen von grafischen Körpern an, während das GIOS primitivere Aufgaben wie das Setzen eines Punktes übernimmt. Will also ein Anwenderprogramm einen Grafikbefehl ausführen, meldet es diesen an das GDOS, das die Rahmenarbeiten verrichtet und lediglich die tatsächliche Grafikausgabe dem GIOS überläßt.

Und jetzt wird es interessant: Wenn schon GDOS und GIOS als GSX-RSXen ('RSXen' gibt es nicht nur beim Schneider CPC, sondern auch unter CP/M Plus!) nur bei Bedarf geladen werden und vorübergehend im RAM-Speicher stehen, könnte man doch verschiedene GIOS-Dateien verwenden und diese unterschiedliche Aufgaben erfüllen lassen. So ist es tatsächlich möglich, mehrere GIOS-Treiber bereitzuhalten und je nach Anwendungsfall zu verwenden. Der eine Driver zeigt eine Grafik auf dem Bildschirm an, der andere auf dem Matrixdrucker und wieder ein anderer vielleicht auf einem Plotter. Aber auch verschiedene Bildschirm-Modi verlangen nach jeweils spezifischen Treibern. Dieser Fall tritt gerade bei den Schneider CPCs auf, die 20, 40 oder 80 Zeichen in einer Bildschirmzeile darstellen können.

Wohlgemerkt: Intern werden diese Peripheriegeräte vom GIOS auf völlig unterschiedliche Weise angesprochen. Doch davon merkt das GDOS gar nichts, weil es ja die Ausgabe der Grafik dem GIOS-Treiber überläßt. Dieser elegante Aufbau von GSX eignet sich natürlich ausgezeichnet dazu, dem Anwender die Wahl zu überlassen, welches Darstellungsgerät er bevorzugt.

'BASIC steht für 'grundlegend' oder 'einfach'. Und tatsächlich, am leichtesten kann man GSX-Grafiken von BASIC aus programmieren. Nicht mit jedem Wald-und-Wiesen-Interpreter, sondern mit dem CBASIC-Compiler. Dieser stammt ebenfalls von Digital Research und wird seit kurzem in der 8-Bit-Version zu einem vernünftigen Preis angeboten.

Bei den neueren CBASIC-Versionen haben die Programmierer von vornherein eine Schnittstelle zu GSX vorgesehen. Die ist zwar im Handbuch nicht überwältigend gut beschrieben, aber mit etwas Herumprobieren kann man die Funktionsweise ohne weiteres herauszufinden.

Wenn Sie ein CBASIC-Programm mit Grafikausgabe schreiben wollen, müssen Sie unbedingt das Programm GRAPHCOM.BAS in den Programmcode einbinden. GRAPHCOM enthält COMMON-Befehle, die die Verbindung zu den Systemvariablen der CBASIC-Grafikroutinen sicherstellen.

In den Programmcode fügen Sie die Initialisierung der GSX-Grafik mit %INCLUDE GRAPHCOM.BAS ein. Dieser Befehl muß direkt am Programmanfang vor allen anderen Befehlen stehen. Alternativ können Sie auch den Inhalt von GRAPHCOM.BAS direkt in den Programmtext eintippen. Das führt zu einer flotteren Kompilierung des entstehenden Programms.

Die Grafikbefehle werden in CBASIC wie ganz normale BASIC-Kommandos aufgerufen. Um GSX zu aktivieren, gibt man erst einmal GRAPHICS OPEN 1 an. Danach sind Befehle wie SET BEAM, SET VIEWPORT, SET WINDOW und andere erlaubt. Nach einem GRAPHIC CLOSE verabschiedet sich GSX wieder. Genauere Informationen über die einzelnen Grafikbefehle enthält das 'CBASIC Graphics Guide'.

Ein Programm mit GSX-Aufrufen wird ganz konventionell mit CB80 compiliert und mit LK80 gelinkt. Dabei können auch andere BASIC- oder Maschinenprogramme wie üblich eingebunden werden.

Sobald Compiler und Linker ihre Arbeit verrichtet haben, besitzen Sie ein COM-File mit GSX-Aufrufen, aber ohne GSX-Ladeprogramm. Das erkennen Sie beim Programmstart oft an der ominösen Fehlermeldung 'ERROR DZ'. Einen GSX-Lader hängen Sie an das Programm mit dem Hilfsprogramm GENGRAF.COM von der CP/M-Systemdiskette. Heißt das kompilierte Programm beispielsweise GSXTEST.COM, versieht GENGRAF es bei folgendem Aufruf mit der Laderoutine:

A>GENGRAF GSXTEST.COM

Jetzt müssen Sie noch einige kleine Dateien auf die Programmdiskette kopieren: GSX.SYS enthält weitere Informationen für GSX. ASSIGN.SYS listet die für GSX vorgesehenen GIOS-Treiber als ASCII-Textdatei auf.

Diese GIOS-Treiber finden CPC-6128- und Joyce-Benutzer auf den Systemdisketten und der CBASIC-Diskette unter dem Namen DD??????.PRL. 'DD' steht hier für 'Device Driver'.

DDSCREEN (Joyce-PCW) beziehungsweise DDMODE0, DDMODE1 und DDMODE2 bei den Schneider CPCs arbeiten mit dem Bildschirm. Die übrigen Driver sind für die Grafikausgabe auf diversen Druckern und Plottern vorgesehen.

Damit GSX weiß, welche .PRL-Dateien es als Device-Driver ansehen soll, benötigt es die bereits erwähnte Datei unter dem Namen ASSIGN.SYS. Diese bestimmt auch die Zuordnung der Gerätetreiber zu den logischen Gerätenummern. Erinnern Sie sich an GRAPHIC OPEN 1 ? Dort steht die Eins für das Peripheriegerät Nummer 1. Eine Datei für ASSIGN.SYS könnte zum Beispiel so aussehen:

21 A:DDFXLR7
11 A:DDHP7470
01 A:DDMODE0

Die Extension .PRL wird von GSX automatisch angenommen.

Eine ASSIGN-Datei können Sie mit jedem beliebigen ASCII-Texteditor erstellen, notfalls auch mit PIP ASSIGN.SYS=CON:. Es gilt aber, einige Regeln und 'Macken' von GSX zu beachten:

1. Die vorrangehende Nummer zeigt die logische Gerätenummer an und wird immer zweistellig angegeben. In obigem Beispiel würde der Bildschirm als Gerät 1 (im Modus 0), der HP-Plotter als Gerät 11 und der Epson-FX-Drucker als Device 21 verwaltet. Digital Research hat außerdem vorgeschrieben, daß die Nummernvergabe nach gewissen Vorschriften zu erfolgen hat:

Das 'Metafile' wird unter CP/M Plus zumindest auf den Schneider-Computern nicht verwendet. Wenn Sie in einer Kategorie nur einen Treiber angeben, sollten Sie ihm die niedrigste zulässige Nummer zuweisen, also für den Bildschirmtreiber 1, für den Drucker 11 usw.

2. Die Gerätetreiber in der Datei müssen nach ihrer Größe geordnet werden. Damit GSX genügend Speicherplatz für die Driver zur Verfügung stellen kann, muß der größte Treiber als erster genannt werden. Das ist in den meisten Fällen der, der den Matrixdrucker anspricht.

3. In einer ASSIGN.SYS-Datei dürfen maximal fünf Treiber aufgeführt werden.

Das Bezugslaufwerk sollten Sie im übrigen bei jedem Dateinamen angeben. Wollen Sie GSX auf dem angemeldeten Laufwerk suchen lassen, ersetzen Sie die Laufwerksbezeichnung durch einen 'Klammeraffen'. Dieser besitzt den ASCII-Code 64 und wird auf der deutschen Tastatur durch das Paragraphenzeichen repräsentiert.

Wenn Sie nach diesem 'Rezept' vorgehen, sollten Sie eigentlich keine Schwierigkeiten mehr haben, GSX und CBASIC miteinander zu kombinieren. Allerdings sei aus gegebenem Anlaß ausdrücklich darauf hingewiesen, daß jedes Programm nur ein einziges Mal mit GENGRAF behandelt werden darf. Durchläuft ein Programm ein zweites oder drittes Mal die GENGRAF-Prozedur, besitzt es nachher eben zwei oder drei GSX-Lader, die nichts anderes tun, als Speicherplatz zu kosten.

Sobald ein Programm mit GSX-Lader gestartet wird, zeigt GSX in einer mehrzelligen Mitteilung, daß es jetzt gedenkt, aktiv zu werden, und verschiebt automatisch das GDOS und GIOS an das obere Ende des CP/M-Programmspeichers TPA (Transient Program Area). Da stört es einfach am wenigsten.

Arbeiten Sie mit einem 16-Bitter (wie beispielsweise dem c't 86) unter CP/M-86 mit der CBASIC-Version CB86, gibt es folgende Unterschiede zum bisher Gesagten:

- Die Gerätetreiber besitzen die Namenserweiterung SYS, zum Beispiel DDMX80.SYS. Die Zuweisungsdatei heißt aber weiterhin ASSIGN.SYS und sollte sich auf dem augenblicklich angewählten Laufwerk befinden.

- Der Arbeitsgang mit GENGRAF entfällt völlig. Ebenso fehlt GSX.SYS. Stattdessen geben Sie vor dem Start eines Grafikprogramms den Befehl GRAPHICS, der die Datei GRAPHICS.CMD in den Speicher lädt. Sie erhalten dann die Meldung 'GSX-86 installed'.

Während GSX sich unter CP/M Plus nach dem Ablauf eines Grafikprogramms selbsttätig aus dem Speicher verabschiedet, muß der Benutzer dies unter CP/M-86 ausdrücklich verlangen:

A>GRAPHICS NO

Unter CBASIC ist die GSX-Grafik sehr einfach zu programmieren. Doch CBASIC besitzt einige schwerwiegende Nachteile, die seine Nutzung nicht allzu attraktiv erscheinen lassen. Der schlimmste ist wohl die für ein kompiliertes Programm ungewöhnlich niedrige Arbeitsgeschwindigkeit des Objektcodes. Teilweise sind CBASIC-Programme sogar noch langsamer als das interpretierende Schneider- oder Mallard-BASIC. Da wird natürlich die Sache für ernsthafte Anwendungen einfach uninteressant.

Aber das ist kein Problem für den Maschinensprache-Freak, den Turbo-Pascal-Junkie oder C-Kryptologen. Denn wirklich ein jedes Programm, das ein ansonsten funktionsfähiges COM-File darstellt, kann Routinen der GSX-Grafik aufrufen. Nur muß man sich dann leider komfortable Grafikprozeduren auf der Basis der GDOS-Aufrufe selber schreiben.

Besonders einfach ist die Sache in Maschinensprache. Denn dort ist die Schnittstelle zur GSX-Grafik einfach ein weiterer BDOS-Aufruf. GSX belegt für diesen Zweck in der 8-Bit-Variante von CP/M die Funktionsnummer 115. Ein GSX-Aufruf erfolgt in drei Schritten. Zuerst wird die Funktionsnummer 115 in das C-Register des Prozessors geladen. Des weiteren läßt man das DE-Doppelregister auf einen Parameterblock zeigen. Und zu guter Letzt erfolgt die Ausführung des Befehls durch einen Sprung über den BDOS-Vektor in der Adresse 0005H:

LD	C,115		MVI	C,115
LD	DE,PBLOCK	LXI	D,PBLOCK
CALL	5		CALL	5

Die linke Spalte zeigt die Z80-Notation, die rechte die (altertümliche) mnemonische Schreibweise laut Intel.

Entsprechend der Bauweise des 8086 und 8088 greift GSX-86 unter CP/M-86 sowie MS-DOS beziehungsweise PC-DOS auf einen Software-Interrupt zurück. Er ist auf die Interruptnummer 224 festgelegt. Als Funktionscode erwartet GSX-86 hier im CX-Register des Prozessors den Code 0473H. Das DS-Segmentregister und das DX-Offsetregister sollten Sie auf den besagten Parameterblock zeigen lassen.

MOV	CX,0473H
MOV	DX,PBLOCK
INT	224

Praktischerweise ist das Lowbyte des CX-Registers dabei 73H, dezimal also 115. Es entspricht folglich genau der BDOS-Funktionsnummer für CP/M Plus.

Im folgenden werden wir uns in Beispielen im wesentlichen auf die Z80-Schreibweise beschränken. Denn GSX wurde durch die Schneider-Computer noch einmal viel weiter verbreiter als durch 16-Bit-Computer. Außerdem sollten Programmierer sowieso keine Schwierigkeiten haben, die minimalen Unterschiede beim Aufruf abzuändern.

Bei den Aufrufkonventionen für BDOS-Funktionen hat sich Digital Research schon seit den allerersten Anfängen von CP/M 1.4 sehr enge Grenzen gesetzt. So darf ein Parameter stets nur im DE-Register übergeben werden.

Da die Programmierer von DRI auch bei GSX konsequent bleiben wollten, mußten sie auf einen Kunstgriff zurückgreifen, den sie bei einer Vielzahl der übrigen BDOS-Funktionen von CP/M Plus bereits angewendet hatten: Das DE-Register zeigt auf einen Speicherbereich, in dem die eigentlichen Daten bereitgehalten werden. So enthält DE vor dem GSX-Aufruf einen Zeiger auf einen speziellen Parameterblock.

Das etwas Verwirrende ist aber, daß der Parameterblock auch wieder nur Adressen enthält. Hier sind der Reihe nach Zeiger auf die Speicheradressen von fünf weiteren Tabellen abgelegt:

PB:     Adresse von contrl
PB+2:   Adresse von intin
PB+4:   Adresse von ptsin
PB+6:   Adresse von intout
PB+8:   Adresse von ptsout

Die Bezeichnungen der Tabellen sind der Originaldokumentation von GSX entnommen. Digital Research hat interessanterweise auch bei GEM wieder auf diese Namen zurückgegriffen ...

Da die realen Speicheradressen bei CP/M-86 und MS-DOS aus der Segmentadresse und dem Offsetwert zusammengesetzt werden, reicht die Größe des Parameterblocks unter CP/M bei den IBMs und Kompatiblen natürlich nicht aus. Folglich belegt jeder Vektor hier vier Bytes:

PB:     Adresse von contrl
PB+4:   Adresse von intin
PB+8:   Adresse von ptsin
PB+12:  Adresse von intout
PB+16:  Adresse von ptsout

'contrl' enthält die wichtigsten Informationen für die GSX-GDOS-Routinen, vor allem die Nummer der gewünschten Grafikfunktion und Informationen über die (variable) Größe der anderen Felder.

Die Bezeichnung 'intin' kommt von dem englischen Ausdruck 'integer input parameter'. Übersetzen muß man das wohl nicht. Der ptsin-Array ('points input') enthält die bei manchen Funktionen geforderten Listen von X-Y-Koordinaten der zu setzenden oder zu löschenden Punkte.

Aus den Feldern 'intout' ('integer Output parameter') und 'ptsout' ('points Output') kann ein Programm nach dem Aufruf einer GDOS-Routine Daten auslesen, die GSX während der Befehlsausführung dort hinein plaziert hat.

Als kleines Beispiel dient ein Maschinenprogramm, das die GSX-Grafik initialisiert und den kompletten Bildschirm mit einem Farbblock auffüllt.

Sie können das Programm etwa als GSXDEMO.ASM abtippen und auf Diskette speichern. Mit MAC oder ASM übersetzen Sie es in den Intel-Hexcode, LOAD beziehungsweise HEXCOM besorgt dann die Umwandlung in das übliche COM-File-Format. Da das Programm bis zu diesem Zeitpunkt noch über keinen GSX-Lader verfügt, verbinden Sie diesen mit dem Programm GSXDEMO mit Hilfe von GENGRAF:

A>GENGRAF GSXDEMO

Vorausgesetzt, GSX.SYS, ASSIGN.SYS und der passende Bildschirmtreiber sind in korrekter Form auf der Diskette enthalten, erscheint nach der Eröffnungsmitteilung von GSX die gewünschte Grafik. Wundern Sie sich aber nicht, daß nach Ablauf des Programms die Bildschirmfarben geändert sind und der Cursor abgeschaltet wurde. Über das Steuerzeichen 'ESC e' läßt sich zumindest der letztgenannte Mangel beheben.

Wie Sie im Quellcode am Größenverhältnis von Datenbereichen und Programmcode unschwer erkennen können, muß man GSX-Anwendungen zu den datenintensiven Programmen rechnen. Besonders im Assembler-Quellcode nehmen die Tabellen arg viel Platz weg. Wehe, wenn der Texteditor nur eine bestimmte Dateilänge verarbeiten kann!

Führen Sie sich ruhig den ausführlich kommentierten Quellcode zu Gemüte. In der nächsten Ausgabe von c't folgen genauere Angaben über die einzelnen GSX-Funktionen und ihre Aufrufparameter.

Sie können aber auch schon einmal versuchen, die verschiedenen Parameter abzuändern. Einen interessanten Effekt, sprich eine andere GDOS-Funktion erreichen Sie, wenn Sie die Funktionsnummer 9 im Feld CONTRL2 in eine 6 abändern.

Und wenn Sie unbedingt wissen wollen, warum die Koordinaten so irrsinnig hohe Werte bis 32767 annehmen, ja dann dürfen Sie auf gar keinen Fall die nächste c't versäumen ...