In der letzen Folge ging es um die Installation des Emulators und die Problematik mit dem GEM-Vektor. Diesmal werde ich Ihnen u.a. einige der neuen bzw. erweiterten Escape-Sequenzen vorstellen.

Bevor ich mit der weiteren Besprechung des Programms fortfahre, möchte ich Ihre Aufmerksamkeit zunächst einmal auf die in Tabelle la und lb dargestellten globalen Variablen TCB und CCB lenken. Da fast alle Funktionen auf diese Strukturen zugreifen, ist es für das Verständnis des Programms nicht ganz unwichtig, zu wissen, welche Informationen sie enthalten. Im allgemeinen wird auf beide Strukturen nur über Offsets zur Basisadresse zugegriffen. Weil sich das so herzerfrischend wissenschaftlich und also chinesisch anhört, hier ein Beispiel: Zu Beginn einer Funktion wird die Adresse des Cursor-Control-Blocks CCB mit dem Befehl "lea CCB,a4” in ein Adress-Register des MC68000 geladen. Möchte man nun die absolute Cursorposition (irgendeine Adresse im Video-RAM) eruieren, so kann man mit 6(a4) darauf zugreifen. Im Prinzip ist das nichts anderes als die Assembler-Variante des von Pascal und C her bekannten Zugriffs auf Records/ Structs und Unions, also z.B. abs_curs(:)=CCB.address. Sie sehen, daß das Verständnis der Maschinensprache manchmal ganz nützlich sein kann, wenn es darum geht, sich abstrakte und damit nicht immer leicht verständliche Sprachkonstrukte zu vergegenwärtigen, wobei dies insbesondere für die leidigen Pointer gilt! ich nehme an, daß Sie dank der Kommentare nun keine Schwierigkeiten mehr haben werden, die beiden Kontrollvariablen zu verstehen. Aber noch eine weitere fundamentale Vorbetrachtung ist zum Programmverständnis notwendig, nämlich die Organisation der systemeigenen

Fonts

Was nützt ein mit allen gängigen Superlativen dekorierter Computer, wenn er sich nicht in der Lage sieht, sich im Klartext mit dem Benutzer zu unterhalten? Gewieft, wie die Hersteller nun ‘mal sind, haben sie Mittel und Wege ersonnen, die uns allen bekannten Schriftzeichen zur Darstellung zu bringen. Dabei gehen allerdings sowohl Mittel wie Wege ihre eigenen ebensolchen. Hersteller X zieht es beispielsweise vor, den ganzen Zeichenkrempel der Hardware zu überlassen; entsprechende Chips hören auf den Namen Character Generators. Der Vorteil hierbei liegt sicherlich in der Einfachheit der Bedienung und der Darstellungsgeschwindigkeit. Man übergibt dem Chip schlicht die Nummer des Zeichens, das darzustellen man sich wünscht - und läßt die Transistoren pfriemeln. Die Nachteile sind aber auch nicht ganz ohne: abgesehen davon, daß selbst Chips "Made in Taiwan" nicht für umsonst zu haben sind, erlauben nur einige wenige den Gebrauch von Textattributen (hell, blinkend, kursiv...). und dann haben sie auch ihren Preis. Ergo gehen andere Hersteller den Weg über die Software. Die ist zwar auch nicht gerade billig, aber wenn sie erst einmal erstellt ist, kann man sie beliebig oft und quasi gratis ohne Qualitätsverlust vervielfältigen (was zugegebenermaßen nicht jedem gefällt - die verschiedensten Kopierschutzmechanismen sprechen da eine deutliche Sprache...). Wie funktioniert nun aber die softwaremäßige Zeichendarstellung? Die Voraussetzung hierzu ist auf jeden Fall, daß der Bildschirm zur Kategorie “bitmapped" gehört.

Bitmapping?

