Ann-Marie Letourneur I Michael Mosel I Tim Raupach (Hrsg.)

Retro-Games und Retro-Gaming

Nostalgie als Phänomen einer performativen Ästhetik von Computer- und Videospielkulturen

~w~1J Fachverlag für Medientechnik und -wirtschaft

A. -M. Letourneur/M. Moselrr. Raupach (Hrsg.): Retro-Games und Retro-Gaming

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen

Nationalbibliografie; detaillierte bibliografische Daten sind im Internet unter

http://d-nb.de abrutbar.

© Verlag Werner Hül sbusch, Glückstadt, 201 5

V W I-. Verlag Werner Hülsbusch I I Fachverlag für Medientechnik und -wirtschaft

www. vwh-verlag.de

Einfac he Nutzungsrechte liegen beim Verlag Werner Hlilsbusch, GIUckstadt.

Eine weitere Verwertung im Sinne des Urheberrechtsgesetzes ist nur mit

Zust immung der Autor/inn/en möglich.

Markenerklärung: Die in diesem Werk wiedergegebenen Gebrauchsnamen, Handels­

namen, Warenzeichen usw. können auch ohne besondere Kennzeichnung geschlitzte

Marken sein und als solche den gesetzlichen Bestimmungen unterliegen.

Korrektorat und Satz: Werner Hülsbusch

Umschlag: design of media, Lüchow

Druck und Bindung: Kunsthaus Schwanheide

Printed in Germany

ISBN: 978-3-86488-078-0

lt's More Fun to Compute!

Retro-Games als Wissensobjekte

Stef an Hältgen

Im Juni 201 3 geriet ein über 30 Jahre altes Computerspiel in die Medien ( SANTOS 20 13), das schon in den Jahrzehnten zuvor für einige Schlagzeilen, Lexikoneinträge und Retrospektiven gesorgt hatte: Das von Atari 1983 in

großen Stückzahlen in der Nähe der Stadt Alamogordo (in New Mex ico, USA) vergrabene Spiel E. T. The Extraterrestrial 1 sollte im Zuge von Film­arbeiten ,exhumiert' werden. Warum wurde es vergraben? Um die Lager da­mals nicht mit dem Spiel (sowie weiteren ,Ladenhütern ' ) aus dem misslun­genen Weihnachtsgeschäft 1982 zu belasten, hatte man sich entschlossen, die

Datenträger auf einer Mülldeponie zu entsorgen. Seitdem ist der "Modul ­Friedhof' eine der häufigst zitierten Urban Legends der Computerspiel­Industri e, die es in zahl reiche Anekdoten, Verschwörungstheorien2 und sogar in die Literatur (GILLIES 2008: 67, 79, 85) geschafft hat. Fünf Millionen Spielmodule vermutete man dort im Sand (o. V. 1983). Nun hat die Ausgra­bung stattgefunden3 und der Dokumentarfilm ist fertig (J ÄGER 201 4), der

dieser Geschichte auf den Grund geht und für den die Filmemacher eine Grab-Erl aubnis der ansäss igen Gemeinde erwirkt hatten.

Während man dort also mit archäologischem Eifer nach ,dem wahren Kern ' hinter der Legende suchte (und dabei zugleich einen der produktivsten Computerspiel-Mythen beerdigt hat), hatte ein paar Monate zuvor eine ganz andere ,Grabungsaktion ' zum selben Spiel Ergebnisse zutage gefördert. In einem Kooperationsprojekt haben der Hobbyist David Richardson und einige User des Internetforums ,AtariAge' das Spielprogramm E. T. aus den ROM­Chips der Module ,geborgen ' und die mutmaßlichen Probleme, die zum da-

I im Folgenden kurzE. T.

2 Dazu zähl t, dass E.T. einer der Hauptverantwortlichen des sogenann ten ,Videospie i­Crashs' von 1983 gewesen sein soll , bei dem zahlreiche Hard- und Softwarefirmen in­solvent gingen (FREUNDORFER 2009).

3 Gefunden wurden dabei a llerdings nur wenige Hundert E.T.-Module.

50 Stefan Höltgen

maligen Flop des Spiels geführ t haben sollen, mit verschiedenen Methoden angegangen.

In diesem Beitrag soll es um die archäologischen Methoden dieser zwei­ten Bergungsaktion gehen. Dabei wird nicht die Firmen- und Wirtschaftsge­schichte des Computerspiels4 fokuss iert, di e mit der Grabung in Almogordo ja fraglos bereichert werden sollte, sondern eine Archäologie im Fou­cault 'schen Sinne als Archäologie des durch Medientechnologien vermittel­ten Wissens angestrebt. Nachdem zunächst der Rahmen der Überlegung im Gebiet des Retrocomputings und -gamings situiert wurde, sollen kurz einige theoreti sche Ansätze vorgestellt werden, die alte Computerspiele als Medien des Wissens neu bewerten. Die Werkzeuge des Medienarchäologen unter­scheiden sich dabei ganz wesentlich von denen des ,kl assischen ' Archäolo­gen, was sich bei ihrer Anwendung auf die Spielsoftware E. T. zeigen wird .

Mithilfe der Tools neuer Computersysteme können alte Computerspiele auch heute noch modifi ziert, debugged und erweitert werden - mehr noch: Heute stehen sogar Werkzeuge zur Verfügung, die ganz andere Zugriffsmöglichkei­

ten auf die alte Hard- und Software bieten, als es damals möglich gewesen

wäre. Dass sich hinter derarti gen ,unzeitgemäßen Betrachtungen ' weit mehr

als nur die (sehr verspätete) Korrektur (fremden) Codes offenbart, soll im Verlauf der Ausführungen und anhand einer spezifischen Korrektur des

Spiels E. T. deutlich werden. Ein derartiger Zugriff auf die Software einer spezifischen Plattform (in diesem Fall der Spielkonsole Atari VCS/26005

)

kann nicht nur ein Verständnis der Funktionsweise einer spezifischen Platt-

4 Hierzu lassen sich GOLDBERG und YENDEL sehr ausführlich im ersten Teil ihrer kürz­lich erschienen Atari -Firmenbiografie aus (GOLDBERGIVENDEL 20 13).

