Schlagwort-Archive: Atari ST

Exemplarisch wie ich mein SPACOLA-Remake entwickle, eine kleine Anekdote aus meinem Leben als Softwareentwickler: Bei meinen ziellosen Recherchen zur Historie des Atari ST und seiner erstaunlichen, reichhaltigen Public-Domain-Welt stolperte ich über eine kurze Spezifikation des Dateiformats für Bilddateien aus dem sehr beliebten Zeichenprogramm STAD. Der Name ist ein Akronym und steht für ST-aided Design. Das Programm wurde 1986 von Peter Melzer bei den Application Systems Heidelberg veröffentlicht und eröffnete den Nutzern ungeahnte Möglichkeiten – selbst 3D-Modellierung war damit machbar, wenn auch äußerst sperrig und unbequem. Auch meine Wenigkeit verbrachte in den 80ern und 90ern sehr viele Kindheitstage mit dem Malen von lustigen Bildern und Animationen in STAD. Achja, bevor ich darauf angesprochen werde: Ja, rein theoretisch war STAD keine PD-Software, aber wir wissen doch alle wie das damals so lief. Wer kennt nicht die berüchtigte Diskettenwanderung.

Die Bilder konnten in mehreren verschiedenen Formaten abgespeichert werden, darunter unkomprimiert als Doodle, gepackt, oder als DEGAS-Bild (ein weiteres zeitgenössisches und sehr bekanntes ST-Zeichenprogramm). Dabei entwickelte Melzer mit den gepackten .PAC-Bilddateien sein eigenes Bildformat, das die Bildinformationen relativ unspektakulär mittels RLE kodiert und so platzsparend auf der Diskette ablegen kann. Nun, meine Programmierkenntnisse in GFA-BASIC in den 90ern waren leider sehr begrenzt, und so konnte ich seinerzeit nur unkomprimierte Bilder in meine Progrämmchen einlesen, da ich dafür Codebeispiele in meinen Programmierbüchern fand. Im Traum hätte ich nicht daran gedacht, gepackte STAD-Bilder zu laden oder noch verrücktere Bildformate. Ich hatte schlicht keinen Code dafür, und wie andere Entwickler solche Formate in ihren Quellcode einbinden, das war für mich eher schwarze Magie.

Bekanntes Beispielbild „KRUSCH.PAC“ aus STAD. Die einzelnen Fortschritte während der Entwicklung des STAD-PAC-Konverters von oben nach unten. (Rote Bereiche sind nur Hintergrund, wo noch nichts gezeichnet wurde.)

Doch kein Problem ist für einen Haudegen wie mich alt genug um es nicht doch noch zu lösen: Kaum 30 Jahre später will ich es mir beweisen. Ich kann einen STAD-PAC-Konverter entwickeln. Vielleicht nicht mehr unbedingt in GFA-BASIC, aber zumindest in Java, und diesen damit theoretisch für mein Remake-Projekt nutzbar machen. Wofür genau? Das ist mir noch vollkommen unklar, aber wen kümmert es schon. Um eins klarzustellen: Es gibt funktionierenden Cross-Platform-Code in der Wildnis um STAD-Dateien zu laden. Unter anderem der beliebte Bildbetrachter “XnView MP” lädt alle STAD-PAC-Dateien erfolgreich, was mich anfangs extrem überrascht hat, da es doch heutzutage ein mindestens äußerst exotisches und rares Dateiformat ist. Scheint so als wolle der Entwickler dem Anspruch gerecht werden, möglichst viele Dateiformate zu beherrschen. Leider ist ausgerechnet die Software dieses Entwicklers natürlich nicht quelloffen, und daher für Studien nicht verfügbar, doch mit Hilfe der im Internet frei verfügbaren Spezifikationen wollte ich es auf jeden Fall selbst versuchen.

Und so setzte ich mich daran und begann die Spezifikation zu implementieren. Aus meiner Kindheit besitze ich unzählige eigene PAC-Dateien mit Bildchen, ich konnte aber zusätzlich sehr viele Beispieldateien im Netz finden und bei der Entwicklung zum Testen nutzen. Wie die Spezifikation beschreibt, gibt es zwei Sorten von STAD-PAC-Dateien: Die vertikal gepackten, und die horizontal gepackten. Die Implementierung der RLE-Dekodierung war dann auch tatsächlich nicht so schwer, vieles an Vorarbeit zum Bytestream-Handling hatte ich bereits früher erledigt bei der Entwicklung an meinem Shapelist- und Dongleware-PAC-Konverter. Schwierig wird es, wenn man zusätzlich Quellen im Internet findet, die zwar ebenfalls das Bildformat beschreiben, aber leider Fehler enthalten, wie einen falschen Runcount zu verwenden. Merke: Man sollte nicht alles glauben, was im Netz steht.

Schon relativ schnell erkannte ich die erste größere Schwierigkeit: Alle Internetquellen haben die Tatsache gemeinsam, dass sie die RLE-Dekodierung genau dokumentieren, aber bei den unkomprimierten Bilddaten nur noch ganz abstrakt von “use bytes” die Rede ist. Es wird tatsächlich nirgends beschrieben, wie das Bild damit genau gezeichnet werden soll. Der Teil fehlt einfach, so als wäre er entweder unnötig oder komplett trivial. Und selbst wenn die Bezeichnung “vertically packed” es so darstellt, die Pixel fortlaufend von oben nach unten zu zeichnen, ist leider nicht des Rätsels Lösung. Und so verbrachte ich noch eine Handvoll weiterer Stunden damit, die Zeichenroutinen zu debuggen, zu reverse engineeren und inkrementelle Fortschritte zu feiern, bis ich endlich eine fehlerfreie Implementierung in den Händen hielt. Gerne möchte ich das Internet mit meinen mühsam selbst gesammelten Erkenntnissen bereichern und die Spezifikationen um die überall fehlenden Informationen ergänzen:

Die vertikal gepackten Bilder (mit dem Header “pM86”) werden in Blöcken von je 8×8 Pixeln gezeichnet, wobei die Pixel innerhalb des Blocks zuerst von links nach rechts und von oben nach unten gezeichnet werden, während die Blöcke zuerst von oben nach unten und von links nach rechts gezeichnet werden. Am Ende erhält man ein binäres Vollbild mit (mehr oder weniger) 640×400 Bildpunkten. Die horizontal gepackten Bilder (mit dem Header “pM85”) werden als fortlaufende Pixelsequenz von links nach rechts und von oben nach unten gezeichnet. Vertikal gepackte Bilder sind dabei in einer erstaunlichen Mehrheit vorzufinden, während das horizontal gepackte Format vermutlich älter ist und seltener vorkommt. Immerhin ist das STAD-PAC-Format um mehrere Größenordnungen weniger komplex als das Dongleware-PAC-Format, aber selbst hier musste ich ein wenig experimentieren und basteln.

Das ebenfalls bekannte STAD-Beispielbild „ESCHER1.SEQ“, dargestellt im STAD-PAC-Konverter

Aufgefallen ist mir außerdem, dass viele STAD-PAC-Dateien mehr Zeichenanweisungen im Bytestream enthalten als es zu zeichnende Pixel auf dem Bildschirm gibt. Aus diesem Grund muss meine Implementierung überzählige Runcounts und überflüssige Bytes am Ende der Datei verwerfen, wenn das Bild vorzeitig fertig ist. Das fand ich durchaus ein wenig seltsam und unnötig. Ebenfalls bemerkenswert, dass besagter Bildbetrachter XnView MP die wenigen horizontal gepackten STAD-Dateien zwar korrekt entpackt, aber aus irgendeinem Grund falsch darstellt: Es wird ein Bild erzeugt, das 640×400 Pixel enthält, doch es wird vertikal gestreckt auf 440 Pixel. Und selbst wenn man dieses Bild direkt nach PNG konvertiert, wird es mit diesem seltsamen Streckfaktor (DPI bzw. Pixels per Unit unterschiedlich in Y-Richtung) in den Metadaten der PNG-Datei gespeichert.

Da kann ich doch glatt stolz darauf sein, dass meine Implementierung einen Fehler weniger hat als einer der bekanntesten Bildbetrachter überhaupt. Alles in allem wieder einmal ein schönes, erfolgreiches, produktives Wochenende, an dem ich eine kleine historische Software-Knobelaufgabe lösen konnte. Das SPACOLA-Remake kann nun gepackte STAD-Bilder laden, falls es mal nötig wäre. Zusätzlich habe ich auch wieder die Arbeit an einigen kleineren Aspekten an dem Spiel aufgenommen. Wie das eben so ist, ich muss mich mal wieder in das Thema reinfinden, und dafür eignen sich am besten die einfacheren Aufwärm-Themen.

Ich will jetzt nicht unbedingt behaupten, dass ich fleißig bin, aber wenn ich mal ausnahmsweise nicht faul bin, dann bin ich so richtig nicht faul. Nach einer längeren Abwesenheit und gleichzeitigen Arbeitspause an meinem Spiele-Remake, bin ich nun endlich wieder dran. Mich hat aus irgendeinem mysteriösen Grund plötzlich wieder die Motivation eingeholt, und sofort konnte ich zumindest wieder etliche Kleinigkeiten angehen und Fehler korrigieren. Allerdings habe ich durch Zufall ganz unerwartet einen weiteren Meilenstein bei der Entwicklung erreicht; einen Punkt auf meiner To-Do-Liste, den ich definitiv irgendwann umsetzen wollte, selbst wenn dies einen Nutzen nur theoretischer Natur auf dem Papier bringt.

Was bisher geschah: Einem unfassbar mäßig begabten Entwickler eines Spiele-Remakes, der zwar nicht vom Erfolg seines Projektes überzeugt, aber dafür wenigstens nicht von seinem Ziel abzubringen ist, war es gelungen, die Original-Dateien des Atari ST-Spiels SPACOLA mit Hilfe eines Debuggers zu entpacken und anschließend sogar das undokumentierte Format der Sprite-Dateien zu dechiffrieren und einen eigenen Konverter zu schreiben. Dies sollte ihm endlich einen wichtigen Einblick in die Hintergründe der Unterhaltungssoftware einer längst vergessenen Zivilisation geben. Wie hatten unsere Vorfahren einst Spiele entwickelt? Wurden die Quellcodes damals noch in Keilschrift verfasst? Mussten Benutzer an einer Kurbel drehen, wenn sie ihren Heimcomputer starten wollten? Waren antike Computerprogramme auch nur in schwarzweiß? (In diesem Fall, ja!). Unermüdlich arbeitete der selbsternannte Software-Archäologe weiter an den historischen Dokumenten, um vielleicht irgendwann einmal das perfekte Remake zu erschaffen.

Teil 3 meines fortlaufenden Hintergrundberichts: Es war eigentlich reiner Zufall als ich im Internet auf die Reverse-Engineering-Erkenntnisse von Jeremy Sawicki aus dem Jahr 2003 stieß. Der hatte diverse OXYD-Spiele in ihren Farbversionen für den IBM-PC erfolgreich analysiert und deren Formatspezifikationen offengelegt, darunter das Levelformat, die Grafik- und Sounddateien. Seine Dokumentation war unter anderem nützlich bei der Entwicklung des freien OXYD-Klons Enigma. Als ich mir die Angaben zum Grafikformat genauer ansah, erkannte ich plötzlich viele Gemeinsamkeiten zu den PAC-Dateien, die in den alten Monochromversionen der frühen Dongleware-Klassiker Verwendung fanden. Diese Dateien enthielten binäre Vollbildgrafiken für die Spiele seit Esprit (1989) und bis mindestens OXYD2 (1991).

Ich hatte mich natürlich längst selbst mehrfach daran versucht, das seltsame Dateiformat zu dekodieren, zuletzt auf Grund meiner Erfolge beim Konvertieren der Sprite-Dateien, doch das PAC-Format widersetzte sich meinen Annäherungsversuchen konsequent. Bis auf einige sehr offensichtliche Headerinformationen konnte ich kaum sinnvolle Werte herauslesen, und meine einzigen Erkenntnisse über das Kompressionsverfahren bestanden darin, dass das Bild in Blöcke unterteilt wird, und die Pixelinformationen grundsätzlich durch ein XOR-Verfahren invertiert von oben nach unten beschrieben werden. Durch Manipulieren der Dateien im Hexeditor und anschließendem Beobachten der Auswirkungen in OXYD, stellte ich erstaunt fest, dass die Dateistruktur eine sehr eigenwillige sein musste, weil oft komplett unvorhersehbare und unintuitive Artefakte im Bild dadurch enstanden. Als ich keinerlei Gesetzmäßigkeiten ausmachen konnte, gab ich mein Vorhaben desillusioniert auf.

Seit heute weiß ich endlich sehr genau, was das große Problem war. Von Sawickis Arbeit angespornt, begann ich endlich an der Entwicklung eines eigenen Konverters, den ich letztlich in mein Remake einbauen wollte, so wie bereits getan beim Konverter für Sprite-Dateien. Ich studierte die Formatspezifikationen und implementierte die Dekompressions- und Zeichenroutinen. Ohne nun zu sehr ins Detail zu gehen (wer alles wissen möchte, kann die Originalseite lesen), besteht jede Packed-Bitplane-Datei aus einem Header, einem Bitstream und einem Bytestream. Der Bitstream beschreibt dabei die gesamte Struktur des Bildes, sowie Angaben über die Kompressionsmethodik, und der Bytestream enthält die tatsächlichen Pixeldaten, die entsprechend gezeichnet werden müssen.

Jedes Bild hat die Auflösung von 640×400 Bildpunkten und ist in Blöcken von je 16×16 Pixeln aufgeteilt. Der Bitstream beschreibt dabei, wie das Bild nacheinander in Reihen von Blöcken, Blöcken, Blockquadranten und Reihen von Pixeln in immer kleinere Häppchen aufgespalten wird, wobei jedes Element entweder übersprungen oder gezeichnet werden kann. Müssen Pixel gezeichnet werden, so wird ein Byte aus dem Bytestream gelesen und dessen Bits als Pixel interpretiert, abhängig von einer der Pixelreihen darüber, die miteinander XOR-verknüpft werden, also je nachdem ob ein Bit gekippt wird oder nicht. Die Formatspezifikation von Sawicki ist dabei technisch betrachtet soweit korrekt, aber leider an mehreren Stellen etwas unpräzise formuliert, so dass ich mehrere Fehler machte, deren Behebung mich viel Zeit gekostet hat.

Das Titelbild „TITLE.PAC“: Die einzelnen Fortschritte während der Entwicklung des PAC-Konverters von oben nach unten. (Rote Bereiche sind nur Hintergrund, wo noch nichts gezeichnet wurde.)

Während der Entwicklung fiel mir jedoch auf, dass Sawicki eines der Features des proprietären Dongleware-Formats definitiv nicht kannte: Neben dem Invert-Flag, das festlegt, ob das fertige Bild noch invertiert werden muss, gab es in meinem Archiv eine einzelne Datei, die ein undokumentiertes Flag setzt. Zum Glück konnte ich am Output des Konverters bereits erkennen, was dem Bild fehlte: Es musste ein Dithered Pattern („Schachbrettmuster“) mittels XOR über das gesamte fertige Bild gezeichnet werden, um die ursprüngliche Grafik wiederherzustellen. Dieser Modus wird wohl zwar nur sehr selten angewandt, aber mein Konverter unterstützt dieses Feature nun ebenfalls. Im Endeffekt war es mir in geschätzt sechs bis sieben Stunden gelungen, eine Implementierung abzuliefern, die sämtliche 16 PAC-Dateien, die ich aus vier Spielen gesammelt hatte, fehlerfrei einzulesen und anzuzeigen vermochte.

Ohne das hilfreiche Dokument wäre ich immer noch nicht schlauer, und sonst einen Konverter zu schreiben, hätte ich wahrscheinlich nur geschafft wenn ich viele Wochen und Monate in mühsames Debugging der Spiele investiert hätte. Ob ich mir diese Zeit jemals hätte nehmen wollen, sei mal dahingestellt. Nun bin ich umso glücklicher über diese angenehme Abkürzung, die ich nehmen konnte. Der Konverter ist fertig und bereits ins Remake eingebaut. Dadurch bin ich jetzt endlich in der Lage, auch die originalen Grafikdateien in unveränderter Form im Remake einzulesen und zu verwenden. Das macht – wie eingangs im Absatz beschrieben – für den Spieler absolut keinen Unterschied, für mich als Entwickler mit Perfektionsdrang aber einen gewaltigen.

