BigSTE: Pump up the Resolution

Ein Großbildschirm ist sicherlich der Traum vieler ST-Besitzer - und wegen der hohen Kosten bleibt er für die meisten bestimmt auch weiterhin ein Traum. Trotzdem sind Großbildschirme und die damit verbundene Auflösungserhöhung nicht mehr aus dem Computeralltag wegzudenken, da sie in vielen Anwendungsgebieten enorme Vorteile bringen (z.B. DTP, CAD).

Ist man nun aber doch glücklicher Besitzer eines Großbildschirmes, hat man das Problem, daß sich ein nicht unbeträchtlicher Teil der gängigen Software außerstande sieht, diese Pixel-Darstellungswunder ordnungsgemäß zu betreiben. Also ist Software gefragt, die durch andere als die Standardauflösungen des ST nicht gleich außer Rand und Band gerät.

Angenommen, Sie wollten nun als (Hobby-) Programmierer mit naturgemäß immer zu kleinem Geldbeutel (und ohne Großbildschirm) solche Programme schreiben, würde bei Ihnen ein mittelgroßes Problem auftauchen, weil Sie die einwandfreie Funktion der Programme mangels Großbildschirm leider nicht austesten können.

„BigSTE“ kann Ihren SM 124 oder Fernseher zwar leider auch nicht in einen 10mal so teuren Großbildschirm verwandeln, aber das Programm kann Ihrem STE zumindest vorgaukeln, daß Sie neuerdings ein paar Pixel mehr darstellen können.

Insider werden jetzt zu Recht einwenden, daß ein Programm mit der eben beschriebenen Fähigkeit bereits existiert („Bigscreen“ von Julian Reschke [ 1 ]), das Ganze also kalter Kaffee ist. Ich habe mich daher ausschließlich der STEs mit ihren neuen Grafikfähigkeiten angenommen und ein Programm ähnlich „Bigscreen“ entwickelt, das die erweiterten Hardware-Fähigkeiten nutzt. Ging bei einem „normalen“ ST und „Bigscreen“ noch sehr viel wertvolle Prozessorzeit dabei verloren, die geänderte Auflösung auf dem Bildschirm darzustellen, macht das ein STE quasi mit Links, man muß nur wissen wie. Deswegen erst einmal ein kleiner Exkurs in die Videohardware der STEs.

Beim STE sind unter anderem die folgenden drei Videoregister ins Leben gerufen worden [2], die es dem Programmierer ermöglichen, dem Videochip flexiblere Darstellungen des Grafikspeichers mitzuteilen. Alle drei Register können sowohl gelesen, als auch beschrieben werden (s. Tab.l).

Diese drei Register machen es möglich, daß wir erhöhte Auflösungen ohne nennenswerten Arbeitsaufwand darstellen können. Natürlich stellt der Monitor jetzt nicht plötzlich 1280 * 800 Pixel dar, wir sehen immer nur einen bestimmten, verschiebbaren Ausschnitt daraus.

Aber, um es noch einmal zu betonen, der Rechenaufwand ist beim STE fast Null, während sich ein ST (ohne E) fast zu Tode arbeiten muß, um ein ähnliches Ergebnis zu liefern.

Das VBASELO-Register macht es möglich, pixelweise vertikal und in 16-Pixel-Schritten (Wortlänge!) horizontal zu scrollen. Pixel weise horizontal scrollen kann man erst mit Hilfe des HSCROLL-Registers, indem dort eine weitere Verschiebung um 0 bis 15 Pixel eingetragen wird.

Zum Verständnis der Wirkungsweise des LINEWID-Registers ein kleines Beispiel: Im Monochrommodus (1 Bitplane) hat eine Bildzeile bei 960 Pixeln horizontaler Auflösung eine Länge von 960 / 16 = 60 Wörtern.

40 Wörter (640 Pixel) werden in hoher Auflösung standardmäßig zur Anzeige gebracht, 20 Wörter müssen im virtuellen Bildschirm also übersprungen werden, um zu den Daten der nächsten Zeile zu gelangen (siehe Bild 1).

Diesen Offset kann man nun in das LINEWID-Register eintragen, und aus wirren Pixel-Mustern wird plötzlich ein ansehnliches Bild, wobei man beachten muß, daß man den Offset auch in Wörtern und nicht in Bytes angibt.

Sobald man jetzt aber in das HSCROLL-Register einen Wert ungleich 0 einträgt, hat man wieder Pixel-Müll auf dem Bildschirm, den man nur durch Verkleinern des Wertes im LINEWID-Register um 1 beseitigen kann. Angezeigt wird in diesem Moment ein Teil des 1. Wortes, dann 39 Wörter komplett und ein Teil des 4L Wortes, also 41 Wörter insgesamt. Daher beträgt die Distanz zur nächsten Zeile jetzt nur noch 19 anstatt 20 Wörter, was entsprechend im LINEWID-Register berücksichtigt werden muß.

