Bildschirm-Schummelei (Assembler)

Einige Programme für den Atari ST laufen nur deshalb nicht in den neuen Auflösungen des Atari TT, weil sie die neuen Bildschirmformate nicht kennen. Hier kann man jedoch bis zu einem gewissen Grad Abhilfe schaffen.

Bereits in [1] habe ich kurz auf die Probleme hingewiesen. die entstehen können, wenn ein Programm die Bildschirmauflösung über den GETREZ-Aufruf des XBIOS erfragt. Noch einmal zur Erinnerung: Auf dem ST liefert GETREZ nur drei mögliche Werte zurück:

0: 320x200 Punkte, 16 Farben, niedrige ST-Auflösung
1: 640x200 Punkte, 4 Farben, mittlere ST-Auflösung
2: 640x400 Punkte, monochrom, hohe ST-Auflösung

Die niedrige ST-Auflösung wird in erster Linie von Spielen verwendet, da hier eine möglichst große Zahl an Farben besonders interessant ist. Für professionelle Anwendungen sind beim ST eher die mittlere und vor allen Dingen die hohe Auflösung von Bedeutung, da es hier in der Regel darauf ankommt, möglichst viele Pixel (also möglichst viel Platz) für die Darstellung von Daten zur Verfügung zu haben. Davon abgesehen erhält man in der hohen ST-Auflösung durch die hohe Bildfrequenz von 71 Hertz eine sehr flimmerfreie Darstellung.

Drei neue Auflösungen

Beim Arbeiten mit dem TT stehen neben den ST-Auflösungen noch drei weitere Bildschirmformate zur Verfügung:

3: 320x480 Punkte, 256 Farben, niedrige TT-Auflösung
4: 640x480 Punkte, 16 Farben, mittlere TT-Auflösung
5: 1280x960 Punkte, monochrom, hohe TT-Auflösung

Für professionelle Anwendungen sind vor allen Dingen die mittlere und hohe TT-Auflösung geeignet. In beiden Fällen werden mehr Pixel auf dem Bildschirm dargestellt, als in der höchsten ST-Auflösung (640x400 Punkte) möglich sind. So gesehen könnte man meinen, daß alle ST-Programme in diesen Auflösungen laufen sollten, aber ganz so einfach ist es nun doch nicht. Ein nicht untypischer Fall sind Programme, die auf ein Bildschirmformat von mindestens 640x400 Punkten angewiesen und denen ausschließlich die drei ST-Auflösungen bekannt sind. Wird nun von GETREZ ein Wert ungleich 2 zurückgeliefert. verweigern solche Programme ihren Dienst. Zwar kann man in den sauren Apfel beißen und in die hohe ST-Auflösung wechseln, aber das ist auf die Dauer umständlich.

Eine alternative Lösung

Wenn es schon Programme gibt, die sich voll auf die von GETREZ gelieferten Werte verlassen, kann man die Übeltäter in einigen Fällen durch eine modifizierte GETREZ-Funktion hinters Licht führen. Wie dies praktiziert werden kann, wird im Listing des Programms REZFIX aufgezeigt. Ist REZFIX installiert, liefert GETREZ für die mittlere und hohe TT-Auflösung den Wert 2. der eigentlich für die hohe ST-Auflösung vorgesehen ist. So ist es in vielen Fällen möglich. Programme, die der Meinung sind, daß nur die hohe ST-Auflösung gut genug für sie sei. auch in der mittleren und hohen TT-Auflösung einzusetzen.

Grenzen des vorgestellten Tricks

REZFIX erfüllt vor allen Dingen dann seinen Zweck, wenn ein Programm gestartet wird, das Bildschirmausgaben in erster Linie über das GEM abwickelt. Programme, die ihre Ausgaben direkt in den Bildschirmspeicher schreiben, machen eventuell dennoch Probleme. Dies liegt daran, daß neben der Anzahl der Pixel auch die Zahl der Farbebenen für die Bildschirmdarstellung von Bedeutung ist. Programme, die nur Ausgaberoutinen für eine Bitplane besitzen, werden in einer Auflösung mit mehreren Bitplanes ein recht chaotisches Bild bieten. Dagegen sollten die meisten Programme mit eigenen Bildschirmroutinen, die für die hohe ST-Auflösung gedacht sind, durch den Einsatz von REZFIX problemlos mit der hohen TT-Auflösung arbeiten können.

Die saubere Lösung

