Einige der neu hinzugekommenen Steuerzeichen wurden bereits im zweiten Teil dieser Serie behandelt. In dieser Folge werden auch noch die restlichen ESCapes unter die Lupe genommen, bevor es dann um den Geschwindigkeitszuwachs gehen wird...

... und der ganze Rest

Beginnen wir also mit dem Komplettieren der xVT52-Sequenzen. In Programmen ist es durchaus nicht unüblich, daß es mehrere Prozeduren oder Funktionen gibt, die in irgendeiner Weise auf den (“TOS”-) Bildschirm zugreifen, um z.B. Texte auszugeben oder auch Eingaben anzufordern. Nun ist das mit dem Ein- und Ausschalten des Cursors so eine Sache. Angenommen, das Hauptprogramm möchte verhindern, daß der Cursor innerhalb einer Prozedur oder Funktion sichtbar werden wird. Dann läßt sich dies mit den konventionellen Möglichkeiten des VT52-Emulators nicht mehr erreichen. Ein Blick ins VDI-Handbuch zeigt aber anhand der Maus-Routinen, daß es auch anders geht. Unter der Nummer 122 läßt sich die Funktion SHOW CURSOR ansprechen, der man eine Variable mitgeben kann. Je nach Wert dieser Variablen wird die Maus entweder sofort sichtbar (0), oder es wird zuerst ein Zähler dekrementiert, der von der Funktion HIDE CURSOR (VDI 123) inkrementiert wird (1). Erst wenn dieser Zähler auf Null liegt, wird die Maus wieder angezeigt. Was liegt also näher als diesen Mechanismus auch für den Cursor einzuführen? Hierzu dient die Sequenz:

• ESC a: Cursor einschalten mit Hide-Cursor-Check.

Der Cursor wird also erst wieder sichtbar, wenn genausoviele ESC a-wie ESC f-Aufrufe erfolgt sind. Der Zähler wird durch ESC e auf Null gesetzt, so daß nach diesem Aufruf der Cursor garantiert sichtbar ist, und bei jedem ESC f inkrementiert (wobei dann der Cursor garantiert unsichtbar wird).

Schwarz auf Weiß und umgekehrt

Um die Augen und/oder den Bildschirm zu schonen, kann es nützlich sein, die Darstellung zu invertieren, d.h. alles, was vorher weiß war, wird jetzt schwarz und umgekehrt. Für diesen Fall kennt der erweiterte Emulator folgende Steuerzeichen:

• ESC m: Umschalten auf weiße Schrift auf schwarzem Grund
• ESC n: Umschalten auf Normalmodus (schwarz auf weiß)

Intern bewirken diese beiden Funknonen lediglich eine Umprogrammierung des Video-Shifters; mit jeweils zwei Assembler-Befehlen kann man sie getrost als die “weniger Code-intensiven” Teile des Emulators bezeichnen. Bemerkenswert ist noch, daß wegen der Shifter-Programmierung natürlich ALLES invertiert wird, also auch das Desktop und alles, was mit GEM zu tun hat. Um also nicht gewollte Effekte zu verhindern, sollten Sie Ihre TOS-Programme noch ein ESC n ausgeben lassen, bevor sie terminieren (sofern die Darstellungsart zwischenzeitlich gewechselt wurde, versteht sich).

X=Print C$ oder: Als die Ausgabe zur Funktion wurde...

Zugegebenermaßen ist es reichlich ungewöhnlich, daß man bei der Zeichenausgabe über Funktionen des Betriebssystems einen Rückgabewert erhält. Aber einerseits liefern eigentlich alle GEMDOS-/BIOS- und XBIOS-Funktionen irgendwelche Werte (das haben Funktionen halt so an sich), andererseits wissen die Kenner der Sprache C, daß printf() auch etwas zurückgibt, nämlich die Anzahl der ausgegebenen Argumente. Für den erweiterten Emulator gab es zwei Probleme, die eine Werte-Rückgabe notwendig machten. Zum einen mußte es eine “legale” Möglichkeit für Programme geben, um feststellen zu können, ob der xVT52-Treiber installiert ist (um gegebenenfalls mit einer Meldung abbrechen zu können; oder andere Routinen für den Standard-VT52-Emulator anzustoßen). Zum anderen sollte der Benutzer ebenfalls eine “legale” Möglichkeit erhalten, um auf alle relevanten Variablen des Emulators zugreifen zu können. Beides läßt sich durch die Einführung zweier Sequenzen erreichen:

• ESC g: Bestimmen des Zeigers auf den TCB.
• ESC h: Bestimmen des Zeigers auf den CCB.