Weil man sich darunter wieder schrecklich viel vorstellen kann, sei’s kurz erläutert. Der SM 124 bringt am ST 640 mal 400 Pixel (Abk. für: picture elements) zur Darstellung. Jeder dieser Bildpunkte wird durch ein Bit im Hauptspeicher des Rechners repräsentiert, d.h., der Bildschirm ist nichts anderes als ein durchgehender RAM-Bereich einer durch die Auflösung bestimmten Länge. Beim Atari sind dies 640*400=256000 Bits durch 8 macht 32000 Bytes. Möchte man nun einen Punkt setzen, wird im mit diesem Punkt korrespondierenden Byte einfach das entsprechende Bit auf “1” gesetzt (raten Sie mal, wie das Löschen funktioniert!). Ein besonderer Chip ist darauf spezialisiert, das Video-RAM ständig abzutasten und die entsprechenden Signale zu erzeugen, die der Bildschirm dann letztendlich darstellen kann. So funktioniert’s bei monochromatischer Darstellung; kommt Farbe ins Spiel, wird’s schon kniffliger. Will man beispielsweise vier Farben darstellen, so benötigt jeder Bildpunkt schon 2 Bit an Information. Die entsprechende Bitkombination muß dann ebenfalls von der Hardware interpretiert werden. Soll der Bildspeicher weiterhin seine Größe von 32000 Bytes behalten, läßt es sich nicht vermeiden, daß sich die Anzahl der darstellbaren Pixel halbiert! Das ist auch der Grund, warum man in der mittleren Auflösung zwar vier Farben, aber nur noch 640 mal 200 Bildpunkte darstellen kann. Übrigens nennt man die Gesamtheit eines Bits über alle Pixel eine “bitplane” (bei Monochrombetrieb gibt’s nur eine, bei vier Farben zwei, bei sechzehn Farben vier, bei... na, Sie wissen schon: Logarithmus dualis und so).

Zeichen auf dem Monitor

Nach diesem Ausflug in die Welt der “bitmapped devices” können Sie sich sicher leicht vorstellen, wie man nun Zeichen auf den Monitor bringt. Jedes Zeichen wird durch eine Kombination aus gesetzten oder eben nicht gesetzten Bits repräsentiert, und zwar in einem Feld von soundsoviel mal soundsoviel Punkten. Im einfacheren Fall ist die Größe des Rasters für alle darstellbaren Zeichen konstant. Im Atari gibt’s gleich drei System-Zeichensätze (Fonts), bei denen dies so gelöst ist (6x6,8x8 und 8x16). Daß es aber auch anders geht, wissen Kenner von Apple’s Mac zu berichten (hat da jemand Aladin gesagt?). Bei diesen Rechnern hat man nicht nur beliebig viele Zeichensätze zur Verfügung, sie sind auch alle für Proportionalschrift ausgelegt, d.h. ein ‘i’ benötigt weniger Platz als ein ‘M’. Im Endeffekt sieht das dann zwar ein wenig ästhetischer aus, ist aber wesentlich aufwendiger. Stellen Sie sich vor, Sie müssen ein Zeichen löschen: abgesehen davon, daß es nicht ganz einfach ist, den Cursor genau auf das Zeichen zu setzen - wieviele Pixel sind’s denn nun, die auszuradieren sind? Ich nehme an, daß Franze “SIGNUM!” Schmerbeck (Tagchen auch) hier ein paar Klagelieder anzustimmen weiß... Bleiben wir also lieber bei der Darstellung äquidistanter Zeichen.

Fonts im ROM

Problem: wie legt man die Font-Daten im ROM ab? Exemplarisch sei’s am 8xl6-Font erklärt (bei den anderen Fonts ist es genauso). Man zerlegt hierzu die Zeichen in sogenannte “scanlines”, wovon es logischerweise 16 gibt. Ab der Startadresse der Fontdaten stehen dann hintereinander: die oberste Zeile von chr(0), gefolgt von der obersten Zeile von chr(1), gefolgt... und so geht das denn bis 255. Dann kommt die zweitoberste Zeile von chr(0) und so weiter. Glücklicherweise ist nun eine Scan-line genau acht Bit breit, so daß man sehr simpel auf ein Zeichen zugreifen kann: die oberste Zeile findet man an der Adresse FontStartAdresse + ASCII-Nummer(Zeichen). Die zweite befindet sich 256 Bytes weiter, die dritte... Nun weiß man aber von GEM/VDI-Programmen, daß auch ein ST zu Textattributen bis hin zur Proportionalschrift befähigt ist. Zu diesem Behufe ist wie üblich wieder Verwaltung notwendig, welche im “Fontheader” residiert. Dort findet man z.B., welche Zeichen überhaupt im Font gespeichert sind, wo die Startadresse des Fonts liegt, wie er heißt und einen Zeiger auf die sogenannte “Offset-Tabelle”.