5 Im Folgenden kurz YCS; IAN BOGOST und NICK MONTFORT haben sich der VCS als Plattform bereits ausführli ch in ihrem Buch Racing the Beam angenommen. Dort de­finieren sie den Begriff Plauform als: "a particular standard or specification before any particular implemenlation of il. To be used by people and Lo Lake parl in our culture di ­rectl y, a platform musl take material form , as the Atari YCS certainly did. This can be done by means of the chips, boards, peripherals, controllers, and other components thal make up the hardware of a phys ical computer system" (MONTFORT/BOGOST 2009: 2). -Dass die von MONTFORT/BOGOST dami t inaugurierten "Platform Studies" zwar metho­dische Ähnlichkeilen zur Medienarchäologie aufweisen, jedoch in ihrer Konsequenz eher den Cullural Studies als einer Medienepistemologie zuzurechnen sind, habe ich an anderer Stelle ausgeführt (HöLTGEN 20 13).

lt's More Fun to Compute! 51

form, sondern auch des sogenannten Computers6 stiften, denn "two things have not changed: Computers are based on binary logic, and the basic struc­tures of games has not changed. [ ... ] Master the past to understand the pre­

sent" (CAREY 2005: XVI); diese Art von Medienkompetenzbildung zeigt sich als ein zentrales Anliegen des Retrocomputings.

1 Retrocomputing als Medienarchäologie

Retrocomputing und -gaming findet in den letzten Jahren erhöhte Aufmerk­

samkeit, sowohl in der Publizistik als auch in akademischen Disziplinen wie den Game Studies. Allein auf dem deutschen Zeitschriftenmarkt existieren

derzeit sechs Periodika7 zum Thema, zu einzelnen Plattformen - insbeson­dere dem Commodore 64, dem Commodore Amiga und Computerspielkon­solen wie der YCS oder Nintendos NES - erscheinen Sammelbände und

Monografien, die sich mit der Geschichte der Firmen, ihren Produkten und insbesondere mit den dafür erschienenen Spielen auseinandersetzen, welche

darin als Auslöser für bestimmte Spielmechaniken, -ästhetiken und -Steue­rungen diskutiert werden. Aber auch technisch sind Retrosysteme durchaus noch ,lebendig': Zu den am stärksten prosperierenden Gebieten bei aktuellen

technischen Entwicklungen auf dem Gebiet gehören Software-Emulatoren, neue Open-Source-Spielkonsolen, die speziell für die Emulation von Retro­

computern und -konsolen designt sind sowie neue Software, programmiert

für alte Systeme. Gerade diese drei Felder verdienen innerhalb einer Untersuchung des Re­

trocomputings besondere Aufmerksamkeit, weil sich in ihnen deutlich jene

Faktoren offenbaren, die einen medienarchäologischen Methodenkomplex umreißen. Im Unterschied zu hermeneutisch-ästhetischen Analysen von

Computerspielen versucht die materialistisch orientierte Medienarchäologie

6 Im Zentrum meines eigenen Forschungsprojektes im Bereich der Medienwissenschaft stehen (die) Computer im Plural - also in ihrer je unterschiedlichen Ausgestaltung ver­schiedener Plattformen, die ihre medientechnischen Funktionen bestimmt.

7 Retro Magazin, RETURN, LOAD, Retro Gamer, Powe1play und unregelmäßige Chip­

Sonderhefte

52 Stefan Höltgen

der "Frage nach dem Kanal" Priorität vor dem, was in ihm übertragen wird,

einzuräumen. Elektronische Medien wie Fernseher, Radios, Telefone und

Computer nehmen durch ihren Aufbau, ihre technische Reali sation und die

zeithistorischen Möglichkeiten (und Unmöglichkeiten!) ihres Designs näm­

lich deutlichen Einfluss auf die Inhalte und Ästhetiken ihrer Übertragungen.

Dies zeigt sich deutlich an Computerspielen für Retro-Plattformen und bei

einem näheren Blick auf deren audiovisuelle Outputs, die oft von groben

Pixeln und schiefen Tönen (BRAGUINSKI 20 12) geprägt sind. Die Idiosynkra­

sien der Hardwares schreiben sich hier auf eine sehr deutliche Weise in die

Ästhetiken der Software-Effekte ein, weswegen ihnen unbedingte Aufmerk­

samkei t geschuldet sein sollte. Es gi lt für eine derartig ausgerichtete Me­

dienwissenschaft also, sich der Medientechnik als dem Apriori des Medien­

inhaltes zu widmen und ästhetische, soziologische sowie kulturhistorische

Fragestellungen an die Fachdisziplinen zu delegieren.

Der Ansatz stellt eine Übertragung und Verschärfung der Überlegungen

Michel Foucaults dar. Foucault stellte in der Archäologie des Wissens beim

Zugriff auf das Archiv ebenso wenig die Frage, was die Texte bedeuten, als

vielmehr, welche machtförmigen Diskurse und Dispositive zu ihrer Entste­

hung und Archivierung geführt haben. Daraus leitet sich ab, dass hi stori sche

Kontinuität und kausale Progression (HUHTAMO 2007: 17- 19) als ,Motoren'

der Diskursgeschichte oft selbst reine, machtgeleitete Konstruktionen darstel ­

len. Eine Archäologie des Wissens sucht daher nach den Fissuren zwischen

diesen Konstruktionen, dem Ausgeschlossenen und den Diskontinuierlichen,

das sich bei einem Blick aufs Detail immer wieder zeigt und tradierte histori ­

sche Narrative di spensiert. Der Mediengeschichte als Erzählung stellt eine

derartig ausgerichtete Medienwissenschaft daher eine Medienarchäologie der

Brüche entgegen, die im Material der Medien nach eben diesen Brüchen sucht

und neue Querbezüge herstellt. ERKKl HUHTAMO flankiert in seiner Archäolo­

gie der Automatenspiele beide Zugriffe auf deren Geschichte: "Alle kulturel­

len Vorgänge bestehen aus einem Wechselspiel zwischen Kontinuität und

Bruch, Ähnlichkeit und Unterschied , Tradition und Neuerung, lediglich der

jeweilige Anteil und Einfluß schwankt. Bei einer kritischen kulturellen Ana­

lyse sollten daher beide Dimensionen Berücksichtigung finden" (ebd.: 21 ). Retrocomputing als Medienarchäologie des frühen Mikrocomputers

nimmt sich vor diesem Hintergrund weniger als konservative/restaurative