Mein SPACOLA-Remake kann nun die ursprünglichen Sounddateien, die Sprites und die Grafikdateien korrekt lesen. An der Interpretation der originalen Leveldaten arbeite ich mich weiterhin Schritt für Schritt voran, sie werden aber immerhin schon komplett eingelesen. Alles was jetzt noch vollständig fehlt: Die Musikdaten im SMS Synthesizer-Format von Jürgen Piscol. Ob ich dieses Kapitel jemals abschließen werde, lässt sich im Moment noch nicht einmal sagen. Andererseits, wer weiß schon, ob sich nicht doch wieder jemand findet, der zufällig eine detaillierte Analyse des Formats in Schriftform für mich zur Einsicht hat. Dann könnte nämlich alles ganz schnell gehen.

Das „Boss Is Coming“-Bild aus OXYD2, dargestellt im PAC-Konverter, zeigt den Datenbank-Manager „Phoenix“ von den Application Systems Heidelberg

Und falls sich nun jemand fragt, wieviele PAC-Dateien in SPACOLA Eclipse denn nun eingelesen und angezeigt werden können: Es sind ganze vier Dateien! Erstens, das Titelbild beim Laden des Spiels. Zweitens, das typische HUD mit dem Radar auf der rechten Seite. Drittens, der Rentenbescheid zum Ausdrucken nach Abschluss des letzten Levels. Die vierte und letzte PAC-Datei ist tatsächlich ein ungenutztes Bild, das die Kontaktadresse des Dongleware-Verlages enthält. Vermutlich wurde es in einer früheren Version des Spiels verwendet, und dann durch ganz normalen Text in der Dongleware-Schriftart ersetzt. Alle diese vier Originaldateien werde ich nun ins Remake einbauen und in irgendeiner Weise nutzen, damit sich der ganze Entwicklungsaufwand auch gelohnt hat.

Seit Jahren angekündigt, und doch nie abgeliefert. Bis heute: Das neue Preview-Video zu meinem kleinen SPACOLA-Remake ist da. Nur endlos weiter über den Entwicklungsfortschritt zu schreiben, ist auf Dauer zu langweilig, und ein paar Bewegtbilder machen den Eindruck doch unendlich viel greifbarer, daher habe ich mich nach allem Zögern nun doch dazu durchringen können, ein bisschen was aufzuzeichnen und zusammenzuschneiden. Dass ich ein unentdecktes Talent für Videobearbeitung hätte, kann ich dadurch zwar leider nicht unter Beweis stellen, aber vielleicht reicht es wenigstens, um zu erkennen, wie das Remake mittlerweile aussieht. Und ohne weitere Umschweife, here we go:

Hauptsächlich soll das Video zur aktuellen Work-In-Progress Version 0.9.6 vom September 2020 (Corona Edition) zwei Dinge mehr oder weniger veranschaulichen: Erstens, das Spiel ist inzwischen fast durchgängig in Farbe spielbar, mit einer höheren Framerate, und es gibt eine ganze Menge erweiterte Features und Verbesserungen, neue Gegner, neue Waffen, hektische und gnadenlose Action, Replays, und noch so einiges mehr. Und zweitens, das Spiel ist leider auch nach zehn Jahren Entwicklungsszeit noch lange nicht fertig. Krass, ne?

Wie ich kürzlich jemandem sinngemäß schrieb, kann der Spieler in dem Remake noch keine echten Fortschritte machen, die Original-Levelskripte werden noch nicht vollständig unterstützt, die Gegner verhalten sich praktisch alle falsch, und es fehlt noch eine ganze Menge Kleinkram, der das Gameplay abrundet und das Geballer zu einem echten Spiel macht. Im Moment ist SPACOLA Eclipse mehr so eine Art 2D Arcade Retro Space-Sandbox, und noch kein wirkliches Spiel.

Falls sich jemand wundert, wieso das Fenster in dem Video so klein aussieht, und man viele Menüs so gar nicht vollständig sieht: Die Grafik ist problemlos skalierbar von 640×400 auf 1280×800 oder 1920×1200. Dadurch wird auch das Fenster größer. Für das Aufzeichnen des Gameplays in OBS wollte ich meine angestaubte Hardware aber nicht komplett überfordern, und habe daher nur die Standard-Auflösung gewählt. Im Vollbild macht das auch fast keinen Unterschied, lediglich einige Teile von geöffneten Dialogen und Menüs waren dadurch bei der Aufnahme eben nicht komplett im Bild und wurden abgeschnitten. Das ändert jedoch nichts daran, dass alles einwandfrei funktioniert.

Da ich – wie ebenfalls seit Monaten angekündigt – bald endgültig von Windows 7 zu Linux wechseln werde, und ich höchstwahrscheinlich gerade in der Anfangszeit doch so einiges an der Linux-Kompatibilität des Remakes schrauben muss, was mich vermutlich um Wochen oder sogar Monate zurückwerfen wird, wollte ich dieses Video auf jeden Fall vorher fertigstellen und hochladen, solange mein Setup noch perfekt läuft. Und ich bin wirklich ganz schön froh, dass das alte Thema jetzt mal vom Tisch ist. Jetzt kann ich endlich wieder den Kopf in den Sand stecken.

Eines meiner heiligsten Prinzipien bei der Entwicklung meines Remakes von Spacola ist Authentizität. In dieser Hinsicht bin ich leider ein Perfektionist. Zumindest so weit es mir technisch möglich ist, versuche ich mich immer zu 100% an den Originaldateien und an Originalmechanismen zu orientieren, und ich weiche nur davon ab, wenn es absolut nötig, wirklich sinnvoll, oder mit meinem Know-How sonst nicht machbar ist. Zu Beginn der Entwicklung konnte ich lediglich rein aus der Beobachtung nachimplementieren, ich musste notgedrungen tausende selbsterstellte Screenshots verarbeiten und Tonaufnahmen aus dem Emulator aufnehmen. Das Ergebnis war natürlich oft nah am Original dran, aber für mich nie authentisch genug. Glücklicherweise habe ich mittlerweile so einige Fortschritte gemacht, die mir meine Mission deutlich erleichtern. In den vergangenen Wochen habe ich einen äußerst wichtigen Meilenstein bei der Analyse des Originalspiels erreicht. Um verstehen zu können, was mir da konkret gelungen ist, muss ich etwas weiter ausholen. Daher hier ein kleiner technischer Exkurs in meine Welt.

Schon wie zuvor im 1990 veröffentlichten OXYD hat Spacola einen eigenen Kopierschutz in Form eines Dongles (das Codebuch). Im Gegensatz dazu sind die Codes allerdings mittlerweile ein integraler Bestandteil des Gameplays geworden, und nicht mehr nur Steine, die den Weg blockieren. Den Kopierschutz schlicht auszubauen hätte im einfachsten Fall bedeutet, direkt das Gameplay von Spacola zu verändern, die Siegbedingungen im Spiel zu entfernen; das Spiel wäre quasi sinnlos geworden. (Spoiler-Warnung: Dennoch ist einem findigen Entwickler vor wenigen Jahren auch das schon auf intelligente Weise gelungen.) Weiterhin bringt das Spiel jedoch noch einen raffinierten Crackschutz mit, um zu verhindern, dass der Kopierschutz überhaupt angegriffen werden kann. Die Daten der Dongleware-Spiele bis einschließlich OXYD lagen noch offen da, wenn auch in proprietären Dateiformaten (SHL, IMG, CMP, PAC), mit denen man so jedenfalls nichts anfangen konnte, bis auf die Sounddateien, die einfach im Rohformat vorhanden waren. Da OXYD schließlich geknackt werden konnte (und auch das Codebuch trotz absichtlich schlechtem Farbkontrast kopiert wurde), wurden die Daten in Spacola inzwischen gegen unbefugte Zugriffe geschützt. Dies macht es natürlich für interessierte Remake-Entwickler wie mich deutlich schwieriger, die eigentlich nicht den Kopierschutz entfernen wollen, sondern Einblick in die Spieldaten brauchen.

Wie sieht dieser Crackschutz nun eigentlich aus? Bei Spacola lagen weder die Spieldaten noch die ausführbare Datei in lesbarer Form auf der Diskette vor. Auf dieser gab es lediglich ein großes mit PFXPak erstelltes, selbstextrahierendes Programm, das das Spiel zur Laufzeit ausschließlich in den Arbeitsspeicher entpackt und dort ausführt. Laut PFXPak-Dokumentation bringt das nicht nur den Vorteil, dass man mehr nutzbaren Netto-Speicherplatz auf der Diskette hat, sondern auch Performance-Verbesserungen, da weniger Daten über das langsame Diskettenlaufwerk geladen werden müssen. Außerdem werden zum einen die einzelnen Dateien immer erst dann entpackt, sobald sie vom Programm referenziert, also im Spiel benötigt werden, zum anderen werden die Dateien auch gleich noch dekodiert, da sie teilweise nur in verschlüsselter Form vorliegen. Und selbst das ist noch nicht alles: Sogar wer glaubt, es sei ihm gelungen, das integrierte LHarc-Archiv des Entpackers aus der Datei zu extrahieren, und dieses von Hand entpacken will, erhält leider kein Spacola, sondern nur ein Programm, das eine kleine Grußbotschaft an den Hacker auf dem Bildschirm anzeigt und gleichzeitig die Festplatte vollmüllt, sofern eine angeschlossen ist. Ja, man musste sich als Spieleentwickler wohl irgendwie gegen Raubkopierer zur Wehr setzen. Der wenig freundliche Inhalt besagter Grußbotschaft wurde mit dem ersten und wahrscheinlich einzigen Spacola-Patch einige Wochen später zensiert.

