Die Hexer

Das ist ja wohl das Letzte! Ja wirklich, auf absehbare Zeit ist dies das letzte Mal, daß sich die Spitzenprogrammierer von »THE UNION« im ST-Magazin zu Wort melden. Nachdem TEX in ihren Artikeln auf das teilweise Entfernen der Ränder eingegangen sind, lüftet UNION-Mitglied Andreas das letzte Geheimnis: Die Beseitigung aller Ränder und das Funktionsprinzip des »Full-Screen-Demos«.

Hallo, hier ist Andreas von Level 16 mit dem zweiten Teil der unglaublichen Geschichten (oder: »was Shiraz Shivji nicht weiß«). Wie ich gerade feststellte, hat Gunter mich dazu verdonnert, einen Artikel über das Ende des linken Randes auf dem ST zu schreiben sowie etwas über »The UNION« und das mittlerweile bekannte UNION-Demo zu erzählen.

Bevor ich nun aus der »Demoküche« plaudere, ein paar Worte zu unserem Team: »Level 16« besteht seit zirka zwei Jahren und ist bei weitem nicht so groß wie TEX, es besteht nämlich nur aus zwei Leuten: Der eine heißt Dirk, der andere bin ich. Wie auch viele andere Mitglieder der »Dachvereinigung« UNION, haben wir uns weniger mit dem Cracken von Spielen beschäftigt, als mit dem Programmieren von kleinen Gags, Demos genannt.

Synchrone Programmierung

Ende Dezember 1987 veröffentlichten wir schon einmal ein kleines Demo, das scheinbar keine Ränder mehr kennt. Noch dazu besitzt es die Frechheit, den ganzen Bildschirm, auf dem sich ein winkendes Männchen befindet, diagonal zu scrollen und dabei einen Jingle des SWF3-Diskjockeys Elmar Hörig ertönen zu lassen. Schon dieses Demo arbeitet nach dem Prinzip, das wir in unserem Demoscreen in der UNION-Demo perfektioniert haben. Die Demo haben wir übrigens »FSD« (Full Screen Demo) getauft. Voraussetzung für solche Spezialeffekte ist, daß das Programm absolut synchron zum Elektronenstrahl des Bildschirms abläuft. Wie dies funktioniert, haben wir eigentlich schon oft genug gesagt, zur Vertiefung des Wissens möchte ich es aber hier noch einmal grob erklären:

Die CPU des ST arbeitet mit 8 MHz, gleich 8000000 Hz. Pro Sekunde stehen somit 8000000 Taktzyklen zur Verfügung.

Die PAL-Betriebsart baut das Bild 50mal pro Sekunde auf, das bedeutet, daß wir, um synchron zum Bildaufbau zu bleiben, pro Bild 160000 Taktzyklen verbraten müssen. Hält man sich nicht daran, so wandern beispielsweise Farbbalken, die Sie durch das Verändern der Farbregister setzen, diagonal über den Bildschirm. Exakt nach diesem Prinzip arbeitet das erste FSD-Demo. Für den diagonalen Scrolleffekt ändert das Programm bei gelöschtem Bildschirm nur so die Hintergrundfarbe, so daß das Bild des grüßenden Männchens entsteht.

Da die Routine exakt 159996 Taktzyklen benötigt, ist der Elektronenstrahl nach Beendigung der Routine noch nicht wieder oben links angekommen.

Jeder Takt zählt

Die Farben wurden um 4 Taktzyklen versetzt geändert, und das Ganze scrollt gemütlich nach links oben. Prinzipiell ist das schon der ganze Trick. Einen Haken hat die Geschichte jedoch: Um bei der verwendeten »Hintergrund-Klotzgrafik« eine brauchbare Auflösung zu erreichen, müssen die Befehle, die die Hintergrundfarbe ändern, sehr kurz sein. Die schnellste Methode, um beim ST eine Farbe zu ändern: Schreiben Sie einen Farbwert, der sich in einem Register befindet, an eine Adresse, auf die ein Adreßregister unmittelbar zeigt. Als Assembler-Befehl heißt das schlicht:

MOVE.W D0,(A6)

Der Befehl benötigt zum Wechseln der Hintergrundfarbe exakt acht Taktzyklen. Wie oben erwähnt, ist so ein Block exakt acht Pixel breit. Wenn Sie also genügend solcher Befehle aneinanderreihen und dabei nicht vergessen, daß eine Bildschirmzeile genau 512 Taktzyklen »lang« ist, bauen Sie damit bildschirmfüllend ein Bild auf. Wer jedoch in den Source-Code sieht, wird solch eine -zigtausend Zeilen lange Routine vermissen: Was geschieht also wirklich?

