Schaut man sich moderne PC-Software an, so fällt eines auf: Kaum ein Programm traut sich noch ohne Pulldown- und Pop-Up-Fenster auf den Mai kt. Erstere hängen bevorzugt wie kleine Jalousien von einer Menüleiste am oberen Bildschirmrand herunter; die zweite Sorte kann an jeder beliebigen Bildschirmposition erscheinen und dient häufig dazu, den Benutzer mit Warnungen oder Fehlermeldungen in Angst und Schrecken zu vei setzen. Natürlich möchte auch der CPC-Programmierer gerne dem Zuge der Zeit folgen und auf seinem Rechner Fenster-Orgien feiern, trifft dabei jedoch auf einige Hindernisse. Wie man sie beseitigt, zeigt diese Folge der Assemblerecke. Der große Vorteil der Pulldown-Win-dows liegt darin, daß man sie problemlos ein- und ausblenden kann, ohne daß der ursprüngliche Bildhintergrund zerstört wird. Dadurch steht die gesamte Bildfläche für die Anwendung (Text, Grafik) zur Verfügung; es gibt keinen Bildschirmbereich, der ständig für Menüs oder Hinweise reserviert bleiben muß. Das CPC-Basic stellt zwar einen WINDOW-Befehl zur Verfügung, mit dem man einen beliebigen Bildschirm-Ausschnitt als Ein-/Ausgabebereich definieren kann. Die Probleme fangen jedoch an, wenn man das Fenster wieder verschwinden lassen will, da der CPC den verdeckten Bildhintergrund nirgendwo zwischenspeichert. Er ist also verloren, sobald man ihn überschrieben hat. Will man dieses Manko beseitigen, so sind folgende Probleme zu lösen: - Speicherplatz: Irgendwo muß der verdeckte Bildbereich hin, und das kostet Silizium. Der gesamte CPC-Bildschirm braucht 16 KByte, es empfiehlt sich also dringend, nur den Ausschnitt zu retten, der vom Fenster verdeckt wird.
- Betriebssystem: Der CPC unterstützt Operationen mit Bildausschnitten in keiner Weise. Hier heißt es 'Do It Yourself, und zwar in Maschinensprache.
- Bildschirmspeicher: Da uns das Betriebssystem nicht hilft, müssen wir uns persönlich ins Video-RAM wagen. Und das ist nicht gerade einfach aufgebaut.
Ein Video-Chip mit eigener Sichtweise Also packen wir den Stier gleich bei den Hörnern und schreiben mit dem folgenden Basic-Programm erst einmal den gesamten Bildschirmspeicher voll: 10 KODE 1
20 FOR adr = &C000 TO &FFFF
30 POKE adr,&FF
40 NEXT adrEs fällt auf, daß auf dem Bildschirm zuerst die obersten Pixelreihen aller Textzeilen angesprochen werden, dann die Pixelreihen darunter usw. Das liegt an der Konstruktion des Video-Chips, der den Bildschirm nicht als ein Rechteck mit 40 x 25 Zeichen betrachtet, sondern als ein langes Buchstaben-Band . Es interessiert ihn dabei nicht im geringsten, daß wir dieses Band auf dem Bildschirm stückweise untereinander angeordnet sehen: Geht man die Adressen nacheinander von &C000 bis &FFFF durch, so wird eben zunächst die erste Rasterzeile des Bandes komplett gefüllt, danach die zweite usw. Noch komplizierter wird die Angelegenheit dadurch, daß es sich um ein Endlosband handelt, also um eine Art Schlange, die sich in den Schwanz beißt. Man kann den Video-Chip dazu veranlassen, den Anfang des Bandes (die obere linke Ecke des Bildschirms) nicht an die physikalische Speicheradresse &C000 zu legen, sondern an eine ganz andere Stelle. Dadurch wird das sogenannte Hardware-Scrolling möglich: Ohne auch nur ein Byte zu bewegen, kann der Bildschirminhalt nach oben oder unten gerollt werden, was zum Beispiel beim Listen eines längeren Programms für Tempo sorgt. A1-lerdings funktioniert das nur, wenn der gesamte Bildinhalt bewegt werden soll, bei Teilbereichen muß die Software aktiv werden. (Probieren Sie mal das Scrolling nach WINDOW 1,1,1,24). Kurz gesagt: Man kann sich nie sichet sein, welche Bildschirmposition an welcher Adresse liegt, außer nach r einem Reset oder einem MODE-Berfehl. Hierbei wird der Video-Chip so programmiert, daß die linke obere Ecke bei &C000 zu finden ist. Pro gramme, die ohne Hilfe des Betriebs-r systems auf den Bildspeicher zugrei fen, sollten deshalb immer mit einen MODE-Befehl beginnen und dafür sor gen, daß zwischendurch kein Hardware-Scrolling stattfindet. Dadurch wird die ganze Angelegenheit wesentlich einfacher. Auch die folgenden Erläuterungen und Listings werden davon ausgehen, daß sich der Bildschirm im Grundzustand befindet. Das Adressen-Labyrinth Das Speicherdiagramm gibt die Anfang- und Endadressen der ersten Rasterzeilen des Bildschirms an und zeigt, wie man sich durch dieses Labyrinth hindurchrechnet. Dem dazugehörigen Basic-Listing können Sie entnehmen, wie man vorgehen muß, um den Bildschirm systematisch von oben nach unten zu beschreiben. Die Angaben sollen hier noch durch etwas Mathematik unterstützt werden: Eine Bildschirm-Rasterzeile umfaßt vom linken bis zum rechten Rand 80 Byte. In MODE 2 passen 80 Zeichen in eine Zeile, jedes Zeichen ist also 1 Byte breit. In MODE 1 und 0 ist die Farbenvielfalt größer. Deshalb werden die Zeichen 2 bzw. 4 Byte breit, damit der zusätzliche Informationsgehalt untergebracht werden kann. Das vom Video-Chip verwaltete Endlos-Band ist also 8 Rasterzeilen hoch und 25 * 80 = 2000 Byte lang, wie man zumindest vermuten sollte. Damit kommen wir jedoch nur auf 8 * 2000 = 16000 Byte Video-RAM, obwohl der CPC für diesen Zweck insgesamt 16 KByte = 16384 Byte zur Verfügung stellt. Was ist mit den überzähligen Bytes? Des Rätsels einfache Lösung: Das Band ist in Wirklichkeit 2048 Byte lang, die jeweils letzten 48 Byte der 8 Rasterzeile erscheinen jedoch nicht auf dem Bildschirm! Hier kann man bei akutem Speicherplatzmangel sogar noch Daten unterbringen. Wie das Basic-Programm zeigt, muß man also zu einer Bildschirmadresse die Länge des Bandes (2048, Hex &800) addieren, um genau eine Rasterzeile nach unten zu wandern. Kritisch wird es nur, wenn wir auf diese Weise an der unteren Kante des Bandes angekommen sind. Addiert man hier nochmals 2048, so übersteigt das Ergebnis den mit 16 Bit darstellbaren Adreßbe-reich (maximal &FFFF). In Maschinensprache macht sich das durch ein gesetztes Übertragsbit (Carry-Flag) bemerkbar; es läßt sich also sehr einfach feststellen, ob gerade ein Übergang zur nächsten Textzeile stattfindet. In diesem Fall rechnet man zunächst bis zur oberen Kante des Bandes zurück, indem man 8 * 2048 (Hex &4000) subtrahiert. Durch Addition der Bildschirmbreite (80, Hex &50) kommt man von dort aus bequem in die erste Rasterzeile der nächsten Bildschirm-Textzeile. Auf Maschinenebene ist es sehr nützlich, wenn ein Unterprogramm zur Verfügung steht, das eine beliebige Bildschirmadresse um eine Rasterzeile nach unten weiterrechnet und dabei den Sprung zwischen den Textzeilen automatisch berücksichtigt. Sie finden es in dem Assemblerlisting ab Zeile 5710 unter dem Label LDOWN. Die Vorgehensweise können Sie den Kommentaren entnehmen. Sie entspricht genau dem im Basic-Listing verwendeten Verfahren, nur werden hier Low- und Highbyte der 16-Bit-Adresse in HL separat behandelt. Ausschnittsberechnung in Assembler Will man in Assembler mit Bildschirmausschnitten operieren, so müssen folgende Werte bekannt sein: - die Adresse der linken oberen Ecke
- die Breite des Bereichs in Byte
- die Höhe in Rasterzeilen Günstig ist es, wenn man die Grenzen des Bereichs (links, rechts, oben, unten) wie beim Basic-WINDOW-Befehl in Textkoordinaten angeben kann und ein Unterprogramm zur Verfügung hat, das daraus die erforderlichen Werte berechnet. Die linke obere Ecke eines Textfensters liegt immer auf der ersten Rasterzeile des Bandes; die Bildschirmadresse ergibt sich deshalb aus folgender Formel: adr =(oben-1)*80 + (links-1)*mf + &C000 Die Subtraktion von 1 ist nötig, da die Textkoordinaten der oberen linken Bildschirmecke (1,1) betragen und nicht (0,0). mf ist ein 'MODE-Faktor', mit dem die horizontalen X-Werte wegen der unterschiedlichen Zeichenbreite multipliziert werden müssen:
MODE 0: mf = 4
MODE 1: mf = 2
MODE 2: mf = 1 Die Berücksichtigung des Faktors garantiert, daß unsere Routinen in allen MODEs funktionieren. Prüfen Sie die Formel nach: Wenn Sie zum Beispiel die Textkoordinaten (1,1) einsetzen, erhalten Sie genau die Bildschirmadresse &C000 der linken oberen Ecke. Auch die Breite eines Fensters in Byte ist vom MODE abhängig, Breite = (rechts-Iinks+l)*mf und jetzt fehlt nur noch die vertikale Höhe in Rasterzeilen: Höhe = (unten-oben +1)*8 Im Assemblerlisting werden diese Formeln innerhalb des Unterprogramms WINADR ab Zeile 5240 verbraten. Die Textkoordinaten werden in HL und DE angeliefert, zum Abschluß befindet sich in HL die gewünschte Bildschirmadresse und im B- bzw. C-Register die Breite/Höhe des Fensters in Byte. Hilfestellung bei der Berechnung gibt die Betriebssystem-Routine SCR GET MODE, die die Prozessorflags in Abhängigkeit vom aktuellen MODE setzt. Genauere Informationen finden Sie in PC International 10/88, Seite 26. Eine weitere kleine Routine (WINPAR, ab Zeile 5080) dient dazu, die Window-Grenzen als Parameter von einem Basic-CALL zu übernehmen und in die richtigen Register einzusortieren. Mit Hilfe dieser Unterprogramm-Bibliothek läßt sich schon etwas Nützliches anfangen: Die Routine INVERS (ab Zeile 1050) invertiert ein beliebiges Textfenster und kann zum Beispiel dazu verwendet werden, die in Pulldown-Menüs üblichen Auswahlbalken zu programmieren. Wie der Aufruf von Basic aus funktioniert, ist den Kommentaren im Listing zu entnehmen. Das ist natürlich längst noch nicht alles. In der nächsten Folge der Assemblerecke werden weitere Routinen für ein Window-Management in das Listing integriert. Aus diesem Grund finden Sie zu Beginn den Ansatz für eine Sprungtabelle, die die Benutzung mehrerer Maschinen-Unterprogramme von Basic aus wesentlich erleichtern wird. Doch auch dazu mehr in der nächsten Folge. Matthias Uphoff/cd , CPCAI |