Wer sich mit Atari ST-Emulation intensiver befasst, weiß, dass es mit dem STeem Debugger ein äußerst mächtiges Debugging-Werkzeug gibt, das genutzt werden kann, um sämtliche ST-Software zu analysieren und zu modifizieren. Fürs Reverse-Engineering ist ein brauchbarer Debugger quasi unverzichtbar. Als ich vor etlichen Jahren zum ersten Mal die Oberfläche des Debuggers öffnete, war ich wie erschlagen von den endlosen Möglichkeiten, die sich mir hier boten. Und mir war sofort klar, dass ich nicht die nötigen Fähigkeiten hatte, um hier irgendetwas zu bewegen, denn natürlich setzt so ein Debugger unter anderem auch ein tieferes Verständnis der Hardware voraus. In meinem Studium hatte ich wenigstens zwei Semester Rechnertechnik, in welchen ich die Grundlagen von 68K-Assembly lernte und auch sehr kleine Programme schrieb. Dies brachte mich zumindest theoretisch in die Lage, die Funktionen des Debuggers rudimentär zu verstehen. Doch als ich mich damals spaßeshalber in ein laufendes Programm einklinkte, Schritt für Schritt durch den Programmcode bewegte, und die Hieroglyphen verstehen wollte, die der Prozessor da ausführte, hörte der Spaß irgendwie auf. Mein Verstand konnte zwar mühsam und sehr langsam erfassen, was dort in jeder Zeile ausgeführt wurde, aber mir fehlte jeglicher Durchblick dafür, warum es ausgeführt wurde, an welcher Aufgabe der Programmcode gerade arbeitete. Es gab keinen Kontext. Es ist ein bisschen so als würde ich mir unter einem Mikroskop nacheinander die einzelnen Holzfasern genauer anschauen, um dadurch herausfinden zu wollen, worum es in dem Buch geht. Dabei könnte ich nicht einmal erkennen, welchen Buchstaben ich mir da gerade ansehe.

Der STeem Debugger mit laufendem Spacola beim Ladevorgang

Aber die ersten kleinen Fortschritte ermutigten mich, den Kopf nicht hängen zu lassen. Der Memory-Browser des Debuggers bietet zum Beispiel eine Suchfunktion und erlaubt das Editieren des Speichers zur Laufzeit. So kann man Texte in den Programmen finden und ersetzen, was nette Spielereien ermöglicht. Eine andere nützliche Funktion ist der Speicherdump, der es erlaubt, den kompletten Arbeitsspeicher in eine Datei zu schreiben. Mit diesem wertvollen Hilfsmittel hatte ich endlich einen ersten direkten Zugang zu vielen Spielinhalten, wenn es auch noch lange nicht lückenlos war. Im Audiobearbeitungsprogramm Audacity konnte ich dieses Speicherabbild als Rohdaten einlesen und die Sounds von Spacola hörbar machen und grob „ausschneiden“, was mir wirklich enorm half. Eines meiner Probleme mit dieser Methode war jedoch, dass ich nie wusste, wo eine Datei beginnt oder aufhört. Die Dateien waren nicht byteperfekt. Und jahrelang waren die Audiodateien leider die einzigen, auf die ich dadurch Zugriff erlangen konnte. Ich wollte aber unbedingt auch an die Grafikdateien herankommen. Später gelang es mir mit großem Aufwand, das „Rentenbescheid“-Bild, das nach gewonnenem Spiel als Urkunde zum Ausdrucken verwendet wird, zu extrahieren. Die Monochrom-Rohdaten habe ich unter anderem durch einen emulierten Drucker als virtuelle Hardcopy in eine Datei schreiben lassen, mühsam rekonstruiert und mit STAD v1.3 laden können. Dadurch konnte ich einen Screenshot anfertigen. Dies war ein weiterer Motivationsschub, der mich daran glauben ließ, irgendwann alles zu schaffen.

Ende 2018 begann ich erneut damit, das Originalspiel aufwändig Schritt für Schritt im Debugger zu beobachten. Ich hatte erst angefangen, mich mit den Breakpoints und den Read- und Write-Monitors vertraut zu machen, und war überzeugt davon, ich könnte die entpackten Dateien abfangen, während sie gerade in den Arbeitsspeicher geschrieben werden. Im selbstextrahierenden Programm gibt es glücklicherweise eine Dateitabelle, die Dateinamen, Dateigrößen und Byte-Offsets enthält. Dies war letztlich der Schlüssel zum Erfolg. Jemand mit mehr Erfahrung im Reverse-Engineering hätte natürlich sofort gewusst, was hier zu tun ist. Ich musste es erst durch unzählige Fehlversuche und Rückschläge lernen. Am Ende dauerte es bis zum Frühjahr 2020, dann hatte ich endlich einen Plan. Durch das geschickte Setzen der Read- und Write-Monitors und Zurückverfolgen der Lese- und Schreibzugriffe, konnte ich genau den Teil des Codes ausmachen, der direkt für das Entpacken aller Dateien zuständig ist. Anschließend musste ich nur noch den Program Counter, die Schleifendurchläufe und die Adress- und Datenregister überwachen, dadurch konnte ich sehen, welche Datei gerade verarbeitet wurde, wo die Daten gelesen und wohin sie geschrieben wurden, und wann der Schreibvorgang exakt beendet ist. Ich führte Notizen darüber, welche Dateien ich dadurch erhalten konnte und ob sie die richtige Größe haben, um ihre Richtigkeit zu verifizieren.

Das Debugging beim Entpacken der Dateien