In dieser ist nun gespeichert, wieviele Bits jedes Zeichen breit ist. Somit müssen nur die Scanlines des ersten darstellbaren Zeichens auf einer Wortgrenze (gerade Adresse) beginnen; die restlichen Daten können über die Offset-Tabelle gefunden werden, was jedoch recht zeitaufwendig und rechenintensiv ist. Für den VT52-Emulator wie auch für die VDI-Escapes ist das aber alles vollkommen wurscht: sie erwarten, daß jedes Zeichen exakt ein Byte breit ist und damit basta! Ich habe die Existenz der Offset-Tabelle lediglich der Vollständigkeit halber erwähnt; sie ist, wie gesagt, für den Teil der Textausgabe, um den es hier geht, nicht relevant. Was ich Ihnen nun lang und breit erklärt habe, ist die in Prosa gefaßte Prozedur PUT, die Sie am Anfang des Listings wiederfinden können. Abgesehen davon, daß sie ein Zeichen auf den Bildschirm bringt, sorgt sie auch dafür, daß - je nach eingestellten Attributen - das Zeichen unterstrichen, halbhell (disabled) oder invertiert dargestellt wird, wobei diese Attribute auch kombiniert werden können. Wie man diese Attribute wählen kann, erfahren Sie im folgenden Kapitel.

Massenweise Esc-Sequenzen!

xVT52 erweitert die Anzahl der Steuerzeichen auf mehr als das Doppelte. Das bedeutet zwar, daß Programme, die von den neuen Möglichkeiten Gebrauch machen, nicht mehr ohne den erweiterten Emulator lauffähig sind (besser gesagt: sie laufen zwar auch unter dem normalen VT52-Emulator, weil dieser - Ausnahmen ausgenommen - die neuen ESC-Sequenzen einfach ignoriert), andererseits dürfte es wohl keine Schwierigkeiten bereiten, xVT52.PRG mit seinen 4.5 Kilobytes Speicherbedarf mit auf die entsprechende Programmdiskette zu kopieren, oder?

An den folgenden Escapes hat sich nichts geändert (d.h. sie unterscheiden sich nicht von denen des Originals):

ESC A, B, C, D, E, H, I, J, K, L, M, und Y
ESC d, e, f, 1, o, p, q, v und w.

Im übrigen sind auch die normalen Steuerzeichen Carriage Return, Line Feed, VT, Backspace und Bell (Wau!) gleich geblieben.

Folgende Steuerzeichen weichen von der VT52-Norm ab:

ESC b und c: Diese dienen dem Setzen der Vorder- und Hintergrundfarbe. Da xVT52 jedoch einen Monochrom-Monitor voraussetzt, werden beide Sequenzen schlichtweg ignoriert.
ESC j und k: Mit der ersten Sequenz kann man die aktuelle Cursorposition speichern und mit ESC k wieder anspringen. Insofern sind sie zum Original kompatibel; allerdings gestatten sie nun das Speichern von bis zu drei (bisher eine) Positionen. Dabei wird mit ESC k immer die zuletzt gespeicherte Position zurückgeholt; ist keine gespeichert, so passiert auch nichts! Möchte man eine zurückgeholte Position später wieder anspringen, muß sie zuerst wieder gespeichert werden.

Von den gewöhnlichen Steuerzeichen hat sich TAB (0x9) geändert. Während die Tabulatorweite beim VT52 konstant 8 Zeichen beträgt, gestattet xVT52 das Setzen von bis zu 80 (!) Tabulatoren an beliebigen Spalten (zugegeben: bei Ausreizen der 80 Tabs ist die Beliebigkeit zumindest beim 80. natürlich etwas eingeschränkt!!). Standardmäßig ist jede achte Spalte mit einem Tabulator versehen, so daß man auch hier ohne weiteres zur Norm kompatibel bleiben kann, sofern man’s möchte. Für den einfachen Aufbau von Tabellen ist es jedoch sicherlich nützlich, von den erweiterten Möglichkeiten Gebrauch zu machen. Hierzu stehen vier Escapes bereit:

ESC N setzt auf jede achte Spalte einen Tabulator, was somit der VT52-Standardeinstellung entspricht.
ESC O löscht alle Tabulatoren. Das kann sinnvoll sein, wenn man neue Tabulatoren setzen möchte und nicht weiß, wo bereits welche gesetzt sind, oder es mehr Aufwand bereiten würde, die bereits gesetzten und unerwünschten Tabs einzeln zu löschen.
ESC P n setzt an Spalte n-32 (die erste Spalte ist 0) einen Tabulator. Möchte man also beispielsweise einen Tabulator auf Spalte 15 setzten, benutzt man z.B. in BASIC folgenden Befehl: Print chr$(27); "P";chr$(15+32);
ESC Q n löscht einen an Spalte n-32 befindlichen Tabulator, wobei es keine Rolle spielt, ob dort vorher einer gesetzt war; will heißen es passiert nichts, wenn Sie einen nicht existierenden Tabulator löschen (warum sollte auch??!). Wenn Sie sich über den Offset von 32 wundem sollten: auch hierfür hat’s eine Erklärung. Wir reden hier die ganze Zeit von Emulatoren, als wären sie die natürlichsten Dinge der Welt neben Bananen und Bühnenlasern! Mal ganz ehrlich: Haben Sie ‘ne Ahnung, warum es VT52-Emulator heißt? Geschweige denn, was man sich darunter vorzustellen hat? If not then read Historie eise goto end.

Historie

Beginnen wir der Einfachheit halber wieder mit dem Ende: Ein Emulator ist die Simulation von Hardware mittels Software, d.h. ein Programm tut so, als ob, ist es aber gar nicht! So ist es ist beispielsweise möglich, den guten alten ST per Programm in einen noch guteren und älteren Macintosh odergar in den allergutesten und alleraltesten Ih Bäh Mhh zu verwandeln, ohne auch nur ein Schräubchen berühren zu müssen. “Fein!”, werden Sie jetzt sagen, “Und was hat das alles mit meinem VT52 zu tun?”. Es hat. Sie müssen sich vorstellen, daß es Zeiten gab, in denen Computer sehr, sehr teuer waren. Anstatt also jedem Mitarbeiter einen Mega ST4 mit 60MB-Festplatte und Laserdrucker auf den Tisch zu stellen, gab es nur einen biederen grün leuchtenden Monitor, während sich der sogenannte Mainframe irgendwo zwischen Waschküche und Heizungskeller befand (zum einen, weil er so laut war, und zum anderen, weil die Warmluft der Röhren sich vortrefflich zum Wäschetrocknen eignete). Jaja, damals gab’s halt noch keine Stiftung Staren-Nest und der Begriff “71 Hertz” wurde noch vergeblich in Biologiebüchern gesucht. Zu dieser Zeit also trug es sich zu, daß man vor dem Problem stand, daß der Benutzer irgendwie mit dem Rechner in Verbindung treten mußte (darf ich’s kommunizieren nennen?). Also baute man eine Hardware, nannte sie Terminal und befahl ihr, Dolmetscher zu spielen. In ihrem Innersten gab es eine Schaltung (heute würde man ja “Chip” sagen, aber damals gab es nur solche aus Kartoffeln), also etwas ureigen Elektrisches, was mittels eines Protokolls den Datenaustausch zwischen Tastatur, Mainframe und Monitor bewerkstelligte (Mäuse gab’s ja nur im Heizungskeller...). Natürlich ist die Problematik bis heute die gleiche geblieben; es gibt nach wie vor Zentralrechner, die eine bestimmte Anzahl von Terminals bedienen können. Nur werden die Protokolle nicht mehr nur über die Hardware realisiert - zunehmend übernehmen auch Programme diese Aufgaben. Womit wir den Kreis geschlossen hätten, denn nun sind wir wieder beim Emulator. Bleibt immer noch die Frage nach dem ominösen Offset von 32. Er hängt halt zusammen mit dem erwähnten Protokoll (keine Angst, das ist nichts Unanständiges und gibt auch keine Flensburger!). Es regelt nämlich solch enorm wichtige Dinge wie etwa die Übertragungsgeschwindigkeit und Datensicherheit (Stichwort: Checksummenbildung), unterstützt aber auch besondere Funktionen, die mit speziellen Steuerzeichen ausgelöst werden (wie z.B. mit ESC, 0x1 B). Damit nun aber unterschieden werden kann, was simpler Text ist und was nicht, hat man den Steuerzeichen einfach spezielle Codes zugeordnet. Beim ASCII-Code zum Bleistift liegen die Steuerzeichen im Bereich bis OxlF, Zahlen, Buchstaben und Sonderzeichen zwischen 0x20 und 0x7F. Das genau ist der Grund, warum der Offset unbedingt notwendig ist - ohne ihn würde man sonst ungewollt ein Steuerzeichen abschicken, was schlimmstenfalls einen Abbruch der Datenübertragung zur Folge hätte! Das hätte ich Ihnen zwar alles viel kürzer verklik-kern können, aber warum sollte ich mich bremsen, wenn’s gerade gut aus der Feder läuft? Ich hoffe. Sie teilen meine Ansicht, nichts sei langweiliger als geballtes Wissen im DIN-Format; und vom Schmunzeln ist ja wohl auch noch keine Muskelfaser gerissen...