Vorrangige Aufgabe des Programmes ist es natürlich, erst einmal dem GEM eine höhere Auflösung mitzuteilen. Dies geschieht durch eine Routine, die sich in den GEM-Vektor einschleift, auf den ersten OPEN WORKSTATION-Aufruf (v_opnwk) wartet und dessen Rückgabewerte sowie einige negative Line-A-Variablen [3] entsprechend abändert. Vorher muß natürlich noch der Bildschirmspeicher so vergrößert werden, daß er die Daten der erhöhten Auflösung aufnehmen kann.

Tabelle 1: Die drei Videoregister des STE

Ist das getan, muß das LINEWID-Register entsprechend gesetzt werden (s.o.), um die geänderte Auflösung sichtbar zu machen. Ab jetzt ist nur noch ein Ausschnitt des gesamten Bildes zu sehen.

Um mit dem Programm sinnvoll arbeiten zu können, ist es wünschenswert, den angezeigten Bildausschnitt verschieben zu können. Dabei bietet es sich an, die Bewegung bzw. die Position des Mauszeigers bei der Wahl des Ausschnittes einzubeziehen, so daß der angezeigte Bereich immer mit dem Mauszeiger mitwandert.

Zwei Routinen erledigen diese Aufgabe:

• eine VBL-Interrupt-Routine, die die Position des Mauszeigers abfragt (negative Line-A-Variablen), die anzuzeigende Bildadresse daraufhin berechnet und den TIMER-B startet.
• eine TIMER-B-Interrupt-Routine, die die zuvor berechnete Bildadresse in die jeweiligen Videoregister einträgt. Der Timer-B wird so programmiert, daß der Interrupt in der letzten Zeile des Bildaufbaus auftritt, so daß keine sichtbaren Störungen mehr auftreten können, wenn die Registerwerte geändert werden. (Das sonst übliche Setzen der Videoregister innerhalb einer VBL-Routine führt hier eigenartigerweise zu stark ruckelnden und äußerst unbefriedigenden Ergebnissen ?!)

Das waren soweit die wichtigsten Aktionen, die das Programm erledigen muß, um grundsätzlich zu funktionieren. Nun aber noch ein paar Worte zu den Nebensachen, die auch getan werden müssen, und die dem Programmierer das Leben meist am schwersten machen:

„BigSTE“ muß aus dem Auto-Ordner heraus gestartet werden!

(falls Sie einen GDOS-Treiber besitzen, unbedingt nach dessen Installation!!!)

Da „BigSTE“ vor der Initialisierung des AES installiert werden muß, ist es nötig zu testen, ob das Programm in der Boot-Phase aus dem AUTO-Ordner heraus gestartet wurde. Das können wir überprüfen, indem wir einen appl_init -Aufruf durchführen und den ersten Eintrag im global-Feld auf 0 testen [4]. Bekommt man dort bereits die Versionsnummer des AES und nicht den Wert 0 zurückgeliefert, wurde das Programm erst nach der Initialisierung des AES gestartet, also zu spät.

„BigSTE“ läuft nur auf den STEs!

Deswegen muß überprüft werden, ob der Rechner, auf dem das Programm gestartet wurde, auch ein STE ist. Um das zu testen, fallen mir mehrere Möglichkeiten ein:

• Test auf Vorhandensein einer STE-TOS-Version
• Test auf Vorhandensein der STE-Hardware-Register
• Test auf einen entsprechenden Eintrag im Cookie-Jar

Letzteres Verfahren ist wohl das „sauberste“ und funktioniert folgendermaßen: Die Systemvariable_p cookie {Adresse $5AO) enthält ein Langwort, das ab TOS 1.6 einen Zeiger auf einen Cookie-Jar darstellt [5]. Hat dieser Zeiger den Wert NULL (bei älteren TOS-Versionen), gibt es keinen Cookie-Jar, und der Test wird mit dem Ergebnis, daß es sich bei dem verwendeten Rechner wohl um keinen STE handelt, abgebrochen. Existiert aber ein Cookie-Jar, findet man an der Adresse, auf die _p_cookie zeigt, eine Tabelle mit Wertepaaren vor. In dieser Tabelle sollte sich ein Eintrag mit der Kennung _VDO befinden, wobei der zugehörige Wert die Version der Video-Hardware beschreibt. Hierbei steht ein Wert von $00000000 für die Video-Hardware eines normalen STs, $00010000 steht für die eines STEs und $00020000 für die eines TTs.

Das Programm soll nicht mehrfach installiert werden können!

Da die vom Programm benutzten Vektoren mit Hilfe des XBRA-Verfahrens umgelegt werden, kann man das relativ einfach abtesten, indem man die jeweiligen Vektorketten nach der eigenen XBRA-Kennung absucht. Dieses Verfahren funktioniert aber leider nur, wenn sich Programme, die sich vorher schon in dieselben Vektoren eingeklinkt haben, auch der XBRA-Kennung bedienen.