Sollten Sie nicht mehr wissen, wozu die beiden Strukturen dienen, hier nochmal die Kurzfassung. Der Terminal Control Block (TCB) enthält alle zum Organisieren der Ausgabe wichtigen Parameter, wie z.B. die aktuelle Cursorposition, den aktiven Font, Attribute (wrapping, invers...) u.ä., während der Cursor Control Block die für die Darstellung des Cursors benötigten Variablen enthält (wie Blinkrate, aktuelle Position und Cursorattribute). Wenn ein Programm nun feststellen möchte, ob der xVT52-Emulator bereits geladen wurde, kann es sich einer Sequenz bedienen, wie dies in Listing 2 exemplarisch anhand eines GFA-Progrämmchens dargestellt ist. Nur bei installiertem Treiber liefern die Ausgabefunktionen die gewünschten Zeiger. Die Differenz zwischen den Zeigern muß genau 66 betragen, ansonsten kann man sicher davon ausgehen, daß nur der Original-Emulator seinen Dienst verrichtet. Damit wären die erwähnten Probleme auch schon aus der Welt geschafft, denn gleichzeitig mit den Zeigern hat man ja auch den Offset auf die xVT52-Variablen und somit die Möglichkeit, auf diese zuzugreifen. Aber Vorsicht!

Fummel, fummel...

Sicher ist es richtig, daß man oft erst durch gezielte Eingriffe in programminterne Bereiche Effekte erreichen kann, die legal unmöglich zu realisieren gewesen wären. Genauso sicher ist es aber auch, daß der am häufigsten dabei erzielte Effekt ein Systemabsturz ist. Der erweiterte Emulator gestattet dem Programmierer einen sehr tiefen Einblick in seine Arbeit. Das Lesen der Variablen ist natürlich absolut ungefährlich; so ist sicherlich nichts dagegen einzuwenden, wenn man z.B. die aktuelle Schreibposition ermitteln möchte. Wohl aber, wenn Variablen geändert werden, ohne sich der Folgen bewußt zu sein! Das Ändern des einen oder anderen Bytes im TCB und CCB kann wunderschöne Effekte mit sich bringen, einschließlich des oben beschriebenen, versteht sich. Für die meisten denkbaren Änderungen stehen ohnehin ESCape-Sequenzen zur Verfügung; allerdings läßt sich ein selbstgeschriebener Zeichensatz (muß denselben Aufbau wie der des GEM und eine konstante Breite von 8 Pixeln haben) mittels direktem Einträgen in den TCB schneller und wohl auch einfacher installieren als über das VDI.Man sollte vor derartigen “Fummeleien” aber dafür sorgen, daß alle Daten, die man evtl, später nochmal benötigen könnte, einer sorgfältigen Rettungsaktion unterzogen werden; sonst - HUAAaaahh!

Um hier allerdings keine falschen Eindrücke aufkommen zu lassen: xVT52 läuft bereits seit Monaten unter den verschiedensten Programmen ohne Fehl und Tadel. Es ist also bei Aktivieren des erweiterten Emulators keineswegs “bloß noch eine Zeitfrage”, wann sich der Rechner wohl verabschieden würde. Insofern bezieht sich meine Mahnung nur auf die vom Anwender eigenmächtig vorgenommenen Manipulationen und deren eventuelle Folgen.

Text-” Windows”

Wohl jedes benutzerfreundliche Programm beinhaltet auf die eine oder andere Art die Möglichkeit, dem Benutzer Hilfestellungen zu geben, wenn er an einer Stelle nicht mehr weiter weis. Innerhalb von GEM-Programmen läßt sich dies mittels eines zusätzlichen Fensters erreichen (sofern nicht schon vier geöffnet sind; aber dann gibt es ja auch noch Alert-und Dialogboxen...). Unter TOS muß man da schon größere “Verrenkungen” anstellen, weil es halt mal nur einen Bildschirm gibt. Und alle VT52-Funktionen - speziell diejenigen zum Einfügen und Löschen einer Zeile - beziehen sich prinzipiell auf den kompletten Bildschirm, wodurch der Einsatz eines “geschützten” Bildschirmbereiches unmöglich gemacht wird. Zwei Sequenzen des xVT52-Emulators erlauben es nun, zwei voneinander unabhängige Textfenster zu unterhalten, indem sie die bereits bestehenden ESCapes L (zum Einfügen) und M (zum Löschen) quasi “im gemischten Doppel” nachvollziehen:

• ESC s: Einfügen einer Zeile, wobei der Bildschirminhalt inklusive der aktuellen Cursorzeile NACH OBEN geschoben wird. Die oberste Zeile geht dabei verloren.
• ESC t: Löschen der aktuellen Cursorzeile, wobei der Rest des Bildschirminhaltes VON OBEN nachrückt. Hierdurch wird die oberste Zeile frei.

Nach diesen Sequenzen befindet sich der Cursor am Anfang (Spalte 0) der eingefügten bzw. gelöschten Zeile. Sie arbeiten somit genauso wie die bisherigen Steuer-Sequenzen, nur in der Behandlung des restlichen Bildschirminhaltes genau umgekehrt. Damit kann man nun problemlos zwei Bildschirmbereiche steuern. Weil es aber einigermaßen umständlich ist zu erklären, in welchem Bereich wie gearbeitet werden muß, möchte ich Sie auf Bild 1 hinweisen, in dem die benötigten ESCapes den beiden Fenstern zugeordnet sind. Es bleibt lediglich Ihrer Phantasie überlassen, was Sie mit dem zweiten Fenster alles anstellen: Sie können damit ebenso Hilfstexte einblenden wie auch in Editormanier zwei Texte bearbeiten. Sie müssen nur darauf achten, daß der Bildschirminhalt gepuffert wird, damit ein durch das zweite Fenster eventuell zerstörter Text wiederhergestellt werden kann. Ansonsten können mit den neuen Sequenzen auch hübsche Effekte erzielt werden: Wenn Sie - ausgehend von Zeile 12 -abwechselnd mit ESC s und ESC L Zeilen einfügen oder mit ESC t und ESC M Zeilen löschen, entsteht der Eindruck, der Bildschirm würde “explodieren” bzw. “implodieren”. Besonders lustig sieht das “Implodieren” bei Verwendung der pixelorientierten Sequenzen aus, die Sie gleich kennenlernen werden.

Seitensprünge (ESCapaden)

Daß man Texte nach oben und unten scrollen kann, ist sicherlich ein Standard-Feature eines jeden Emulators. In einer pluralistischen Gesellschaft wie der unseren sollte es aber fast schon eine Selbstverständlichkeit sein, in allen vier Himmelsrichtungen Freizügigkeit zu genießen... Also wurden beim xVT52 zwei weitere Sequenzen implementiert, die ein spaltenweises Scrollen ermöglichen:

• ESC u: Inhalt der aktuellen Zeile um 1 Spalte nach links durchlaufen lassen
• ESC x: Inhalt der aktuellen Zeile um 1 Spalte nach rechts durchlaufen lassen.

In beiden Fällen bleibt der Cursor an derselben Position stehen, an der er auch stand, bevor gescrollt wurde; er ändert also weder Zeilen- noch Spaltenposition. Das “Durchlaufenlassen” bedeutet hier, daß das Zeichen, welches durch das Scrollen links oder rechts “herausgefallen” ist, auf der jeweils anderen Seite wieder “hereingeschoben” wird. Wozu läßt sich das gebrauchen? Sie können beispielsweise damit eine Eingaberoutine schreiben, die - sobald die letzte Spalte der aktuellen Zeile erreicht ist - den bisherigen Inhalt um eine Spalte nach links schiebt und die letzte Spalte zum Eingeben eines neuen Zeichens löscht. Wenn Sie sich den Editor von GFA-BASIC einmal näher betrachten, werden Sie feststellen, daß dort genau dies passiert. Nur: Das Feuerwerk an ESCape-Sequenzen in Kombination mit wiederholter Textausgabe läßt erahnen, welche Verrenkungen Sie sich mit ESC u/x sparen können!

Wem diese beiden Sequenzen nicht genügen, der dürfte - Assembler-Kenntnisse vorausgesetzt - keine Probleme haben, die entsprechenden Prozeduren SCR_LEFT bzw. SCR_RIGHT auf seine Bedürfnisse umzustricken, so daß es dann möglich ist, ab der aktuellen Spalte den Rest (ohne Turn-around) nach links oder rechts zu scrollen.

Bit By Bit - Built-In Smooth Scrolling

