Megapixel auf dem Vormarsch

Lang ist's her, daß die Schreibtische der Atari-Anwender von der Monokultur der »SM-124«-Monitore beherrscht wurden. Die Konkurrenz ist inzwischen da, farbiger und größer.

Eigentlich sollte das Anlaß zu ungeteilter Freude sein, doch leider werden viele Anwender Probleme mit alten Programmen bekommen, die sich allzusehr auf die farblosen 640 x 400 Bildpunkte des SM-124 verlassen. Immerhin ist die Lage nicht mehr so trostlos, wie vor der Einführung der monochromen Matrix-Großbildschirme vor mehr als zwei Jahren: Viele wichtige Programme wurden angepaßt, die Tendenz zum sauberen Programmieren zeigt sich deutlich. Dennoch haben viele Software-Entwickler Probleme mit der Anpassung an die Fähigkeiten der neuen Grafikkarten.

Für viele Programmierer stellt sich beim Thema portables Programmieren zunächst die Frage nach dem »Warum«. Die Meinung, Großbildschirme seien nur etwas für eine elitäre Minderheit, ist tatsächlich weit verbreitet. Wer aber als Grafiker, Layouter, Vielschreiber oder Programmierer über längere Zeit mit einem Großbildschirm gearbeitet hat, kennt den enormen Produktivitätsgewinn durch die komfortablere Arbeitsfläche. Aber auch für den rein privaten Gebrauch gibt es sehr preiswerte Möglichkeiten, die Auflösung zu vergrößern, sogar ohne den Monitor zu wechseln. Die vor einiger Zeit vom ST-Magazin vorgestellte »Hyperscreen«-Lösung erlaubt auf einem ganz normalen SM-124 eine um etwa 50 Prozent vergrößerte Arbeitsfläche.

Im Bereich der Farbgrafik bekommt man schon für 1300 Mark eine »Matrix«-Grafikkarte mit Coprozessor, die auf handelsüblichen Farbmonitoren z.B. 640 x 400 Punkte in satten 256 Farben darstellt. Sie sehen, Grafik-Erweiterungen sind auch für den privaten Anwender erschwinglich geworden. Allein diese Tatsache sollte für jeden Software-Entwickler Grund genug sein, portabel zu programmieren, damit die Anwender von den Möglichkeiten ihrer Grafikkarten optimalen Gebrauch machen können. Der wohl wichtigste Aspekt moderner Software ist die Art und Weise, in der sich ein Programm dem Anwender präsentiert. Das Ziel sollte immer sein, den Benutzer möglichst effizient bei der Erledigung seiner Arbeit zu unterstützen. Diese Effizienz ist nicht mit der Arbeitsgeschwindigkeit eines Programms, z.B. eines Texteditors, identisch, sondern besteht aus mindestens fünf Komponenten:

1. leichte Erlernbarkeit durch eine standardisierte Benutzeroberfläche

2. effiziente Handhabung auch nach der Lernphase

3. ausreichende Arbeitsgeschwindigkeit

4. Zuverlässigkeit

5. einfache Integration in bestehende sowie sich ändernde Arbeitsumgebungen