Wenn in niedriger und mittlerer Auflösungsstufe die Info-Box des Desktops angezeigt wird, wird vom Betriebssystem der TIMER-B benutzt, um die durchlaufenden Farben im Atari-Logo zeichnen zu können. Erstens benötigt „BigSTE“ diesen Timer zum Scrollen, und zweitens wird nach Verlassen der Info-Box der alte Vektor vom Betriebssystem nicht restauriert, daher wird der eigene Vektor vom Programm in jeder VBL-Routine aufs neue eingetragen, um eine einwandfreie Funktion des Programms zu gewährleisten. Auf eine bunte Info-Box muß man jetzt leider verzichten, aber das dürfte wohl eines der kleineren Übel sein.

Mit „BigSTE“ hat man die Möglichkeit, Auflösungen in gewissen Grenzen einzustellen. Die Programmierung der Auflösungseingabe wäre aber relativ aufwendig geworden und hätte das Programm unnötig aufgebläht, da das Programm in Assembler geschrieben ist. Daher habe ich noch ein kurzes Programm in GFA-BASIC geschrieben, das die Konfiguration von „BigSTE“ übernimmt. Es sollte, wie „BigSTE“, im AUTO-Ordner liegen, sinnvollerweise davor, damit sich die Konfiguration direkt auswirken kann. Das Programm wird bei einem Start aus dem AUTO-Ordner nur bei vorher aktiviertem CapsLock durchlaufen, ansonsten gleich wieder beendet! Man hat hier die Möglichkeit, folgende Einstellungen vorzunehmen:

• „BigSTE“ installieren (ja/nein)
• Auflösungsstufe in Farbe (niedrig/mittel)
  (Stimmt die Auflösungsstufe nicht mit der in der „DESKTOP.INF“-Datei angegebenen überein, wird sie dort auch noch entsprechend abgeändert.)
• Auflösungen in Pixeln für alle drei Auflösungsstufen
• Schieberänder für alle drei Auflösungsstufen
  (Mit Schieberand ist der Randbereich gemeint, bei dem „BigSTE“ anfängt zu scrollen, wenn sich der Mauszeiger hineinbewegt.)

Die Hardcopy-Routine des Betriebssystems kommt mit einer geänderten Bildschirmauflösung leider nicht zurecht, deswegen ist der Vektor dump vec (Adresse $502) auf eine eigene kleine (um nicht zu sagen winzige) Routine verbogen worden. Diese Routine macht schlicht und einfach nichts, außer sofort wieder zurückzuspringen. Auf eine Hardcopy-Funktion muß also leider verzichtet werden.

Zum Schluß noch ein paar Einschränkungen beim Umgang mit „BigSTE“:

Ein Auflösungswechsel über das Desk-top sollte vermieden werden, da „BigSTE“ auf diesen Wechsel nicht reagieren kann. (Es ist aber problemlos möglich, über einen Reset und eine entsprechende Konfiguration von „BigSTE“ die Auflösungsstufen zu wechseln.)

Werden Programme gestartet, die bezüglich der Bildschirmdarstellung „unsauber“ programmiert sind, kann es bei manchen dieser Programme passieren, daß auch nach deren Beendigung die Bildschirmdarstellung nicht mehr korrekt ist. Hier hilft dann meistens nur ein Reset.

Ich habe es trotz unzähliger Versuche leider nicht geschafft, in mittlerer und hoher Auflösung mit Hilfe der STE-Register pixelweise horizontal zu scrollen, ohne daß ein unschöner Seiteneffekt auftritt.

Und zwar klappt ständig ein Teil des rechten Bildes auf die linke Seite um, wenn der Inhalt des HSCROLL-Registers auf 0 wechselt. Hier scheint die Bildsynchronisation gehörig aus dem Tritt zu geraten. Alle Versuche, dieses Register zu verschiedenen Zeitpunkten während des Bildaufbaues zu ändern, haben keine befriedigenden Ergebnisse gebracht. Was bleibt, ist die Vermutung, daß pixelweises, horizontales Scrolling hardwaremäßig nur für die niedrige Auflösungsstufe gedacht ist. Auf eine diesbezügliche Anfrage bei Atari habe ich leider keine Antwort erhalten. Wer hier eine Lösung kennen sollte, möge sie mir bitte mitteilen. In mittlerer und hoher Auflösungsstufe kann deswegen leider auch nur in 16-Pixel-Schritten horizontal gescrollt werden.

Quellennachweis:

[1] Julian F. Reschke: Der weiche Großbildschirm, ST-Magazin 11/1988

[2] Martin Backschat: STarkes noch STErker, ST-Magazin 12/1989

[3] Julian F. Reschke: Saubere Fenster, ST-Magazin 10/1988

[4] Laurenz Prüßner: Reine Existenzfrage, ST-Magazin 2/1990

[5] Julian F. Reschke: Vorhang auf für die Keksdose, ST-Magazin 3/1990