Atarium: Ans EinGEMachte
Ans EinGEMachte - Die Ablage, HDX 3.0 und unterschiedliche GEM-Bildschirmformate
Bevor ich mich, wie so oft, in die Interna des Betriebssystems stürze, noch kurz einige Nachträge und Korrekturen:
Seit Wochen läuft in der Atari-Gruppe des MausNet eine angeregte Diskussion über das Clipboard. Und wie so oft hat die angeregte und kontroverse Unterhaltung zu neuen Einsichten geführt. Für kurzfristige Verwirrung sorgte das Problem: »Wie stellt ein Programm fest, das vom Clipboard liest, in welcher SCRAP-Datei die 'gültigen' Daten liegen?«. Dazu folgendes Beispiel: Die SCRAP.GEM-Datei - angelegt vom genialen Biorhythmus-Programm - erhält Gesellschaft durch die SCRAP.IMG-Datei des nicht weniger interessanten Snapshot-Programms: Welche der beiden Dateien soll das eigene Programm als »gültige« lesen?
Informationen in verschiedenen Formaten
Wieder einmal ist die Antwort viel einfacher als erwartet: Das Scrap-Directory enthält immer nur eine Information. Wer neue Daten im Scrap-Directory ablegt, muß vorher alle Dateien namens »SCRAP. « im Scrap-Directory löschen. Ab GEM 2.0 steht dafür die AES-Funktion »scrp_clear()« zur Verfügung, die allerdings zumindest im ABC-GEM nicht richtig funktioniert. Selbstverständlich ist es einem Programm unbenommen, die Information in mehreren verschiedenen Formaten zu speichern. »1st Word Plus 3.11« beispielsweise speichert Textblöcke im TXT- und im 1WP-Format. Wichtig ist nur: Machen Sie sich klar, daß alle Dateien der Form »SCRAP.« die gleiche Information darstellen - nur eben in verschiedenen Formaten. Das lesende Programm ist dann in der Lage, das jeweils geeignetste Format herauszusuchen. Digital Research machte sich leider nie die Mühe, die Benutzung des Clipboards konkret zu beschreiben. Beim Macintosh [1] und unter Microsoft-Windows gehen die Clipboard-Anwender aber genauso vor.
Doch nun zu etwas ganz anderem: Seit kurzer Zeit liefert Atari mit seinen Festplatten den Treiber »HDX Version 3.0« mit »AHDI Version 3.01« aus. Durch den neuen HDX macht Atari endlich Schluß mit der 4-Partitionen-Begrenzung. Darüber darf jetzt jede einzelne Partition beliebig groß formatiert sein. Dazu benutzt der Treiber einfach größere als die bisher üblichen 512-Byte-Sektoren. Der Haken: Die überwiegende Zahl aller Festplatten-Utilities geht davon aus, daß ein Sektor nur 512 Byte enthält. Zu den Übeltätern zählt leider auch mein Festplatten-Cache-Programm »HaBoo«. Deshalb meine Warnung: HaBoo zerstört unter Umständen Daten auf derart formatierten Festplatten. Erst Version 1.8 - in der Maus Münster erhältlich - arbeitet mit dem »neuen« Plattenformat korrekt zusammen.
Kommen wir nun zum Hauptthema dieses Monats. Mit unserer Overscan-Umrüstung haben wir unter den Programmierern - nicht völlig unerwartet - erhebliche Verwirrung angerichtet: Da gibt es das ungewohnte Bildschirmformat, Logbase() und Physbase() benehmen sich irgendwie komisch, und zu allem Überfluß ist der benutzte Bildspeicher noch nicht einmal in einem zusammenhängenden Stück abgelegt. Auch wenn es so mancher nicht glauben will: Alle diese Probleme sind eigentlich keine Probleme, wenn man nur das VDI so verwendet wie von Digital Research geplant.
Beginnen wir mit den Problemen beim »Umschalten« des Bildschirms, wie es beispielsweise Turbo-C beim Starten von externen Programmen macht. Zunächst sei vorausgeschickt, daß im GEM-Konzept natürlich kein Platz für Manipulationen an Bildspeicheradressen ist. Besser ist, immer mit den Auskunftsfunktionen des VDI die X- und Y-Auflösung sowie Anzahl der Planes zu bestimmen, daraus die Größe des benötigten Puffers zu errechnen und diesen dann in Verbindung mit den VDI-Rasterfunktionen (siehe unten) zu benutzen.
Wer dennoch nicht darauf verzichten will, den logischen bzw. physikalischen Bildspeicheranfang zu verändern, muß anschließend mit »Logbase()« bzw. »Physbase()« prüfen, ob das Umsetzen der Bildspeicheradresse geglückt ist. Niemand garantiert, daß man bei jeder Grafikkarte Bildspeicheradressen verändern kann. Dies funktioniert zumindest mit der neuesten Version von »BigScreen« nicht.
Entwickler mit Weitblick
Die Raster-Funktionen des VDI sind die vielleicht am schlechtesten verstandenen Funktionen des ganzen Betriebssystems. Nun ist aber die Kenntnis dieser Funktionen unverzichtbar, will man mit den verschiedenen denkbaren Bildschirmum- und -aufrüstungen zurechtkommen. Die bisher beste Einführung zu diesem Thema gab vor langer Zeit Tim Oren für den Online-Service der amerikanischen Zeitschrift »Antic« [3]. Ich fasse an dieser Stelle das Wichtigste aus dieser Quelle zusammen.
Zunächst unterscheidet er zwischen dem »Standard-Format« und dem »geräteabhängigen Format« eines Rasters. Gerade hier bewiesen die Entwickler mit Blick auf die Zukunft und verschiedene Computer viel Weitblick. Das GEM-Standardformat ist auf jedem Grafiksystem gleich, auf dem GEM läuft. Damit ist es das einzige Format, auf dessen Aufbau man sich als Programmierer verlassen darf. Wie sieht das Standardformat nun aus?
Beginnen wir der Einfachheit halber mit einem monochromen Raster. Einfach deshalb, weil es identisch mit dem normalen monochromen Bildschirmformat des ST ist. Jedem Pixel entspricht ein Bit, das höchste Bit gibt den am weitesten linken Punkt an etc. Ein Farbraster wird - wie auch bei der ST-Hardware - in mehrere Planes aufgeteilt. Bei einem sechzehnfarbigen Raster hat man dann vier Planes (2-4 = 16), die im Standardformat hintereinander abgelegt sind. Ein normaler 320 x 200-Bildschirm wird also in vier hintereinanderliegenden Blöcken zu je 8 KByte Länge dargestellt.
Das geräteabhängige Format ist hingegen genau das Format ' in dem der VDI-Treiber seine Raster codiert. Es ist im allgemeinen mit dem bevorzugten Format des benutzten Grafikchips identisch. Die Raster-Copy-Funktionen des VDI arbeiten ausschließlich mit dem geräteabhängigen Format. Zur Umwandlung zwischen beiden Formaten steht Ihnen die Funktion »vr_trnfrm()« (Transform Form) zur Verfügung, mit der Sie zwischen beiden Formaten hin- und herkonvertieren.
Es kommt nicht überraschend, daß Icons und Bit-Images in RSC-Dateien im Standardformat abgelegt sind - wie sollte man sie sonst mit anderen Computern austauschen? Die monochromen Raster kopiert das AES bei »objc_draw()« unter Verwendung von »vrt_cpyfm()« auf den Bildschirm. Langer Rede, kurzer Sinn: Auch diese Images müssen Sie zuerst mit »vr_trnfm()« ins geräteabhängige Format wandeln, auch wenn beim ST beide Formate für einfarbige Raster gleich sind. Nach »rsrc_load()« also einmal die Funktion »trans_gimage()« aus dem Listing für jede BITBLK-Struktur aufrufen. Bei Icons ist - analog zu »trans_gimage()« - zusätzlich die Icon-Maske zu konvertieren.
Listing: Routinen, um das GEM-Standard-Format ins geräteabhängige Bildschirmformat zu konvertieren (uh)
Quellennachweis:
[1] »Inside Macintosh«, Chapter 15: »The Scrap Manager«, Addison Wesley Publishing Company
[2] »Programmer's Guide to Windows - Second Edition«, Durant/Carlson/Yao, Sybex Inc. Alameda, ISBN 0-89588-496-8
[3] »Professional GEM«, Part IV: »Raster Operations«, Tim Oren
[4] »Introduction to GEM-Programming«, enthalten im GEM-Toolkit von Digital Research
Julian F. Reschke uw