The Thalion Source - Die Hexer -

Willkommen zum ersten Teil unserer neuen Serie, die eine Gruppe der besten ST-Programmierer verfasst 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 Softscrolling 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 STs 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 geschwindigkeitsoptimierte 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 (Carsten) 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: NAME ID"' 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(0) 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 ruckeln 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 1/50 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 ruckeln. 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.

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 STs: 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 (1 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.

Udo hat vor unserem ersten Demo (so ein Zufall) eine Lösung gefunden und erklärt sie nun ausführlich:

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ß schnell 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.

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 Neochrome 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 STs 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 1 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 "Extensor" 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-Maschinensprache 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.

Im vergangenen Monat verrieten uns die Programmierzauberer der "Exceptions" einiges über Softscrolling auf dem ST. Erik und Udo klären uns im zweiten Teil der TEX-Serie über die Theorie und Praxis der flackerfreien Rasterinterrupts auf. Ihr abtippfertiges Listing liefert durch die geschickte Steuerung des Elektronenstrahls Dutzende Farben gleichzeitig.

Hallo, liebe Demofreaks und Maschinenprogrammierer, hallo lieber Leser ! Hier sind wir also wieder zu einer weiteren Plauderstunde versammelt. Haben Sie die letzte Folge gut überstanden, und gleiten nun die Buchstaben butterweich über Ihren Bildschirm ? Oder haben Sie Ihren ST wutentbrannt zum (geschlossenen) Fenster hinausgescrollt ? Wie dem auch sei, heute geht es gnadenlos mit dem zweiten Teil weiter: Stürzen wir uns in die wunderbare Welt der Rasterinterrupts ! Doch wie in der letzten Folge möchte ich Ihnen auch heute ein paar Anekdoten aus der "Entstehungsgeschichte" unseres merkwürdigen Vereins berichten. Stöhnen Sie nicht, schließlich beschreibe ich nun einige folgenschwere Ereignisse, die dazu führten, dass Udo und meine Wenigkeit jemanden kennenlernten, der sich "Mad Max" oder besser Jochen nennt. Heute ist er, in aller Bescheidenheit, einer der besten (oder der beste ?) Soundprogrammierer auf dem Atari ST.

Begonnen hat die ganze Sache mit Jochen (und dem zweiten Demo) in den Verkaufsräumen eines Mannheimer Computergeschäftes. Dort unterhielt ich mich mit einem Menschen namens Sascha, das Gespräch drehte sich natürlich um, ähem, Raubk..., nein, wir sprachen über dezentralisierte Sicherheitskopien, deren Anfertigung uns beiden sehr am Herzen lag. So fuhr ich hin und wieder zu dem Treffen einiger ST-Fans nach Ramsen, einem Dorf, das noch weiter in der Provinz liegt, als unser Heimatkreis Bad Dürkheim. Die Zusammenkünfte fanden bei unserem späteren Mitprogrammierer Michael ("Daryl") statt. Ab und zu ließ sich dort ein langhaariger Bursche blicken, der zwar noch nicht im Besitz eines ST war, sich jedoch sichtlich für das Gerät interessierte. Tolle Geschichten wurden mir von ihm erzählt: Obwohl damals erst 15 Jahre zählend, hatte er auf dem C 64 die Musikroutine des Soundspezialisten Rob Hubbard schon soweit im Griff, dass er eigene Melodien in ihr abspielen konnte. An seiner Schule gelangte Jochen zu erstem Ruhm, indem er den Computerarbeitskreis mit "Rock-Versionen" verschiedener Weihnachtslieder verblüffte. Als auch er einige Zeit später im Besitz eines Ataris war, bestürmten wir ihn sofort, ob er es nicht auch auf dem ST mit der Musikprogrammierung versuchen möchte. Seine lapidare Antwort lautete: "Warum nicht ?". Nach einer Weile zeigten sich tatsächlich die ersten Erfolge. Wie ich später von ihm erfuhr, hatte Jochen den ST auf eine Weise erforscht, die sich nur als abenteuerlich bezeichnen lässt. Ohne durch Bücher über die Hardware des "Sixteen-Thirtytwo" abgelenkt zu sein, bekam er fast alle für die Musikprogrammierung wichtigen Register heraus und begann mit ihnen zu experimentieren. Schon bald hörte man aus dem winzigen Zimmer, in dem sich nun auch Udo bei den "Treffs" drängelte, verblüffend wohlklingende Töne. Bis dahin wurden die ST-Freunde nämlich nicht gerade von guten Sounds bei Spielen oder Musikprogrammen verwöhnt. Wir waren begeistert. Und von nun an zu dritt: Jochen war als Musikspezialist bei TEX mit dabei.

Der Gedanke an ein neues Demo tauchte in unseren Köpfen auf, ein Demo mit mehr Bewegung auf dem Bildschirm, noch mehr Farben und eigener Musik. Als Rob Hubbard-Fan machte sich Jochen an das Unmögliche und setzte einige C 64-Musikstücke auf den ST um. Damals war die Methode noch recht mühsam, stundenlanges Umrechnen und Eintippen ausgedruckter Lieder waren vonnöten. Eines Nachmittags trafen wir uns dann bei Jochen, bürgerten seine Schwester aus dem gemeinsamen Zimmer aus und begannen mit dem Zusammensetzen des zweiten Demos. Grafik wurde entworfen, Routinen aufeinander abgestimmt und Notentabellen eingetippt. Die fieberhafte Arbeitswut unterbrach lediglich das hastige Verschlingen einiger (nicht sehr guter) Pizzen und das gelegentliche Erscheinen der Hauskatze auf unseren Tastaturen. Jochen tippte gerade den Soundtrack zum 64'er-Spiel "Thing on a Spring" ein, als er mich aufforderte, ebenso wie für die anderen Lieder, ein Logo zu malen. Das war vielleicht so gegen 2.00 Uhr. Nachts. Ich tat es. Und das ist der Grund dafür, dass im zweiten TEX-Demo ein einsamer Grafikblock vor sich hin gammelt, der niemals das Licht der Mattscheibe erblicken wird, denn wie Sie sicher erraten haben (oder kennen Sie gar unser "Zweites" ?), bekamen wir "Thing on a Spring" im Gegensatz zum Logo nicht rechtzeitig fertig. Warum ? Nun, die Morgensonne schien mittlerweile direkt auf unsere Monitore und außerdem waren wir, wer hätte es geglaubt, MÜDE ! Torkelnd machten sich Udo, Michael und der Chronist dieser Begebenheiten auf den Heimweg. Glücklich murmelten wir etwas von "Endlich fertig !", "Gute Musik" und "Alle Raster stehen".

Ja, da sind sie wieder, die geheimnisvollen "Rasterinterrupts". Schließlich besteht so ein Programm nicht nur aus Musik, sondern soll auch optisch einige außergewöhnliche Effekte bieten. Und was würde sich mehr dazu eignen, als eine Grafik mit mehr als den normalen 16 Farben gleichzeitig, die sich normalerweise darstellen lassen ? Zuerst wollen wir uns aber erst das Prinzip der Rasterinterrupts anschauen. Wie Sie sicher wissen, ist ein "Interrupt" ein Signal von den Bausteinen eines Computers, das den Prozessor dazu veranlasst, die normale Programmabarbeitung zu unterbrechen und an einer bestimmten Adresse in eine Routine zu springen. Danach kehrt der Prozessor wieder in das "normale" Programm zurück. Ein Rasterinterrupt ist nun ein Interrupt, der ausgelöst wird, wenn der Elektronenstrahl des Monitors (den ja der Computer steuert) eine bestimmte Zeile auf dem Bildschirm erreicht. Wenn Sie nun den Rasterinterrupt in ein kleines Programm springen lassen, das zum Beispiel die Rahmenfarbe ändert, können Sie irgendwo im Bild eine neue Rahmenfarbe erzeugen. Sie müssen nur noch darauf achten, am oberen Bildrand wieder die alte Rahmenfarbe zu setzen, und schon haben Sie zwei Rahmenfarben statt nur einer auf dem Schirm. Da die Umschaltung immer in der gleichen Zeile stattfindet, entstehen zwei gleichbleibende Farbregionen. Die Methoden einen Rasterinterrupt zu erzeugen sind von Computer zu Computer verschieden. Beim C 64 sorgt der Videochip für einen geeigneten Interrupt, man braucht ihm nur die gewünschte Zeile mitzuteilen; beim Amiga ist ein Coprozessor namens Copper für diese (und andere) Aufgaben da. Unser guter ST geht da ein wenig anders vor.

Der Shifter, seines Zeichens für die Bilddarstellung verantwortlich, ist doof wie Stroh. Will heißen, dass bei ihm nicht viel vorhanden ist, was bei unserer Aufgabe hilfreich ist. Zwar befinden sich dort einige Register, die die augenblicklich dargestellte Videoadresse beinhalten, aber wir müssten diese andauernd abfragen, um an einer bestimmten Strahlposition zu reagieren. Bingo. Schließlich sollen uns die zusätzlichen Farben so wenig Rechnerzeit wie möglich kosten. Schauen wir uns also nach anderen Interruptquellen um. Wie wäre es denn mit den sogenannten Timern ? Von denen hat der ST vier Stück, und jeder kann nach Herzenslust Unterbrechungen auslösen. Am schlauesten stellt sich dabei der Timer B an. Ihm können wir einen Zähler übergeben, der diesen dann gemütlich dekrementiert, also immer um eins vermindert. Gelangt der Wert bei Null an, löst der Timer B über den MFP (Multi Function Peripheral Chip) einen Interrupt aus. Der Witz bei der ganzen Sache ist, dass der Zähler immer dann dekrementiert wird, wenn der Monitor eine Bildschirmzeile auf die Mattscheibe geschrieben hat. Übergeben wir also zum Beispiel als Zähler "100", so wird exakt 100 Bildschirmzeilen später ein Interrupt ausgelöst. Praktisch, nicht wahr ? Wenn wir nun noch unseren Zähler am oberen Bildrand immer wieder auf seinen Ausgangswert setzen könnten, ließe sich an jeder beliebigen Stelle des Bildschirms der begehrte Rasterinterrupt auslösen. Nun, das macht uns der ST ausnahmsweise einmal einfach. Es gibt den sogenannten "VBL" (Vertical Blank), der regelmäßig dann ausgelöst wird, wenn der Monitor ein neues Bild zu schreiben beginnt (in Farbe 50- oder 60mal in der Sekunde). Dieser Interrupt wird im ST und bei vielen Anwendungen gern benutzt, um regelmäßig anfallende Aufgaben zu bearbeiten. Wenn wir dort, möglichst vor allen anderen VBL-Routinen, unseren Zähler neu setzen, sind wir am Ziel: Unser Rasterinterrupt "steht".

Da wir schon so weit sind, sollte es klar sein, dass wir natürlich nicht nur eine lächerliche Rahmenfarbe umschalten. Die Perspektiven sind fast unbegrenzt. Einige Beispiele: Setzt man nach dem ausgelösten Interrupt den Zähler neu, lassen sich selbstverständlich mehrere Rasterinterrupts erzeugen. Das funktioniert bis zur Zeile 199 (vorerst einmal) und bitte nicht vergessen, nach dem VBL, also am oberen Rand, den ersten Zähler und die erste Farbpalette wiederherzustellen. Es lassen sich, logo, alle 16 Farben auf einmal umschalten. Aber auch die beiden Farbauflösungen (320 x 200, 640 x 200 Punkte) lassen sich mit diesem Trick gleichzeitig darstellen, wie die berühmten Adventures von "Magnetic Scrolls" zeigen (The Pawn, Jinxter u.a.). Ein weiterer Weg, den Shifter zu quälen, ist das Wechseln der Bildfrequenz mitten im Bild. Dabei entstehen lustige Effekte, die wir aber erst in unserer letzten Folge ausführlich erklären wollen.

Vorerst einmal freuen Sie sich über das theoretische Wissen, wie man "Raster setzt". Dieser Freude mischen wir gleich einen Wermutstropfen bei. Denn Rasterinterrupt ist nicht gleich Rasterinterrupt. Nein, die Trennungslinie zwischen zwei Farbpaletten muss absolut stillstehen und nicht durch das geringste Flackern das Auge des verwöhnten Betrachters beleidigen. Wie ein solches Flackern entsteht, ist leicht einzusehen. Stellen Sie sich vor, Sie haben in einer Zeile einen Interrupt ausgelöst, um beispielsweise die Rahmenfarbe zu wechseln. Zwei Dinge können Ihren "Raster" stören: Entweder wird Ihre Routine von einem höherwertigen Interrupt unterbrochen. Das führt zum Flackern um mehrere Zeilen. Wird die Interruptroutine in Ruhe gelassen, braucht es nach dem Auslösen des Interrupts eine gewisse Zeit, bis der ST Ihr Programm überhaupt abarbeitet. Je nach Programmierung dauert es auch ein Weilchen, bis der Befehl an der Reihe ist, der die Rahmenfarbe neu setzt. In der Zwischenzeit wandert der Elektronenstrahl jedoch weiter und das Umschalten von einer Farbe zur nächsten kommt in den sichtbaren Bereich des Bildschirms. Wie Sie diese unschönen Effekte vermeiden, und was man alles durchmacht, bis alle Schwierigkeiten beseitigt sind, erzählt Ihnen nun Udo.

Wie Erik uns eben erklärte, verwöhnt uns der ST nicht gerade bei der Programmierung von Rasterinterrupts. Dennoch gibt es auf dem ST drei Wege eine Farbumschaltung zu realisieren: Wir übernehmen die Kontrolle des horizontalen Strahlrücklaufs, des vertikalen Strahlrücklaufs und des MFP. Dazu noch einige Erklärungen: Der MC 68000 besitzt verschiedene Interrupt-Prioritäten. Ein Interrupt niedriger Priorität lässt sich durch einen Interrupt höherer Priorität unterbrechen. Im ST gibt es drei Prioritätsebenen mit den Werten 2, 4 und 6.

Die Methode über den VBL ist sehr umständlich, da dauernd die aktuelle Bildposition verglichen wird und sie somit kein "Interrupt" im eigentlichen Sinne ist. Daher verzichte ich auf eine Beschreibung.

Es begann alles damit, dass Erik mehr als 16 Farben wollte. So überraschte er mich an einem Wochenende mit einem Programm, das mehrere Rahmenfarben darstellte. Gelöst war es mit Hilfe des HBL-Interruptes, der bei jedem Aufruf einen Zähler verkleinerte, bis er den Wert Null erreichte Dann wurde die Farbe umgeschaltet und der Zähler für den nächsten Aufruf gesetzt. Im Prinzip ganz einfach, aber es sah furchtbar aus ! Da jeder andere Interrupt den HBL unterbrechen darf, konnte er die Zeilen nicht so genau zählen. Die Bereiche der Farbumschaltungen flackerten je nach Mausbewegung und Tastaturimpulsen rauf und runter (die Maus ist eine intensive Level-6-Interruptquelle). Deshalb war diese Methode für uns nicht geeignet, obwohl sie auch in Spielen wie Gauntlet 1 (Titelbild) Verwendung findet.

Nachdem die Scrollroutine unseres Demos fertig war und wir prinzipiell schon das Hintergrundbild hatten, wollten wir nur noch mitten im Bild mehrmals die Farben verändern und für den Scroller ebenfalls 16 neue Farben verwenden. Dann erschien im April 1986 ein Programm im 68000er Sonderheft, das alle 512 Farben des STs gleichzeitig auf den Bildschirm bringt. Ja, Ihr Markt & Technik-Leute ward es, die uns mit den Prinzipien der "mehr-als-sechzehn-Farben"-Programmierung vertraut machten !

Das Ausprobieren des Programms ließ ein schachbrettartiges Muster auf dem Bildschirm erscheinen, in dem tatsächlich alle 512 Farben des ST zu sehen waren. Nun gut, die Maus richtete hier auch noch etwas Schaden an (Flackern um eine Zeile), aber die hatte in unserem Demo sowieso nichts mehr zu melden. Schnell bauten wir die entsprechenden Teile in unser Demo ein und siehe da...: Immer noch mies. Nun flackerte die Farbumschaltung zwar nicht mehr um Zeilen nach oben, aber man sah die Umschaltung innerhalb der Zeile flackern. Das hat folgende Ursache: Der MFP meldet dem Prozessor einen Interrupt der Ebene 6, wenn der interne Zähler den Wert 0 erreicht. Nun arbeitet die CPU den aktuellen Befehl erst vollständig ab, bevor die Interruptbehandlung anfängt. Rücksprungadresse merken, Status merken, Trace löschen... der Prozessor hat einiges zu tun, bevor er den ersten Befehl der Interruptroutine überhaupt abarbeitet. In dieser Zeit hat sich der Elektronenstrahl natürlich weiterbewegt, so dass man in der nächsten Zeile sieht, wie der ST die Farben der Reihe nach umschaltet. Viele Programme lassen zur Umschaltung einige Zeilen Platz, in unserem Bild durfte das aber nicht sein. Irgendwie mussten wir die Farben schneller umschalten. Doch auch die schnellste Methode ist zu langsam: Denn schon gleich nach der Interrupterkennung müssen die Farben umgeschaltet sein. Und nun kommt der Trick: Man löst den Interrupt eine Zeile früher aus und wartet eine weitere Zeile auf die Austastlücke für den horizontalen Strahlrücklauf. So lassen sich die Farben während des Rücklaufs setzen. Mit dieser Methode setzen wir also die Farben von einer Zeile zur nächsten. Im Gegensatz zu den Titelbildern von Magnetic Scrolls (The Pawn, Jinxter...) unterbricht der Interrupt unser Hauptprogramm nur eine Zeile früher, das so noch weitere Routinen ausführt (Scrolling, Musik...).

In unser erstes Demo bauten wir dann nur noch die Musik ein, und es war vollendet. Aber für unser zweites Demo hatte sich Erik noch einige Tricks ausgedacht. Angefangen bei den Palettenanimationen in kleinen Bereichen des Bildschirms bis hin zum Hineinkopieren verschiedener Logos in den Bildschirm, bauten wir neue Sachen in das Demo ein. Es war früher Morgen, als das Demo fertig war. Da es hauptsächlich um Musik ging, nannten wir es "Little Sound Demo".

Soweit Udos Exkurs in die verschärfte Rasterprogrammierung. Und jetzt können Sie sich auf das folgende abtippfertige Listing stürzen. Kleiner Tipp: Starten Sie das assemblierte Programm als ".TOS", sonst gibt es beim Bewegen der Maus einen Crash. Offenbar gerät GEM beim Anblick so vieler Farben erstmal ein wenig in Panik. Wir erwarten, dass uns in Zukunft kein Spiel, und sei es Public-Domain, jemals wieder mit Rasterinterrupts belästigt, die flackern oder gar durch Abwesenheit glänzen. Als mahnendes Beispiel sei der "Game Over"-Bildschirm des neuesten Spieles einer englischen Softwarefirma genannt, dessen Name uns irgendwie an die Stadtbibliothek erinnert, obwohl dort niemand mit einer riesigen Knarre durch ein Alien-Raumschiff stolpert...

Alsdann, liebe Leser, mit etwas Glück finden Sie in der nächsten Ausgabe einiges über Musikprogrammierung und wie man dem ST-Soundchip Töne entlockt, mit denen seine (mittlerweile wohl pensionierten) Entwickler sicher nicht gerechnet hätten. Tschüss !

"The Exceptions" gehen im dritten Teil ihrer Serie für Assembler-Programmierer in die Vollen: 17 KByte Sourcecode liefern Ihnen den Traum- Synthesizer, der auf dem ST seinesgleichen sucht. "Symphony ST" spielt parallel zu jedem anderen Programm Musik und entlockt dem schmächtigen ST-Soundchip Töne, die niemand für möglich hielt. Frequenzmodulation, beliebige ADSR-Hüllkurven, Vibrato und Soundeffekte mit bis zu drei Stimmen gleichzeitig, liefert dieses definitive Werkzeug für Computermusik in Profiqualität. Doch damit nicht genug: Schreiben Sie die beste Eingabehilfe für "Symphony" und gewinnen Sie 1000 Mark!

Was, schon wieder ein Monat vorbei? Wahnsinn! Früher habe ich ungeduldig auf das Erscheinen dieser Zeitschrift gewartet, aber seitdem wir eine Serie für das ST-Magazin schreiben, erscheint dieses Blatt mindestens doppelt so oft wie früher! Aber was soll das Gejammere, schließlich interessieren Sie nicht unsere Terminprobleme, sondern Sie möchten etwas über Musikprogrammierung auf dem ST erfahren. Diesmal gibt es ein besonderes Bonbon für alle, die an den bescheidenen Klangfähigkeiten des ST bisher verzweifelten: eine exklusive Synthesizer-Routine fürs ST-Magazin, lauffähig in eigenen Programmen und mit etlichen Spezialeffekten ausgerüstet! Sie kennen unser Muster: Erst werde ich, Erik, mit einer kleinen Hintergrundgeschichte und einigem Grundwissen unser Honorar für diesen Monat in die Höhe treiben, und dann wird Sie der Fachmann für den Bereich Musikprogrammierung, Jochen, vollends darüber aufklären, wie man dem ST Wohlklänge zu entlocken vermag.

Unser zweites Demo (LSD, Little Sound Demo; ST-Magazin 8/88) war kaum fertiggestellt, da begann er seine Synthesizerroutine schon wieder zu verbessern. Angeheizt von wahren Soundorgien, die besonders der englische Musikprogrammierer Robb Hubbard auf dem C 64 feierte, versuchte »Mad Max« verzweifelt, ähnliche Effekte auf dem Uralt-Soundchip des ST zu vollbringen. Eines muß man dabei vorausschicken:

Objektiv betrachtet, hat unser guter ST den schlechtesten Soundchip aller derzeit verbreiteten Heimcomputer. Sowohl der C 64 als auch der Amiga sind ihm in dieser Hinsicht um Längen voraus. Doch man muss in aller Unbescheidenheit sagen, daß sich Jochen von Hardware-Unzulänglichkeiten genausowenig beeindrucken läßt, wie der Rest unserer merkwürdigen Truppe. Alsbald verschwand mein alter C 64 immer öfter von seinem angestammten Platz, um bei unserem Musikfreak als Referenz bei der Umsetzung von Robb Hubbards Spielesoundtracks zu dienen. Denn nachdem wir einige positive Reaktionen auf unsere Demoschreiberei erhalten hatten, wuchs die Motivation, mit einem dritten Demo alles bisher Dagewesene in den Schatten zu stellen.Während sich meine Wenigkeit daran machte, am ST ein kleines Portrait des erwähnten Mr. Hubbard zu malen, und Udo sich mit meinen komischen Ideen für neue Effekte herumschlug, war auch Jochen nicht untätig. Deshalb ein paar Worte zur Umsetzung eines Liedes vorn 64er auf den ST.

Zur Zeit des dritten Demos war die Sache noch wirklich mühselig. Jochen konnte das Format, in dem die Noten für ein Lied im Speicher des Commodore lagen, zwar lesen wie andere ihre Comics, doch mußte das Ganze ausgedruckt, im Kopf in Jochens Notenformat umgerechnet und dann in den ST getippt werden. Anschließend mußte er noch versuchen, die Klänge, die der »Brotkasten« von sich gab, so gut wie es eben ging mit den bescheidenen Mitteln des Yamaha- Soundchips nachzubilden. So entstanden acht Songs, die zur damaligen Zeit ihresgleichen suchten. Außer dem guten Sound gab es zwei besonders herausragende Dinge zu bestaunen: eine »Dreikanal-LED-Aussteuerungsanzeige« und einen in Dutzenden von Farben leuchtenden Scrolltextstreifen, der dem Programm den Namen "LCD" (Little Color Demo) einbrachte. Danach war erst einmal eine Weile Ruhe. Wie noch heute im LCD zu lesen ist, wollten wir fürs erste keine weiteren Demos mehr produzieren (waren wir naiv!), denn seit einiger Zeit arbeiteten Udo und ich an unserem ersten kommerziellen Programm, natürlich einem Spiel.(Dragonflight; Anm. d. Webmasters)

Zu dem Zeitpunkt, da Sie diese Zeilen lesen, wird es wohl immer noch nicht im Handel sein. Das wundert allerdings niemanden, am wenigsten uns selbst, denn natürlich konnten wir es nicht lassen, mit weiteren Demoprogrammen unsere Zeit zu verschwenden. Zunächst konnten wir der Versuchung nicht widerstehen, ein Diashow-Programm für Neochrome-Bilder zu programmieren. Ein Freund in Mannheim mit dem Pseudonym ALYSSA hatte entdeckt, wie man im unteren Bildschirmrand des ST Grafik erscheinen läßt. Folglich schaffte es Udo, komplette Bilder anzuzeigen, im Rahmen eine Scrollzeile laufen zu lassen, Rasterinterrupts zu setzen, Musik mit digitalisiertem Schlagzeug abzuspielen und mit dem Betriebssystem Bilder zu laden: und zwar alles gleichzeitig.

Heute interessiert uns die Musik. Jedem, der unsere Demos kennt, fällt dabei das B.I.G.-Demo ein, denn es enthält 127 verschiedene Musikstücke. Derjenige, der den Stein für das B.I.G.Demo ins Rollen brachte, war unser guter Freund Richard Karsmakers aus Holland, seines Zeichens Herausgeber des wohl besten Diskettenmagazins für den Atari, den »ST-News«. Nachdem er uns, sprich Jochen, dazu überredet hatte, seine Disketten- Zeitschrift mit Hintergrundmusik zu versorgen, fing er auf einmal an, uns mit Plänen für ein Demo zu bombardieren, das uns den Atem verschlug. Er meinte knochentrocken, es wäre doch toll, in diesem Demo alle Musiken des von ihm (und uns) verehrten Robb Hubbard unterzubringen. Bevor wir auch nur entsetzt Luft holen konnten, hatte »Mad Max« schon zugestimmt. Sein »Ja« kam so schnell, da wir kurz zuvor eine nützliche Erfindung gemacht hatten. Denn während ich ein Kabel zur Datenübertragung vom C64 zum ST zusammenlötete, programmierte Udo ein wenig auf beiden Computern herum, und siehe da, der ganze Speicherinhalt des 64ers ließ sich in wenigen Sekunden ins üppige RAM des Ataris schleudern. Nun gehörte die lästige Tipperei für Jochen der Vergangenheit an. Was lag aber näher, als zusätzlich eine Konvertierungsroutine zu schreiben, die Robbs Musik automatisch in eine Form brachte, die Jochens Synthesizerroutine gefiel. Es bleibt zwar noch genug Arbeit übrig, da sich nicht alle Informationen sinngerecht umsetzen lassen, außerdem muß das Klangbild der einzelnen Stimmen bis auf den heutigen Tag sorgfältig per Hand eingestellt werden. Aber dieses Kabel war immerhin die Voraussetzung, so etwas Verrücktes wie das B.I.G.-Demo überhaupt in Erwägung zu ziehen. Außerdem hatte TEX mittlerweile tatkräftige Unterstützung in Form von Michael (Daryl) und Gunter (6719) bekommen.

Über drei Monate hinweg arbeiteten wir mehr oder weniger intensiv an unserem 5. Demo. Letztlich investierten wir alle mehr Arbeit, als ursprünglich gewollt und es unserem Spiel gutgetan hätte. Die programmtechnischen und grafischen Tricks des B.I.G.-Demos enthüllen wir Ihnen ein andermal. Soundmäßig war uns nämlich die endlose Liste von Musiktiteln dieses Programmes noch nicht genug.

Im B.I.G.-Demo hatte deshalb noch ein weiteres Programm von Jochen Weltpremiere: Der Digitalsynthesizer! Er ist zu nichts geringerem fähig, als nach dem gleichen Prinzip Töne zu erzeugen, wie es der Soundchip des Amiga tut.

Unterhalten wir uns zunächst einmal darüber, wie ein "normales" Synthesizerprogramm Musik mit dem eingebauten Soundchip erzeugt. Dieser Soundchip wurde ursprünglich von General Electric entwickelt und findet sich im ST in Form eines Yamaha-Clones mit dem Namen "YM- 2149" wieder. Zur Zeit seiner Markteinführung war er ein Segen für die Coin-Op-Hersteller und versorgte somit neueste Spielhallengeräte mit noch nie dagewesenem Sound. Gemeint sind so aktuelle Spielhallenschlager wie Pac-Man, Asteroids und andere Heuler, an die man heute noch mit Tränen der Rührung zurückdenkt.

Tränen des Zorns treibt es einem jedoch in die Augen, wenn man so ein ehrwürdiges Stück Technik in einem der modernsten Heimcomputer Ende der achtziger Jahre wiederfindet. Wahrscheinlich betrachteten Jack Tramiels Entwickler den YM sowieso hauptsächlich als Portbaustein, an dem versehentlich noch ein paar armselige Schwingkreise hängengeblieben sind. Ja, ja, in Ordnung, ich höre jetzt mit dem Geläster auf. Die technischen Daten des Chips sprechen Bände: Die erwähnten Ports, zwei an der Zahl, einer als Ein- und einer als Ausgang geschaltet, übernehmen beispielsweise die Datenübertragung zum Diskettenlaufwerk und zum Drucker. Zur Klangerzeugung tragen sie allerdings aus naheliegenden Gründen nicht allzuviel bei. Eher geeignet scheint da einer der drei Tonkanäle zu sein.

Als Hüllkurve bezeichnet man, wie sich ein Ton beim Anschlag, Abschwellen, Halten und Abklingen des Instrumentes verhält. Ins Englische übersetzt heißt das Attack, Decay, Sustain und Release, weshalb nicht nur wir von ADSR-Hüllkurven sprechen. Ein Klavier hat zum Beispiel einen schnellen Anschlag, hält den Ton fast gar nicht, klingt aber sehr lange aus. Damit ist schon fast zuviel über die Hüllkurven gesagt, denn leider klingen die vorgegebenen ADSR-Kurven unseres Soundchips zwar nicht gut, dafür aber alle fast gleich.

Der YM-2149 kennt nur eine Wellenform, nämlich die Rechteckwelle. Ferner läßt sich allen Stimmen ein einziger Rauschgenerator zuschalten. Das war's. Im Ernst, mehr ist nicht! Damit Sie erkennen, wie wenig das wirklich ist, schauen wir kurz auf den SID, den Soundchip des C 64 hinüber: Auch er verfügt nur über drei Stimmen, die sich sogar ein einziges Lautstärkeregister teilen. Dafür hat er zusätzlich:

Alle Features lassen sich für jede einzelne Stimme einstellen. Insgesamt liefert der 64er ein wesentlich abwechslungsreicheres Klangbild, und das, obwohl es diesen Computer schon seit 1982 gibt! Vielleicht wundern Sie sich jetzt, warum ein gestandener ST-Freak so übel über die Soundfähigkeiten seines Gerätes herzieht. Der Soundchip im ST ist aber einfach mies... Wenn man in Testberichten von Spielen oder Musikprogrammen liest, »dass der Sound seltsamerweise schlechter als beim C 64 ist«, sehen wir einmal mehr, daß die Menscheit im allgemeinen und manche Softwaretester im besonderen (nein, nicht Du, Boris!) eben nicht ausreichend über die technischen Hintergründe aufgeklärt sind. Besonders ärgerlich ist es, wenn sich ein Programmierer viel Mühe gab, dem Soundchip mit programmtechnischen Tricks einen besseren Klang zu entlocken, ohne daß es irgend jemand merkt. Ich denke da unter anderem an »Sapiens«, ein Programm aus Frankreich mit sehr gutem, dreistimmigen Digi-Sound im Hintergrund, das bei uns nie auf den Markt kam.

Denn es gibt, wie Sie sicherlich schon gemerkt beziehungsweise gehört haben, einige Methoden, sich nicht mit den kläglichen Piepsern des YM- 2149 zufriedenzugeben. Wie immer, muß hier die Software herhalten. Sehen wir uns deshalb die prinzipielle Arbeitsweise einer Synthesizerroutine an.

Zunächst sollte sie im Hintergrund, das heißt auf einem Interrupt, laufen. So läuft die Musik parallel zum Hauptprogramm. Ferner ergibt sich daraus, daß die Soundbearbeitung gleichmäßig abläuft. Im ST eignen sich dafür beispielsweise der 200-Hz-Timer, oder, wie bei unserem Programm, der VBL-Interrupt (Vertical BLank), der bekanntlich 50 oder 60mal in der Sekunde aufgerufen wird. Prinzipiell macht ein solches Programm nichts anderes, als sich aus einer Tabelle Note und Notenlänge zu holen und diese, anhand einer Frequenzliste umgerechnet, in den Soundchip zu schreiben. Durch das regelmäßige Aufrufen einer solchen Routine läßt sich ein Sound beliebig verändern. Die so erzeugten Effekte gehen weit über die vorgesehenen Fähigkeiten des Chips hinaus. In unserem hier abgedruckten Synthesizer »Symphony ST« sind folgende Effekte eingebaut:

All diese Effekte bringen zusammen ein verblüffendes Ergebnis aus Ihrem Lautsprecher. Hören Sie sich nur einmal das kleine Demo-Lied an, das am Ende des Listings beigefügt ist.

Bevor Ihnen Jochen nun die genaue Erklärung zu seinem Programm liefert, gehe ich noch kurz auf die Arbeitsweise des "Digitalsynthesizers" ein. Dieses Wunderwerk der Programmierkunst (Protz!) bringt dem ST, wie schon erwähnt, ähnliche Soundfähigkeiten wie dem Amiga bei, allerdings auf Kosten der Rechenzeit. Es wird im Speicher nur ein einziger digitalisierter Ton eines beliebigen Instrumentes benötigt. Die Software gibt diesen Ton in beliebiger Frequenz und Länge wieder. Bis zu vier solcher Stimmen werden anschließend gemischt und dann simultan über den Soundchip ausgegeben. Jochen benutzt dabei übrigens nur die Lautstärkeregister, die, als Analog- Digital-Wandler missbraucht, die Samples abspielen. Das Ganze läuft zwar noch auf Interrupt, fairerweise muß man aber einräumen, dass diese Methode der Klangerzeugung zwischen 70 und 80 Prozent der Rechenzeit verbraucht. Wie der Digital-Synthesizer nun genau funktioniert, soll bis auf weiteres unser Geheimnis bleiben, alles wollen wir ja auch nicht verraten. Statt dessen übergebe ich nun die Tastatur an Jochen, er wird sie nun genau über die Arbeitsweise seines Listings aufklären.

Grüezi, Musikfreaks. Hier ist nun Jochen am Keyboard. Die Anrede ist mit Bedacht gewählt, denn der Synthesizer verfügt zur Zeit noch über keine Eingabehilfe. Die Noten und Effekte müssen Sie daher direkt innerhalb des Assemblers eingeben. Das ST-Magazin macht aber tatsächlich 1000 Mark für denjenigen Programmierer locker, der die beste Benutzeroberfläche für "Symphony ST" programmiert. Da ich den Quellcode ausführlich dokumentiere, ist das Schreiben einer soliden Benutzeroberfläche wohl nicht mehr so schwierig.

Übrigens arrangiere und komponiere ich mit meinem »großen« Synthesizerprogramm, das ich für unsere Demos und kommerzielle Spiele verwende, auch innerhalb des Assemblers. Zur besseren Übersichtlichkeit habe ich die Anleitung zu "Symphony ST" zusammen mit dem Listing auf Seite 74 tabellarisch zusammengefaßt. Sie erklärt alle Programmteile, die für das Schreiben eigener Musik von Bedeutung sind.

So weit, so gut. Ich hoffe, Sie finden die Anleitung einigermaßen verständlich. Viel Spaß beim Ausprobieren und Experimentieren! Nun wissen Sie hoffentlich auch über die Musikprogrammierung des STs Bescheid, liebe Leser. Nächstes Mal kümmern wir uns nicht ums Ohr, sondern verwöhnen das Auge: grafische Tipps und Tricks sind angesagt. Bis dann, Tschüss!

"The Exceptions" schlagen wieder zu ! Der vierte Teil der TEX-Serie weiht alle ST-Fans in die Geheimnisse der Grafik-Programmierung ein. Pixel-Künstler Erik verrät, was sich hinter "Antialiasing" verbirgt und beschreibt Grafiktricks von "Paletten-Animation" über Transparenzeffekte bis hin zum Vorder- und Hintergrund-Scrolling. "The Exceptions" enttarnen versteckte Funktionen des Malprogramms "Neochrome" und demonstrieren alle Grafiktechniken in ihrem Assembler-Listing. Doch lesen Sie selbst...

Hallihallo liebe Leser ! Wieder fit für eine neue Runde TEX-Tipps ? Ich verspreche Ihnen nach dem langen Synthesizer-Listing der letzten Ausgabe für den vierten Teil etwas Erholung, aber nur, soweit es das Eintippen von ellenlangen Listings betrifft. Zwar konnten wir uns auch heute ein Programm zum Abtippen nicht verkneifen, aber diesmal ist es wirklich klein und harmlos. Einsteiger wird es freuen, dass sie für diesen Artikel keine besonderen Assembler-Kenntnisse benötigen, denn es handelt sich um mein eigenes Spezialgebiet: Die Grafik.

Nun fragen Sie sich vielleicht, was sich zu diesem Thema überhaupt noch sagen lässt: Fleißige Autoren füllten damit schon unzählige Bücher und Zeitschriftenseiten, nicht wahr ? Aber ich bin sicher, dass es einige Tricks und Kniffe gibt, von denen Sie bisher nichts wussten. Oder kennen Sie sich aus mit:

Sie wissen nichts darüber ? Das ändert sich schnell, denn wir möchten Sie in die Geheimnisse der Grafik-Hexerei einweihen. Außerdem verraten wir einige Eigenschaften des Malprogramms "Neochrome", die Sie bestimmt noch nicht kennen. Wie alle unsere bisherigen "Anleitungen für Zauberlehrlinge", beziehen wir uns auch diesmal ausschließlich auf die niedrigste Auflösungsstufe des ST, in der sich normalerweise 16 Farben gleichzeitig darstellen lassen (Leser des zweiten Artikels können darüber natürlich nur müde lächeln). Also, machen wir uns daran, alle der oben aufgeführten Begriffe der Reihe nach abzuhaken.

Als erstes steht dort "Antialiasing", ein Begriff aus den professionellen Sphären der Computergrafik. Frei übersetzt entspricht dieser Ausdruck etwa der Formulierung: "Wie zum Henker vermeide ich diese treppenartigen Übergänge in meinem Computerbild ?" Wir wissen alle, dass der ST eine recht geringe Auflösung hat. Besonders bei schrägen Linien oder Kreisen sind deshalb typische Abstufungen zu sehen. Nun, wenn sich die Hardware ausnahmsweise nicht übers Ohr hauen lässt (selbst die Zaubersprüche von "Hexern" zeigen gelegentlich keine Wirkung) machen wir uns einfach daran, ein anderes "Peripheriegerät" zu betrügen: Das menschliche Auge.

Dabei machen wir uns unter anderem das Kontrastempfinden des Sehens zunutze: Beim "Antialiasing" verfahren wir nach folgendem Schema: An der Überschneidungskante zweier Farben füllen wir die entstehenden "Treppen" mit Punkten auf, deren Farbwert zwischen diesen beiden Farben liegt. Das ist alles. Um die erstaunliche Wirkung zu demonstrieren, machen Sie doch mit uns eine kleine praktische Übung. Sicherlich befinden Sie sich im Besitz eines beliebigen Farb-Malprogramms mit einer Lupenfunktion. Laden Sie das Programm (vorzugsweise "Neochrome") und definieren Sie folgende Farbwerte:

Hintergrundfarbe	000
Zeichenfarbe 1	711
Zeichenfarbe 2	600
Zeichenfarbe 3	400
Zeichenfarbe 4	300

Nun lassen Sie uns ein Dreieck in der Zeichenfarbe 1 malen. Ziehen Sie dazu drei Linien, beispielsweise von ganz links oben (Position x = 0 / y = 0) bis zur Position x = 20 und y = 80, dann eine Linie bis zum linken Bildrand ( x = 0 / y = 80) und von dort wieder zurück zum Ausgangspunkt. Füllen Sie nun diesen Linienzug mit der Zeichenfarbe 1 aus. Nun befindet sich ein hellrotes Dreieck auf Ihrem Bildschirm, auf dessen rechter Seite klar die computertypischen Treppen zu sehen sind. Kopieren Sie dieses Dreieck, so dass zwei Dreiecke nebeneinander stehen. Dieses zweite Dreieck werden wir nun "Antialiasen". Gehen Sie dazu in Ihre Lupenfunktion und wählen Zeichenfarbe 2 an. Setzen Sie einen Punkt in dieser Farbe an jede "Treppenstufe" der rechten Dreieckseite. Danach wählen Sie Zeichenfarbe 3 an und wiederholen den Vorgang und noch ein drittes Mal mit Zeichenfarbe 4. Nun haben Sie an jeder "Treppe" nach oben hin drei immer dunkler werdende Rot-Töne angesetzt. Verlassen Sie die Lupenfunktion und schauen Sie sich die beiden Dreiecke an. Der Unterschied ist verblüffend, nicht wahr ?

Dreieck Nummer 2 erscheint in einer wesentlich höheren Auflösung als Ihr Ursprungs-Dreieck. Das ist "Antialiasing", ganz einfach ! Wenn Sie Lust haben, malen Sie noch einen gefüllten Kreis in Zeichenfarbe 1 daneben und setzen Sie an die entstandenen Treppen wieder die immer dunkler werdenden Rot-Töne an. Mit der Zeit bekommen Sie ein Gefühl dafür, an welche Stufen Sie wie viele "Anti-Aliasing-Punkte" setzen dürfen, denn an einem Kreis sind viele "Treppen" vorhanden. Nicht "Antialiasen" lassen sich horizontale und vertikale Geraden (klar) und eine genaue Diagonal-Linie, da dort natürlich keine "Treppen" vorhanden sind.

Nach dieser Methode lassen sich alle Grafiken verfeinern, wenn die Farbpalette entsprechend ausgelegt ist. In unserem Beispiel ist Schwarz (000) die Hintergrundfarbe, Hellrot (711) die Zeichenfarbe und die Farben 2 bis 4 die "Antialiasing-Farben". Soviel also zum ersten Farben-Trick, viel Spaß beim Experimentieren mit diesem Effekt !

Was haben wir denn als nächstes auf unserer Liste ? Aha, Farbpalettenanimation !

Zunächst eine kurze Erklärung, was das überhaupt ist: Der ST verfügt über 16 Farbregister. Werden davon einige oder alle miteinander zyklisch vertauscht, nennt man das "Color-Cycling" oder Palettenanimation. "Color Cycling" eignet sich zum Beispiel sehr gut, um fließendes Wasser zu simulieren. Als bestes Beispiel sei hier eines der ersten und bekanntesten Neochrome-Bilder genannt: Der Wasserfall. Neochrome zirkuliert hier laufend die Blautöne des Wassers, der Eindruck von Bewegung entsteht. Aber mit Palettenanimation lässt sich noch sehr viel mehr machen. Es bereitet mir immer ein diebisches Vergnügen, damit Effekte zu gestalten, die alle Betrachter für normale Grafikprogrammierung halten. Eine ausgesprochen hinterhältige Anwendung der Palettenanimation finden Sie zum Beispiel in dem TEX-Programm "Super-Neo-Demo-Show". Dort befindet sich ein Scrolltext im unteren Rand des Bildschirms, und darunter drehen sich viele kleine Propeller. Nach dieser Einleitung werden Sie nicht überrascht sein, dass diese drehenden Linien nichts anderes als Palettenanimation sind.

Wie das geht ? Nun, es ist nicht ganz einfach in Worte zu kleiden, aber ich will es versuchen. Stellen Sie sich vor, Sie malen zwölf sich überkreuzende Linien, jede in einer Farbe. Nun setzen Sie alle zwölf Farbwerte der Linien auf Schwarz, mit einer Ausnahme: Eine einzige Linie bleibt zum Beispiel blau. In die Mitte setzen Sie dann einen kleinen Kreis mit einer nicht "animierten" Farbe, um die Kreuzungsstelle zu verdecken. Ordnen Sie jeder Linie nun in schneller Folge den Blau-Wert zu, während die anderen Linien schwarz "geschaltet" sind, so entsteht der Eindruck einer rotierenden Linie (Propeller-Effekt). Gemein, was ? Unser Foto zeigt mehrere Propeller auf einmal, da die Belichtungszeit des Dias einige "Drehphasen" lang war. Es gibt noch ein paar andere Tricks dieser Art, beispielsweise die hüpfenden Punkte im zweiten Psych-O-Screen unseres B.I.G.-Demos. Sie beruhen prinzipiell alle auf dem gleichen Trick: Fast alle beteiligten Farben sind gleich der Hintergrundfarbe, nur eine oder wenige sind "eingefärbt", durch die Palettenanimation entsteht Bewegung. Sie können die Farbspielereien sogar so weit treiben, dass zum Beispiel ein Männchen über den Bildschirm läuft. Das Prinzip ist mit den Propellern identisch. Sie zeichnen die Bewegungsphasen der Figur in jeweils einer anderen Farbe und setzen sie nebeneinander (überschneiden dürfen sie sich natürlich nicht). Da jede der einzelnen Figuren durch die Palettenanimation nacheinander "aufleuchtet", sieht es so aus, als liefe die Figur über den Bildschirm. So lassen sich also regelrechte Animationen durch die Manipulation der Farbregister erzeugen. Der Nachteil dieses Tricks sei nicht verschwiegen: Wenn Sie viele Farben für die Palettenanimation verwenden, bleiben nur wenige Farben für das eigentliche Bild übrig. Der große Vorteil der Palettenanimation offenbart sich bei der benötigten Rechenzeit: Sie beträgt nur einen Bruchteil der Dauer normaler Bit-Block-Grafikanimation.

So, liebe Leute, jetzt wird's ernst. Bis jetzt waren es nur harmlose Spielereien, aber nun...

Vielleicht haben Sie in einem unserer Programme schon einmal gesehen, dass dort Grafikteile durchsichtig wie gefärbtes Glas über anderen Bildteilen schweben. Sicher wunderten Sie sich, welches wunderbare und aufwendige Programm wohl dahintersteckt... Fehlanzeige ! Wie Sie es wohl schon erwarteten, steckt auch hier ein Trick dahinter.

Um ihn zu verstehen, müssen Sie allerdings über den Grafikaufbau des ST genau Bescheid wissen, deshalb hier eine kleine Gedächtnisauffrischung. In der niedrigsten Auflösungsstufe sieht die Bildschirm-Verwaltung folgendermaßen aus: Der ST adressiert einen bestimmten Speicherbereich als Bildspeicher. Dort gehören jeweils vier hintereinanderliegende Speicherwörter (1 Wort = 16 Bit) zusammen. Jedes Wort ist ein Teil einer der vier sogenannten "Planes". Am besten stellen Sie sich diese vier zusammengehörigen Wörter untereinandergeschoben vor, so sehen Sie am besten, dass jeder einzelne Punkt aus 4 Bit besteht. Die Kombination dieser 4 Bit bestimmt den Farbwert eines Punktes aus einem der 16 Farbregister. In der niedrigsten Auflösung von 320 x 200 (= 64000) Punkten darf jeder Punkt eine von 16 Farben annehmen. Jede Plane ist also 8 KByte groß. Vier Planes sind somit ein voller Bildschirm und benötigen 32 KByte. Diese Planes sind aber nicht nur zur Bestimmung der Farbe eines einzelnen Punktes gut, wenn Sie jede für sich als "Ebene" ("Plane") betrachten und auch so behandeln, ergeben sich einige nette Effekte.

Nehmen wir an, Sie haben eine Grafik, die nur aus acht Farben besteht. Diese acht Farben lassen sich mit nur drei Planes darstellen (drei "untereinanderliegende" Bits = 8 unterschiedliche Kombinationen). Befindet sich unsere Grafik in den ersten drei Planes, so sind ihre Farben in den Farbregistern 1 bis 8 zu finden. Erfreulicherweise haben wir aber noch eine Plane übrig. In dieser Plane bringen wir nun zum Beispiel einen einfarbigen Grafikblock unter. Setzen wir die Farbregister 9 bis 16 auf den gleichen Wert, dann lässt sich dieser Grafikblock mit einem kleinen Programm in seiner Plane bewegen (das Programm behandelt nur jedes vierte Wort). Die zusätzlich entstehenden Bitkombinationen ergeben nur die Farben in den Registern 9 bis 16. Und so legen wir eine einfarbige Grafik über eine achtfarbige Grafik, ohne den Klotz aufwendiger Verknüpfungsoperationen am Bein zu haben. Das ist alles. O.K., O.K., ich höre Sie ja schon rufen: "Was ist denn jetzt mit dem Transparenteffekt, und mit dem Vorder- und Hintergrund, hmm !?".

Programmtechnisch passiert auch bei diesen Effekten nicht mehr als eben beschrieben. Alles andere sind hirnverdreherische Gedanken um das geschickte Setzen unserer Farbpaletten. Noch mal: Sowohl Transparent- als auch Vorder- und Hintergrundtricks erreichen wir nur durch einfaches Setzen geeigneter Farbpaletten. Dazu müssen Sie sich noch mal ganz genau durch den Kopf gehen lassen, was mit den Bitkombinationen geschieht, wenn Sie eine Grafik in einer Plane "über" die drei anderen bewegen. In den Farbregistern 9 bis 16 stehen die Werte, die sich durch Kombination der vierten Plane mit den drei ersten ergeben. Bewegen Sie diese Plane über die drei anderen Planes, verändern sich laufend die Farben dieser vierten Plane. Denn je nachdem, ob sich die Pixel der vierten Ebene mit den Pixeln der anderen Ebenen überschneiden, verändern sich die Farbwerte. Die Farbe richtet sich also immer danach, ob das vierte Bit gesetzt ist oder nicht.

Wenn Sie sich dies klargemacht haben, leuchtet es ein, wie der Transparenteffekt zustande kommt: Einfach, indem die oberen acht Farben nicht alle gleich sind, sondern in ihrer Helligkeit den unteren acht Farben angepasst sind. In unserem Progranmbeispiel springt eine feuerrote "Glasplatte" über ein in Grautönen gehaltenes Hintergrundmuster. Die Farben sind hierbei folgendermaßen verteilt: Die Farben 1 bis 8 sind von Schwarz (000) über alle Graustufen bis Weiß (777) hin verteilt. Die "Transparentfarben" 9 bis 16 gehen folgerichtig von Dunkelrot (004) bis Gelb (770). Wenn sich also der einfarbige Grafikblock in der vierten Plane "über" die Planes 1 bis 3 bewegt, erscheint bei Überschneidungen dort, wo Farbe 1 war die Farbe 9, wo Farbe 2 war die Farbe 10 und so weiter. Programmtechnisch ganz einfach, aber darauf muss man erst einmal kommen, nicht wahr ?

Udo und die anderen haben sich auch ganz schön an den Kopf gegriffen, als ich mit diesem Vorschlag ankam. Die Sache mit dem Vorder- und Hintergrund ist nun natürlich auch ganz einfach, als Beispiel diene Ihnen der B.I.G.-Scroller in unserem B.I.G.-Demo, dort geht eine Laufschrift zwischen Vorder- und Hintergrund hindurch. Hierbei setzten wir die oberen acht Farben folgendermaßen:

Bei den unteren acht Farben, bei denen die einfarbige Grafik im Hintergrund erscheinen soll, setzen wir die entsprechende obere Farbe auf den gleichen Wert. Alle Farben, die die einfarbige Grafik überdecken, bekommen den gewünschten Farbton. Soll also zum Beispiel der Ein-Plane-Grafikblock (beziehungsweise die Laufschrift oder was auch immer) ganz im Hintergrund der Drei-Plane-Grafik sein, setzen wir die oberen acht Farben den unteren gleich. Nicht gerade einfach, meinen Sie ? Hm, Sie haben wahrscheinlich recht. Aber was tut man nicht alles, um das Letzte aus seinem ST zu holen ?

Auch bei diesem Effekt ist es nicht ganz einfach, ihn in Worte zu kleiden. Ein Blick auf unser Listing beseitigt aber sicher Ihre letzten Zweifel. Das Programm baut ein Hintergrundmuster in drei Planes, also den ersten acht Farben auf und lässt einen Grafikblock in der vierten Plane auf und nieder schweben.

Auf den Tasten 1 bis 4 lassen sich verschiedene Farbpaletten abrufen, die die obige Beschreibung bestätigen. Das schlichte Wechseln der Palette bewirkt folgende Effekte:

Taste <1>	Palette 1	einfarbiger Block bewegt sich über die Grafik
Taste <2>	Palette 2	Block befindet sich im Hintergrund
Taste <3>	Palette 3	Block schiebt sich zwischen das Muster
Taste <4>	Palette 4	transparenter Block über der Grafik

Viel Erfolg beim Eintippen und viel Spaß beim Ausprobieren. Setzen Sie ruhig ein paar andere Farbpaletten in das Programm, es lassen sich damit lustige Effekte erzielen. Damit sind wir fast am Ende des vorletzten Teils der Hexer-Serie angelangt. Am Schluss dieses Artikels möchte ich allerdings noch ein kleines Plädoyer loswerden. Nein, nicht etwas in der Richtung "geplagte ST-Grafiker aller Länder vereinigt Euch !". Es geht mir vielmehr um mein Lieblings-Malprogramm. Es ist nach meiner und der vieler anderer Leute Meinung das am meisten unterschätzte Programm für den ST. Die Rede ist von Neochrome, das Atari in der Version 0.5 in den Anfangszeiten des ST als Public Domain-Programm beilegte und in der wesentlich erweiterten Form 1.0 verkaufen wollte. Die Vermarktung blieb aber bis heute aus. Viele Händler sahen auch die Version 1.0 als Public Domain an, so dass die meisten ST-Besitzer in den Genuss von Neochrome kamen. Wieso Neochrome so gut ist, möchte ich Ihnen nun erklären. Dabei erfahren Sie einige "Geheimnisse", die bisher nur wenigen Leuten über Neochrome bekannt waren.

Die eigentliche Begründung ist sehr kurz: Neochrome enthält (fast) alle Funktionen, die das Malen wirklich guter Bilder erfordert, es verzichtet auf überflüssige Funktionen und es ist sehr, sehr schnell. Im Gegensatz zu allen anderen Programmen auf dem Markt hat Neochrome eine Lupe, die immer zu sehen ist und die bei allen Funktionen arbeitet. Sie ist auch bei Blockoperationen, beim Linienziehen und Flächenfüllen dabei. Die Geschwindigkeit der Lupe erklärt sich übrigens durch die Verwendung von Rasterinterrupts. Ferner lässt sich unter dem Menüpunkt "Jackknife" ein Block mit wirklich beliebigen Konturen (nicht bloß Polygone) ausschneiden, der sich auch im Hintergrund bewegt. Diese Funktion bietet nicht einmal "Deluxe-Paint II" auf dem Amiga.

Davon ausgehend, dass Sie über die Neochrome-Funktionen informiert sind, komme ich nun zu einigen Eigenschaften, die in keinem Pull-Down-Menü Neochromes auftauchen...

Vieles verbirgt sich beispielsweise in der rechten Maustaste: Im "normalen" Blockmenü wird der gerade ausgeschnittene Block an die aktuelle Position gesetzt. Wenn Sie jedoch mit einem "Jackknife"-Block auf die rechte Taste drücken, malen Sie mit dem Block wie mit einem Pinsel. Und auch das, im Unterschied zu anderen Programmen, sehr schnell. Im "Brush"-Modus bewirkt der Druck auf die rechte Taste, dass Neochrome innerhalb der mit den "Farbpfeilen" eingestellten Grenzen beim Malen die Farben wechselt. Das gleiche gilt für die "Nozzles", die zusammen mit Palettenanimationen sehr effektvoll wirken.

Befinden Sie sich im "Grabber", so können Sie die Farbe eines beliebigen Punktes bestimmen, indem Sie die rechte Taste drücken. Das kleine Dreieck der gerade benutzten Farbe springt dann auf die entsprechende Farbe (Color Find). Im "Line"-Modus löschen Sie die gerade entstehende Linie, wenn Sie die rechte Taste zusätzlich zur linken drücken. Mit einem Doppelklick der rechten Maustaste auf dem Radiergummi löschen Sie das gesamte Bild.

Nun aber zu einem wirklich heissen Tipp, denn nur die wenigsten Leute wissen, dass in Neochrome 1.0 ein komplettes Animationstool steckt. Da der Programmierer Dave Staugas keine Zeit hatte, es völlig fehlerfrei zu machen, hat er es regelrecht versteckt. Und so zaubern Sie das neue Icon in das Befehlsfeld: Gehen Sie in den "Grabber"-Modus (Icon der greifenden Hand) und klicken Sie mit der rechten Maustaste genau in die Schleife des hinteren Rs vom Wort "GRABBER", das auf der rechten Menüseite erscheint. Schon taucht eine kleine Kamera in der Iconleiste auf. Nachdem Sie so das Animationstool aktiviert haben, stehen Ihnen einige neue Funktionen zur Verfügung: Bestimmen Sie zunächst einen beliebigen Animationsausschnitt mit der Maus. Mit der rechten Maustaste lässt sich nun die Grafik des ganzen Bildes durch diesen Ausschnitt schieben. Haben Sie den gewünschten Ausschnitt gefunden, klicken Sie "Add" an und das Bild befindet sich im "Animationsspeicher". Addieren Sie so viele Bilder, wie Sie wollen. Schieben Sie dann den Ausschnitt zurück auf Ihren ersten Block (nur Dave weiß, warum), und nun können Sie anhand der Pfeile im Animationsmenü die Bilderfolge vorwärts und rückwärts abspielen. Bedienen Sie die Pfeile des Animationstools genauso, wie die Pfeile der Palettenanimation. "Del" löscht, logisch, das gerade sichtbare Bild. "Load" und "Save" funktionieren. Erschrecken Sie aber nicht über die ramponierte Fileselektor-Box (vorher Animation stoppen). Experimentieren Sie nur ein wenig mit dem Animationstool, es ist im Unterschied zu allen anderen Programmen dieser Art für den ST sehr einfach zu bedienen. Der größte Vorteil ist allerdings, dass sich eine animierte Figur sofort im Malprogramm korrigieren lässt. Aber seien Sie gewarnt: Das Animationstool ist nicht fehlerfrei, unter anderem empfiehlt es sich nicht, die Undo-Taste zu drücken, während die Animation angewählt ist, sowie das Menü abzuschalten. Bevor Sie also den neuen Menüpunkt benutzen, speichern Sie das Bild besser ab.

Zum Schluss noch ein kleiner Gag: Sie können die Farbauswahlpalette im Menü selbst bestimmen. Neochrome sucht nach dem Laden ein 1024 Byte langes File Namens "NEO.MCP", in dem sich 512 Wörter mit Farbwerten befinden müssen, die die voreingestellte Palette ersetzen. Probieren Sie's aus !

Sollten Sie öfter mit Neochrome arbeiten (wenn nicht, dann tun Sie es sicherlich in Zukunft), dann geben Sie Ihrem Herz einen Stoß und dem guten Dave Staugas etwas Geld für sein wirklich gutes Programm. Er ist seines Zeichens Systemprogrammierer bei Atari und ziemlich enttäuscht darüber, wie wenig man sein Programm würdigte, von der mangelhaften Vermarktung ganz zu schweigen. Zuwendungen finanzieller Art können Sie ihm über folgende Adresse zukommen lassen: [...] Wenn Sie Neochrome-Fan sind, zögern Sie nicht. Dave hat mir versprochen, dass er bei entsprechender "Fanpost" noch mal die alten Sources entstaubt und einige schon seit langem geplante Verbesserungen einbaut.

So, liebe Leserinnen und Leser, wieder einmal haben wir Ihnen einige TEX-Tricks verraten, aber die Krönung der Hardware-Überlistung steht noch aus: Es handelt sich hierbei um die Beseitigung von Grenzen im wortwörtlichen Sinne. In der nächsten Ausgabe verraten wir Ihnen, wie Sie Grafik dort darstellen, wo sich normalerweise der untere Rand des ST befindet. Mit Hilfe dieses Tricks sind Sie dann in der Lage, effektiv mehr Zeilen darzustellen, als sie die Entwickler des ST je vorsahen. Sollten Sie einen Monitor besitzen, bei dem vom unteren Rand nicht viel zu sehen ist, dann stellen Sie ihn schon einmal so ein (oder lassen dies tun), dass dort einige Zentimeter unbenutzt sind. Denn dieser Platz wird nächsten Monat gebraucht.

Ich hoffe, dass auch für Sie diese Folge mit einigen heissen Tipps versehen war. Seien Sie gespannt auf das große Finale in der nächsten Ausgabe...Bye, bye.

Für den letzten Teil ihrer Serie mit Assembler-Tricks haben die "Exceptions" ein großes Finale vorbereitet. Die Krönung der Hardwareüberlistung ist angesagt, denn heute geht es den Bildschirmrändern an den Kragen. Gunter erklärt, wie Sie Grafik in den unteren und oberen Rand des Bildschirms schreiben und welch wichtige Rolle die MMU dabei spielt. Als Extra-Bonbon verraten TEX ausserdem, wie sich 35 Farben pro Bildschirmzeile darstellen lassen.

So, das ist ja wohl das Letzte. Ja, ja dies ist wahrhaftig die letzte Folge der TEX-Serie im ST-Magazin. Uff, nie mehr muss ich (Erik) eines dieser merkwürdigen Vorworte schreiben. Endlich kommt die Hardware Ihres Rechners wieder etwas zur Ruhe, aber nicht, bevor wir noch einige lustige Sachen aus dem ST geholt haben. Ich bin nicht sicher, ob die Entwickler unseres guten Atari wissen, was alles aus ihrer schäbigen Videoelektronik herauszuholen ist. Sicher denken Sie jetzt, dass wir in dieser Folge endlich verraten, wie man Grafik im Bildrand des ST darstellt. Nun, das ist natürlich völlig richtig und war ja schließlich lange genug angekündigt. Nach reiflicher Überlegung haben wir uns sogar schweren Herzens dazu entschlossen, nicht nur das Geheimnis des Entfernens des unteren, sondern sogar auch die (teilweise) Beseitigung des oberen Randes zu verraten.

Wie verrückt muss jemand sein, um auf die Idee zu kommen, zusätzliche Grafik in irgendwelchen Rändern darzustellen ? Noch dazu, wo der Videoshifter nicht gerade vor Registervielfalt strotzt.

An dieser Stelle muss ich betonen, dass nicht wir auf die Idee mit der Rahmengrafik gekommen sind (allerdings haben wir oft genug den Erfinder der unteren Rahmengrafik erwähnt). Den Stein brachte nämlich vor zirka 1 1/2 Jahren ein Mensch aus Mannheim ins Rollen. Er nannte sich Alyssa (Hallo Sven, lebst Du noch?) und verbreitete damals das Gerücht, dass es ihm gelungen sei, im unteren Rand zusätzliche Grafik darzustellen. Natürlich taten wir das einzig vernünftige: Wir erklärten ihn kurzerhand für verrückt. Kurze Zeit später blieb uns das Lachen im Halse stecken, denn er gab uns prompt eine Kostprobe seines Könnens, und wir trauten unseren Augen kaum: Da unten war tatsächlich etwas ! Mit vor Aufregung zitternden Händen luden wir den beiliegenden Source-Code in den Editor und sahen uns dort die Methode an, nach der das Wunder geschah.

Die genaue Erklärung des Tricks folgt später, wie allerdings Sven auf diese Methode kam, vermögen wir nicht zu ermessen. Wir können uns höchstens vorstellen, dass er vorher einen C 64 besaß, denn dort wird an derselben Stelle (letzte Zeile, siehe unten) der Trick zum Randaufklappen angesetzt, auch wenn dort etwas völlig anderes geschieht, um den Rahmen zu beseitigen. Wir waren also ziemlich geplättet, allerdings hinderte uns das nicht daran, Svens Methode aufzugreifen, zu verbessern und fortzuführen, so dass wir heutzutage auch Grafik im linken und rechten Rand und überhaupt in allen Rändern darstellen können. Aber ein paar Geheimnisse wollen wir noch behalten, deshalb wird Gunter Ihnen zunächst alles über die restlose Beherrschung des Elektronenstrahls und dann nicht alles über Rand-Programmierung verraten...

Moin, liebe Leser, hier Gunter auf den Tasten. Nachdem Sie wohl in unserer letzten Folge von der programmtechnischen Seite nicht überfordert wurden, geht's heute wieder ans Listingtippen (vier Stück, hä, hä). Wenn Sie beim Abtippen etwas aufpassen, können Sie sich allerdings Arbeit sparen, denn es kommen einige Programmteile doppelt vor.

Es handelt sich diesmal um den unteren und oberen Rand, besser gesagt nicht um den Rand selbst, sondern darum, wie wir ihn verschwinden lassen. Ferner möchte ich Ihnen noch etwas über Synchron-Programmierung erzählen. Ich hoffe, Sie verzeihen mir diesen selbsterfundenen "Fachausdruck", aber die Sache ist ganz einfach: Prinzipiell. Trotzdem hole ich wohl doch besser ein wenig aus:

Der ST ist ja bekanntlich mit 8 MHz getaktet, das macht in einer Sekunde 8 000 000 Taktzyklen. Wie fast immer hängt nun alles mit dem periodischen (Fernseh-/ Monitor-) Bildaufbau zusammen. Dividieren wir die 8 000 000 durch 50, das ist, wie Ihnen bestimmt bekannt ist, die Anzahl der Bilder pro Sekunde, so erhalten wir die Anzahl der Taktzyklen pro Bild. Nun dividieren wir die Zahl noch durch 313, das ist nämlich die Anzahl der Zeilen pro Bild. Haben Sie auch (ungefähr) 512 herausbekommen ? Gut, das ist die Anzahl der Taktzyklen, die der Elektronenstrahl braucht, um eine Zeile zu schreiben. Diese Rechnung stammt übrigens von Erik. Er stellte damals recht eindrucksvoll unter Beweis, dass seine Fernsehtechniker-Lehre doch zu etwas zu gebrauchen ist.

Was können wir nun damit anfangen ? Unser einfaches Programm (Listing 1) macht sich diese Tatsache zunutze und erzeugt zirka 35 vertikale Farbbalken. In einer Zeile befinden sich also tatsächlich 35 Farben. Das erregt natürlich Aufmerksamkeit, denn selbst mit Rasterinterrupts lassen sich nur 16 Farben pro Zeile erzeugen. Der Trick hinter dieser Geschichte ist ganz einfach: Die Schleife zwischen "loop:" und "dbf d0,loop" ist nämlich genau 512 Taktzyklen lang. Dadurch kommen in jeder Zeile immer gleiche Farben untereinander. Der "move.w #$2700,sr" ist unbedingt notwendig, damit kein Interrupt das empfindliche Timing stört. Genauso fürchterlich wirkt es sich aus, wenn die Schleife nicht 512 Zyklen lang ist. Lassen Sie doch mal einen "nop" weg ! Das Malprogramm "Spectrum 512" arbeitet übrigens auch nach dieser Methode. Natürlich ändert Spectrum nicht nur die Hintergrundfarbe, sondern wechselt alle 16 Farben der Reihe nach. Das Prinzip ist aber das gleiche. Besonders praktisch ist unser erstes Programm allerdings noch nicht. Man kann es nicht vorzeitig abbrechen, die Lage der Farbstreifen ist nicht vorhersehbar (starten Sie das Programm mehrmals), und die gesamte Rechenzeit des Prozessors wird "verbraten". Wie wir diese Probleme lösten, erkläre ich Ihnen ein paar Kapitel weiter. Doch nun machen wir uns wie versprochen an den unteren Rand.

Ich hoffe, Sie haben unseren Artikel über Rasterinterrupts noch im Kopf, denn die brauchen wir jetzt wieder. Um den unteren Rand zu entfernen, müssen Sie in der letzten Bildschirmzeile (Zeile 199) rechts im Rand auf 60 Hz schalten. Kurz danach, im linken Rand, müssen Sie wieder auf 50 Hz zurückschalten. Der richtige Zeitpunkt ist dabei sehr wichtig. Liegt der Umschaltpunkt schon im Bild, hat dies eine hässliche Verzerrung der Grafik zur Folge. Graben Sie also wie gesagt die Raster aus und legen Sie los.

Allen, die den Artikel über die Rasterinterrupts nicht kennen, sei kurz gesagt, dass "hblon:" die Raster aktiviert. Bei Erreichen des rechten Randes der Zeile 198 löst das Programm einen Interrupt aus. Danach springt der Prozessor in die Routine "newtb:". Hier wird es dann interessant. Zunächst warten wir auf den rechten Rand der Zeile 199 (letzte "offizielle" Bildschirmzeile). Deshalb müssen Sie den Interrupt auch eine Zeile vorher auslösen. Sofort nach der Warteschleife schalten wir auf 60 Hz. Nach einer kurzen Verzögerung gehen wir wieder auf 50 Hz zurück. Das war's ! Der untere Rahmen ist nun verschwunden. Der Bildschirmspeicher läuft ganz normal weiter, das heißt $7d00 Bytes nach Beginn des Bildschirms befindet sich der Speicher für die Bordergrafik. Sie können hier zum Beispiel die Laufschrift aus der Juli-Ausgabe des ST-Magazins hineinsetzen, und schon haben Sie einen schönen Borderscroller. Unser Beispielprogramm (Listing 2) füllt lediglich den kompletten Bildschirm mit einem kleinen Muster.

Wagen wir uns nun an den oberen Rand. Hier ist die Sache nicht ganz so einfach. Es gibt zwar eine recht einfache Methode, die aber einen entscheidenden Nachteil hat: Sie ist stark Computer- und Monitor-abhängig. Oder anders ausgedrückt: Auf der Hälfte aller STs geht dieser Trick in die Hose. Meistens ist das Bild stark verzerrt und eine damit kombinierte Routine, die den unteren Rand aufmacht, funktioniert nun gar nicht mehr. Sollten Sie also irgendwo ein Demo (garantiert nicht eins von uns) sehen, das diese Effekte zeigt, so ist wahrscheinlich eine falsche Routine für den oberen Rand am Werk. Genug gelästert, jetzt verrate ich endlich, wie man es richtig macht.

Mit unserer Methode, die ein gewisser Andreas von Level 16 verbessert hat, lässt sich nicht der gesamte obere Rand entfernen. Es gibt eine bestimmte Stelle, die sich je nach Computerversion 13 oder 29 Zeilen über dem regulären Bildanfang befindet, an der sich der obere Rand öffnen lässt. Ja, Sie haben leider richtig gelesen, es gibt in der Tat zwei (ich hoffe, dass es nicht noch mehr gibt) verschiedene Rechnerversionen. Schuld an diesem Dilemma sind wohl unterschiedliche MMU-Versionen. Denn wir überlisten bei der ganzen Border-Grafik eigentlich die MMU und nicht den Shifter, wie des öfteren behauptet wird. Die MMU "entscheidet" im ST darüber, wann der Shifter Grafik darstellt und wann er einen Rahmen anzeigt. Der Shifter selbst ist wirklich strohdumm. Selbst im Rahmen muss die MMU ihm noch kontinuierlich Nullen liefern. Genau hier überlisten wir die MMU dann auch und bringen sie dazu, keine Nullen zu liefern, sondern den Grafikspeicher weiter auszulesen.

So, nun aber endlich zum oberen Rand. An den unterschiedlichen MMU-Versionen lässt sich leider nichts ändern. Wir können aber durch einen kleinen Trick sicherstellen, dass der ST den Rand auf jeder Computerversion sicher öffnet. Wir bauen also die bekannte 50-/ 60-Hz-Umschaltung einfach 29 und zusätzlich 13 Zeilen über dem Bildanfang ein. Dadurch öffnet sich der Rand in jedem Fall. Je nachdem, welchen Computer Sie besitzen, haben Sie nun 29 oder 13 Zeilen mehr von Ihrem Bildschirm. Die zweite Umschaltung stört.

Jetzt taucht allerdings noch ein weiteres Problem auf. Ich rede die ganze Zeit davon, dass wir über dem Bildbeginn umschalten müssen. Leider lässt sich dort kein Rasterinterrupt setzen, da der Timer B naturgemäß erst bei Bildbeginn losläuft. Nun, da hilft kein Jammern und Stöhnen, wir müssen in den sauren Apfel beißen und fleißig Rasterzeit "verbraten". Wir lösen in der letzten möglichen Bildschirmzeile einen Rasterinterrupt aus. Dann warten wir einfach so viele Zeilen ab, bis wir nach der vertikalen Austastlücke die richtige Stelle erreicht haben, an der wir den oberen Rand öffnen. Diese Warterei bewerkstelligen wir am besten mit einer Schleife, die ein Vielfaches von 512 Taktzyklen verzögert. Sie erinnern sich; ich habe Ihnen vorhin erklärt, dass eine Zeile genau 512 Taktzyklen besitzt.

Nehmen Sie jetzt Listing 3 zur Hand und versuchen, mit mir die größten Geheimnisse der Ränder zu erforschen.

Zunächst lösen wir ein Raster aus, der nach altbekannter Methode den unteren Rand öffnet. Denken Sie jetzt nicht, dass der obere Rand nur in Verbindung mit dem unteren zu öffnen ist. Wir öffnen den unteren Rand vielmehr, um Rechenzeit zu sparen. Dazu setzen wir einen zweiten Raster 47 Zeilen tiefer. Dieser zweite Raster ("newtb2:") sitzt auf der letztmöglichen Zeile, die noch alle STs verkraften. Erst hier müssen wir unsere rechenzeit-schluckende Warteschleife aufrufen. Hätten wir den unteren Rand nicht geöffnet, so hätten wir zusätzlich 47 Zeilen mehr warten müssen. Die erste Warteschleife endet 29 Zeilen über dem Bild. Hier probieren wir nach der gleichen Methode, die wir schon im unteren Rand angewendet haben, den oberen Rand zu öffnen. Danach müssen wir nochmal 15 Zeilen warten, um dann auch an der zweiten Stelle unser Glück zu versuchen. So nebenbei stellt das Programm den alten Level 4-Vektor wieder her. Wir benötigten die geänderte Level 4-Routine nur für den allerersten Durchgang. Von nun an rufen sich die beiden Timer-B-Routinen gegenseitig auf. Nach dem zweiten Versuch, den oberen Rand zu öffnen, laden wir nämlich das Timer-DATA-Register mit dem Wert 199+13. So treffen wir wieder genau die Stelle, an der der untere Rand aufgeht (13 Zeilen oberer Rand + 199 Zeilen im regulären Bild). Hier schließt sich der Kreis.

Im Listing sind an den Umschaltstellen noch ein paar Kontrollfarben vorhanden. Zwischen Grün und Weiß wird der untere Rand geöffnet. Die zwei Umschaltpunkte für den oberen Rand befinden sich zwischen Weiß und Rot sowie zwischen Rot und Grün. Damit stellen Sie fest, welche MMU-Version Sie besitzen. Je nach Version beginnt das Hintergrundmuster schon nach Weiß oder erst nach Rot. Wir haben übrigens die Erfahrung gemacht, dass vor allem ältere STs 13 Zeilen mehr im oberen Rand darstellen, während die neueren Modelle immerhin 29 Zeilen schaffen. Dafür ist bei diesen der untere Rand kleiner. Nachdem Sie wohl nun von Rändern und deren Beseitigung genug haben dürften, komme ich abschließend noch einmal auf unsere Farbstreifen zurück: Sie erinnern sich an die Geschichte mit den 512 Taktzyklen. Das erste Programm war ja ziemlich unbrauchbar. Das wollen wir jetzt ändern. Das Hauptproblem ist, dass sich die Routine nicht unterbrechen lässt, um zum Beispiel Musik zu spielen, da sich beim nächsten Bildaufbau die Streifen verschieben. Man müsste einen Weg finden, bei jedem Bild die Streifen neu zu synchronisieren, so dass sie immer an der gleichen Stelle stehen. Danach könnte man diese Routine verlassen und hätte noch Rechenzeit übrig. Unser erster Versuch ging über die Rasterinterrupts (ja, ja, schon wieder). Wir setzten auf eine beliebige Bildschirmzeile einen Interrupt. Die lnterrupt-Routine bestand im wesentlichen aus Listing 1. Der "dbf"-Zähler war natürlich auf 100 Bildschirmzeilen gekürzt. Das Ergebnis war nicht sonderlich toll (würg). Die Streifen flackerten wild umher. Eigentlich ist es auch ganz logisch, dass es so nicht (ganz) funktioniert, denn der lnterrupt kommt nie auf den Taktzyklus genau. Sie kennen ja das Problem mit den flackernden Rastern. Nach längerem Grübeln fand ich dann den Video-Adresszähler der MMU, ein Register, das eigentlich noch nie gebraucht wurde. Die MMU führt in diesem Register aufs Wort genau die Speicheradresse mit, die sie gerade ausliest und dem Shifter übermittelt. Jetzt müssen wir nur noch wissen, dass die MMU alle vier Taktzyklen ein Wort ausliest (glauben Sie es einfach) und dies gleich im Register vermerkt. Ein Byte entspricht also zwei Taktzyklen. So, mit diesem Vorwissen bringen wir die Balken nun zum Stehen:

Zunächst setzen wir noch einen Raster auf die Zeile, ab der wir die Balken haben wollen. Dabei müssen Sie aber beachten, dass Sie den Raster nur auf eine durch 8 teilbare Zeile minus 1 setzen dürfen. Wieso ? Haben Sie noch einen Augenblick Geduld. Nehmen wir also zum Beispiel die Zeile 127 (siehe Listing). In der HBL-Routine warten wir wie gewohnt eine Zeile ab; deshalb die "minus 1". Wir befinden uns jetzt also im rechten Rand. Werfen wir einen Blick auf den Video-Adresszähler, er zeigt schon die erste Adresse der nächsten Bildschirmzeile an. Aber er steht natürlich, da momentan kein Bildschirmspeicher ausgelesen wird. Und nun kommt Trick Nummer 1: Zu Beginn jeder 8. Bildschirmzeile ist das Low-Byte des Zählers 0. Wissen Sie jetzt, warum wir den Raster nur in Achterschritten verändern dürfen ? In einer kleinen Warteschleife (Label: "waitloop") lauern wir nun darauf, dass der Zähler weiterläuft. Denken Sie nicht, dass dies allein ausreicht. Die Warteschleife ist im Prinzip genauso ungenau wie das Warten auf den rechten Rand nach der altbewährten Methode über das Timer-B-DATA-Register. Aber werfen Sie nochmal einen Blick auf das Listing. Mit Absicht steht hier nämlich ein "move.b (a0),d0", obwohl ein "tst.b (a0)" eigentlich ausreicht. Wir haben also den ersten von 0 verschiedenen Wert des Zählers in d0. Erfahrungsgemäß sind dies Werte zwischen 2 und $c. Überlegen wir nun, was das heisst. Je höher dieser Wert ist, desto weiter ist der Elektronenstrahl schon vom linken Rand entfernt. Der Elektronenstrahl ist ja direkt vom Video-Adresszähler abhängig. Wir müssen das folgende Programm nun so gestalten, dass bei kleinen Werten eine längere Verzögerung eintritt als bei großen.

Mein erstes Programm löste dieses Problem, indem es jeden möglichen Wert einzeln abfragte und daraufhin in eine verschieden lange "Pauseschleife" verzweigte. Es war eine wilde Taktzyklen-Zählerei und sah auch nicht sehr schön aus. Doch unser Freund Michael von der TNT-Crew kam dann auf eine sehr schöne Lösung, die ich Ihnen auch zeigen möchte (danke, Michael !).

Es sind genau drei Befehle notwendig: Zunächst subtrahieren wir unser d0 von 30 (moveq # 30,d2 und sub d0,d2). 30 ist so hoch gewählt, dass das Ergebnis garantiert positiv ist. Das Register d2 gibt also jetzt an, wie viele Taktzyklen mal zwei wir warten müssen. Sie erinnern sich, die MMU benötigt für ein Byte 2 Taktzyklen. Und nun kommt der entscheidende Befehl: "lsl.l d2,d0". Im Prozessorbuch steht nämlich, dass der lsl genau 8+2*n Taktzyklen braucht. n steht für die Anzahl der Verschiebungen. Also könnte man auch sagen 8 + 2*d2. Das ist aber genau die Verzögerung, die wir benötigen.

Puh ! Ich hoffe, das Ganze war Ihnen nicht zu lang. Wenn ja, dann merken Sie sich einfach, dass dieser Programmabschnitt die ganze Sache synchronisiert, und vergessen den Rest wieder. Danach können wir also (endlich) die 512 Taktzyklenschleife aus Listing 1 dranhängen, und fertig sind ein paar farbige Balken über 100 Zeilen, die ungefähr ein Drittel Rechenzeit benötigen. Vor allem lässt sich neben dem Hauptprogramm noch etwas anderes machen, zum Beispiel ins Desktop zurückgehen. Ja, ja, ich weiß. Das Ganze lässt sich noch etwas durch Floppy- und Harddiskzugriffe aus der Ruhe bringen, aber es sollte auch nur ein kleiner Gag am Rande sein.

Schließlich und endlich wollen wir doch noch das letzte Manko beseitigen. Ich hatte erwähnt, dass wir nur jede achte Zeile synchronisieren können. Trotzdem lassen sich die Farbbalken auch zeilenweise verschieben. Wir fügen einfach noch eine zusätzliche Warteschleife ein, die so aufgebaut ist, dass sie um ganze Vielfache von 512 Taktzyklen verzögert. Mit Werten zwischen 1 und 8 lassen sich die Balken fein verschieben (0 bis 7, da es sich um einen "dbf" handelt). Wer größere Sprünge haben will, kann ja den Raster verschieben.

Ursprünglich wollte ich zumindest noch ein paar Worte über den rechten Rand verlieren, aber mir wurde unter Androhung von schlimmsten Strafen verboten, schon jetzt darüber zu berichten. Aber wenn genug Leser irgend etwas in der Art von "Zugabe" oder ähnlichem brüllen, lassen wir uns vielleicht breitschlagen, auch unsere intimsten Geheimnisse preiszugeben.

Hier ist wieder Erik. Die anderen haben mir gesagt, ich solle noch einige Abschiedsworte schreiben. Nun, warum so sentimental ? So müssten eigentlich alle zufrieden sein. Sind Sie es, dann schreiben Sie einen Leserbrief. Sind Sie es nicht, könnten Sie doch auch einen Leserbrief schreiben, oder ? Wie dem auch sei, uns hat es Spaß gemacht, diese Serie zu schreiben, und wir hoffen, dass Ihnen sowohl der Inhalt, als auch unser Stil gefallen hat. Wir möchten uns von Ihnen verabschieden; wie oben erwähnt, "sehen" wir uns vielleicht einmal wieder, bis dann, tschüss !

Jawohl, sie sind wieder da ! Nach ihrer überaus erfolgreichen ST-Magazin-Serie für Programmierer im vergangenen Jahr melden sich die Assembler-Profis der "Exceptions" auf Ihren besonderen Wunsch mit einer weiteren Folge zurück: Heute geht es dem rechten Bildschirmrand an den Kragen.

Hallo liebe Leser und Freunde unserer kleinen TEX-Serie. Nach einem halben Jahr Pause ließ uns ein gewisser Mitarbeiter des ST-Magazins (Hallo Tarik !) nicht mehr in Ruhe und berichtete uns pausenlos von Ihren Briefen, in denen Sie sich eine Fortsetzung der TEX-Serie wünschen. Das Ergebnis von Tariks Hartnäckigkeit sehen Sie nun auf diesen Seiten: Eine neue Folge der Hexer ist da. Worum es diesmal geht, habe ich schon in unserem letzten Artikel angedeutet. Ich werde Ihnen heute erzählen, wie man softwaremäßig den rechten Rand beseitigt. Anschließend gibt's dann noch einen Scroller über den linken und rechten Rand, der überhaupt keine Ränder öffnet. Das klingt vielleicht seltsam, aber lassen Sie sich überraschen. Keine Angst, wir verraten auch noch das Geheimnis des linken Randes, allerdings erst in der nächsten Ausgabe.

Rufen Sie sich nun unseren letzten Artikel ins Gedächtnis. Für alles, was ich Ihnen oben versprochen habe, brauchen wir die sogenannte "Synchron-Programmierung". Falls Sie den Artikel nicht mehr zur Hand haben, fasse ich noch einmal kurz das Wichtigste zusammen. Die Experten unter Ihnen dürfen die nächsten Absätze getrost überfliegen.

Der wichtigste Grundsatz der Synchron-Programmierung ist die Tatsache, dass der Elektronenstrahl genau 512 Taktzyklen benötigt, um eine Zeile zu schreiben. Man kann dies an einem netten Effekt ganz gut verdeutlichen. Setzen Sie einfach Befehle, die die Hintergrundfarbe ändern (also "move.w #$-xxx,(a0) mit a0 = $ff8240") untereinander und ans Ende einen Sprung an den Anfang des Programms, bis die Schleife genau 512 Taktzyklen lang ist. Sollte es nicht aufgehen, fügen Sie noch ein oder zwei "NOPs" (4 Taktzyklen) ein. Wichtig ist noch, dass keine Interrupts auftreten, da diese das Timing durcheinanderbringen.

Setzen Sie zu Beginn das Statusregister auf $2700. Haben Sie alles richtig gemacht, sehen Sie zirka 30 senkrechte Farbbalken auf dem Bildschirm. Da das Programm auf den Taktzyklus genau synchron läuft, kommen in jeder Zeile immer die gleichen Farben untereinander, und schon entstehen die Balken. Besonders praktikabel ist dieses Programm allerdings noch nicht, da der Prozessor in der Schleife festhängt, und keine Zeit für andere Aufgaben mehr übrig ist. Deshalb gibt es eine Methode, wie sich jeder VBL in einer beliebigen Zeile neu synchronisieren lässt. Anschließend arbeiten Sie die Sync-Schleifen ab und verlassen die Routine, um das restliche Programm wieder zum Zuge kommen zu lassen. Logischerweise hängt die freie Rechenzeit direkt mit der Anzahl der Zeilen, die Sie im Synchronprogramm nutzen, zusammen. Die eigentliche Synchronisation läuft folgendermaßen ab: Zunächst setzen Sie einen Rasterinterrupt auf die synchronisierende Zeile. Dann warten wir wie gewohnt (über das Timer B Data Register) auf den Beginn des nächsten rechten Randes. Genaugenommen muss der Raster auf einer durch acht teilbaren Bildschirmzeile minus eins sitzen. Für den Sync-Trick nutzen wir nämlich die Tatsache aus, dass das Lowbyte des Video-Adresszählers zu Beginn jeder achten Zeile auf Null steht. Der Raster muss natürlich eine Zeile höher sitzen, da wir auch eine Zeile warten. Zum Synchronisieren warten wir nun, bis besagtes Lowbyte erstmals wieder von Null verschieden ist und merken uns diesen Wert, den wir unmittelbar von 30 subtrahieren (30 ist willkürlich gewählt, es muss nur sichergestellt sein, dass das Ergebnis in jedem Fall positiv ist). Nun haben wir ein direktes Maß für die Verzögerung , bis wir mit dem Elektronenstrahl synchron sind, in der Hand oder vielmehr im Datenregister. Da die MMU pro Byte genau zwei Taktzyklen benötigt, gibt unser Wert mal zwei genommen an, wie viele Taktzyklen wir noch warten müssen. Zum Glück gibt es aber einen Befehl, der dies automatisch erledigt: lsl.w dx,dy . Er benötigt laut Handbuch 8+2n Taktzyklen. Nehmen wir unser obiges Rechenergebnis und lassen damit ein "Dummy"-Register rotieren. Ab hier sind wir synchron und können beliebige Routinen einbauen, zum Beispiel eine "Randaufklapproutine" für den rechten Rand.

Ich hoffe, das hat als Vorinformation gereicht, lassen Sie schon einmal den Atari ST warmlaufen, erzählen Sie ihm aber nichts von einer neuen TEX-Folge, sonst geht Ihr Computer vielleicht in einen vorübergehenden Warnstreik. Meiner zeigte schon erste Ausfälle, als ich die Listings für Sie zusammenstellen wollte. Ich habe ihn aber geschickt mit 1st Word überlistet und habe erst einmal folgende Zeilen getippt.

Das Geheimnis des rechten Randes war schon früh gelüftet. Damals hatten wir gerade frisch geknüpfte Kontakte zu einer neuen deutschen Softwarefirma, und so ergab es sich, dass sich fast unsere gesamte Truppe über die Ferien im Bielefelder Raum tummelte (was nicht gerade in unserer Gegend liegt). Mir war da so eine Idee gekommen, was man mit der schönen Routine, die viele senkrechte Farbbalken auf den Bildschirm zaubert, noch alles anfangen könnte. Nach wenigen Worten mit Udo stürzte dieser begeistert an den Computer, stieß Erik beiseite, der dort zufällig saß. Neochrome verschwand zusammen mit einem angefangenen Bild aus dem Speicher; ich glaube Erik hat es nie mehr vollendet. Wenige Augenblicke später saßen wir dann beide vor dem Bildschirm, im Speicher nun der Source, der bis jetzt nur viele Farben erzeugen konnte.

Es dauerte dann keine fünf Minuten mehr, und der rechte Rand war offen. Wenn Sie später meine genauen Erläuterungen im Listing sehen, verstehen Sie dann auch, warum es damals so schnell ging. Der Trick ist prinzipiell sehr einfach, es funktioniert genauso, wie mit dem unteren Rand. Hier schaltete man einfach in der letzten Bildschirmzeile auf 60 Hz und wieder zurück. Mit dem rechten Rand ist es ähnlich. Hier schalten Sie in jeder Zeile, in der der Rand geöffnet werden soll, kurz vor Beginn derselben auf 60 Hz und sofort wieder zurück. Nur müssen Sie diese Stelle recht exakt treffen, es läuft auf eine "Synchron-Schleife" hinaus, die sie kennen (sollten). Wir dehnten diese Experimente gleich auch auf den linken Rand aus, allerdings erfolglos. Mit einer einfachen 60/50 Hz-Umschaltung irgendwo im linken Rand war es offenbar nicht getan. Wir hatten allerdings ein lustiges Ergebnis. Man kann den ST dazu bewegen, überall Rand darzustellen, indem man am Ende des linken Randes die 60/50- Hz Umschaltung einbaut. Allerdings wurde dieser Trick mangels Verwendungszweck wieder ad acta gelegt. Schließlich gibt es auch einfachere Methoden einen einfarbigen Bildschirm zu erhalten. Wir gaben uns zunächst einmal mit dem rechten Rand zufrieden. Durch geschicktes Experimentieren stellte sich heraus, dass der ST nun 204 Byte pro Zeile darstellt. Schnell war der Bildschirm mit einem Muster gefüllt, und auch ein einfacher 1-Plane-Scroller an die neue Screenbreite angepasst. So war dann an einem Abend der "Overscan-Screen" des Amiga-Demos fertig. Bis allerdings das gesamte Demo fertig war und von einer Boot-Disk lief, verging noch ein wenig Zeit.

Wir machten auch noch ein Intro, dessen Scroller sich ebenfalls im rechten Rand tummelte. Aber die ganze Sache wirkte immer so unsymmetrisch. Wir haben einfach immer unser Bild am Monitor nach links gedreht, aber das gilt schließlich nicht. Wir überlegten uns, wie sich zumindest ein Scroller auch im linken Rand darstellen lässt. Damals weigerte sich dieser Rand ja noch hartnäckigst aufzugeben, und so mussten wir uns etwas besonders Ausgefallenes einfallen lassen, um einen "symmetrischen" Scroller zu erzeugen. Für die Lösung musste mal wieder der Farbbalken-Trick herhalten. Statt vieler Hintergrund- Farben verwendeten wir diesmal nur zwei, nämlich eine x-beliebige Farbe und Schwarz (Hintergrund). Hält man diese beiden Farbwerte in zwei Registern (d0 und d1) kann man durch Kombination von zwei Befehlen, nämlich move.w d0,(a0) ;a0 = $ff8240 und move.w d1,(a0) Muster mit einer horizontalen Auflösung von 8 Pixeln erzeugen. Arbeitet man diese Befehlskette, die natürlich wieder genau 512 Taktzyklen lang sein muss, in einer Schleife ebenfalls 8mal ab, so erhält man schöne quadratische Kästchen mit 8 x 8 Pixel auf dem Bildschirm. Der Vorteil dieser Methode: Da wir nur die Hintergrundfarbe umschalten, sind wir von Rändern unabhängig. Hintergrundfarbe ist schließlich überall vorhanden. Jetzt braucht man nur noch mehrere dieser Kästchenreihen untereinander zu setzen und schon hat man einen zwar sehr groben, dafür aber über das gesamte Bild laufenden Scroller.

Diese Routine wurde übrigens für das erste Union-Intro geschrieben. Der Name Union dürfte spätestens seit dem Erscheinen des Union Demos allen ein Begriff sein. Interessiert es Sie, wie es zu dieser Gruppe kam ? Wie Sie vielleicht wissen, gibt es noch eine zweite große Gruppe in der "Szene", die "Bladerunners". Sie existieren schon eine ganze Weile länger als die Union und waren der Grund für uns (ich meine jetzt die Gründer der Union) eine zweite "Dachorganisation" für ST-Freaks aufzumachen. Denn die Qualität der Bladerunner Intros und Demos ließ doch (zumindest am Anfang) schwer zu wünschen übrig. Also setzten wir uns zusammen, tauschten Erfahrungen und Source-Codes aus und machten uns zum Ziel, vernünftige Demos zu programmieren. Das war der eigentliche Zweck der Union, Programme zu "knacken" war und ist nur eine Nebenaktivität, die nicht (mehr) alle Mitglieder der "Union" billigen. Insgesamt ist es viel effizienter, wenn jeder ein bisschen zum Ganzen beiträgt. Ansonsten würde sich vielleicht jeder zu Hause abmühen und am Ende ist fünfmal das gleiche da, nur mit einem anderen Namen im Scrolltext. Das tatsächlich etwas dabei herausgekommen ist, sieht man wohl an unserem Demo, oder ?

Nun aber genug der Selbstbeweihräucherung, fangen wir endlich an. Wir nehmen uns zuerst den rechten Rand vor. Listing 1 entfernt ihn sachgemäß. Im wesentlichen dürfte Ihnen das Programm aus unserem letzten Artikel bekannt vorkommen. Es enthält die Standard HBL-Routinen, die den Rasterinterrupt in diesem Fall auf Zeile 31 setzen. Die Position ist natürlich nach Bedarf in den altbekannten Achterschritten verschiebbar. Hinzugekommen ist die Routine "prepare". Sie füllt den Bildschirm zunächst mit Farbe 15 auf, damit man sieht, wo der Rand beginnt. Anschließend wird dort, wo sich später der Rand öffnet, ein kleines Kästchenmuster gezeichnet. Die Timer B Routine synchronisiert sich wie oben beschrieben über den Videoadresszähler mit anschließendem "lsl.w d2,d1". Nun wird es langsam interessant. Die folgende Verzögerung (delayloop 1) ist so abgestimmt, dass die eigentliche Sync-Schleife (zeilenloop2) genau in der horizontalen Austastlücke beginnt, außerhalb des Bildes. Die Sync-Schleife ist fast völlig leer, nur an einer Stelle kurz vor dem (ehemaligen) Beginn des rechten Randes sitzt die schon erwähnte Umschaltung auf 60 Hz (move.b d4,[a]) und sofort danach der Befehl zum Zurückschalten auf 50 Hz (move.b d3,[a0]). In unserem Beispiel wird die Schleife 150mal abgearbeitet. Natürlich ist auch dieser Wert variabel. Kritisch wird es nur, wenn wir die Schleife auch im Bereich des unteren Randes abarbeiten. Von alleine geht der untere Rand leider nicht auf. Da müssten Sie schon noch eine zusätzliche Umschaltung für den unteren Rand in die 200. Zeile einbauen. Sie wissen ja noch, wie es geht, oder ? Um Platz zu sparen, habe ich das Block (blk) Kommando des Seka recht intensiv eingesetzt. Der Befehl blk.w 30,$4e71 bedeutet, dass der Assembler hier 30mal das Wort $4e71, was nichts anderes als der Befehl nop ist, einsetzt. Haben Sie kein vergleichbares Kommando in Ihrem Assembler, so müssen Sie eben 30 NOPs untereinander kopieren. So, jetzt passen Sie noch probeweise Ihre Scroll-Routine an 204 Byte pro Zeile an, dann sind Sie schon in Übung, denn im nächsten Monat wird Ihr ST 230 Byte in jeder Zeile darstellen. Bis dahin dürfen Sie sich mit unserem Hintergrundfarben-Scroller beschäftigen. Das Hauptprogramm sowie die HBL-Routinen sind inzwischen wohl hinreichend bekannt. In der new4-Routine ist eine kleine Besonderheit eingebaut. Der Scroller kann in jeder beliebigen Bildschirmzeile (1 bis 200) beginnen. Deshalb wertet die Level 4 Routine eine Koordinatentabelle (jumpbahn) aus, die den Scroller auf und ab springen läßt. Wem dies zu viel Tipparbeit ist, kann die Tabelle auch kürzen. Wie üblich ist -l die Endekennung, nicht vergessen ! Die Position des Rasters ergibt sich durch das Aufteilen der Koordinaten in die nächst kleinere Zahl, die durch 8 teilbar ist. Den verbleibenden Rest schreiben wir zunächst in der Variablen "scandelay". Das Synchronprogramm verschiebt dann den Scroiler zeilenweise um diesen Wert nach unten. Die Timer B Routine beginnt zunächst nach altbekanntem Schema: Eine Zeile warten, synchronisieren und noch einmal warten, bis der Strahl im rechten Rand ist. Dann folgt die oben angesprochene Verschiebung um ganze Zeilen (scandelay loop).

Nun kommt noch einmal ein kleiner Trick. Unser Scroller hat bekanntlich eine Auflösung von 8 Pixeln. Trotzdem scrollt er mit 4 Pixeln, was durchaus noch als "Soft"-Scrolling durchgeht. Dies wird durch die Variable "nummer" mit anschließendem "lsl.w d6,d6" bewirkt. Nummer, hat entweder den Wert 2 oder 0, deshalb verzögert der lsl.w einmal um 8+4 Zyklen, das nächste Mal nur um 8 Zyklen. Es bleibt eine Differenz von 4 Taktzyklen, was unserer Scrollgeschwindigkeit von 4 Pixeln entspricht. Die Routine hat jeden zweiten VBL nichts anderes zu tun, als "nummer" von 2 auf 0 zu ändern. Das Scrolling kommt dann ganz automatisch. Nach dieser kleinen aber wichtigen Verzögerung folgt der Programmteil, der den Scroller auf den Bildschirm bringt. Wie oben erwähnt, lässt sich die 8-Pixel-Auflösung nur durch move.w dx,(a1) erreichen. Der folgende Programmabschnitt enthält selbstmodifizierenden Code. Die move.w dx,(a1) Befehle werden in die Schleifen hineingeneriert. Die so entstandene Befehlskette (im Source als blk.w 55, $3280 zusammengefasst) steckt in einer 512 Taktzyklenschleife, die der ST jeweils acht Zeilen lang abarbeitet. Für den gesamten Scroller sind fünf dieser Schleifen vorhanden, da der Zeichensatz 5 Pixel hoch ist. Beim Aneinanderhängen der Schleifen muss man allerdings aufpassen. Der dbf-Befehl braucht leider 4 Taktzyklen mehr, wenn er nicht verzweigt. Der Scroller würde merkwürdig kursiv scrollen. Deshalb haben wir noch einen zusätzlichen bra.s inloopx eingebaut, der beim jeweils ersten Schleifendurchlauf 4 NOPs überspringt. Das ist genau der Differenzbetrag für dbf + bra.s. Nach der synchronen Anzeigeroutine folgt der Programmteil, der für das eigentliche Scrolling zuständig ist. Er ist nicht mehr synchron programmiert (wozu auch ?). Deshalb sind auch andere Interrupts erlaubt (move.w #$2500,sr). Zunächst prüfen wir, ob es genügt, "nummer" zu ändern oder ob zusätzliches Scrollen nötig ist. Im letzteren Fall kopieren wir zunächst die oben erwähnte "move.w dx,(a1)" Kette direkt im Programm um ein Wort nach links. Dies übernehmen für jede Schleife jeweils vier movem.l Befehle. Anschließend hängen wir das Bitmuster für die Pixelspalte ganz rechts an. Ist im Zeichensatz ein Bit gesetzt, generiert das Programm ein move.w d7,(a1), andernfalls ein move.w d0,(a1). "Bitnummer" gibt dabei an, welche Spalte des Zeichens das Programm gerade bearbeitet. Ist dies die Spalte null gewesen, müssen wir ein neues Zeichen aus dem Scrolltext holen. Eine negative Zahl (zum Beispiel -1) ist die Ende-Kennung, in diesem Fall beginnt der Text von vorne. Die Zahl 127 ist ein spezielles Steuerzeichen, das den Scroller für eine gewisse Zeit anhält. Empfängt der Scroller diesen Wert, holt die Routine noch ein zusätzliches Byte aus dem Text, das es mit 16 multipliziert. Dieser Wert gibt nun an, wie viele VBLs der Scroller stehen soll. Die Zeichen von 0 bis 49 sind gewöhnliche Zeichen, Werte größer 49 fängt das Programm nicht ab, passen Sie ein wenig auf, sie sind weder im Zeichensatz noch in der "proportionaltab" definiert ! Anhand der Zahl, die es aus dem Text liest, bestimmt das Programm die Adresse des Zeichens im Zeichensatz, die es sich in "buchst_addr" merkt, sowie die Breite des Zeichens aus der Proportionaltab, die in "bitnummer" vermerkt ist. Mit diesen Parametern übernimmt es dann das Zeichen in der "bitcopyloop" spaltenweise.

Listing 2 finden Sie aufgrund des enormen Umfangs nur auf der Leserservice-Diskette zu dieser Ausgabe.

The Exceptions geben eine Zugabe: Das ist ja wohl das Letzte ! Ja wirklich, auf absehbare Zeit ist dies das letzte Mal, dass 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 "FuIl-Screen-Demos".

Hallo, hier ist Andreas von Level 16 mit dem zweiten Teil der unglaublichen Geschichten (oder: "was Shiraz Shivji nicht weiss"). 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.

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, dass 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, dass 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 dass 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.

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 Adressregister unmittelbar zeigt. Als Assembler-Befehl heisst 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, dass 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?

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 TabeIle BILD die MOVE.W D0,(A6)-Befehle so ab, dass 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ässt sich somit weder abdrucken, noch passt er auf die Leserservice-Diskette. Deshalb habe ich eine verkürzte Version geschrieben, die Sie im Anschluss 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.

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. Dass 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 irgendein "Mann im Computer" festhielte ?

Die Erklärung liegt in einer Eigenart des ST begründet: Die CPU und MMU des ST teilen sich den Daten-/Adressbus. Daraus ergibt sich, dass es auf dem ST keine Befehle mit ungerader, das heisst 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, dass 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.

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 wiederum benötigen über hundert Taktzyklen. All dies vor dem Hintergrund, dass sich während der Programmierung praktisch unabwendbar Fehler einschleichen und man eventuell Teile komplett verwerfen muss.

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, dass 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 einmal 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ß.

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. Nachdem 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.

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 Misshandlung 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üsste jetzt in der Lage sein, Grafik auf allen Rändern darzustellen. Es gibt fünf Angriffspunkte: