Academia.eduAcademia.edu
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.