ST programmiert sich selbst

Nun, die Lösung ist ganz einfach: Das Programm schreibt sich selbst! Diese wundersame Aufgabe erledigen zwei Unterprogramme: PICANZ schreibt 39 Blöcke, jeder 8 Pixel hoch, 48 Pixel je Zeile, in den Speicher. MODIFY ändert anhand der Tabelle BILD die MOVE.W D0,(A6)-Befehle so ab, daß es jeweils die Nummer des Datenregisters in den Opcode schreibt, dessen Farbwert neue Hintergrundfarbe werden soll.

Der Source-Code des FSD hat fast 400 KByte und läßt sich somit weder abdrucken, noch paßt er auf die Leserservice-Diskette. Deshalb habe ich eine verkürzte Version geschrieben, die Sie im Anschluß an diesen Artikel finden. Als kleines Bonbon erhalten Sie auf der Leserservice-Diskette das komplette erste FSD als ausführbares Programm.

Das also zu dem ersten Versuch, Grafik auf allen Rändern des ST darzustellen. Wie gesagt, es war ja nur ein Versuch.

Es geht ans Eingemachte

Wie seit der Veröffentlichung des »UNION-DEMO« bekannt sein dürfte, gibt es auch andere Wege als diese Mogelmethode, Grafik auf den Rändern darzustellen. Nachdem TEX in den vergangenen Ausgaben kleckerweise verraten haben, wie zuerst der untere, dann der obere und zuletzt der rechte Rand zu Öffnen ist, bleibt es an mir hängen, ein wenig über den linken Rand zu plaudern. Dafür benötigen wir aber noch einen Ausflug in die synchrone Programmierung:

Das Fernsehbild der PAL-Norm besteht aus 625 Zeilen, die in zwei sogenannten Halbbildern zu 312.5 Zeilen (nicht wundern, einfach glauben!) dargestellt werden. Je Zeile stehen 512 Taktzyklen zur Verfügung. Wann immer Sie ein Programm schreiben, das synchron zum Elektronenstrahl agiert, müssen Sie sich an diesen Takt halten. Andernfalls wandert (im harmlosesten Fall) ein Farbbalken über den Bildschirm. Manchmal geschehen jedoch wirklich sonderbare Dinge: Benötigt unsere Hintergrundfarben-Routine nur 510 Taktzyklen anstelle der verlangten 512, so wandert der Farbbalken einige Augenblicke nach links und bleibt dort auf einmal hängen. Daß er nach links wandert, ist zu erwarten, schließlich ist die Routine zwei Taktzyklen je Bildschirmzeile zu kurz. Warum aber verharrt er plötzlich, als ob ihn dort irgend­ein »Mann im Computer« festhielte?

Wieso der Farbbalken »hängt«

Die Erklärung liegt in einer Eigenart des ST begründet: Die CPU und MMU des ST teilen sich den Daten/Adreßbus. Daraus ergibt sich, daß es auf dem ST keine Befehle mit ungerader, das heißt nicht durch vier teilbarer Ausführungszeit gibt. Die MMU liest immer nur dann Daten aus dem Arbeitsspeicher und liefert sie an den Shifter, wenn auch Daten auf den Bildschirm kommen sollen. Während der Zeit, in der auf dem ST »Randzeit« herrscht, liefert die MMU von sich aus Nullbytes an den Shifter. Ein Zugriff auf die RAMs findet somit während dieser Zeit nicht statt, was bedeutet, daß die Befehle nicht mehr auf durch vier teilbare Ausführungszeiten aufgerundet werden.

Warum ich dies so lang und breit erkläre? Ganz einfach: In unserem Beitrag zum UNION-Demo fristen 18 verschiedene Funktionen ihr Dasein, die alle ganz unterschiedliche Ansprüche an die von ihnen benötigte Zeit und die Position innerhalb des völlig synchron ablaufenden Programmes stellen. Aus wohl begreiflichen Gründen war es völlig unmöglich, anhand all dieser Bedingungen ein Programm von Hand zu schreiben.

Kein Programm ohne Fehler

Man bedenke: Die Ränder können nur dann aufgeklappt werden, wenn zu ganz bestimmten Zeiten ganz bestimmte Befehle ausgeführt werden. Diese Befehle müssen sich also an fest vorgegebenen Stellen innerhalb des Programmes befinden (bezogen auf die aktuelle Position des Elektronenstrahls). Weiterhin gibt es Befehle, die nur vier Taktzyklen benötigen, andere wie­derum benötigen über hundert Taktzyklen. All dies vor dem Hintergrund, daß sich während der Programmierung praktisch unabwendbar Fehler einschleichen und man eventuell Teile komplett verwerfen muß.