Hinter diesem netten Zungenbrecher verbirgt sich eine Besonderheit von xVT52, die bei vielen Effekten wertvolle Hilfe bieten kann. Gemeint ist das pixelweise Verschieben des Bildschirminhaltes. Zu allen Steuerzeichen, die der erweiterte Emulator kennt und die dem Einfügen/Löschen und horizontalen Scrollen dienen, gibt es ein “pixelweises Pendant“. In allen Fällen bleibt der Cursor auf seiner alten Position stehen. Soll - wie bei den normalen Sequenzen - der Cursor im Anschluß an die jeweilige Operation am Anfang der bearbeiteten Zeile stehen, so kann man dies durch nachträgliches Ausgeben eines Zeilenrücklaufes (Carriage Return, ASCII-Code 13) erreichen. Tabelle 1 zeigt den Zusammenhang zwischen Sequenzen zum zeilen-/spaltenweisen Scrollen und den entsprechenden, pixelweise arbeitenden Verschieberoutinen. Anzumerken ist hier noch, daß bei den spalten weisen Verschieberoutinen (ESC T/U) tatsächlich nur um ein Pixel nach links bzw. rechts gescrollt wird. Möchten Sie also eine Zeile um eine komplette Spalte verschieben, müssen Sie die entsprechende Sequenz achtmal abschicken. Warum? Weil der Prozessor abgeht wie die Feuerwehr! Würden diese Sequenzen jeweils eine komplette Spalte verschieben, wären sie überhaupt nicht mehr von den spaltenorientierten Routinen zu unterscheiden...

Alphabet (fast) komplett!

Wer mitgezählt hat, wird auf bisher 51 (!) ESCape-Sequenzen kommen, die der erweiterte VT52-Emulator “versteht”, nämlich von A-Z und a-z. Die letzte Sequenz, ESC r, dient dazu, den Emulator grafikfähig zu machen. Es ist sicherlich die reizvollste Erweiterung des VT52, mit der sich etliches anstellen läßt. Um den Rahmen nicht zu sprengen, muß ich Sie aber leider auf den vierten und letzten Teil dieser Serie vertrösten. Da Sie sowieso erst mit dem Emulator arbeiten können, wenn Sie ihn komplett eingegeben haben, dürfte dies aber leicht zu verschmerzen sein. Es ließ sich nicht vermeiden, den Artikel in vier Teile zu splitten, weil er “en bloc” schlicht-weg zu groß geworden wäre. Andererseits war es aber unmöglich, das Programm zu modularisieren, so daß Sie also portionsweise immer ein “Stückchen mehr vom Emulator” gehabt hätten. Denn: Entweder läuft alles oder es läuft eben nichts. So ist das nunmal im Digitalgeschäft...

Speed It Up

Wenn man ein Programm schreibt, das ein bereits bestehendes Programm ablösen soll, muß man dafür natürlich gute Gründe haben. So auch bei der Vorstellung eines neuen (alten, weil kompatiblen) Terminal-Emulators. Nun kann der erweiterte Emulator mit einer Vielzahl wirklich neuer Features aufwarten, aber das hätte man sicher auch anders erreichen können; beispielsweise durch Einführung neuer GEMDOS-Funktionen. Die Einbindung in den Emulator ist natürlich die wesentlich elegantere Methode, weil hierbei die logisch zueinander gehörenden Funktionen auch auf dieselbe Weise angesprochen werden können. Aber es gibt noch ein weiteres Argument, warum xVT52 dem “gewöhnlichen” VT52 überlegen ist: die Geschwindigkeit. Diese liegt nämlich im Vergleich zum “Alten” um mindestens Faktor zwei höher; in Spezialfällen kann die Ausführung auch sechsmal und mehr beschleunigt werden. Um diese Steigerungen zu erreichen, wurden einige programmtechnische Tricks angewandt, die ich Ihnen nicht vorenthalten und zur Nachahmung empfehlen möchte. Aber erst das nächste Mal; jetzt möchte ich Ihnen zunächst einmal zeigen, wie schnell er denn nun wirklich ist, der erweiterte Emu.

Vorher/nachher und die Benchmarks

Wann immer es darum geht, Programme und deren Leistung zu objektivieren, geht es früher oder später um deren Geschwindigkeit. So auch diesmal. Auch wenn man nicht zu den “Geschwindigkeits-Fanatikern” gehört, die Leistungen (nur noch) nach der Anzahl der gewonnenen Nanosekunden beurteilen, so muß man sich doch darüber im klaren sein, daß eine tausendmalige Einsparung einer Millisekunde bereits eine Sekunde ausmacht und sich somit viele Wenig zu einem Viel aufsummieren. Wer fast ausschließlich die grafische Benutzeroberfläche und sonstige GEM-Programme benutzt, wird sich über die teilweise drastischen Geschwindigkeitszunahmen durch den Blitter-Einsatz freuen, obwohl dieser in einzelnen Funktionsaufrufen “nur unwesentlich” schneller als die softwaremäßigen Emulationen ist. Umgekehrt gibt es aber auch viele ST-Besitzer, die die grafischen Fähigkeiten zwar nicht verachten, aber aus Gründen der Effizienz lieber mit TOS-Programmen und Kommando-Interpretern arbeiten. Da in diesen Programmen der Bildschirmausgabe per VT52-Emulator eine tragende Rolle zukommt, spielt es hier sehr wohl eine Rolle, ob ein Bildschirm nun in einer oder in einer fünftel Sekunde aufgebaut ist, da sich dieser Vorgang leicht ein paarhundertmal in der Stunde wiederholen kann. Und eine durchschnittliche “Session” kann viele Stunden dauern...