Ein ernsthafter Programmierer wird sich (hoffentlich) mit der hier vorgestellten Notlösung nicht zufriedengeben, sondern seine Programme so flexibel gestalten, daß sie, soweit möglich. auflösungsunabhängig eingesetzt werden können. Es bringt nichts, sich nur auf die drei zusätzlichen TT-Auflösungen einzustellen und sich weiter keine Gedanken zu machen. Sollte es nach dem TT noch einmal einen ST-kompatiblen Rechner geben (hoffen wir das Beste!), so wäre es ärgerlich, wenn dann die gleichen Probleme auftauchten, vor denen man nun beim TT steht. Schließlich ist es für Programme, die das GEM nutzen, denkbar einfach, sich über das Bildschirmformat zu informieren. Die Aufrufe APPL_INIT sowie OPEN VIRTUAL SCREEN WORKSTATION, die wohl jede GEM-Applikation im Rahmen ihrer Initialisierung tätigen dürfte, liefern alles, was man braucht [2], APPL_INIT legt im global-Array die Anzahl der Farbebenen ab. OPEN VIRTUAL SCREEN WORKSTATION versorgt das work_out-Array mit der horizontalen und vertikalen Bildschirmauflösung.

Stichwort LINEA

Programme, die das GEM nicht benötigen, haben noch eine andere Möglichkeit, flexibel auf die Bildschirmauflösung zu reagieren. Die Nutzung der LINEA-Routinen sollte zwar unterbleiben, da nicht garantiert ist. daß diese in Zukunft weiterhin unterstützt werden, aber zumindest das Erfragen von Bildschirmparametern über $A000 dürfte unkritisch sein [2]. (Dies auch auf die Gefahr hin, daß ich mit dieser Äußerung den Unmut einiger Programmierer auf mich ziehe). So besteht die Möglichkeit, auch ohne OPEN VIRTUAL SCREEN WORKSTATION Angaben über die Bildschirmauflösung und die Zahl der Farbebenen zu erhalten. Das Adreßregister A0 zeigt nämlich nach der LINEA-Initialisierung auf zwei Parametertabellen. die die entsprechenden Angaben enthalten.

Aber: Die Nutzung des LINEA-Opcodes $A000 ist keine wirkliche Garantie dafür, daß Programme auch mit zukünftigen Bildschirmauflösungen zurechtkommen. Denn: Nur durch konsequente Nutzung des GEM ist es möglich. Programme zu schreiben, die unabhängig von der Auflösung und der Zahl der Bitplanes arbeiten und für zukünftige Grafikformate gerüstet sind.

[1] „Wie ST-kompatibel ist der TT?“, ST-Computer 10/90

[2] Jankowski. Reschke, Rabich. „Atari ST-Profibuch“, SYBEX-Verlag

******************************
* REZFIX                     *
*                            *
* geänderte GETREZ-Routine   *
*                            *
* Oktober 1990 by Uwe Seimet *
*(c) MAXON Computer GmbH 1990* 
******************************

GEMDOS   =  1
PTERMRES = 49

BIOS     = 13
SETEXC   =  5

XBIOS    = 14
GETREZ   =  4

        text

        move.l 4(sp),a6         ;Basepage-Adresse
        pea newxbios(pc)        ;neuer
        move #46,-(sp)          ;XBIOS-Vektor
        move #SETEXC,-(sp)
        trap #BIOS
        addq.l #8,sp
        move.l d0,oldxbios+2    ;alter Vektor 
        move.l 12(a6),a0        ;TEXT-Segment
        lea $100(a0),a0         ;Länge der Basepage
        clr -(sp) 
        pea (a0)
        move #PTERMRES,-(sp)
        trap #GEMDOS            ;zurück zum TOS

newxbios:
        lea 8(sp),a0
        btst #5,(sp)            ;Supervisor-Modus?
        bne *4-4                ;ja-
        move.l usp,a0           ;sonst User-Stack
        cmp #GETREZ,(a0)
        bne.s oldxbios
        tas xbiosflg            ;bereits im XBIOS?
        bne.s oldxbios          ;ja-
        move #GETREZ,-(sp)      ;wahre Auflösung 
        trap #XBIOS             ;erfragen
        addq.l #2,sp
        cmp #4,d0               ;Auflösung ändern?
        bcs.s ret               ;nein-
        moveq #2,d0             ;hohe ST-Auflösung
ret:    clr.b xbiosflg
        rte
oldxbios:jmp $ffff              ;weiter im Text-

*xbiosflg verhindert eine Endlosschleife 
xbiosflg:dc.b 0