Wie Sie sehen, ist dies eine für einen Programmierer praktisch unlösbare Aufgabe. Aber wozu gibt es schließlich Computer? Ich habe deshalb zu dem bereits im FSD verwendeten Trick gegriffen und ein Programm geschrieben, das seinerseits ein Programm schreibt und dieses Programm schließlich mit einem Assembler übersetzt und ausprobiert. Je Testlauf waren etwa 20 Minuten nötig. Schließlich ist es auch für einen Computer nicht ganz einfach, all diese Bedingungen zu beachten. Bei der Verwendung eben dieses Programmgenerators fiel mir auf, daß zum Beispiel ein CLR.L D0 meist die (aufgerundeten) acht Taktzyklen benötigte, manchmal jedoch weniger, nämlich die angegebenen sechs Taktzyklen.

Jetzt werde ich erklären, was zu tun ist, um auch den letzten, im wahrsten Sinne des Wortes linken Rand zu öffnen. Nachdem Gunter im letzten ST-Magazin die zugehörige Hintergrund-Story erzählt hat, werde auch ich sie nicht verschweigen und dabei nach Gunters »Wodka-Ideen« unser Image wieder zurechtrücken.

Mittlerweile sollte sich jeder Grafik-Programmierer auf dem tricktechnischen Stand (oberer Rand, unterer Rand, rechter Rand) befinden, auf dem wir uns befanden, als wir von TEX, TNT-Crew und Level 16 uns am 6.8.1988 in Udos (TEX) Keller trafen. Zu diesem Zeitpunkt war Michael von der TNT-Crew der einzige, der den linken Rand öffnen konnte, und dies lief auch nur auf Computern neueren Datums. Nach einigen Dosen Cola und ein paar Tüten Chips, von denen Jochen sich wieder ein­mal die meisten reingezogen hatte, war Michael dazu überredet, den kleinen Schönheitsfehler seiner Routine zu beseitigen — wie gesagt, sie lief nur auf Computern neueren Datums.

Nach einigen Stunden angestrengter Tüftelei war es geschafft: Es existierte ein Programm namens »L2TEST«, das auf den anwesenden Computern den rechten und den linken Rand verschwinden ließ.

Das »Erik-Gedenk-NOP«

Eins hatten wir jedoch nicht bedacht: Erik und seinen Neochrome-Computer. Bis jetzt hatte er es noch geschafft, seinen Computer vor unseren Angriffen zu bewahren. Nachdem wir ihn dort weggezerrt hatten und wieder eines seiner Bilder ins Nirwana geschickt hatten, gab es lange Gesichter: Rechts war der Rand weg, links jedoch trotzte er unseren Angriffen. Mit vereinten Kräften (ein paar hielten Erik fest, weitere saßen vor seinem Computer) entfernten wir auch dort den Rand. Deshalb taucht im anschließenden Listing, das dem entstandenen Programm »L2TEST2« stark ähnelt, das sogenannte »Erik-Gedenk-NOP« auf.

Nachdem auch der letzte Computer der anwesenden sieben dazu überredet war, die Existenz des linken Randes zu vergessen, stürzten wir uns auf die »jochensicher« untergebrachten restlichen Chips.

Nun aber zum Ergebnis unseres Treffens in Udos Keller: Leser des letzten Artikels erinnern sich vielleicht noch an Gunters Programm zum Öffnen des rechten Randes. Um nicht wieder das Rad neu erfinden zu müssen, habe ich mir sein Programm geschnappt und es erweitert.

Nehmen wir an, die Stelle in dem vorhin genannten Listing, an der der rechte Rand geöffnet wird, ist Taktposition 0. Nach dem zweiten MOVE.B ist somit Taktposition 16 erreicht (je MOVE.B acht Taktzyklen). Die kritische Taktposition ist somit Position 68: Dort wird auf Monochrom umgeschaltet. Nach­dem der Prozessor das »Erik-Gedenk-NOP« abgearbeitet hat, schalten wir auf Position 80 wieder zurück auf niedrige Auflösung mit 50 Hz. Danach hat die MMU ein wenig Ruhe vor uns. An Taktposition 140 schalten wir wieder auf Monochrom, diesmal aber sofort wieder zurück auf die niedrige Auflösung mit 50 Hz.