lt's More Fun to Compute! 53

Rückbezogenheit oder privatistisches Nostalgieerlebnis8 aus, sondern viel ­mehr als eine gezielte Redaktion9 und Rekursion, bei der das Alte durch das Neue und das Neue durch das Alte aufgerufen wird: Ein Emulator für dem Commodore 64 auf einem modernen PC stellt sicherlich eine Reminiszenz jener klassischen Plattform in/als Software dar, ist aber zugleich immer auch radikal gegenwärtig, wenn im Emulator (neuer oder alter) Code ausgeführt wird. Zugleich stellt der Emulator als anspruchsvolle, moderne Software extreme Anforderungen an die ausführende Plattform und ihre Programmie­rung, weil niemals sämtliche Effekte der emulierten Plattform berücksichtigt werden können. Auf geschickte Weise werden nur spezifische Effekte der alten Plattform auf der neuen emuliert - wohlwissentlich, dass dabei alle anderen, gerade nicht benötigten Prozesse des alten Systems von der Soft­ware ignoriert werden müssen, um eine akzeptable Ablaufgeschwindigkeit zu gewährleisten. Hier führt das Alte das Neue also an seine Leistungsgrenze.

Diese Anachronismen, Rudimente und Atavismen sind dem Mikrocompu­ter der 1970er- und -80er-Jahre inhärent: Er vereint in sich zugleich (damals) neueste Halbleitertechnologie mit völlig veralteten Hardwareeigenschaften 10

,

Schnittstellen 11 und einer ganzen historischen Bandbreite von Software12• Die

Computerplattformen, die heute unter dem Siegel ,Retrocomputer' firmieren,

8 Insbesondere Marketingkonzepte wie die sogenannten ,Retro-Moden' scheinen die

medienarchäologische Brisanz von ,Retro ' zu überdecken und das Phänomen doch

wieder nur in eine Wirtschaftsgeschichte integrieren zu wollen.

9 "Für den neuzeitlichen Begriff von Archäologie ist es kennzeichnend, grabend zu suchen. Genau dies aber kennzeichnet nicht den klassisch-griechischen Gebrauch des

Wortes; in der gleichnamigen Schrift des Dionysos von Halikarnaß meint archaiolo­gia schlicht die Redaktion, das Bearbeiten alter Nachrichten." (ERNST 2004: 253 f.)

10 Die 4-bit- und 8-bit-Bus- und -Wortbreiten früher Mikrocomputer wirken im Ve r­

gleich zu den Möglichkeiten der Minicomputer der 1960er-Jahre wie gewaltige Rück­schritte. Ihre Mikroprogramme sind fest verdrahtet - eine Technologie, die ab den frü­

hen 1950er-Jahren zugunsten der Mikroprogrammierung aufgegeben wurde. Mikro­

programmierung hält erst wieder am Ende des Heimcomputerzeitalters - Mitte der

1985 mit Zilogs Z180- Einzug in die Mikroprozessoren.

II Die bitweise Schalterprogrammierung früher Mikrocomputer - wie beim Altair 8800,

Micral-8 oder Mark-8 - stellt einen Brückenschlag zur Computertechnologie der

1940er-Jahre dar. Die Ontogenese des Mikrocomputers vollzieht sich in den 1970er­

und -80er-Jahren als verkürzte Phylogenese des Digitalcomputers.

12 Als erstes finden alte höhere Programmiersprachen (Fortran, BASIC, Cobol, ... ) und

Spielkonzepte Eingang in die Speicher früher Mikrocomputer.

54 Stefan Höltgen

waren im Prinzip also schon immer ,retro ', wenn dieser Begriff auf die oben

dargelegte Medienarchäo logie rekurriert. Das bedeutet aber auch, dass Retro­computing heute damit viell eicht allenfa ll s noch eine Radikalis ierung erfährt, wenn modernste Plattformen - die selbst ja auch immer noch auf computer­archi tektonischen Überlegungen von 1945 (NEUMANN 1945) basieren - mit

denen der letzten vier Jahrzehnte verschränkt werden.

2 Epistemisches Spielzeug

Computer können nichts anderes als spielen, konstatiert CLAUS PJAS mit Verweis auf den grundsätzlichen Simulationscharakter von Software: In Computern werden Modelle der Welt auszugsweise generiert und den Regeln

des Codes unterworfen. "Was wäre wenn?" (PIAS 2001 ) ist die Frage, die der Hardware-Software-Verbund in Simulationen beantworten will - stets in

einem reduzierten Setting und unter den Bedingungen der Möglichkeiten zeitgenössischer Computertechnologie (PIAS 201 2: 58 f.). Auf diese Weise kann eine Panzerschlacht in unzähligen Variationen ,durchgespielt ' werden,

noch bevor der erste Panzer an die Front rollt, kann das ,Rendezvous' von Projektilen und Zielen in Abschießspielen berechnet werden, bevor noch das

erste Geschütz abgefeuert wird, und kann die optimale Ladung eines Ver­dichtungssprengsatzes für eine Plutoniumbombe immer und immer wieder

experimentell optimiert werden, lange bevor dieser Bomben-Prototyp über Nagasaki zur Explosion gelangt. Die enge Verzahnung von Kriegstechnolo­

gie und Computertechnologie ist in der Medienwissenschaft durch Friedrich Kittler analysiert und von Pias auf das Computerspiel übertragen worden.

Insofern lässt es den Medienwissenschaftler skeptisch aufhorchen, wenn 1983 als eine der Neuerungen im Spiel E. T. genannt wird: "It was complete­

ly non-violent. You can' t hurt the bad-guys, and they can' t hurt you. There isn ' t even any competition" (RICHARDSON 20 13).13 Dieses ,oberfl ächliche'

Narrativ steht Technologien der Konditionierung des Spielerkörpers durch

13 Der Spielverlauf, die Regeln (und ein ausführbares Binary) können auf AtariMania (o.J .) eingesehen werden.

lt's More Fun to Compute! 55

das Computerspiel' 4 ebenso gegenüber wie der programmiertechnischen Ver­wirklichung von Pixelkollisionen, die schon in den allerersten zweidimensio­

nalen Grafikdarstellungen der Radarsysteme als ,Treffen' zweier Objekte im Raum zur Anwendung kam. Bezeichnenderweise wird es beim Debugging von E. T. vor allem um die Verbesserung der Pixelkollisionsabfrage gehen -also darum, , besser zu treffen'.

Natürlich ließen sich solche Fragen an Computerspiele auch an deren

,Oberflächen' stellen. Und selbstverständlich kann und darf das , laufende Spiel' aus einer Analyse nicht ausgeblendet werden, denn erst zur Laufzeit zeigen sich ja die Effekte des Zusammenspiels von Code und Maschine.

Weil aber jene Oberflächen bereits durch die Methoden der Game Studies in ihrer Ästhetik, Wirkung, Motivgeschichte und so weiter erforscht werden, könnte ein Blick auf die , Unterflächen' einen lohnenswerten Beitrag zur Theorie der Computerspiele liefern:

Alles, was aus dem Computer kommt, existiert doppelt: es existiert als sinnlich wahrnehmbare Oberfläche (vornehm: surface) und als symbolisch manipulier­bare Unterfläche (subface). Die Oberfläche ist für uns da, für die Menschen.

Die Unterfläche ist für sie da, für die Computer. Fiir uns fangt alles mit den Sinnen an. Fiir die Maschine aber mit dem Code. Wenn jemand programmieren will, dann muss er oder sie lernen, so zu denken, wie eine Maschine denken wUrde, wenn sie es könnte. (NAKE 20 I 0; 2006)

Diese Position lässt sich sogar noch gewinnbringend radikalisieren, wenn

man die Unterfläche selbst zum Spielfeld erklärt, wie es Hacker in ihrem Selbstverständnis immer schon verlangen und auch praktizieren. Dann wird

der Blick auf das ablaufende Programm eher zu einem Messverfahren, das eruiert, welche Konsequenzen die Manipulation des Codes haben. Für dieses Spiel braucht es jedoch spezifische ,Spielregeln' , ein klar definiertes ,Spiel­

feld' und vor allem passende ,Spielutensilien'. Das gewählte Beispiel des Spiels E. T. lässt sich dahingehend adäquat ein­

grenzen: Es wurde - wie beinahe alle Titel für damalige Plattformen - in Assembler programmiert; einem 8-bit-Assembler für den Prozessor MOS 6507, der in die Hardwareumgebung der VCS-Spielkonsole mit spezifischem

Speicherdesign, Taktrate, Input-Output-Schnittstellen und Grafik-/Sound-

14 Das Computerspiel wird vom Spieler gewonnen, wenn dieser der "Verantwortung zur Pünktlichkeit" (PIAS 2002: 108) nachkommt - also zu dem Zeitpunkt, den der Pro­grammierer vorgesehen hat, genau das tut, was nötig ist, damit das Spiel weitergeht. Diese Konditionierung erfolgt intellektuell wie somatisch.

56 Stefan Höltgen

Chip (TIA - Television Interface Adapter) usw. eingebettet war. Die Kennt­ni s des Assembler-Dialektes sowie des Aufbaus der Hardware (die durch den Code "adressiert" wird) bilden im Folgenden die ,Spielregeln ' . Die moderne Entwicklungsumgebung, bestehend aus einem iMac (Intel Core i7 , 2,93 GHz, 8 GB RAM) unter Mac OS I 0.9 und einer Atari 2600 jr.-Spielkonsole mit 15-Zoll-CRT-Monitor und Harmony-Cardridge 15 generieren die ,Spielflä­

che'. Der YCS-Emulator ,Stella ' (Version 3.5)- unter Mac OS X - dient als ,Spielutensi l '. 16

Mithilfe dieser Hard- und Software ist es möglich, einen Blick in die Binary-Datei - die sich letztlich auf dem Spielmodul befindet und von der YCS ausgeführt wird - zu werfen und sie zu manipulieren. Durch den Emu­

lator kann dies als Echtzeit-Debugging durchgeführt werden: Während das Spiel abläuft, lassen sich Manipulationen der Spielsoftware vornehmen und in ihren Effekten gegebenenfall s sofort wahrnehmen. Das Spiel mit dem Code geschieht also in Echtzeit und ermöglicht, zur emulierten Hardware in

direkten Kontakt zu treten.

3 Das Projekt Fixing ,E. T.'

"Why do people hate E.T.?", fragt DAVID RICHARDSON (2013) zu Beginn

seines Debugging-Protokolls und konstatiert, dass das Spiel zum einen über

nicht wenige innovative Spielkonzepte und -ästhetiken verfügt, zum anderen aber auch verleumdet wurde, denn nicht alle vermeintlichen Fehler in E. T. sind tatsächlich ,Bugs' , sondern ein ige von ihnen sind eher ,Features'. Diese

, Features' wurden von den Spielern 1982 nur nicht als solche erkannt, weil

15 Das Harmony-Cardridge erschien 2009 und ermöglicht es, Software flir die VCS auf

SD-Speicherkarte über den Modulschacht in die Spielkonsole zu laden. Zuvor waren

bereits ähnliche ,Multi -ROM '-Module, wie die Cutt le Card, verfügbar (CARLESS

2005 : 15- 18).

16 Das Ambiente dieses neuen, medienarchäologischen Spiels ist - ana log zur Grabung

im Wüstensand von New Mexico - die ,Sandbox ': Den Code auf der Originalhard­

ware zu manipulieren, wäre nicht nur unmöglich, sondern auch nicht wünschenswert,

we il bei j edem Fehlversuch und Absturz der ,Spielstand ' verloren ginge, wohingegen

man in der geschützten Umgebung der Emulation die Möglichkeit zur Zwischenspei­

cherung und zum Anhalten des Prozesses beim Auftreten von Feh lern hat.

lt's More Fun to Compute! 57

z. B. Spiele mit Open-World-Szenarien, multiplen Lösungswegen und side quests zu dieser Zeit unüblich waren. Diese und einige andere ,Features' finden sich allerdings in E. T. - wie auch einige Probleme, die das Spiel auch

heute noch problematisch erscheinen lassen:

The game seems incredibly eomplex. This isn ' t a real problem. Once you learn how to play, it's really very simple. You just need to read the manual, or watch a tutorial video, to understand it. The game is ineredibly hard. It ' s diffieult for noviees to eomplete the game even on mode 3, the easiest setting. Fortunately, this can be fixed. You spend a Iot oftime accidentally falling in to [sie] wells. I believe that I know reason [sie] why this happens to so many people, and what can be done to fix it. E.T. is not green. I'm really surprised that this isn't a common eomplaint. We' ll fixthat as weil. (RICHARDSON 2013)