Um nun also ein Maß für die Ausführungsgeschwindigkeiten zu bekommen, mußte wieder einmal einer der so beliebten Benchmarks herhalten. Für das Messen der Bildschirmausgabe gelten zwei Tests als Standard (zumindest für die IBM-Welt), so daß ich sie auch für den xVT52 verwendet habe (s. Listing 3). Es galt zehn volle Bildschirmseiten ohne und mit Scrollen auszugeben - bloß: wie? Denn mit Benchmarks ist das immer so eine heikle Geschichte. Wenn man nicht aufpaßt, mißt man mit diesen Tests alle möglichen Nebeneffekte - nur halt eben nicht das, was man eigentlich wollte! Tatort: GFA-BASIC. Wenn man hier mißt, wie lange es dauert, um 250 Zeilen mittels PRINT -Anweisung auszugeben, wird man lediglich herausbekommen, wie fix der BIOS-Traphandler ist. Grund: Frank Ostrowski hat schon früh erkannt, daß das BIOS wesentlich hurtiger arbeitet als die GEMDOS-Funktionen, in denen u.a. auf Ausgabeumlenkung geprüft wird, bevor dann am Ende ohnehin BIOS- oder XBIOS-Funktionen aktiviert werden. So wird also alles, was hinter dem PRINT-Befehl steht, Zeichen für Zeichen direkt über das BIOS ausgegeben. Also mußte ich direkt die GEMDOS-Funktion PRINT LINE (0x9) ansprechen, die ja einen beliebig langen String ausgeben kann und dabei nur einmal den Trap-Handler zu durchlaufen braucht. Somit konnte gewährleistet werden, daß nur die Ausgabegeschwindigkeiten und nicht die Nebeneffekte (inklusive der Interpretergeschwindigkeit) gemessen wurden.

Wow!

Ich glaube, daß man mit den Zeiten recht zufrieden leben kann. Es sind zwar keine Tempus-Geschwindigkeiten erreicht worden (was für ein Betriebssystem zugegebenermaßen auch unmöglich ist), aber dennoch liegen die Zeiten von xVT52 deutlich unter denen des Original-Emulators. In Tabelle 2 können Sie die Ergebnisse für die verschiedenen ST-Konfigurationen nachlesen. Je nach TOS-Version und Blitter-Einsatz liegt der Geschwindigkeitszuwachsfaktor zwischen zwei und fünf. Im “normalen” Einsatz ist eine Steigerung um das zwei- bis dreifache als realistisch zu betrachten. Natürlich werden mir jetzt einige Leser vorwerfen, daß die Benchmark-Tests alles andere als objektiv sind, weil die verwendete Funktion des GEMDOS so umgeschrieben wurde, daß sie die Strings nun “am Stück” und somit ohne weitere BIOS-Aufrufe ausgeben kann. Aber: Ist es denn nicht gerade Sinn und Zweck von (System-) Patches, Mängel in Programmen auszuräumen (auch mangelnde Geschwindigkeit)? Und: Die meisten TOS-Programme benutzen genau diese Funktion, um ihre Ausgaben auf den Bildschirm zu realisieren und kommen somit auch in den Genuß des erweiterten Emulators. Und schließlich hat der xVT52 ja auch noch ganz andere Qualitäten und Vorzüge...

Soweit für diesmal. Ich darf natürlich auch heute nicht versäumen, Ihnen viel Spaß (und wenig Blasen) beim Abtippen des Listings zu wünschen. Vielleicht hat der eine oder andere Tippfaule unter der Leserschar mit Blick auf Benchmarks und ESCapes nun doch noch Appetit bekommen. Würde mich natürlich freuen...

MS

Es folgen noch zwei Listings auf der nächsten Seite.

Listing 2: So einfach kann man prüfen, welcher Emulator gerade aktiv ist (in GFA-BASIC).

Listing 3: So wurden die Ausgabezeiten ermittelt (in GFA-BASIC)