Aufgepaßt mit 71 Hz

Hier gleich eine dicke Warnung: Wer mit der Routine »spielt« und dabei die Zeit, während der Computer auf Monochrom geschaltet ist, eigenmächtig verlängert, riskiert seinen Monitor! Der »Notreset«, den der ST normalerweise bei solchem Tun ausführt, ist in dem Programm deaktiviert.

Wenn dort also auf 71 Hz geschaltet wird, dann schaltet der GLUE ohne Rücksicht um und besinnt sich erst dann wieder des Farbmonitors, wenn er es vom Programm gesagt bekommt. Die in dem abgedruckten Programm vorgenommenen Umschaltungen dauern jedoch maximal 1.5 Mikrosekunden und sind harmlos. Außerdem hat mein Atari-Monitor bereits eine 20sekündige Mißhandlung mit 71 Hz schadlos überstanden. Ganz so kritisch wie immer beschrieben, scheint die Sache wohl doch nicht zu sein, man sollte es aber nicht darauf ankommen lassen. Das große Geheimnis über die Grafik am Rand des ST ist somit gelüftet. Wer alle Folgen schön gesammelt hat, müßte jetzt in der Lage sein, Grafik auf allen Rändern darzustellen. Es gibt fünf Angriffspunkte:

1. Aufbrechen des rechten Randes: Dies geschieht so, daß der Befehl zur 60-Hz-Umschaltung links des ehemaligen rechten Randes liegt, die Rückumschaltung jedoch rechts davon. (Taktpositionen 0 und 8)
2. Schließen des rechten Randes: Dies ist bei älteren STs nötig. Tut man es nicht, stellen diese STs unverständlicherweise nur jede zweite komplette Plane dar. Dies war bei der TNT-Crew-Demo »Death of the left border« leider noch so. Es schaltet zuerst auf 70 Hz, nach der kurzen Verweilpause für Eriks Computer schaltet es wieder auf 50 Hz zurück (Taktpositionen 68 und 80).
3. Öffnen des linken Randes: Auch dort liegt der erste Befehl links des linken Randes, der zweite jedoch rechts davon. Es wird wieder zwischen 70 Hz und 50 Hz umgeschaltet. (Monitor verzeih!), (Positionen 140 und 148).
4. Öffnen des unteren Randes: Dies geschieht zu Beginn der Austastlücke der letzten normalen Bildschirmzeile. (Positionen 40 und 132.) Es wird zuerst auf 60 Hz, dann wieder auf 50 Hz zurückgeschaltet.

Hallo Softwareentwickler: Dazu sind ein Timer B auf Zeile 199 und 1.5 Prozent Rechnerzeit nötig. Möchte das jemand in einem Programm verwenden?

1. Öffnen des oberen Randes: Dies ist die gräßlichste Plackerei, die man sich nur vorstellen kann, dadurch ändert sich am ST fast alles, was mit der Bildausgabe zu tun hat. Wer diesen Rand öffnet, sollte darauf achten, daß es zwei Stellen gibt, wo abhängig von der im Computer eingebauten MMU umgeschaltet werden muß. Die Stellen liegen relativ zur ehemaligen ersten Zeile auf den Zeilen 284 und 300. (Taktposition 116 auf 60 Hz, bei Position 156 auf 50 Hz.) Wichtig: Ein installierter Timer B startet danach 13/29 Zeilen früher, wenn man den oberen Rand per Interrupt öffnet. Dies führt zu Synchronisationsproblemen im Programm. Der Rand öffnet sich dann nämlich nur jedes zweite Bild!

Wer keine alten Listings zum Entfernen des oberen Randes hat, sollte es sich unbedingt besorgen, da es wirklich nicht einfach ist, diesen Rand zu entfernen. Selbst jetzt, wo ich weiß, was zu tun ist, hat die Öffnung des oberen Randes noch einmal sechs Stunden Tüftelei und eine Literflasche Cola (nein, die Marke verrate ich nicht) gekostet. Für alle diejenigen, die es auf die schnelle einmal ausprobieren möchten (für alle STs): Im VBL muß möglichst früh auf 60 Hz geschaltet werden, im ersten Timer B Interrupt dann wieder zurück auf 50 Hz. Der obere Rand müßte dann auf allen STs provisorisch aufklappen, meist ist das Bild dort allerdings verzerrt, da der Monitor infolge der großzügigen Umschaltung nur noch mangelhaft synchronisiert. Damit genug für heute. Bis zum nächsten Mal... ?

Listings zu dem Artikel

(Tarik Ahmia/tb)

---

---