Ann-Marie Letourneur I Michael Mosel I
Tim Raupach (Hrsg.)
Retro-Games
und Retro-Gaming
セキQj@
Nostalgie als Phänomen einer
performativen Ästhetik von
Computer- und Videospielkulturen
Fachverlag für Medientechnik und -wirtschaft
A. -M. Letourneur/M. Moselrr. Raupach (H rsg.): 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.
© Verl ag Werner Hül sbusc h, Glückstad t, 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 Hlilsb usch, GIUckstadt.
Eine weitere Verwertung im Sinne des Urheberrechtsgesetzes ist nur mit
Zustimmung der Autor/inn/en mög lich.
Markenerklärung: Die in diesem Werk wiedergegebenen Gebrauchsnamen, Handelsnamen, Warenzeic hen usw. können auch ohne besondere Kennzeichnung geschlitzte
Marken sein und als solche den gesetzlic hen Bestimmungen unterli ege n.
Korrektorat und Satz: Werner Hülsbusch
Umschlag: design of media, Lüchow
Druck und Bindung: Kunsthaus Schwanheide
Printed in Germa ny
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 Computers piel in die Medie n
(SANTOS 20 13), das schon in den Jahrzehnten zuvor für eini ge Schl agzeilen,
Lex ikoneinträge und Retrospektiven gesorgt hatte: Das von Atari 1983 in
großen Stückzahl en in der Nähe der Stadt Alamogordo (in New Mex ico,
USA) vergrabene Spiel E. T. The Extraterrestrial 1 sollte im Zuge von Filmarbeiten ,exhumiert' werden. Warum wurde es vergraben? Um die Lager damals nicht mit dem Spi el (sowie weiteren ,Ladenhütern ' ) aus dem mi sslungenen Weihnachtsgeschäft 1982 zu belasten, hatte man sich entschl ossen, die
Datenträger auf einer Mülldeponie zu entsorgen. Seitdem ist der "Modul Friedhof' eine der häufi gst zitierten Urban Legends der ComputerspielIndustri e, die es in zahl reiche Anekdoten, Verschwörungstheorien2 und sogar
in die Literatur (GILLIES 2008: 67, 79, 85 ) geschafft hat. Fünf Milli one n
Spielmodule vermutete man dort im Sand (o. V. 1983). Nun hat die Ausgrabung stattgefunden 3 und der Dokumentarfilm ist ferti g (J ÄGER 201 4), de r
dieser Geschichte auf den Grund geht und für den die Filmemacher eine
Grab-Erl aubni s der ansäss igen Gemeinde erwirkt hatten.
Während man dort also mit archäologischem Eife r nach ,dem wahre n
Kern ' hinter der Legende suchte (und dabei zugleich einen der produktivste n
Computerspiel-Mythen beerdigt hat), hatte ein paar Monate zuvor eine ganz
andere ,Grabungsaktion ' zum selben Spiel Ergebni sse zutage gefördert. In
einem Kooperationsprojekt haben der Hobbyist David Richardson und einige
User des Internetforums ,AtariAge' das Spielprogramm E. T. aus den ROMChips der Module ,geborgen ' und die mutmaßlichen Proble me, die zum da-
I im Folgenden kurzE. T.
2 Dazu zähl t, dass E.T. einer der Ha uptverantwortlichen des soge nann te n ,Videosp ie iCras hs' vo n 1983 gewesen sein so ll , bei dem zahlreiche Hard- und Softwarefirmen insolvent gingen (FREUN DORFER 2009).
3 Gefunden wurden dabei all erd ings nur weni ge Hundert E.T.-Modul e.
50
Stefan Höltgen
maligen Flop des Spiels geführ t haben sollen, mit verschiede nen Methoden
angegangen.
In diesem Beitrag soll es um di e archäologischen Methoden dieser zweiten Bergungsaktion gehen. Dabei wird nicht die Firmen- und Wirtschaftsgeschichte des Computerspiels4 fo kuss iert, di e mit der Grabung in Almogordo
ja fraglos bereichert werden sollte, sondern eine Archäologie im Foucault'schen Sinne als Archäologie des du rch Medientechnologien vermittelten Wissens angestrebt. Nachdem zunächst der Rahmen der Überlegung im
Gebiet des Retrocomputings und -gamings situiert wurde, sollen kurz eini ge
theoreti sche Ansätze vorgestellt werden, die alte Computerspiele als Medien
des Wissens neu bewerten. Die Werkzeuge des Medienarchäologen unterscheide n sich dabei ganz wesentlich von de nen des ,kl assischen ' Archäologen, was sich bei ihrer Anwendung auf die Spi elsoftware E. T. zeigen wird .
Mithilfe der Tools ne uer Computersysteme können alte Computerspiele auch
heute noch modifi ziert, debugged und erweitert werden - mehr noch: Heute
stehen sogar Werkzeuge zur Verfügung, di e ganz andere Zugriffsmöglichkeiten 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 (fre mden) Codes offenbart, soll im
Verlauf der Ausführungen und anhand einer spezifisc hen Korrektur des
Spiels E. T. deutlich werden. Ein derarti ger Zugriff auf di e Software einer
spezifi schen Plattform (in diesem Fall der Spielkonsole Atari VCS/2600 5)
kann nicht nur ein Verständni s der Funkti onsweise einer spezifischen Pl att-
4 Hierzu lassen sich GOLDBERG und YEN DEL sehr ausführlich im ersten Teil ihrer kürzlich erschienen Atari -Firmenbiogra fie aus (GOLDBERGIV EN DEL 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 definieren sie den Begriff Plau form als: "a parti cul ar standard or specification before any
particul ar implemenlati on 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 certainl y did. This can be
done by means of the chips, boards, peripherals, controllers, and other components thal
make up the hardware of a ph ys ical computer system" (MONTFORT/BOGOST 2009: 2). Dass die von MONTFORT/BOGOST dami t inaugurierten "Platform Studies" zwar methodische Ähnlichkeilen zur Medi enarchäologie aufwe isen, jedoch in ihrer Konsequenz
eher den Cullural Studies als einer Medi enepistemologie 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 structures of games has not changed. [ ... ] Master the past to understand the present" (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 Aufmerksamkeit, 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 - insbesondere dem Commodore 64, dem Commodore Amiga und Computerspielkonsolen 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 -Steuerungen 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 Retrocomputern und -konsolen designt sind sowie neue Software, programmiert
für alte Systeme.
Gerade diese drei Felder verdienen innerhalb einer Untersuchung des Retrocomputings 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 verschiedener Plattformen, die ihre medientechnischen Funktionen bestimmt.
7 Retro Maga zin, RETURN, LOAD, Retro Gamer, Powe1play und unregelmäßige Ch ipSonderhefte
52
Stefan Höltgen
der "Frage nac h dem Kanal " Priorität vor dem, was in ihm übertragen wird,
einzuräumen. Elektroni sche Medi en wi e Fernseher, Radios, Telefone und
Computer nehmen durch ihren Aufbau, ihre technische Reali sation und die
zeithistorischen Möglichkeiten (und Unmöglichkeiten!) ihres Designs nämlich deutlichen Einfluss auf die Inhalte und Ästhetiken ihrer Übertragungen.
Di es 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 sch iefen Tönen (BRAGUINSKI 20 12) geprägt sind . Die Idiosynkrasien der Hardwares schreiben sich hier auf eine sehr deutliche Wei se in die
Ästhetiken der Software-Effekte ein, weswegen ihnen unbedingte Aufmerksamkei t geschuldet sein sollte. Es gi lt für eine derartig ausgerichtete Medienwissenschaft also, sich der Medientechnik als dem Apriori des Medieninhaltes zu widmen und ästhetische, soziologische sowie kulturhistorische
Fragestellungen an die Fachdisziplinen zu delegieren.
Der Ansatz stellt eine Übertragung und Verschärfung der Überlegungen
Michel Foucau lts 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 Entstehung 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äologie der Automatenspiele beide Zugriffe auf deren Geschichte: "Alle kulturellen 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 Analyse 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 Nostalgieerlebnis 8 aus, sondern viel mehr als eine gezielte Redaktion 9 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 di e ausführende Plattform und ihre Programmierung, 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 Software 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 Mikrocomputer der 1970er- und -80er-Jahre inhärent: Er vereint in sich zugleich (damals)
neueste Halbleitertechnologie mit völlig veralteten Hardwareeigenschaften 10,
12
Schnittstellen 11 und einer ganzen historischen Bandbreite von Software • 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
suche n. Genau dies aber kennze ichnet nicht den klassisch-griechischen Gebrauch des
Wortes; in der gleichnamigen Schrift des Dionysos von Halikarnaß meint archaiologia schlicht die Redaktion, das Bearbeiten alter Nachrichten." (ERNST 2004: 253 f.)
10 Die 4-bit- und 8-bit-Bus- und -Wortbreiten früh er Mikrocomputer wirken im Ve rgleich zu den Möglichkeiten der Minicomputer der 1960er-Jahre wie gewaltige Rückschritte. Ihre Mikroprogramme sind fest verdrahtet - eine Technologie, di e ab den frühen 1950er-Jahren zugunsten der Mikroprogrammierung aufgegeben wurde. Mikroprogrammierung 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 1970erund -80er-Jahren als verkürzte Phylogenese des Digitalcomputers.
12 Als erstes finden alte höhere Programmi ersprachen (Fortran, BASIC, Cobol, ... ) und
Spielkonzepte Eingang in die Speicher früher Mikrocomputer.
Stefan Höltgen
54
waren im Prinzip also schon immer ,retro ', wenn dieser Begriff auf die oben
dargelegte Medienarchäo logie rekurriert. Das bedeutet aber auch, dass Retrocomputing heute damit viell eicht allenfall s noch eine Radikalis ierung erfährt,
wenn modernste Plattformen - di e selbst ja auch immer noch auf computerarchitektonischen Überlegungen von 1945 (NEUMANN 1945) basieren - mit
denen der letzten vier Jahrzehnte verschränkt werden.
2
Epistemisches Spielzeug
Computer können ni chts anderes als spielen, konstatiert CLAUS PJAS mit
Verweis auf den grundsätzlichen Simulationscharakter von Software: In
Compute rn 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 Simulati onen beantworten will - stets in
eine m reduzierten Setting und unter den Bedingungen der Möglichkeiten
zeitgenössischer Computertechnologie (PIAS 201 2: 58 f.). Auf diese Weise
kann eine Panzerschl acht in unzähli gen Variationen ,durchgespielt' werden,
noch bevor der erste Panzer an di e 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 optimal e Ladung eines Verdichtungssprengsatzes 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 Kriegstechnologie und Computertechnologie ist in der Medienwissenschaft durch Friedrich
Kittler analysiert und von Pias auf das Computerspiel übertragen worden.
Insofern lässt es den Medienwi ssenschaftler skepti sch aufhorchen, wenn
1983 als eine der Neuerungen im Spiel E. T. genannt wird: "It was completely non-v iolent. 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 Konditi onierung des Spi elerkörpers durch
13 Der Spielverlauf, di e 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 Verwirklichung von Pixelkollisionen, die schon in den allerersten zweidimensionalen 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 manipulierbare 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 ,Spielfeld' und vor allem passende ,Spielutensilien'.
Das gewählte Beispiel des Spiels E. T. lässt sich dahingehend adäquat eingrenzen: 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 gewo nnen, wenn di eser der "Verantwortung zur
Pünktlichkeit" (PIAS 2002: 108) nachkommt - also zu dem Zeitpunkt, den der Programmierer 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 Kenntni s des Assembler-Dialektes sowie des Aufbaus der Hardware (die durch den
Code "adressiert" wird) bilden im Folgenden die ,Spielregeln ' . Die moderne
Entwickl un gsumgebung, 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
,S pi elutensi 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 Emulator 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 geschi eht also in Echtzeit und ermöglicht, zur emu lierten 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 all e 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ög li cht es, Software flir di e VCS auf
SD-Speicherkarte über de n Modulschacht in di e Spielkonsole zu laden. Zuvor waren
bereits ähnliche ,Multi-ROM '-Module, wie die Cuttle Card, verfügbar (CARLESS
2005 : 15- 18).
16 Das Ambiente dieses neuen, medie narchäologischen Spiels ist - ana log zur Grabung
im Wü stensand von New Mex ico - di e ,Sandbox ': Den Code auf der Originalhardware zu manipulieren, wäre nicht nur unmöglich, sondern auch nicht wünschen swert,
we il bei j edem Fehlversuch und Absturz der ,Spielstand ' verloren ginge, wohingegen
man in der geschützten Umgebung der Emulation die Möglichke it zur Zwischenspeicherung und zum Anhalte n 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 DebuggingProtokoll.
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 Zeitdruck (KENT 200 I: 234-240) auf einer professionellen Entwicklungsumgebung - einer Hardware, die eigens für die Erstellung von YCS-Spielesoftware 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 1980erJahre). Ein sogenannter Cross-Assembler - ein Assemblierer, der auf einer
Plattform A aus mnemonischem Sourcecode Binary-Dateien für einen Mikroprozessor 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 manipulieren; darüber hinaus lässt sich die emulierte Maschine anhalten und in
Einzelschritten (Single-Step-Debugging) in ihrem Verhalten detailliert beobachten (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 erfol gt als Mnemonics und Hexadezimalwerte. Letztere stellen di e
Opcodes des Maschinensprache-Programms sowie die Daten, die im Debugger manipuliert werden, dar. Da der ROM -Speicher (in dem der Programmcode des Spiels E. T. abgelegt ist) nur vi er Kilobyte groß ist und der RAMSpeicher der VCS (in dem di e durch den Programmcode manipulierten Daten
gespe ichert sind) sogar nur 128 Bytes umfasst, ist mit dem Debugger ein
guter Überblick über die Software und den Programmabl auf möglich.
''"11
ゥエQ。GOセャイP\@
B
aBGイMエNisvLuゥヲセZ・ャ@
../Oeekt.opm/t,T , TtoP Eo<tra
f :..uolli ' " ·
セicゥオ\Zエ」ーO
{ャON@
T. - Thl
\l''t"l tllPI'W"' t foondm
•to r'ltJ\
{ャエ
エ イ。Mt
エイ
j !D••II:too/[l ,[,T,- Th& {^セ
エ イ。Mt
・イョウエAN。ャ@
イp。エセャ@
ャ・イョ。エBゥNセ@
no\.
HャセzI@
,,
lfltar l ) . lat
ij\[セFzI@
;J
(RUr i ).W\jn
'"'-"'
""""
"""'
'''""
nrx
'"'
• S07
•IOC
イBセ
'P\.
L
'"'
""
...,.
L!4C C
イセ
...'"''"' ...,.
CPY
acc
sn
{ヲ@
;7
:2
;2
,,
,,
",,
,,,
,,
,,,,
,,:J
;l
;2
;l
eヲ@
•U1
l・\セc
,,:2•
ゥ ャ@
l'ai\.. Er
f""-LL
r-..rr
;2
lo6 [[
...,
"
10 00
A;.: Uti
ca
CO 31
1:02
'"'
セBG@
ll
Abb. I Überbli ck über di e 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 stellt sie e ine überaus aufwendi ge 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 beyo nd me at Lhis poinl.
The fac t did not stop me from wondering how to change in-game graphi cs. [ ... Thai]
requires no programming skill. [ ... ] To change graphics in a VCS game, one onl y
needs to know addition and conversion from decimal to hexadecimal" (TRIOFINO
20 12). - Aber selbst für di e 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 Hexadezimalwerten, sondern auch darin, dass das Programm mit ,fester Adresse' assembliert 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 ei ner 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 Hardwareelemente entwickelt werden muss . Das Einfügen auch nur eines zusätzlichen
Befehls an bestimmten Stellen kann das gesamte Spiel ,aus dem Takt' bringen und unspielbar machen.
Die Umprogrammierung wird wesentlich erleichtert, wenn man Zugriff
auf den Sourcecode des Spiels bekommt oder eine Rückübersetzung durch
einen Disassembler 18 zur Verfügung steht. Der besser lesbare AssemblerCode 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, wohingegen andere einen durchaus höheren Programmieraufwand nach sich
zogen, der allerdings als Nebeneffekt ein tief(er)es Verständnis des SoftwareHardware-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-Mnemonics aus der Binary-Datei her. Nach di esem Übersetzungsschrill ist es aber zumeist
noch nötig, den erhaltenen Code zu kommentieren, um so die Strukturen des Programms 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älti gung etc.) geschützt wurde, was zu grav ierenden Fehlern in
der Rückübersetzung führen kann (GELFRAND et al. 1987: 55- 119).
19 Ein auskommentiertes Disassamblat hat DENNIS DEBRO (20 I0) vorgelegt.
60
4
Stefan Höltgen
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 " versehentlichen " 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 hineinzustü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 Spielfigurenkö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 Konsequenzen: 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 . Zunä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 werden, 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 ei nen 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
spezifi sche Adresse im TlA, die den Aufenthaltsort des Kathodenstrahls
,kennt ' .2 1 Durch Entfernung dieser Abfrage wird die Generierung e iner Spielfigurengrafik hier derartig beeinflusst, dass sie die Hälfte ihrer Zeilen ei nbüßt
und danach durch Verdopplung jeder Pixelzeile etwas gröber aufgelöst dargestellt wird.22 Dies nimmt Richardson gegenüber dem Gewinn an Spie lbarkeit 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) sow ie 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 angesch lossenen Fern sehers oder Monitors gekoppelt. Zwar wird die Position dieses
Strah ls ni cht wirklich abgefragt, aber der TlA generiert sein Videosignal synchron
zum Bildschirm, sodass die Position des Kathodenstrahls stets durch Abfrage der
Videosignal-Generierun g 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 Programm ierer der VCS
programmierend auf dem Kathodenstrahl reitet (ebd.: 28) .
22 Über die Zusammenhänge der Sprite-Generierung in Verbindun g mit dem Rasterstrahl rücklauf siehe WRIGHT ( 1979: 3- 10).
It 's More Fun to Compute!
63
screen a little bit so that they 're lying on the ground and not hovering in midair. 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. geschaffen werden. Zunächst entfernt Richardson eine Routine, deren Effekt er ohnehin 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 Prozessor-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 Situationen 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 "medienepistemologisches Spiel" kann jedoch darauf verzichtet werden. Klar werden sollte hier
vielmehr: Durch Eingriff in den Programmcode lässt sich dieser zwar manipulieren; der Eingriff zeitigt jedoch Folgen, die problematisch sind und eine
Reihe zusätzlicher Eingriffe notwendig machen. Diese Folgen betreffen insbesondere den ,reibungslosen Ablauf' des Spiels, denn das Einfügen zusätzlichen Codes verändert das Zeitverhalten des Spiels und ist ein raumfordernder Prozess.
Hier verschränken sich eine Reihe medienwissenschaftlicher Fragestellungen: Wie stellen sich die Zeitverhältnisse im Computer zur Laufzeit dar?
In welchem Zusammenhang stehen Software (Spielcode) und Hardwarefunk-
64
Stefan Höltgen
tion , in sbesondere bei maschinennaher Programmierung? Und nicht zuletzt:
Welche Möglichkeiten der (autodidaktischen) Medienkompetenzbildung ergeben sich durch die Konfro ntation von alter und neuer Technik? Am Beisp iel E. T. ließ sich zeigen, dass die Diskuss ion eines Spiels von seinem Einflu ss auf die Wirtschaftsgeschichte der Spielindustrie bi s hin zu seinen
medi enarchäologischen Facetten (hier etwa die Frage der Pixelkollision als
Rudiment von Kriegstechnologien der Yi suali sierung) ebenfalls auf der
Codeebene (nach)voll zogen werden kann . Die Erkenntn isse, die sich über
eine solch , unterflächliche' Analyse einstellen, ermöglichen e ine medi enwi ssenschaftliche Diskussion über Computerspiele abseits diskursiv-verhandelbarer Momente von Sinnproduktion; sie versuchen vielmehr das medientechni sche Apriori dieser Sinnproduktion aufzuzeigen und seine idiosynkratischen Aspekte freizulegen.
Die Atari YCS ist eine der am besten erforschte n Plattformen der Computerspiel-Geschichte, stellt aber trotzdem oder gerade deswegen auch heute
noch eine Herausforderung für viele Retrocomputer-Hobbyisten dar. Ihr einfacher Aufbau, ihre überschaubaren Funktionen und die verhältnismäßig
leicht zu erlerne nde 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äßi g so viel neue Software. Die Retrocomputer- und -sp iei-Community liefert
hierfür die besten Bedingungen, indem sie Dokumentationen frei zugänglich
macht, einfache Anleitungen (zur Programmierung, zum Modding usw.)
publiziert und ohne Unterlass in Di skuss ion miteinander steht. Di es ist nur
möglich, weil das Alte auf das Neue trifft: Yernetzung und Informationsdi stribution im Internet, Entwicklung von Crossdevelopment-Tools und Emulatoren für neueste Systeme, Bau von Hardware-Erweiterungen, welche die
Analyse und Entwicklung von Software für die Originalplattfo rm vereinfachen, die komplette Yirtuali sierung von Spielplattformen 23 und so weiter.
Zusammengezählt verdeutlichen di ese Aspekte, dass Retrocomputing und
-gaming weit über die Aktivi erung ei ner Erinnerungskultur hinausgeht, sondern sich selbst als Wille zum Wi ssen offenbart.
23 Wer weder ei ne Atari YCS besitzt, noc h de n Emulator installi eren möchte, kann seit
kurzem on line unter JSMESS E. T. spiele n, das zusammen mit zahl reichen andere n
Titeln für die YCS und andere Computer und S pi elkonso len in die Software-Samm lung von archi ve.org aufgeno mmen wurde (The Internet Archive Software Coll ection
o. J.).
It's More Fun to Compute!
65
Quellen
AtariMania (o.J.): E.T. - The Extra-Terrestrial (ROM-Image des Originals mit Abbildungen, Screenshots und Scans): www.atarimania.com/game-atari -2600-vcset -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 Maga zin 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 : ROMhacking.net: http ://www.romhacking.net/doc uments/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üsseldorf: Data Becker.
GOLDBERG, M./VENDEL, C. (20 13): Atari ln c. : 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.-A usgrabungs-Doku. In : gamona,
28.07.20 14: www .gamona.de/games/atari-game-over,erster-trailer-zur-e-t-ausgrabungs-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
Ste fan 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/l ecture-day.
NEUMANN, J. VON ( 1945): First Draft of the Report on the ED V AC: https://arc hi ve.org/details/firstdraftofrepoOOvonn.
o. V. ( 1983) : Atari Parts Are Dumped. In : The New York Times, 28.09. 1983:
www . nyti mes.co m/ 1983/09/28/bu siness/atari -parts-are-dumped.html.
P IAS, C . (200 I): Synthetic History. In : Archiv für Mediengeschichte 1/200 I (Themenheft "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 Wo lfgang Pircher.
Zürich/B erlin : diaphanes, S. 41 - 60.
RICHARDSON, D. (20 13): Fixing E.T. The Extra-Terrestrial for the Atari 2600:
www.neoco mputer.org/proj ects/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-anet-casto ff-in-a- most -terrestrial-pl ace. html ?_ r=O.
T he Internet Archive Software Collection (o.J .): Historical Software Co llection :
E. T . The Ex tra-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.orphanedga mes .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.