Zentrale Bestandteile aller modernen Benutzeroberflächen sind Fenster, Menüs und Dialogboxen. Bei allen Unterschieden zwischen den Human Interface Guidelines von »Apple«, der Systems Application Architecture von »IBM« und GEM von »Digital Research«, in einem Punkt sind sich die Beteiligten einig: Daten sollen grundsätzlich in Fenstern dargestellt und bearbeitet werden. Auch die wichtigsten Kontrollelemente der Fenster, z.B. die horizontalen und vertikalen Rollbalken, finden sich überall wieder. Fenster sind rechteckige Bereiche auf dem Bildschirm, die einen Ausschnitt aus einem Dokument zeigen. Durch Variieren der Fenstergröße und Position kann der Anwender die Arbeitsumgebung seinen persönlichen Bedürfnissen anpassen und hat zudem durch die Rollbalken eine ausgesprochen effiziente und elegante Kontrolle über den sichtbaren Ausschnitt der bearbeiteten Daten. Programme ohne Fenstertechnik (z.B. »Signum«, »That's Write«, diverse Malprogramme) schreiben dem Anwender den Bildschirmaufbau vor, entfernen sich von einem Standard, der sich über alle Rechner- und Betriebssystemgrenzen hinweg durchgesetzt hat, und machen damit den Anwender höchst abhängig von der verwendeten Grafikkarte.

Ein Programm, das die Fenstertechnik vollständig implementiert, also frei verschiebbare und in der Größe veränderbare Fenster anbietet, ist prinzipiell bereits von der Auflösung unabhängig. Die meisten Anwender sind in erster Linie interessiert, daß der Computer samt seiner Software funktioniert, und das ist richtig so. Wer sich von seinem Händler eine Grafikerweiterung einbauen läßt, hat ein gutes Recht darauf, daß seine Software zumindest irgendwie läuft. Wenn ein Gerät gar beruflich eingesetzt wird, kostet jede Minute, die damit vergeudet wird, die Auflösung und den Monitor umzuschalten, bares Geld. Daher im Sinne des Anwenders die Forderung, daß jegliche Software in jeder Auflösung laufen sollte. Ausnehmen kann man vielleicht Auflösungen unterhalb von 640 x 200 Punkten, die ernsthaftes Arbeiten nicht zulassen.

Um das Problem zu verdeutlichen, führen wir uns folgendes praxisnahe Beispiel vor Augen: H. Müller hat einen Atari ST, den er für Textverarbeitung und Grafik verwendet. Um eine höhere Auflösung auf seinem Multisync-Monitor zu erhalten, hat er sich eine Farbgrafikkarte gekauft, die zudem das Arbeiten im S/W-Modus deutlich beschleunigt. Seine Grafiken kann er in Graustufen oder Farbe auf dem Monitor begutachten, bevor er den Drucker einschaltet oder die Diskette zum Belichtungsservice gibt.

Seine Präsentationsgrafik ist ordentlich programmiert und läuft daher einwandfrei mit der neuen Grafikkarte. So weit, so gut. Die Textverarbeitung läuft zwar auch mit der neuen Grafikkarte, aber nur monochrom bei der Standardauflösung von 640 x 400 Punkten. Jetzt hat H. Müller ein Problem: Für jeden Wechsel zwischen Textverarbeitung und Grafikprogramm muß er den Computer komplett neu starten. H. Müller weiß durchaus, daß ihm die vielen Farben seiner Grafikkarte in der Textverarbeitung nichts nützen. Er versteht auch, daß der Grafikaufbau im Farbmodus langsamer als in monochrom ist, aber für ein paar Änderungen in seinem Text mochte er verständlicherweise nicht den Rechner neu starten. Dasselbe gilt auch für die Studentin Liese Lotte, die einen 1040 ST benutzt und für 100 Mark die Overscan-Lösung eingebaut hat, um ein wenig mehr von ihrer Diplomarbeit auf dem Bildschirm zu sehen.

Wichtig ist aber vor allem, daß die Software-Entwickler portable Programmierung als technische Notwendigkeit und Dienst am Kunden betrachten und nicht erst tätig werden, wenn jeden zweiten Tag ein Kunde telefonisch eine Großbildschirm-Anpassung fordert. Die Grundregel der portablen Programmierung fordert eine völlige Unabhängigkeit des Programms von der verwendeten Hardware. Für den Bereich der Grafikausgabe bedeutet das, daß der Programmierer keinerlei Annahmen über die Beschaffenheit des Bildschirms machen darf. Alle Informationen über Auflösung und Farbpalette müssen vom Betriebssystem erfragt werden.

Daß die eigentlichen Grafikausgaben ausschließlich über GEM-Funktionen bewältigt werden dürfen, versteht sich da fast von selbst. Der direkte Zugriff auf den Bildschirmspeicher ist schon deshalb schlechter Stil, weil verschiedene Grafikkarten den Bildspeicher unterschiedlich organisieren. So legen die Farbgrafikkarten von Matrix alle Bits eines Bildpunkts nebeneinander, während die normalen Farbmodi des Atari ST und TT das Format der sog. Interleaved Bitplanes verwenden. Bei Interleaved Bitplanes handelt es sich um eine Modifikation der früher gebräuchlichen Bitplanes, die heute noch in »VGA-Karten« auf IBM-kompatiblen Computern benutzt werden. Während sich ein Bildspeicher mit normalen Bitplanes aus mehreren einfarbigen Rastern zusammensetzt, die bei der Erzeugung des Farbsignals quasi übereinandergelegt werden, werden bei Interleaved Bitplanes jeweils 2 Byte jeder Bitplane hintereinander in den Speicher geschrieben.

Sie sehen also, bei direktem Zugriff auf den Bildschirmspeicher kann keine Kompatibilität zu sämtlichen Grafikkarten erreicht werden. Hinzu kommt, daß nur durch die Benutzung des VDI die eventuell vorhandenen Grafik-Coprozessoren ausgenutzt werden können. So greift der von »Matrix« und »Maxon« verwendete »Intel 82786« dem VDI, z.B. beim Scrolling oder Linienzeichnen, ganz gehörig unter die Arme. Ein sauber programmiertes und optimiertes Programm scrollt bei Verwendung einer solchen Grafikkarte im Monochrom-Modus 2-3mal schneller als ein normaler Mega ST mit Blitter. Wer sich selbst schon intensiver mit Grafikprogrammierung beschäftigt hat, weiß, daß z.B. ein Großbildschirm mit 256 Farben ohne Coprozessorunterstützung nicht mehr sinnvoll vom 68000er bedient werden kann.

Leider gibt es auch bei völligem Verzicht auf direkten Bildschirmzugriff einige Möglichkeiten, Software so zu schreiben, daß sie nicht auf allen Grafikkarten lauffähig ist. Bei genauer Betrachtung fällt eine Anhäufung spezifischer Probleme auf:

1. falsches Öffnen der Bildschirm-Workstation
2. Setzen eines zu kleinen Clipping-Rechtecks
3. fehlerhafte Benutzung der VDI-Rasterfunktionen
4. Umsetzen des Bildschirmspeichers
5. fehlerhafte Benutzung der VDI-Textfunktionen

Zu den seltener auftretenden Fehlern zählen die falsche Verwendung von VDI-Schreibmodi sowie eine zu kleine Dimensionierung des Desktop-Hintergrundes.

Jedes Programm, das per VDI auf den Bildschirm ausgibt, muß zunächst eine sog. virtuelle Workstation öffnen. Das VDI besitzt das Konzept der Workstations, um zu verhindern, daß verschiedene AES-Prozesse (Hauptprogramm, AES, Accessories) sich gegenseitig die Ausgabe-Attribute verstellen. Das VDI merkt sich sämtliche Attributeinstellungen und sonstige Informationen für jede Workstation getrennt. Zur Identifizierung der gewünschten Workstation wird bei jedem VDI-Aufruf ein sog. Handle als Parameter übergeben. Eine virtuelle Workstation kann man natürlich nicht im luftleeren Raum öffnen. Das VDI möchte nämlich wissen, welches Gerät gemeint ist. Dazu muß bekannt sein, daß das AES bei seiner Initialisierung eine physikalische Bildschirm-Workstation öffnet, auf der alle weiteren virtuellen Workstations geöffnet werden. Das zur Identifizierung dieser Workstation erforderliche Handle kann mit graf_handle() beim AES erfragt werden. In Listing 1 werden zusätzlich die wichtigsten Informationen über den Bildschirm in globale Variablen geschrieben.

Das von v_opnvwk() gelieferte Handle ist gültig, wenn es größer als Null ist. Negative oder Null-Handles werden dann zurückgegeben, wenn das Öffnen der Workstation (z.B. aufgrund von Speichermangel) nicht funktioniert hat. Wenn das Öffnen der Workstation mißlingt, empfiehlt es sich, das Programm nach Anzeige einer Fehlermeldung ordnungsgemäß zu beenden. Dabei darf man natürlich nicht den Fehler machen, die Workstation mit v_clsvwk( ) zu schließen, denn man hat in dem Fall ja kein gültiges Handle, das dem VDI sagen könnte, welches Gerät gemeint ist.

Wer sichergehen möchte, sollte sein Programm auf jeden Fall zusammen mit »AMCGDOS« austesten, da dieses zuverlässig die Benutzung von ungültigen Handles anzeigt. Vielleicht erscheint es überzogen, so ausführlich auf die VDI-Handles einzugehen. Nichtsdestotrotz handelt es sich dabei um ein wichtiges Thema, da die falsche Benutzung von Handles des öfteren dafür sorgt, daß die Attribute des AES so verstellt sind, daß nur noch ein Neustart des Rechners helfen kann.

Die VDI-Ausgabefunktionen teilen sich in die Gruppen Polygon, Fläche, Marker, Text und Raster auf. Bis auf die Rasterfunktionen sind diese Funktionsgruppen auf allen ordentlichen GDOS-Treibern prinzipiell problemlos. Bei der Textausgabe ist zu beachten, daß der GDOS-Treiber zur »MGE«-Farbgrafikkarte derzeit keine Zeichen ausgeben kann, die größer als 16 Bildschirmpunkte sind.

Bei der Textausgabe kann es Probleme geben, wenn beliebig skalierbare Zeichensätze ins Spiel kommen. Gut optimierte Programme legen Tabellen der Zeichenbreiten an, um nicht jedesmal bei der Ausgabe beim VDI nachfragen zu müssen. Wenn in einem System nun beliebig skalierbare Zeichensätze vorliegen, wird der Speicherplatz ein wenig eng. Selbst wenn man nur Zeichen bis zu 72pt unterstützt, würden die Breitentabellen allein für einen einzigen Zeichensatz rund 36 KByte verbrauchen. Spätestens, wenn ein Benutzer mehrere dieser Zeichensätze installiert hat, muß man sich etwas anderes einfallen lassen.

Der beste Gedanke ist wohl, wenn man nur Tabellen für die am häufigsten gebrauchten Größen anlegt und die Maße anderer Zeichen nur bei Bedarf errechnet. Allerdings ist diese Methode komplizierter, als es sich zunächst anhört. Immerhin muß ja festgestellt werden, welches die am häufigsten benötigten Größen sind. Mein Vorschlag ist, für einige festgelegte Größen die Tabellen auf jeden Fall anzulegen und dann während des Programmlaufs festzustellen, welche zusätzlichen Größen der Benutzer benötigt. Als Grundstock für die Tabellen bieten sich 8, 9, 10, 12, 14, 18 und 24pt an.

Ein oft übersehener Aspekt der Textausgabe auf dem Atari ist die maximale Anzahl der Zeichensätze. Nichts und niemand (außer vielleicht die Speicherknappheit) kann einen Anwender daran hindern, 32000 Zeichensätze beim GDOS anzumelden. Daran scheitern allerdings solche Programme wie der »Timeworks Publisher«, die nur eine feste Anzahl von Zeichensätzen erlauben. Ein ordentlicher Textselektor muß auf jeden Fall eine scrollbare Liste von Zeichensätzen und vorhandenen Größen anbieten und darüber hinaus die manuelle Eingabe einer Größe erlauben.

Auch hier muß natürlich der Fall der frei skalierbaren Zeichensätze bedacht werden. Wer im Textselektor den Speicherplatz für die Tabellen nicht dynamisch verwaltet, darf sich nicht wundern, wenn sich später die Anwender beklagen. Ein Textselektor, der feststellt, daß ein Zeichensatz frei skalierbar ist (z.B. im Postscript-Treiber), sollte in der Größenliste eine Auswahl von etwa zehn Standardgrößen anbieten und weitere Größen nur durch direkte Eingabe erlauben. Stellen Sie sich nur vor, Sie hätten eine Liste mit Größen von 2 bis 200pt vor sich und wollten 72pt einstellen.

Wie stellt man nun fest, welche Zeichengrößen vorhanden sind? Die VDI-Funktion vst_height() des normalen Bildschirmtreibers liefert neben den tatsächlich vorhandenen Größen die jeweils doppelten sowie alle kleineren Größen. Die Farbtreiber der Matrix-Karten können bei vst_height() auch (fast) beliebig aufwärts skalieren. Im Gegensatz dazu kann man mit vst_point() nur real existierende sowie die jeweils doppelten Größen einstellen. Wenn also der Zeichensatz Helvetica in den Größen 10 und 12pt installiert ist, kann man mit vst_point() nur die Größen 10, 12, 20, und 24pt erzielen. Leider kann man die verdoppelten Größen nicht einwandfrei ermitteln. Stellen wir uns vor, wir bekämen von vst_point die Größen 10, 20, 40 und 80pt. Dann könnten entweder die Größen 10 und 40pt, vielleicht aber auch zusätzlich 20pt installiert sein. Wohl oder übel muß man in der Größenliste also alles anzeigen, was man mit vst_point() einstellen kann.

Die zweite nicht ganz einfache Gruppe sind die Rasterfunktionen des VDI. Zur Darstellung von Rastern auf dem Bildschirm bietet das VDI die drei Funktionen vro_cpyfm(), vrt_cpyfm() und vr_trnfm() an. Ein Raster wird im VDI durch einen sog. Memory Form Definition Block, kurz MFDB beschrieben. Dabei unterscheidet man zwei Formate, das Standardformat und das geräteabhängige Format. Während das Standardformat eindeutig definiert ist, kennt nur der betreffende Gerätetreiber das geräteabhängige Format. Im idealen Fall ist das Standardformat mit dem geräteabhängigen identisch, da dann das Raster nicht konvertiert werden muß und die Ausgabe besonders schnell ist.

Wenn die beiden Formate nicht identisch sind (was leider meistens der Fall ist), muß das VDI das Raster konvertieren. Da das mitunter sehr zeitaufwendig sein kann, konvertiert das VDI die Raster nicht automatisch, sondern bietet für diesen Zweck die Funktion vr_trnfm() an. Auf diese Weise kann ein Programm das Raster einmal konvertieren und bei jedem Neuzeichnen des Fensterinhalts auf das bereits fertig konvertierte Raster zurückgreifen. Obwohl eine ausführliche Besprechung der Rasterfunktionen den Rahmen dieses Artikels sprengen würde, sollen einige wichtige Aspekte hier Erwähnung finden. Betrachten Sie zunächst bitte das Listing, in dem die Struktur des MFDB's in CNotation abgebildet ist. Ein MFDB beschreibt grundsätzlich nur das Raster, in dem gearbeitet werden soll. Der gewünschte Ausschnitt wird beim VDI-Aufruf gesondert übergeben. Als Raster kann entweder ein selbst angelegter Speicherblock oder der Bildschirm angegeben werden. In bezug auf den MFDB stellt der Bildschirm eine Besonderheit dar. Immer dann, wenn der Bildschirm angesprochen werden soll, muß als Rasteradresse ein Nullpointer eingetragen werden. Wohlgemerkt, nicht als Adresse des MFDBs muß ein Nullpointer übergeben werden; gemeint ist vielmehr die im MFDB eingetragene Rasteradresse (fd_addr).

Findet das VDI beim Aufruf von vrt_cpyfm() oder vro_cpyfm() in einem MFDB einen Nullpointer als Rasteradresse, so trägt es selbständig alle für den Bildschirm geltenden Parameter ein. Beachten Sie bitte, daß bei vrt_cpyfm() als Ausgangsraster nicht der Bildschirm verwendet werden darf. Das ist insofern auch schlüssig, als vrt_cpyfm() nur monochrome Raster auf ein- oder mehrfarbige Raster kopiert und der Bildschirm ja durchaus auch farbig sein kann. Beide Rasterausgabefunktionen des VDI arbeiten ausschließlich mit Raster im geräteabhängigen Format. Wer Raster im Standardformat kopieren möchte, muß diese zunächst mit vr_trnfm() umwandeln. Das Anwenderprogramm wiederum darf ausschließlich mit Rastern im Standardformat arbeiten, da es ja den Aufbau des geräteabhängigen Formats nicht kennt.

Wie bereits erwähnt, kann die Umwandlung von Rastern vom geräteabhängigen ins Standardformat (und umgekehrt) durchaus etwas dauern. Auch wenn die Umwandlungszeiten sogar bei farbigen Großbildschirmen im Bereich unterhalb einer Sekunde liegen, sollte man die Raster nur dann umwandeln, wenn es unbedingt nötig ist. Vor allem aber empfiehlt sich die Verwendung eines ausreichend großen Pufferspeichers beim Transformieren der Raster.

Wer beim Aufruf von vr_trnfm() zwei identische Rasteradressen angibt, darf sich nicht wundern, wenn das Umwandeln einige Zeit kostet. Zwar versucht der Matrix-Farbtreiber, selbst einen Puffer anzufordern, um den Vorgang zu beschleunigen, doch sollte man sich darauf lieber nicht verlassen, um nicht bei anderen Treibern eine schlechte Performance zu bekommen. Wer auf das Anlegen eines eigenen Puffers verzichtet, sollte zumindest darauf achten, daß er dem Treiber genug GEMDOS-Speicher übrig läßt, damit dieser selbst tätig werden kann.

Ein wichtiger Hinweis zum Abschluß dieses Themas: Auch Icons, die sich im Ressourcefile befinden, müssen nach dem Laden mittels rsrc_load() ins geräteabhängige Format umgewandelt werden. Ein komplettes Beispielprogramm finden Sie in (3) und (4), die bisher ausführlichste Behandlung der Rasterfunktionen in (4).

Kommen wir nun zu einem sehr leidigen Thema, der Umschaltung der Bildschirmadresse bzw. der Ermittlung derselben. Leidig ist das Thema deshalb, weil viele Programmierer immer wieder meinen, die Bildschirmadresse erfragen oder gar verstellen zu müssen, obwohl es wirklich nur sehr wenige Gründe gibt, dies zu tun. Lediglich für flackerfreie Animationen erscheint es sinnvoll, auf zwei getrennten Bildschirmseiten zu arbeiten und diese im Vertical-Blank-Interrupt umzuschalten. Sämtliche bisher verfügbaren Großbildschirm- und Farbkarten stellen kein VBI-Signal zur Verfügung und haben meist nicht ausreichend Platz, um zwei Bildschirmseiten gleichzeitig im Speicher zu halten. Da allerdings selbst Rechner auf 68030-Basis kaum in der Lage sind, professionelle Animationen darzustellen, schmerzt der Verlust nicht allzusehr.

Darüber hinaus muß darauf hingewiesen werden, daß das VDI das Umschalten der Bildschirmadresse nicht erlaubt. Zwar funktioniert das auf einem SM-124 ohne weiteres, verlassen darf man sich darauf aber nicht. Wer meint, unbedingt direkt in den Bildschirmspeicher schreiben zu müssen, kann die Bildschirmadresse per XBIOS-Aufruf »Logbase()« erfragen. Bleiben noch die Anwendungen, in denen es nützlich ist, mit zwei getrennten Bildschirmseiten zu arbeiten, zwischen denen der Anwender umschalten kann. Wenn überhaupt, sollte das allerdings nur in Programmierumgebungen wie z.B. Turbo-C geschehen. In allen anderen Fällen greift man besser auf mehrere Fenster zurück.

Wie bereits erwähnt, darf man die Bildschirmadresse nicht umschalten, so daß als einzige Alternative das Umkopieren der Bildschirmseiten bleibt. Am einfachsten und portabelsten erledigt man das mit der VDI-Funktion vro_cpyfm(). Selbst ohne Blitter arbeitet diese Funktion ausreichend schnell. Beachten sollte man in diesem Zusammenhang auch, daß es möglicherweise einmal Grafikkarten gibt, die nicht im normalen Adreßraum des Prozessors liegen. Den Bildschirminhalt dieser Grafikkarten kann man nur über das VDI bekommen. Ein Grund mehr, sich intensiv mit den Rasterfunktionen auseinanderzusetzen.

Wenn Sie testen möchten ob sich die Startadresse des Bildschirms verschieben läßt, können sie notfalls die XBIOS-Funktion »Setscreen()« verwenden und anschließend mit »Physbase()« erfragen, ob das Umschalten geklappt hat. Eine reine Notlösung bleibt das deshalb, weil einem niemand garantiert, daß sich diese XBIOS-Funktionen auf den angeschlossenen Großbildschirm oder die Farbkarte beziehen. Der Treiber zum Atari-Großbildschirm SM-194 geht beispielsweise davon aus, daß diese Funktionen sich immer auf den Shifter, den Grafikchip des Atari ST, beziehen.

Nun hat nicht jeder Programmierer Zugriff auf einen Großbildschirm und eine Farbgrafikkarte, um seine Schöpfungen auszuprobieren. Glücklicherweise gibt es einige sehr preiswerte Testmöglichkeiten. Da wäre zum einen die »Hyperscreen« (Overscan)-Lösung von Karsten Isakovic, die einem ganz normalen Atari eine höhere Monochrom-und Farbauflösung beschert, zum anderen das im ST-Magazin präsentierte »BigScreen« von Julian Reschke, das einen Großbildschirm durch Scrolling simuliert und so eine ausgezeichnete Testmöglichkeit bietet. Die Overscan-Lösung baut jeder qualifizierte Fachhändler ein, BigScreen kann man z.B. in den Maus-Mailboxen (Maus Münster, Tel. 0251/ 77261) bekommen.

Wie eingangs bereits erwähnt, gibt es viele Gründe für portables Programmieren. Neben den wirtschaftlichen Erwägungen, die für sich allein schon überzeugend genug sind, macht es einfach Spaß, ein Programm auf einer Hardware laufen zu sehen, auf der es vorher nie getestet worden ist. In diesem Sinne viel Erfolg.

(uw)

Literatur:

[1] Jankowski, Rabich, Reschke: Atari ST Profibuch. Sybex-Verlag Düsseldorf, 1987, ISBN 3-88745-563-0.

[2] GEM Programmer's Toolkit V. 3.11. Digital Research, München.

[3] Geiß, Geiß: Vorn Anfänger zum GEM-Profi, Hüthig-Verlag Heidelberg, 1990, ISBN 3-7785-1792-9

[4] Oren,T.:Professional GEM, ein in der amerikanischen Mailbox Compuserve erschienene Artikelserie einer der GEM-Schöpfer, ist auch in vielen deutschen Mailboxen erhältlich sowie für Entwickler bei Atari Deutschland auf Diskette zu beziehen.

[5] IBM Corp.: Common User Access, Advanced Interface Design Guide. Document No. SY0328-300-ROO-1089

[6] Apple Computer Inc.: InsideMacintosh. Vol I-Ill, IV, V. Addison-Wesley. ISBN 0-201-17737-4 (Vol I-III), ISBN 0-20105409-4 (Vol IV), ISBN 0-201-17719-6 (Vol V).

Download Listings

Arnd Beißner

---

---