Zum Thema Textattribute stehen unter xVT52 folgende ESCapes zu Ihren Diensten:

ESC y: Schaltet den Unterstreichungsmodus ein.
ESC z: Schaltet den Unterstreichungsmodus aus.
ESC R: Schaltet die halbhelle Darstellung ein.
ESC S: Schaltet die halbhelle Darstellung aus.

Halbhelle Darstellung ist dabei gleichbedeutend mit dem Attribut “disabled” bei Drop-Down-Menüs und Dialogboxen. Die für diesen Effekt verantwortliche Funktion heißt LIGHTMASK und löscht für jede Scanline abwechselnd alle geraden und ungeraden Pixel, indem sie den ursprünglichen Inhalt mit 0x55 (%01010101) bzw. 0xAA (%10101010) verUNDet. Das Unterstreichen dagegen ist noch in der Routine PUT untergebracht, weil hier ja lediglich die unterste Scanline des Zeichens mit 0xFF zu ersetzen ist -sehr ökonomisch. Zwei weitere neue Sequenzen kümmern sich um den Font:

ESC F: Schaltet auf den “normalen” 8x16-Font um
ESC G: Umschalten auf den “kleinen” 8x8-Font.

Hierbei ist zu erwähnen, daß beim Umschalten vom 8x16 in den 8x8-Font die Zeile verdoppelt und umgekehrt halbiert wird, damit die Cursorposition (zumindest bei geraden Zeilen) unverändert bleibt. Bereits zu Beginn des ersten Teils hatte ich ja bereits erwähnt, daß man mit ESC i die Ausgabeparameter zurücksetzen kann, so daß sich eine weitere Erklärung erübrigt. Ich verweise hier nochmal auf die Funktion INIT_CONOUT, die sich in des Listings erstem Teil befindet und aus der Sie ersehen können, was alles initialisiert wird. Da fast jede Zeile des Listings dokumentiert ist (was ich Ihnen für Assemblerprogramme nur wärmstens zur Nachahmung empfehlen kann!), hoffe ich, daß Sie mit dem Programm einigermaßen zurecht kommen - auch wenn Sie nicht gerade zu den Koryphäen des Motorola-Jargons zählen sollten...

TCB: 
	dc.w 0 		; 0(TCB) aktuelle Spalte
	dc.w 0 		; 2(TCB) aktuelle Zeile
	dc.w 79 	; 4(TCB) maximale Spalte
	dc.w 24 	; 6(TCB) maximale Zeile
	dc.b 2		; 8(TCB) Bitvektor für Attribute:
					Bit 0=1: Invertieren ein (ESC p)  
					Bit 1=1: Wrapping ein (ESC v)
					Bit 2=1: Unterstrich ein (ESC y)  
					Bit 3=1: Halbhell ein (ESC R) 
	dc.b 0		; 9(TCB) Grafikflag (ESC r; 0=aus, -1=ein)
	dc.w 0		; 10(TCB) Anzahl gespeicherter Cursorpositionen (ESC j)
	dc.w 0,0 	; 12(TCB) 1. gespeicherte Position (x, y)
	dc.w 0,0 	; 16(TCB) 2. -"-
	dc.w 0,0 	; 20(TCB) 3. -"-
	dc.l 0 		; 24(TCB) Zeiger auf 8x16-Fontdaten (GEM).
	dc.l 0 		; 28(TCB) Zeiger auf 8x8-Fontdaten (GEM)
	dc.l 0 		; 32(TCB) Zeiger auf aktuellen Font
	dc.w 16 	; 36(TCB) Höhe eines Zeichens in Pixel
	dc.w 16*80	; 38(TCB) Bytes pro Textzeile

Tabelle 1a: Aufbau der Variablen TCB (TerminalControlBlock)

Damit’s für diesmal nicht zu lang wird, möchte ich an dieser Stelle einen Breakpoint setzen; jedoch nicht ohne Ihnen beim Abtippen viel Spaß und wenig Krämpfe gewünscht und Sie darauf hingewiesen zu haben, was Sie im dritten Teil erwartet: Einerseits die weitere Besprechung der neuen ESC-Sequenzen, andererseits will ich Ihnen verraten, wie man zeitkritische Programme auf Trab bringen kann und - naja, mal sehen... Alsdann tschüß bis neulich!