Das Modifizieren der Dateitabelle im Programm erlaubte es mir sogar, den Entpacker dazu zu bringen, die „falschen“ Dateien zu entpacken, darunter auch eine Sounddatei, die offenbar gar nicht referenziert, also im Spiel selbst niemals verwendet wird. Dies war immens hilfreich und verkürzte die weitere Zeit, um auch die letzten verbliebenen Dateien zu bekommen. Später bemerkte ich noch, dass Spacola leider wieder mal schlauer war als ich: Viele Sounddateien wurden im Spiel komprimiert, d.h. in der Größe reduziert, andere Sounddateien wurden aber nur in irgendeiner Weise kodiert, also bei gleicher Dateigröße unlesbar gemacht. Hierzu musste ich einen weiteren Codeabschnitt ausfindig machen, der Sounddateien entschlüsselt. Die zentralen Breakpoints waren mir in der Folge heilig, ich habe sie akribisch notiert und verwendet, um nacheinander alle 104 Dateien mühsam zu entpacken, aus dem Memory-Browser zu extrahieren und mittels HEX-Editor byte-perfekt auf die Festplatte zu schreiben. Das Ergebnis sind 557 KByte an Rohdateien, die exakt so im Originalspiel verwendet werden: 50 Sounddateien, 48 Sprite-Dateien, vier Bilddateien, eine Textdatei und eine IMG-Datei. Als Bonus erhielt ich auch die ungeschützte SPACOLA.PRG, also die ausführbare Datei ohne den Packer. Diese lässt sich auch starten und lädt sogar das Titelbild, anschließend hängt sie sich leider auf. Allerdings habe ich mich entschlossen, dieses Problem nicht weiter zu verfolgen, da es sich wahrscheinlich nicht lohnt.

Für mich war das bis hierhin schon ein großartiger Durchbruch. Dies war ein Thema, das mir noch Jahre zuvor wie eine unlösbare Aufgabe erschien, und plötzlich liegen mir alle Daten offen, um sie endlich in unberührter Form in meinem Remake zu verwenden. Aber da war natürlich weiterhin diese eine nicht ganz unbedeutende Hürde: Das selbstentwickelte Dateiformat der Sprite-Dateien ist leider unbekannt, undokumentiert und es gibt kein öffentlich verfügbares Programm, das die Dateien lesen könnte. Scheint so, als sei ich in einer Sackgasse gelandet.

Und in der nächsten Folge lesen Sie: Die Sprites von Spacola.

Seit ich denken kann, habe ich Daten produziert und gesammelt. Ganz am Anfang noch auf Disketten am Atari ST. Ich habe Bilder mit STAD gemalt, Musik mit DIGIT komponiert, Programme in GfA BASIC geschrieben, und alles fleißig auf Disketten gespeichert. Hinzu kamen natürlich alle meine Spiele, meine Programme, mein ganzer PD-Krempel, und hey, sogar meine eigenen Burgen für Ballerburg. Jahre später haben mein Vater und ich in wochenlanger Arbeit hunderte Atari-Disketten auf DAT-Bänder gesichert. Und dann vergessen. Keiner weiß heute wo diese Bänder liegen, und ob sie noch lesbar sind.

Am Amiga ging das im Grunde genauso weiter, nur die Programme hießen anders. Und am PC bekam ich dann endlich ganz neue Möglichkeiten, noch viel größere Datenmengen zu produzieren und zu speichern: Mit unserer Videocapturing-Karte konnte ich kleine Filmchen drehen und als AVIs speichern. Unsere beiden Festplatten waren damals zwar leider viel zu klein um viele Videos zu speichern, doch glücklicherweise konnte ich ab 1998 einen CD-Brenner verwenden, der fortan fleißig genutzt wurde, um „Backup-CDs“ zu brennen, wenn der Festplattenspeicher mal wieder zu knapp wurde. Darauf brannte ich all die kurzen Spaß-Videos mit meinen Schulfreunden, mit unserem alten Handy-Scanner gescannte Fotos, Schnappschüsse von meinen Geschwistern, Shareware-Versionen von meinen liebsten Win3.11-Spielen, Savegames, private Wordpad-Dokumente und welche für die Schule, aus dem Internet einzeln heruntergeladene Tipps-&-Tricks-Seiten für Spiele, Chatprotokolle, und und und. Die Liste ist quasi endlos. Die Backup-CDs stapelten sich schon bald bei mir im Kinderzimmer, gleich neben den Diskettenstapeln.

Die Abstellkammer-Skyline aus CD-Wolkenkratzern

Die Massenspeicher wurden mit der Zeit größer. Schon im Jahr 2000 wurde endlich eine 30 GB-Festplatte angeschafft. „Die bekommt man ja NIE voll!“, hieß es da schon wieder, während gleichzeitig die Wolkenkratzer aus selbstgebrannten Rohlingen wuchsen. Mit unserer neuen ISDN-Flatrate und mächtigen Downloadmanagern wie Gozilla oder GetRight konnte ich komplette Webseiten inklusive ihrer Download-Archive quasi über Nacht herunterladen, was ich dann vielfach auch tat. Einmal landeten so 600 MB allein an 3dfx-Treibern auf meiner Festplatte. Oder gigabyteweise Musik von mp3.com, einer Webseite, die zur Jahrtausendwende gratis MP3-Dateien anbot. Oder 500 MB an Mod-Dateien von The Mod Archive. Aber ich glaube, das waren nur die Buchstaben A und B. Weiter bin ich damals nicht gekommen. Überhaupt habe ich sehr gerne komplette Archive heruntergeladen, wenn ich welche fand. Egal ob Fotos, Videos, Audios, Spielesammlungen, Spaßprogramme, eBooks, GIF-Animationen, Midi-Kollektionen, Custom-Maps für Spiele – ich hab alles gedownloadet, weggspeichert, und letztlich weggebrannt, oftmals, ohne die Dateien jemals wieder anzurühren.