Richardson und einige User des Internetforums AtariAge nehmen sich dieser vier Probleme an und versuchen, sie im Code zu beheben. Aus Platzgründen konzentriere ich mich im Folgenden auf das dritte Problem (die Fallgruben)

und verweise bei den anderen Fixes auf das ausführliche Debugging­

Protokoll.

Zunächst sollen die beiden Software-Entwicklungsumgehungen von 1982 und 2013 gegenübergestellt werden: Der Programmierer Ho ward Scott Warshaw schrieb das Spiel E. T. im Spätsommer 1982 unter enormem Zeit­druck (KENT 200 I: 234-240) auf einer professionellen Entwicklungsumge­

bung - einer Hardware, die eigens für die Erstellung von YCS-Spielesoft­ware und die Prototypen-Entwicklung von ROM-Chips konzipiert worden

war. Diese Entwicklungsumgebung war zeitbedingt in Komplexität und Funktionalität der VCS ähnlich (ein 8-bit-Computer der frühen 1980er­

Jahre). Ein sogenannter Cross-Assembler - ein Assemblierer, der auf einer Plattform A aus mnemonischem Sourcecode Binary-Dateien für einen Mik­

roprozessor der Plattform B generiert - diente als Programmierumgebung; die Tests der Software fanden auf der Originai-Spielkonsole statt. Eine ad­

äquate Emulation der VCS wäre mit keinem der damals erschwinglichen

Mikrocomputer möglich gewesen. Demgegenüber verwendete David Richardson die VCS-Emulation

,Stella', die über einen eingebauten Debugger verfügt. Damit lassen sich die

Prozesse, die in der emulierten Hardware stattfinden, beobachten und mani­pulieren; darüber hinaus lässt sich die emulierte Maschine anhalten und in Einzelschritten (Single-Step-Debugging) in ihrem Verhalten detailliert be­

obachten (Abb. I). Schließlich verfügt der Debugger über einen Monitor, mit

dem der Speicherinhalt des Spielmoduls dargestellt werden kann. Die Dar-

58 Stefan Höltgen

stellung erfolgt als Mnemonics und Hexadezimalwerte. Letztere stellen die Opcodes des Maschinensprache-Programms sowie die Daten, die im Debug­ger manipuliert werden, dar. Da der ROM-Speicher (in dem der Programm­code des Spiels E. T. abgelegt ist) nur vier Kilobyte groß ist und der RAM­Speicher der VCS (in dem die durch den Programmcode manipulierten Daten gespeichert sind) sogar nur 128 Bytes umfasst, ist mit dem Debugger ein

guter Überblick über die Software und den Programmablauf möglich.

''"11 it1•a'111/~llr11tl0<'1 "" •A"'rr•-t.ISVIIIII,...,Uif'~.-.:::.et•ll

.. /Oeekt.opm/t,T , TtoP Eo<tra lernatl"ial.a~lla no\.

•to r'ltJ\ f :..uolli ' " · ~ICiu<:tcp/[l/[. T. - Thl [lt tra-TtrrPatr~al (l~Z) lfltar l ) . lat

\l''t"l tllPI'W"'t foondm j !D••II:too/[l ,[,T,- Th& [>~ tra-T ernstr!.al IJ<;~&Z) (RUr i ).W\jn

'"' nrx 'P\. L

'"' "" CPY acc

'"' sn ... '"'

,, ;J :2•

'"'-"' ,, ;7

"""" :2 • S07 ;2

"""' ,, •IOC ;l

