Saubere Fenster: Softwareprobleme mit Ganzseitenbildschirmen

Wer glaubt, daß eine Bildschirmzeile immer nur 80 Zeichen lang sein kann, wundert sich später
Die Ausgabetreiber von Caiamus passen sich an den verwendeten Biidschirm an

Als vor über drei Jahren die ersten ST-Entwicklungssysteme Deutschland erreichten, lagen zwar etwa 3000 Seiten Dokumentation dabei, jedoch blieben viele Aspekte des Betriebssystems bis heute schlecht dokumentiert oder wurden gar nicht durchdacht. Man bemerkt es immer wieder, wenn man Software unter »Extrembedingungen« testet.

Was die Software-Abteilung von Atari offenbar zu leisten nicht bereit ist, haben seit einiger Zeit unabhängige Programmentwickler übernommen — man denke beispielsweise an das »XARG«-Verfahren von Dale Schumacher, über das wir vor drei Monaten [1] berichteten und das mittlerweile auch von der Command-Shell »Master V5.4« verstanden wird. Diesen Monat wollen wir wiederum eine Methode vorstellen, die die reibungslose Zusammenarbeit von Programmen erleichtern soll: das »XBRA-Protokoll zur Verwaltung vektorverbiegender Programme«.

Das XBRA-Protokoll

Speicherresidente Utilities, die Systemvektoren »verbiegen«, haben zwei Probleme:

Das hier vorgeschlagene XBRA-Verfahren (extended BRAner) [3] geht auf die Idee des amerikanischen Programmierers Moshe Braner (Autor von »GNOME«) zurück, die wir in einem Punkt etwas erweitert haben.

Jedes vektorverbiegende Programm plaziert direkt vor seiner eigenen Einsprungadresse (also genau vor der Adresse, auf die der Vektor gesetzt wurde) folgende C-Struktur:

typedef struct
{
    char xb_magic[4];
    /* "XBRA" = 0x58425241 */
    char xb_id[4];
    /* Indentifikations code des instal lierten Programms */ 
    long xb_oldvec;
    /* ursprünglicher Wert des Vektors */
} XBRA;

Zunächst überträgt man den geretteten Inhalt des betreffenden Systemvektors in »xb_oldvec«.»xb_id« sollte eine Identifikationsnummer des installierten Programms enthalten, Konvention ist dabei eine vierstellige Zeichenkette (beispielsweise »CACH« für einen Hard-Disk-Cache). Mittels dieser Konstante überprüft man dann in eigenen Programmen, ob die Routinen bereits installiert sind.

»xb_magic« ist die besagte, von uns vorgenommene Erweiterung der Braner-Methode, mit deren Hilfe man erst hunderpro-zentig sicherstellt, daß an der betrachteten Stelle im Speicher eine XBRA-Struktur steht. Mittels der XBRA-Methode installierte Programme stellen mit Leichtigkeit fest, ob sie bereits installiert sind und sind auch wieder einfach aus der Vektorkette zu entfernen. Wir hoffen, daß alle Programmierer in Zukunft beim Schreiben eigener Programme diesen Vorschlag beherzigen.

Wo ist der EST?

Viele Besucher der gerade beendeten Atari-Messe in Düsseldorf haben vermutlich den von uns in der August-Ausgabe [4] getesteten Doppel-Ganzseitenmonitor der Firma Matrix bewundert. Der Haken an dieser imponierenden Hardware: Leider gibt es nur ganz wenig Software, die die erhöhte Auflösung nutzt — ganz zu schweigen von den Programmen, die überhaupt nicht laufen. Es ist sicherlich keine allzu gewagte Behauptung, daß Atari aus genau diesem Grund bis heute den EST nicht vorgestellt hat. Vereinfacht lautet die Problematik: »Gibt es keine geeignete Software, weil es bislang die Hardware nicht gab — oder wurde die Hardware deshalb nicht gebaut, weil sowieso keine geeignete Software zur Verfügung steht?«

Nun ist eine variable Bildschirmauflösung ja kein unbedingt neues Problem: Bereits die drei verschiedenen Auflösungen des ST machen den Software-Entwicklern genug Probleme. Im folgenden ein paar Faustregeln, die das Entwerfen von der Bildauflösung unabhängiger Programme erleichtern.

Am einfachsten hat man es sicherlich, wenn man durchgängig unter GEM programmiert. Aber selbst Programme, die auch unter PC-GEM laufen, wie beispielsweise Adimens oder 1st Word plus, haben ihre Probleme. Ein paar Tücken gibt es allerdings doch:

Wer sauber unter GEM programmiert, hat nichts zu befürchten...
1st Word plus setzt die Icon-Leiste für die Funktionstasten an eine feste Bildschirmkoordinate
Offset Name Typ Belegung
-$002 BYTES_LIN Word Bytes pro Bildschirmzeile
-$004 V_REZ_VT Word vertikale Auflösung in Pixeln
-$00C V_REZ_HZ Word horizontale Auflösung in Pixeln
-$028 V_REZ_WR Word Bytes pro Character-Zeile
-$02A V_CEL_MY Word maximale Cursorzeile
-$02C V_CEL_MX Word maximale Cursorspalte
-$02E V_CEL__HT Word Zeichenhöhe des Systemzeichensatzes
-$2B4 DEV_TAB Words die 45 Werte, die man bei ’v_opnvwk()’ erhält
-$30E INQ_TAB Words die 45 Werte, die man bei ’vq_extnd()’ erhält

Tabelle. Eine Auswahl der nützlichsten Adressen im negativen Line-A-Bereich

Vorbild: schnelle GEM-Programme

Auch wer glaubt, an GEM vorbei programmieren zu müssen, kann sich selbst mit allen Informationen über den verwendeten Bildschirm versorgen. Seit einiger Zeit sind nämlich die berüchtigten »negativen« Line-A-Variablen offiziell dokumentiert [3,5]. Vor der Manipulation dieser Adressen warnen wir allerdings — man sollte sie wirklich als »READ ONLY« betrachten! Eine Auswahl der in diesem Zusammenhang interessanten Adressen sehen Sie in der Tabelle. Sowohl TOS-Anwendungen (beispielsweise »microEmacs 2.19«) als auch grafische Anwendungen mit eigenen Ausgabetreibern (»Calamus«) greifen auf diese Adressen zu, um sich dem verwendeten Bildschirm anzupassen. Wer es nicht tut, muß mit Resultaten wie bei »Tempus« oder »Signum« rechnen (wer davon ausgeht, daß eine Bildschirmzeile immer maximal 80 Zeichen breit ist, braucht sich nicht zu wundern…).

Dennoch sei nochmals darauf hingewiesen, daß es in den allermeisten Fällen völlig überflüssig ist, den sauberen Weg über das VDI zu verschmähen. Viele Programme demonstrieren immer wieder, daß man bei geschickter Programmierung auch unter GEM schnelle Programme schreibt, man denke zum Beispiel an den Editor von Turbo-C, DEM-Draw oder Campus-CAD.

Wir sparen 5000 Mark

Soweit die graue Theorie — doch was nützt das alles ohne eine Gelegenheit zum Testen? Selbst die Tatsache, daß ein Programm in der PC-Version auf den abenteuerlichsten Grafikkarten läuft, garantiert nicht, daß es sich auch auf dem ST richtig verhält — das liegt an geringfügigen Unterschieden in den GEM-Implementationen (diese schmerzliche Erfahrung mußten die Adimens-Programmierer mit ihrer ansonsten vorbildlichen programmierten GEM-Oberfläche machen...)

Nicht jeder kann sich eine Grafikkarte samt Ganzseitenmonitor leisten — als Ausweg bietet sich, wie so oft, die Emulation an:

In der nächsten Ausgabe finden Sie ein Programm zur Emulation einer (fast) beliebigen Auflösung auf Ihrem Monitor, mit dem Sie Ihre Software austesten können! Besonders professionelle Programmierer werden ihre helle Freude daran haben.

Und zum Abschluß noch eine brandheiße Meldung aus Raunheim: Die »Freigabe« der neuen TOS-Version wird pünktlich zur Atari-Messe erwartet! Hoffentlich müssen wir nicht allzu lange auf die ersten ROMs warten.

(uh)

Quellennachweis:

[1] Julian Reschke: »Schranken durchbrechen«, ST-Magazin 7/1988

[2] Axel Pretzsch: »Programmieren in guter Atmosphäre«, ST-Magazin 5/1988

[3] Jankowski/Rabich/Reschke: »Das Atari ST Profibuch«, 5. Auflage, Sybex Düsseldorf 1988, ISBN 3-88745-501-0

[4] Wolfgang Fastenrath: »Über-Sicht«, ST-Magazin 8/1988

[5] Mark Jansen: »S.A.L.A.D. — Still another Line A document«, Atari Corporation 1987


Julian F. Reschke
Links

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