Die Hexer (Teil 1)
Willkommen zum ersten Teil unserer neuen Serie, die eine Gruppe der besten ST-Programmierer verfaßt hat. »The Exceptions«, oder auch kurz TEX, machten sich mit einer Reihe von Demo-Programmen einen Namen, die schier Unglaubliches aus dem ST herausholen. Jeder Teil dieser Serie versucht Ihnen auf unterhaltsame Weise das wichtigste Kapitel aus der Evolution der mittlerweile fünf Demos zu vermitteln und gibt viele Profi-Programmiertips preis.
Diesmal: Erste Erfahrungen zweier Unbedarfter mit dem ST, sowie Theorie und Praxis von horizontalem Soft-scrolling auf einem Computer, der dafür nicht gerade gebaut wurde.
Nützlich sind Grundkenntnisse in Assembler und über den Grafikaufbau des ST.
THE EXCEPTIONS, eine Gruppe von ST-Freaks, die durch ausgetüftelte Programmiertricks bekannt wurde, begrüßen Sie zu einer Expedition in die Tiefen des STs. Wir möchten mit Ihnen einen Streifzug durch die Hardware dieses Computers unternehmen, seine Stärken und Schwächen kennenlernen, sowie seine Grenzen erkunden und diese Grenzen durchbrechen!
In loser Folge gehen wir auf folgende Themen ein: Horizontales Softscrolling, flackerfreie Rasterinterrupts (das heißt unter anderem mehr als 16 Farben gleichzeitig auf dem Bildschirm), Prinzipien der Musikprogrammierung, grafische Tricks und Kniffe (Anti-Aliasing, Transparenteffekte etc.) und das Darstellen von Grafik im Bildschirmrand. Damit das Ganze nicht zu trocken wird, wollen wir die Serie mit einigen Anekdoten aus dem Leben sogenannter »Cracker«, wie man uns manchmal auch nennt, auflockern. Manche von Ihnen haben vielleicht eines unserer Demoprogramme gesehen, die uns in den Kreisen der ST-User eine gewisse Bekanntheit eingebracht haben. Diese Demos zeigen, jedes zu seiner Zeit, einige Effekte, von denen behauptet wurde, sie seien auf dem ST nicht zu programmieren. Doch bekanntlich reizt sowohl das Verbotene als auch das Unmögliche. Und so führte der Zufall einige Leute zusammen, die sich vornahmen, der Hardware des ST das Fürchten zu lehren. Lassen Sie mich Ihnen diese Leute und ihre »Künstlernamen« kurz vorstellen: Unsere Assembler-Programmierer Udo, Gunter und Michael haben sich die Kürzel -me-, 6719 und Daryl zugelegt, sie sind Spezialisten für Rasterinterrupts, Scrolling und ge-schwindigkeitsoptimierte Maschinenprogramme. Jochen (Mad Max) stürzt sich mit Vorliebe auf den Soundchip und entlockt diesem zugegebenermaßen veralteten Bauteil Töne, die seine Entwickler bestimmt nicht für möglich gehalten hätten. Der Schreiber dieser Zeilen heißt Erik (Es), meine Spezialität sind Grafik und das Ausdenken von Effekten, die von den Obengenannten programmiert werden sollen und bei ihnen im geringsten Fall entsetztes Stöhnen auslösen. THE EXCEPTIONS bestehen außerdem noch aus drei weiteren Leuten, die sich ÄFF (Axel), Martin Fry (Markus) und Dr. Byte (Garsten) nennen, allerdings arbeiten sie nicht an den Artikeln dieser Reihe mit.
Wie kommt man eigentlich als »normaler« ST-User dazu, sich einen dieser ulkigen Decknamen zuzulegen und sich in mehr oder weniger gern gesehenen Aktivitäten zu ergehen? Für diejenigen, die es interessiert, und die sich an ihren eigenen ersten Kontakt mit dem ST zurückerinnern möchten, hier nun ein kleiner Abriß aus unserer Entstehungsgeschichte, die schließlich bis zum ersten TEX-Demo führte (alle anderen mögen sich getrost auf das Listing auf Seite 82 stürzen).
Begonnen hat alles, wie könnte es anders sein, auf dem guten alten C 64. Damals saßen zwei Leute, Udo und meine Wenigkeit, hinter dem Brotkasten, und nicht anders als heute rückte Udo der Hardware in Assembler zu Leibe, während ich mich mehr für die grafischen Fähigkeiten des Gerätes interessierte. Die Sache machte Spaß, Erfolgserlebnisse blieben nicht aus. 1985 begann sich dann aber eine neue Computergeneration am Horizont abzuzeichnen. Jede Neuigkeit über die brandneuen 68000-Computer wurde von uns aufmerksam verfolgt. Und wir begannen... 68000-Assembler zu programmieren. Wie das, fragen Sie vielleicht, ohne einen Amiga, Mac oder ST? Ganz einfach: auf dem C 64! Nur wenigen bekannt, erschien damals ein 68000-Simulator auf dem kleinen Commodore (kein Witz!). Auf diesem Programm, es enthielt Assembler und Simulator, unternahmen wir die ersten Schritte auf dem neuen Prozessor. Kurz darauf erfuhren wir, daß jemand in unserer Nähe das Kleingeld für einen Atari ST aufgebracht hatte (Hallo, Heinz! Viel Glück in Stuttgart!). Das Resultat waren einige Pilgerfahrten zu einem Computer, der mit hoher Auflösung, 512 KByte RAM, 360-KByte-Laufwerk und einem superschnellen Prozessor das Nonplusultra zu sein schien. Verständnisvoll blickten wir über das kaum vorhandene Softwarerepertoire hinweg, schließlich war dies ein neuer Computer und überdies gab es doch schon einiges zu bestaunen: zum Beispiel eine luxuriöse Benutzeroberfläche, Fenster und Menüs wohin man sah, es war toll (haben Sie eigentlich schon einmal 'OPEN 1,8,15, "N: NAMEJD"' getippt, um eine Diskette zu formatieren?). Ferner eine Textverarbeitung mit nie gekannter Darstellungsqualität, nicht die schnellste, aber schließlich in einer Hochsprache programmiert! Mit Logo konnten auch wir auf diesem Computer nicht viel anfangen. Aber natürlich gab es ein Basic, auf das wir uns sofort stürzten. Nach dem Laden herrschte kurze Verwirrung, aber als wir ein schnell geschriebenes Liniendemo durch den Fensterdschungel gebracht hatten, herrschte Begeisterung: Selbst die älteste ST-Basic-Version konnte einen Freak mit ihrer Geschwindigkeit verblüffen. Was lag also näher, als die erworbenen Maschinensprache-Kenntnisse praktisch zu erproben? Kein Assembler weit und breit, also wurde eine kleine Routine per Hand in Opcodes verwandelt. Ohne durch Kenntnisse wie Speicheraufteilung oder ähnliches behindert zu sein, POKEten wir unser Programm ins RAM und hatten sofort ein Schlüsselerlebnis: Es erschien eine Reihe ausdruckskräftiger Atompilze auf dem Bildschirm, nicht gerade geschmackvoll, aber ganz der Situation entsprechend. Es folgte das Austesten verschiedener Speicherbereiche nach der Methode: TOS booten, Basic laden, BUMM! Wir vergnügten uns so eine Weile, als Udo auf die glorreiche Idee kam, nach dem noch freien Speicherplatz zu fahnden. Ein PRINT FRE(O) brachte Stimmung in unsere Runde: entsetzte Schreie und die Worte »11720 Bytes?« hallten durchs Haus. Was war mit dem gigantischen Speicherplatz geschehen? Wer die Größe des TOS und des ST-Basics kennt, kann es sich leicht ausrechnen. Das taten wir dann auch und verzogen uns mit unserer Routine knapp vor den Bildschirmspeicher, den wir durch wildes Umherpoken (BUMM!) gefunden hatten. Und da lief es nun: unser erstes Assembler-Programm! Es sollte den Bildschirmspeicher mit der Zahl $FFFF füllen. Der Bildschirm füllte sich jedoch nicht, sondern er war ganz einfach gefüllt, nachdem wir das Programm starteten. Wir schauten uns an, und unsere scharfsinnige Schlußfolgerung lautete: »Dieser Prozessor muß schnell sein!«. Fortan schrieb und assemblierte Udo seine Programme auf dem C 64 und tippte sie am Wochenende in Heinz's ST, der sich solchen Zudringlichkeiten durch reges Pilzeschleudern vergeblich zu entziehen suchte.
Dann kam die CeBIT '86, der ST rückte preismäßig in greifbare Regionen, während man für unseren anderen Kandidaten, den Amiga, über 6000 Mark verlangte. Damit nahm man uns die Entscheidung ab: Im Frühjahr '86 legten sich Udo und ich einen ST zu, er zunächst mit monochromen, ich mit Farbmonitor, denn seit ich in einem Computerladen das erste Mal mit »Neochrome« gespielt hatte, wußte ich, daß der ST mein Computer war. Wir machten uns langsam mit den Maschinen vertraut, und da Udo den K-Seka-Assembler mit dem Computer gekauft hatte, konnte das Programmieren auf dem ST losgehen. Der K-Seka-Assembler war ein wahrer Segen für uns, denn wir wollten kleine Programme austesten, ohne dafür in einem Editor ganze Romane zu deklarieren, vom Assembler Fehlermeldungen abzuschreiben und uns danach von einem Linker linken zu lassen. Ganz zu schweigen davon, daß es komfortablere Methoden des Debugging gibt, als Bömbchen zu zählen. Trotz zahlreicher Fehler war auch das gerade erschienene Buch »ST-Intern« von Data Becker eine unentbehrliche Hilfe: Die Jagd auf die Hardware konnte beginnen!
Während ich mich an kleinen Maschinenroutinen versuchte, und ansonsten hauptsächlich die Grafikfähigkeiten des Gerätes erforschte, ging Udo gleich in die Vollen. Rasterinterrupts und Softscrolling waren schon auf dem C 64 seine Lieblingsdisziplinen, warum sollte das nicht auch mit dem ST gehen?
Über das Abenteuer Rasterinterrupts berichten wir das nächste Mal, deswegen werfen wir in dieser Folge nun einen näheren Blick auf das Scrolling, das ein wichtiges Feature unseres ersten Demos ist. In diesem Demo läuft unter anderem ein Text von rechts nach links durch den Bildschirm. Wir verwenden einen selbstdefinierten Zeichensatz, jedes Zeichen ist 32 x 32 Pixel groß. Dank der »Softscrolling«-Routinen, die wir im folgenden beschreiben, ist die Bewegung fließend und flackerfrei. Die Routine läuft allerdings nicht in Schwarzweiß.
Was ist unter dem Begriff »Scrolling« eigentlich zu verstehen? Grundsätzlich läßt sich sagen, daß damit das Verschieben des Bildschirminhaltes in eine bestimmte Richtung gemeint ist, seien es nun Buchstaben oder Grafik (was beim ST bekanntlich sowieso das gleiche ist). Scrolling ist eine Kurzform der Begriffe »Screen-Roll«. Wenn Sie zum Beispiel ein Listing über den Bildschirm laufen lassen, scrollt dieses nach oben. Die nächste Stufe bildet das sogenannte »Softscrolling«. Das Bild verschiebt sich ruhig, ohne zu ruckein oder zu flackern. Dieses »weiche« Scrolling wird durch drei Faktoren erreicht. Einmal darf der Abstand von einem Bewegungsschritt zum nächsten nicht allzu groß sein. Die wesentlich wichtigeren Einflüsse sind aber folgende (sie gelten übrigens für alle bewegten Grafiken, also auch zum Beispiel für Shapes, die über den Schirm laufen): Von einem Scrollschritt zum nächsten darf nie mehr Zeit als 1/50 Sekunde vergehen. Das ist die Bildfrequenz Ihres Monitors, also die Zeit, die der Elektronenstrahl der Bildröhre braucht, um ein Bild auf die Mattscheibe zu schreiben. Braucht Ihr Programm mehr als %o Sekunde, um die zu verschiebende Grafik zu bewegen, passiert etwas ähnliches, als wenn Ihr Monitor das Bild zu langsam aufbauen würde: das Bild beginnt zu flackern, zu ruckein. Denken Sie zum Vergleich an einen zu langsam laufenden Filmprojektor. Dem menschlichen Auge läßt sich bei weniger als zirka 50 Bildern pro Sekunde keine fließende Bewegung mehr vortäuschen.
Zum perfekten Scrolling müssen Sie außerdem beachten, daß in dem Moment, in dem Sie die Grafik bewegen, diese nicht gerade vom Elektronenstrahl auf den Bildschirm geschrieben wird. Die Folge wäre, daß Ihr Monitor zum Teil noch die »alte« Grafik darstellt, während Ihr Programm schon den Bildschirmspeicherinhalt verschiebt. Man sagt zu diesem störenden Effekt auch »der Strahl läuft durch das Scrolling«. Soweit also zur Theorie.
Mehr Grundlagen zur Funktionsweise eines Monitors finden Sie in dem auf Seite 84 folgenden Artikel.
Softscrolling im Überblick: Bitweises Scrolling erweist sich als Bremsklotz. The Exceptions verschieben die Grafik deshalb wonweise in 8 Pufferspeichern.
Unsere praktischen Versuche auf dem ST verliefen zunächst eher enttäuschend. Scrolling in vertikaler Richtung klappte recht gut, in horizontaler Richtung schlugen die ersten Versuche jedoch fehl. Der Grund dafür liegt im Grafikaufbau des ST: hintereinanderliegende Speicherwörter bilden die Bitmap. Möchte man das Bild, oder einen Teil davon, um 1 Pixel nach oben oder unten verschieben, genügt es, einen Speicherblock wortweise zu verschieben (l Wort sind 2 Byte = 16 Pixel). Der 68000 ziert sich in einem solchen Fall nicht lang und erledigt diese Aufgabe mit seiner berühmten Geschwindigkeit. Das erklärt übrigens auch, warum es so viele Ballerspiele mit vertikalem Scrolling auf dem ST gibt. Warum aber äußerst wenige Programme mit horizontalem Scrolling auf dem Markt sind (Hallo, Steve Bak!), hat einen einfachen Grund. Soll nämlich Grafik um weniger als ein Wort (16 Pixel) nach links oder rechts bewegt werden, so muß man die Bits der Speicherwörter verschieben und das kostet auch den 68000 zuviel Zeit, wenn man mehr als nur ein paar Zeilen scrollen will. 32 Zeilen sind zwar noch zu bewältigen, aber es bleibt keine Prozessorzeit übrig, um Shapes und anderes zu verwalten. Man sollte also die bitorientierten Operationen so gering wie möglich halten. Aber wie das? Schließlich wollen wir mehr als nur einen kleinen Teil des Bildschirms horizontal softscrollen, und dabei soll noch möglichst viel Zeit für andere Aufgaben (zum Beispiel bewegte Objekte) übrigbleiben.
Don't panic!
Udo hat vor unserem ersten Demo (so ein Zufall) eine Lösung gefunden und erklärt sie nun ausführlich:
Hallo, hier ist Udo.
Damit meine Erklärungen zum Softscrolling nicht nur Theorie bleiben, finden Sie dazu auf Seite 82 ein abtippfertiges, voll dokumentiertes Assembler-Listing, das nur auf Farbe läuft.
Die ersten Versuche gingen vom einfachen bitweisen Verschieben der Speicherwörter aus und waren so langsam, daß ich sofort Überlegungen zu einer neuen Methode anstellte. Ich schrieb die Bit-Verschieberoutine auf Papier und zählte die Taktzyklen zusammen. Ein Blick ins 68000-Assembler-Buch, ein wenig Knobelei und ich wußte, wie ich das entsprechende Ergebnis mit anderen Befehlen schneller erreichte. Aber auch diese Optimierung stieß schnei! an ihre Grenzen.
Ich mußte deshalb einen ganz anderen Weg gehen, eine neue Programmlogik mußte her:
Das bitweise Verschieben ist der Bremsklotz in meiner Routine, etwas schneller ist byteweises Verschieben und, wegen des Grafikaufbaus am allerschnellsten, ist wortweises Verschieben. Dies wären jedoch 16 Pixel auf einmal, und das ist zum Lesen zu schnell und ruckelt wegen des großen Verschiebewertes. Also blieb nur der Ausweg acht Puffer zu benutzen, in denen die Grafik jeweils um 2 Pixel verschoben ist, und diese nacheinander anzuzeigen. Nach der Anzeige des letzten Puffers wird der erste Puffer um ein Speicherwort verschoben, und die nun um 16 Pixel verschobene Grafik paßt nahtlos an den achten Puffer.
Das Kopieren des Puffers in den Bildschirm benötigt auch einige Zeit, so daß bis zu 50 Zeilen nach dieser Methode gescrollt werden können (über die nachzuschiebenden Daten reden wir später). Um sich die Zeit des Puffer-Kopierens zu sparen, kann man auf acht Bildschirmen arbeiten und die Bildschirmadresse jeweils entsprechend verschieben. So lassen sich zwar bis zu 100 Zeilen scrollen, aber 256 KByte Speicher sind dann allein für das Scrollen belegt.
Nun zum Problem des Datennachschubs. Wir müssen die in unserem Falle von rechts nachgeschobenen Daten in jedem Fall bitweise verschieben. Die Daten kommen in acht andere Puffer, aus denen der jeweilige Scrollpuffer seine Speicherworte holt, um sie rechts anzufügen. Die Vorbereitung der acht Zusatzpuffer (bei denen wir ja nur zwei Speicherworte bitweise verschieben) dauert genauso lange wie das wortweise Verschieben eines Puffers, einschließlich des Hineinkopierens in den Bildschirm. Daran läßt sich schon sehen, wie langsam bitorientierte Operationen sind. Ein weiterer Trick besteht in der Art des Verschiebens: Da ja nicht nur das nächste Speicherwort, sondern auch schon das übernächste sichtbar werden kann, müssen dessen Daten nachgeschoben werden. Hier wird nicht mehrmals einzeln geschoben und das im Carry-Flag erhaltene Bit nachgeschoben, sondern es wird das übernächste Wort in die obere Langworthälfte eines Registers geladen, das nächste in die untere Langworthälfte und dann um den entsprechenden Faktor nach links rotiert. Dabei schließen die Bits vom übernächsten Wort automatisch rechts an das nächste Wort an (die Grafik verdeutlic^ diesen Zusammenhang).
Hier nun ein allgemeiner Überblick über unser Programm auf Seite 82:
Zur Vorbereitung baut es eine Tabelle auf, die für jedes Zeichen einen Zeiger enthält. Die Zeichen unseres ersten Demos sind in unserem Falle 32 auf 32 Pixel groß und wurden mit Neo-chrome gemalt. In den ersten 32 Bildschirmzeilen befinden sich also die ersten zehn Zeichen und so fort. Später steht in unserem Text nur noch die darzustellende Zeichennummer.
Danach müssen wir nur noch die Höhe in »zanz« eintragen und unsere Routine in die Interruptstruktur des ST einbauen. Unsere Interruptroutine führt einen internen Zähler, anhand dessen der ST festlegt, welcher Puffer angezeigt und welcher zur Anzeige vorbereitet wird. Je nachdem verzweigt der ST in ein entsprechendes Unterprogramm. Die Unterprogramme l bis 7 sind identisch mit den Unterprogrammen 9 bis 15. Sie übergeben nur die Adressen der jeweiligen Puffer und führen dann die Anzeige und das Verschieben aus. Routine 0 und 8 müssen jedoch auch noch die Nachschubpuffer vorbereiten, wobei Routine 0 das nächste anzuzeigende Zeichen holt, auswertet und die entsprechenden Zeiger einrichtet. Dann werden die Nachschubpuffer geshiftet. Routine 8 übernimmt die entsprechenden Zeiger und shiftet die Nachschubpuffer für die zweiten 16 Pixel.
Die Routine »linksw« verschiebt einen Puffer um 16 Pixel, also einem Speicherwort (2 Bytes) nach links und hängt rechts die 16 Pixel vom geshifteten Nachschubpuffer an. Die Routine »show« kopiert den entsprechenden Puffer in den sichtbaren Bildschirm. Die Routine »addpuff« bereitet alle Nachschubpuffer vor, wobei die Routine durch den oben erwähnten Trick optimiert ist.
Ich habe diese Technik in dem Assembler-Listing eingesetzt, das im K-Seka-Format vorliegt. Wenn Sie also etwas Lust zum Experimentieren haben und das Softscrolling in der Praxis sehen möchten, können Sie sich direkt an die Arbeit machen.
Haben Sie die Routine fertig assembliert, benötigen Sie nur noch eine Grafikseite mit den entsprechenden Zeichen, und schon kann es losscrollen.
Und so waren, zusammen mit den Rasterinterrupt-Effekten, die Voraussetzungen geschaffen, eines dieser Demoprogramme zu schreiben, wie Sie bei Crackern auf dem C 64 gerade in Mode kamen. Also malte ich ein Bild und einen Zeichensatz, und Udo erweckte das Ganze zu buntem Leben. Da wir damals unseren Soundprogrammierer Jochen noch nicht kannten, kam die Musik aus dem Spiel »Exten-sor« zu der zweifelhaften (?) Ehre, unser erstes Demo mit Klängen zu unterlegen. Natürlich brauchten wir nun auch einen klangvollen Namen, der »Tradition« solcher Programme entsprechend. Nach einigem Grübeln nannten wir beide uns schließlich »The Exceptions«, denn erstens hatte dieser Name etwas mit 68000-Maschinen-sprache zu tun, zweitens waren wir zumindest in der Hinsicht »Ausnahmen«, als wir so gut wie keine Programme geknackt hatten und uns auch sonst alle Verbindungen zur damals gerade entstehenden »Szene« fehlten. Außer etwas lokalem Ruhm brachte uns dieses Demo auch nicht sonderlich viel, mit ein paar Ausnahmen: Erfahrung, Know-how und Spaß!
Ein fertiges TEX-Demoprogramm steht kostenlos in der M & T Mailbox im Public-Directory bereit.
Weiter geht es in der nächsten Ausgabe mit der Entstehung des zweiten Demos und der Programmierung von mehr als 16 Farben gleichzeitig durch Rasterinterrupts. Ich hoffe, es hat Ihnen Spaß gemacht (am)