'''"" ,, r"~[f " lo6 [[

;2 " L!4CC ,, 10 00 .. .,. ;l A;.: Uti r~Ef ,, ... , ,, ca •U1 ,, CO 31 Le<~C il ;2 1:02 .. .,. ,, l'ai\..Er ,, '"' f""-LL :J ~"' l l r-..rr ,,

Abb. I Überblick über die Software und den Programmablauf mit dem Debugger

Die "Umprogrammierung" einer Software über die Hexadezimalwerte im Monitorprogramm kann, solange sie nur kleine Details betrifft, sinnvoll

sein .17 Andernfalls ste llt sie e ine überaus aufwendige und kompli zierte Art

17 Mit dieser Methode läss t sich sogar das Erlernen der Assembler-Programmiersprache umgehen, wie ADAM TRIOFONO in sei nem Essay "Changing Atari YCS Graphics -The Easy Way" beschreibt: "Creating an Atari YCS game is beyond me at Lhis poinl. The fac t did not stop me from wondering how to change in-game graphics. [ ... Thai] requires no programming skill. [ ... ] To change graphics in a VCS game, one only needs to know addition and conversion from decimal to hexadecimal" (TRIOFINO 20 12). - Aber selbst für die Arithmetik nennt der Autor dann noch Tools, die dem , Umprogrammierer' diese Denkarbeil abnehmen.

lt's More Fun to Compute! 59

des Debuggings dar: "[B]inary hacking is a can of complex, time-consuming, and unwholesomely difficult worms, especially if you want to rewrite !arge chunks of the game" (KüHLER 2006: 375). Der Grund hierfür liegt nicht nur in der schweren Lesbarkeit des Programmcodes in Form von Hexadezimal­werten, sondern auch darin, dass das Programm mit ,fester Adresse' assem­bliert vorliegt und sich Codebestandteile deshalb nicht einfach verschieben lassen, wenn zusätzlicher Platz an einer bestimmten Stelle benötigt wird, weil dadurch gegebenenfalls Sprungziele verändert werden. Bei einer alten Plattform wie der VCS kommt verschärfend hinzu, dass der Code aufgrund der Langsamkeit der Hardware mit genauem Gespür für den Prozessortakt, den Rücklauf des Kathodenstrahls und andere zeitkritische Hardwareele­mente entwickelt werden muss . Das Einfügen auch nur eines zusätzlichen Befehls an bestimmten Stellen kann das gesamte Spiel ,aus dem Takt' brin­gen und unspielbar machen.

Die Umprogrammierung wird wesentlich erleichtert, wenn man Zugriff auf den Sourcecode des Spiels bekommt oder eine Rückübersetzung durch einen Disassembler18 zur Verfügung steht. Der besser lesbare Assembler­Code lässt sich dann nach der Bearbeitung wieder in ein Binary übersetzen und in den Emulator oder die Konsole laden. Zur Zeit des Debuggings von E. T. hatte Richardson nach eigener Auskunft keinen Zugriff auf einen Assembler-Sourcecode. 19 Einige Korrekturen - wie die Farbanpassung der E. T.-Spielfigur von Grün nach Braun - haben keine Probleme bereitet, wo­hingegen andere einen durchaus höheren Programmieraufwand nach sich zogen, der allerdings als Nebeneffekt ein tief(er)es Verständnis des Software­Hardware-Verbundes mit sich gebracht hat. Richardson hat sowohl für das eigene Verständnis als auch für die ,Didaktik' seiner Dokumentation die betreffenden Hex-Codes aus dem Binary extrahiert und in mnemonischen Assemblercode übersetzt.

18 Über den Verbleib des E. T.-Sourcecodes von Howard Scoll Warshaw ist bis dato

nichts bekannt. Ein Disassembler stellt die Rückübersetzung der Assembler-Mne­

monics aus der Binary-Datei her. Nach diesem Übersetzungsschrill ist es aber zumeist

noch nötig, den erhaltenen Code zu kommentieren, um so die Strukturen des Pro­

gramms erkennbar zu machen. Zudem ergibt sich auch immer die Gefahr, dass der

Code durch Maßnahme der Obfuskierung vor der Rückübersetzung (und damit vor

Manipulation, Vervielfältigung etc.) geschützt wurde, was zu gravierenden Fehlern in

der Rückübersetzung führen kann (GELFRAND et al. 1987: 55- 119).

19 Ein auskommentiertes Disassamblat hat DENNIS DEBRO (20 I 0) vorgelegt.

60 Stefan Höltgen

4 Pitfall! Löcher im Boden - Löcher im Code

"The myth: A Iot of people blame poor collision detection for this problem",

beginnt RICHARDSON (2013) seinen Abschnitt über die ständigen "versehent­

lichen" Stürze der Spielfigur in die Gruben (Abb. 2). Die Pixelkollisionen in

E. T. ist allerdings keineswegs schlecht, sondern vielmehr ,zu gut': Geht man

als Spieler davon aus, dass man nur dann in eine Grube stürzen kann , wenn

man mit den Füßen hineintritt, so stellt man bei E. T. fest, dass bereits die

Berührung der Grube mit irgend einem Teil des Körpers ausreicht, um hin­

einzustürzen.20 Der Grund dafür liegt in der ungewöhnlichen Perspektive der

Spielgrafik. Das Spielareal wird dem Spieler aus einer erhöhten Position

dargeboten - zu erkennen daran, dass die Fallgruben oft oval dargestellt sind.

Die Gebäude und Spielfiguren erscheinen hingegen in der Seitenansicht, was

RICHARDSON zu der Annahme veranlasst, die Grafik zeige einen "Three

Quarters View [ . .. ] a 'tilted bird's eye view perspective"' (R!CHARDSON

20 13). Diese Mischperspektive bietet zugleich einen Überblick über das

Spielareal al s auch die Seitenansicht der Spielfiguren (Abb. 3). Letzteres

erleichtert dem Programmierer die Steuerung der Figuren; ersteres führt aber

zu jener problematischen Pixelkollisionsabfrage.

Abb. 2 und 3 E.T. in einer Fallgrube (links) und auf einem Areal mit verschiedene n

Fallgruben (rechts)

Richardson löst dieses Problem, indem er den Bereich des Spielfiguren­

körpers, der bei der Pixelkollision abgefragt wird, verkleinert: War es im

Original die gesamte Spielfigur, die nicht mit den Grubenrändern kollidieren

durfte, so ist es im Hack nun nur noch der untere Bereich (die Füße). Somit

20 Im YouTube-Yideo "How close we can get to the wells?" erprobt ein Spieler die Annäherung an die Grubenränder: http://www.youtube.com/watch ?v=tKGBSyZWu Ek.

lt's More Fun to Compute! 61

kann die Figur an einer Grube vorbeigehen und die Grafik ihres Oberkörpers die Grafik der Grube überlappen, ohne dass die Figur hineinfällt. Damit stimmt auch die Perspektive wieder (Abb. 4).

Abb. 4 E.T. kann in der neuen Version die Fallgrube mit dem Körper berühren ohne hineinzufallen.

Dieser ebenfall s verhältnismäßig einfache Hack hat allerdings Konse­

quenzen: Dadurch, dass nicht mehr der gesamte Körper der Spielfigur bei Pixelkollisionen abgefragt wird, treten drei Probleme auf:

We can't pick-up phone parts. (We ' ll fix this a little later.) We need to step on candy to collect it. (Thi s is a problem we can ' t yet avoid.) The routine isn't called when there is another character next to you . [ .. . ] If part of your sprite overlaps a weil and another character approaches, the collision latches won ' t get cleared and you ' ll fall right it! (ebd.)

Um diese Folgeprobleme zu beheben, ist es notwendig, zusätzlichen Code in das Spiel einzufügen - eine Maßnahme, die, wie oben geschi ldert, in einer

Binary-Datei nur mit großen Schwierigkeiten vollzogen werden kann. Zu­nächst konzentriert Richardson sich auf das letztgenannte Problem, für das

eine neue Routine in das Spiel eingefügt werden muss, die diesen Sonderfall korrekt behandelt. Der dafür benötigte Platz muss erst einmal gefunden wer­den, indem der komplette Programmcode daraufhin untersucht wird, ob

irgendwelche ,Löcher' darin enthalten sind - also ,Orte' in der Binary-Datei ,

an denen entweder gar nichts oder nicht benötigte Bytes gespeichert sind. Nachdem Richardson ein paar vielversprechende Kandidaten identifiziert

und wieder verworfen hat, stößt er auf einen relativ großen Bereich, der

durch Löschung und Umprogrammierung einer vorhandenen Routine frei wird: "We need at least 9 bytes for our routine, but our Juck is holding out

62 Stefan Höltgen

and we can safely eleminate the WSYNC at I 060 giving us a whole 10 bytes to use as we please" (ebd.) . WSYNC (,Wait for Horizontal Sync ' ) ist eine spezifische Adresse im TlA, die den Aufenthaltsort des Kathodenstrahls ,kennt ' .21 Durch Entfernung dieser Abfrage wird die Generierung einer Spiel­

figurengrafik hier derartig beeinflusst, dass sie die Hälfte ihrer Zeilen ei nbüßt und danach durch Verdopplung jeder Pixelzeile etwas gröber aufgelöst dar­gestellt wird.22 Dies nimmt Richardson gegenüber dem Gewinn an Spielbar­

keit in Kauf.

Abb. 5 In den Fallgruben verbergen sich Gegenstände zum Einsammeln .

Die beiden anderen Probleme, das notwendige Berühren der Pflanzen

m der Grube (Abb. 5) sowie das Aufsammeln der Süßigkeiten, bearbeitet RICHARDSON in zwei kurzen Abschnitten:

If you've been following along, you've probably already figured out that the

reason we can't collect phone parts is because E.T.'s feet never touch them.

Hovering up to make E.T.'s feet touch them doesn't work which seems obvious

in retrospect. The simplest so lution is to just move the phone parts down the

2 1 Der Bildaufbau bei der VCS ist eng an die Steueru ng des Kathodenstrahlseines ange­sch lossenen Fernsehers oder Monitors gekoppelt. Zwar wird die Position dieses Strah ls nicht wirklich abgefragt, aber der TlA generiert se in Videosignal synchron zum Bildschirm, sodass die Position des Kathodenstrahls stets durch Abfrage der Videosignal-Generierung erm ittelt werden kann (MONTFORT/BOGOST 2009: 30). Diese Rasterstrahl-nahe Art der Programmierung ist der Hintergrund des Buchtitels Racing the Bewn, der nichts anderes meint, als dass der Programmierer der VCS programmierend auf dem Kathodenstrahl reitet (ebd.: 28) .

22 Über die Zusammenhänge der Sprite-Generierung in Verbindung mit dem Raster­strahl rücklauf siehe WRIGHT ( 1979: 3- 1 0).

It 's More Fun to Compute! 63

screen a little bit so that they 're lying on the ground and not hovering in mid­air. lt's an easy fix, just one byte . (ebd .)

Das Problem, dass die perspektivisch unrealistischen Grubenstürze wieder auftreten, sobald eine andere Spielfigur in der Nähe ist, weil dann die neue, o. g. Routine nicht aufgerufen wird , stellt sich als etwas komplizierter dar.

Zu seiner Behebung muss zunächst wieder ,Platz' gefunden bzw. geschaf­fen werden. Zunächst entfernt Richardson eine Routine, deren Effekt er oh­nehin für fragwürdig erachtet: Wenn E. T. stirbt, wird eine blutende Wunde an seinem Körper gezeigt. ROBERTSON sieht hierin einen Widerspruch zur "Familienfreundlichkeit" des gewaltfreien Spielsujets und kommt daher zu dem Schluss: "[A] new feature is much better than a bleeding E. T." (ebd.). Durch die Entfernung der Routine wie auch durch andere Verfahren des Code-Bumming und der -Verschiebung gewinnt er Speicherplatz und Prozes­sor-Taktzyklen, in denen eine neue Routine abgearbeitet werden kann. Denn der Programmteil , der nur die Fußregion der Spielfigur für die Pixelkollision abfragt, wird nun als Subroutine realisiert, damit er in verschiedenen Situa­tionen aufgerufen werden kann. Hierzu ist nicht nur Platz nötig, sondern auch die präzise Beachtung des Programm-Timings.

5 Das Spiel mit dem Code als Archäologie

In der obigen Darstellung habe ich darauf verzichtet, Codebestandteile aus dem Paper von Richardson zu zitieren. Die Auseinandersetzung mit dem Code ist zwar zwingend erforderlich, wenn man den Fixing-Prozess in Gänze nachvollziehen will, zur Darlegung des Prozesses als "medienepistemologi­sches Spiel" kann jedoch darauf verzichtet werden. Klar werden sollte hier vielmehr: Durch Eingriff in den Programmcode lässt sich dieser zwar mani­pulieren; der Eingriff zeitigt jedoch Folgen, die problematisch sind und eine Reihe zusätzlicher Eingriffe notwendig machen. Diese Folgen betreffen ins­besondere den ,reibungslosen Ablauf' des Spiels, denn das Einfügen zusätz­lichen Codes verändert das Zeitverhalten des Spiels und ist ein raumfordern­der Prozess.

Hier verschränken sich eine Reihe medienwissenschaftlicher Fragestel­lungen: Wie stellen sich die Zeitverhältnisse im Computer zur Laufzeit dar? In welchem Zusammenhang stehen Software (Spielcode) und Hardwarefunk-

64 Stefan Höltgen

tion , insbesondere bei maschinennaher Programmierung? Und nicht zuletzt: Welche Möglichkeiten der (autodidaktischen) Medienkompetenzbildung er­geben sich durch die Konfrontation von alter und neuer Technik? Am Bei­sp iel E. T. ließ sich zeigen, dass die Diskuss ion eines Spiels von seinem Ein­fluss auf die Wirtschaftsgeschichte der Spielindustrie bis hin zu seinen

medienarchäologischen Facetten (hier etwa die Frage der Pixelkollision als Rudiment von Kriegstechnologien der Yisuali sierung) ebenfalls auf der Codeebene (nach)voll zogen werden kann. Die Erkenntn isse, die sich über e ine solch ,unterflächliche' Analyse einstellen, ermöglichen e ine medienwis­

senschaftliche Diskussion über Computerspiele abseits diskursiv-verhandel­barer Momente von Sinnproduktion; sie versuchen vielmehr das medientech­nische Apriori dieser Sinnproduktion aufzuzeigen und seine idiosynkrati­

schen Aspekte freizulegen. Die Atari YCS ist eine der am besten erforschten Plattformen der Compu­

terspiel-Geschichte, stellt aber trotzdem oder gerade deswegen auch heute

noch eine Herausforderung für viele Retrocomputer-Hobbyisten dar. Ihr e in­facher Aufbau, ihre überschaubaren Funktionen und die verhältnismäßig

leicht zu erlernende Programmierung generieren ,kreative Schranken' für Hacker, immer neuere, elaboriertere Spiel- und Demokonzepte auf ihr zu

verwirklichen. Für kaum eine andere alte Spielkonsole erscheint so regelmä­ßig so viel neue Software. Die Retrocomputer- und -sp iei-Community liefert hierfür die besten Bedingungen, indem sie Dokumentationen frei zugänglich

macht, e infache Anleitungen (zur Programmierung, zum Modding usw.)

publiziert und ohne Unterlass in Diskuss ion miteinander steht. Dies ist nur möglich, weil das Alte auf das Neue trifft: Yernetzung und Informationsdi s­

tribution im Internet, Entwicklung von Crossdevelopment-Tools und Emula­toren für neueste Systeme, Bau von Hardware-Erweiterungen, welche die

Analyse und Entwicklung von Software für die Originalplattform verein­fachen, die komplette Yirtualisierung von Spielplattformen23 und so weiter.

Zusammengezählt verdeutlichen diese Aspekte, dass Retrocomputing und -gaming weit über die Aktivierung einer Erinnerungskultur hinausgeht, son­

dern sich selbst als Wille zum Wissen offenbart.

23 Wer weder eine Atari YCS besitzt , noch den Emulator installieren möchte, kann seit

kurzem online unter JSMESS E. T. spielen, das zusammen mit zahl reichen anderen

Titeln für die YCS und andere Computer und Spielkonsolen in die Software-Samm­

lung von archive.org aufgenommen wurde (The Internet Archive Software Collection

o. J.).

It's More Fun to Compute! 65

Quellen

AtariMania (o.J.): E.T. - The Extra-Terrestrial (ROM-Image des Originals mit Ab­

bildungen, Screenshots und Scans): www.atarimania.com/game-atari -2600-vcs­et -the-extra-terrestrial_7300.html.

BRAGUINSKI, N. (2013) : Das klinget so herrlich, das klinget so schön. Die Ästhetik der Atari VCS-Sounds. In : Retro Magazin Nr. 28 (2/2013), S. 30-33.

CAREY, E. J . (2005): Retro Game Programming. Unleashed for the Masses . Boston:

Thomson Curse Technology.

CARLESS, S. (2005): Gaming Hacks. 100 lndustrial-Strength Tips & Too/s. Bejing u.a. : O ' Reilly.

DEBRO, D. (2010): Disassemblat von "E.T. - The Extra-Terrestrial". In : ROM­hacking.net: http ://www.romhacking.net/documents/480/.

FREUNDORFER, S. (2009): Als E.T. die Videospiele killte. In: Spiegel Online - Eines Tages: http://einestages.spiegel.de/static/topicalbumbackground/3764/ als_e_t_die_ videospiele_killte.html.

GELFRAND, R. et al. ( 1987) : Das Anti-Cracker-Buch : Für C64 und C/28. Düssel­

dorf: Data Becker.

GOLDBERG, M./VENDEL, C. (20 13): Atari lnc. : Business is Fun. Cannel: Syzygy

Company Press.

HöLTGEN, S. (20 13): Game Circuits. Platform Studies und Medienarchäologie als Methoden der Erforschung von Computerspielen. In: BENJAMIN BIGLISEBASTIAN STOPPE (Hrsg.): Playing with Virtuality. Theorie.\· and Methods of Computer Game Studie.\· . Frankfurt am Main: Lang, S. 83-100.

HUHTAMO, E. (2007): Eine Archäologie des elektronischen Spiels. In : CHRISTfAN H./PIAS, C. (Hg.): Escape! Computerspiele als Kulturtechnik. Köln u.a.: Böhlau .

JÄGER, S. (2014): Erster Trailer zur E.T.-Ausgrabungs-Doku. In : gamona, 28.07.20 14: www .gamona.de/games/atari-game-over,erster-trailer-zur-e-t -ausgra­bungs-doku:news,2498906.html .

KüHLER, C. (2005) : Retro Gaming Hacks. Tips & Too/s for Playing the Classics. Bejing u. a.: O'Reilly.

MONTFORT, N./BOGOST, I. (2009): Racing the Beam. The Atari Video Computer System. Cambridge/London: MIT Press.

NAKE, F. (2006) : Das doppelte Bild. Bildwelten des Wissens. In: Kunsthistorisches Jahrbuchfür Bildkritik Nr. 3, 2/2006, S . 40-50.

66 Stefan Höltgen

NAKE, F. (20 I 0): Oberfläche & Unterfläche I Vom Zeichnen aus großer Ferne: http://node I 0. vvvv.org/events/lecture-day.

NEUMANN, J. VON ( 1945): First Draft of the Report on the EDV AC: https://archi ­

ve.org/details/firstdraftofrepoOOvonn.

o. V. ( 1983) : Atari Parts Are Dumped. In : The New York Times, 28.09.1983: www. nyti mes.com/ 1983/09/28/business/atari -parts-are-dumped. html.

PIAS, C. (200 I): Synthetic History. In : Archiv für Mediengeschichte 1/200 I (The­

menheft "Mediale Historiographien").

PIAS, C. (20 12): Zur Epistemo logie der Co mputersimulation. In: BERZ, P. et al. (Hrsg.): Spielregeln. 25 Auf\"lellungen. Eine Festsdniji jlir Wolfgang Pircher. Zürich/Berlin : diaphanes, S. 41 - 60.

RICHARDSON, D. (20 13): Fixing E.T. The Extra-Terrestrial for the Atari 2600:

www.neocomputer.org/projects/et/.

SANTOS, F. (20 13): Hunting for an E.T. Castoff in a Most Terrestrial Place. In : The New York Times, 17.06.201 3: www.nytimes.com/20 13/06/18/us/hunting-for-an­et -casto ff-i n-a- most -terrestrial-place. html ? _r=O.

The Internet Archive Software Collect ion (o.J .): Historical Software Co llect ion : E. T . The Extra-Terrestrial ( 1982) (Atari) (NTSC): https://archive.org/details/

E.T._ The_Extra-Terrestriai_ I982_ Atari_ NTSC.

TRIOFINO, A. (2012): Changing Atari VCS Graphics - The Easy Way: www.orpha­nedgames .com/ocgs/issue 12/vcsgraph .html.

WRIGHT, S. ( 1979): Stella Programmer' s Guide. Reconstructed by Charles Sinnett:

http:/ /atari hq .com/danb/fi les/stella. pdf.