Im Jahr 2005 wandelte sich mein Datenmessie-Verhalten ein wenig. Erstmalig wurde das Brennen der vielen wertvollen Daten auf DVD-Rohlinge immer mühsamer, und gleichzeitig wurden die Festplatten endlich in schneller Folge immer deutlich größer. Schließlich – nach wahrscheinlich an die tausend gebrannten Backup-CDs und -DVDs – stellte ich das Brennen ganz ein, und ging dazu über, einfach immer größere Festplatten zu kaufen und die Daten jeweils immer umzukopieren. Meistens in einen Unterordner, der dann so hieß wie die alte Festplatte, damit ich wusste, wo die Daten herkamen. Das führte dazu, dass die Dateien immer einen Unterordner tiefer wanderten, je mehr Festplatten sie durchliefen. Und es führte dazu, dass ich noch weniger Ordnung halten musste, denn ich konnte alles einfach immer irgendwo in einen Ordner werfen, und musste keinen Gedanken mehr daran verschwenden. Ordner und Unterordner stapelten sich nun bei mir – ganz so wie früher Disketten, CDs und DVDs.

Wir machen einen Zeitsprung ins Jahr 2019: Inzwischen stapeln sich bei mir nicht mehr nur Disketten, CDs, oder DVDs, sondern Festplatten. Es handelt sich um meinen ganzen, nutzlosen Datenschatz, der heute in die zweistelligen Terabytes geht, und der regelmäßig (teilweise) mit Hilfe von Batch-Skripten auf ein 15 TB-NAS gespiegelt wird. Ich bin längst damit fertig, alle meine Backup-CDs und -DVDs aus den Jahren 1998 bis 2006 auszulesen und auf meinen Festplatten zu speichern, so dass ich in meinem unkontrollierbaren Backup-Wahn dazu übergegangen bin, nun auch die unzähligen alten Beilage-CDs von GameStar, PC-Games, PC-Action, PC-Player, PC-Joker usw. zu kopieren. „Wer macht denn so einen Quatsch?“, werden sich viele fragen. Ich habe vergessen, warum ich das mache. Es ist wie ein Reflex. Alles muss in mein Backup-Archiv.

Kürzlich habe ich in einige meiner alten Dateien vom Dezember 1997 reingeschaut, und war erstaunt, was sich dort noch alles findet. Es ist ganz sicher dasselbe Gefühl, das jemand hat, der auf dem Dachboden im Haus der Eltern eine alte, verstaubte Kiste mit Krempel aus der Kindheit findet. Ich habe meine allerersten E-Mails gefunden, und den gesamten E-Mail-Briefverkehr mit einigen meiner ersten Internetbekanntschaften, darunter eine gleichaltrige E-Mail-Brieffreundin aus Berlin. Diverse gespeicherte Mitschriften aus den guten alten Internet-Chatrooms, QBasic-Quellcodes, ein erster gescheiterter Versuch einer eigenen GTA-Homepage. Meine erste Bookmark-Liste, als lange TXT-Datei, wo ich jede Webseite noch einzeln und ausführlich kommentiert und bewertet habe. Hättet ihr z.B. gewusst, dass Fireball die allerbeste Suchmaschine ist? Eine wirklich quietschbunte Mischung aus allen möglichen Dingen, mit denen ich mich damals beschäftigt habe. Es war ein wirklich atemberaubender Flashback, und das Gefühl wird noch dadurch verstärkt, dass ich selbst vergessen hatte, dass ich das ganze Zeug noch habe. Das ist irgendwie der Vorteil dabei, wenn man nichts wegwerfen kann. Alles taucht irgendwann wieder auf.

Der Nachteil ist, dass es quasi aussichtlos ist, diese unvorstellbaren Datenmengen irgendwie sinnvoll zu sortieren. Das hätte vermutlich den Umfang eines separaten Lebenswerks. Beim Sichten der alten Dateien ist mir aufgefallen, dass die Unordnung überwältigend ist, vieles ist doppelt und dreifach vorhanden, tausende nichtssagende Ordnernamen, alles mögliche in ZIP- oder RAR-Archiven, oder auch nicht. Stöbern geht gerade noch so, aber nach etwas Bestimmtem suchen? Keine Chance. Mir fällt nicht einmal im Ansatz ein System ein, mit dem man diesen ganzen Kram sortieren könnte. Wie als wollte man auf einer Müllhalde den ganzen Müll kategorisch ordnen, um eine bestimmte Cornflakes-Schachtel im Zweifel schneller finden zu können. Alles radikal nach Dateinamen, Dateidatum oder Dateityp sortieren? Besser nicht, schließlich sind ja auch etablierte Dateigruppierungen darunter, die ich beibehalten will.

Ich habe mit dem Sortieren inzwischen trotzdem mal ganz rudimentär angefangen, ein paar Ordner zusammengefügt, ein paar offensichtliche Duplikate gelöscht, aber sehr weit bin ich wie erwartet nicht gekommen. Das Datenchaos ist eigentlich kaum mehr zu entwirren. Ob ich ohne den ganzen Datenschrott überleben könnte? Sicher, aber es wäre dennoch ein schmerzhafter Verlust, wenn alles weg wäre. Wer verliert etwa gerne alle seine alten Briefe, seine Tagebücher, seine alten Schulsachen, seine Dias und Super-8-Filme, seine alten Spielsachen? Klar, solche Leute wird es geben, aber ich gehöre absolut nicht dazu. Diese ganzen Altlasten sind schließlich ein wichtiger Teil von mir, alles was ich je produziert habe. Und ich habe keine genaue Vorstellung davon, was in dem ganzen Datenschatz noch so alles verborgen liegt. Womöglich befindet sich sogar das Bernsteinzimmer irgendwo darunter.