GOTO MOON: Mondlandesimulationen als Computerspiele – Einblick und Eingriff ins Software-Archiv

­„It is amazing how they managed to get to
the moon with such primitive technology.“¹

„Sometimes the challenge was simply guessing
which would crash first – your rocket or the program.“²

Die erste Landung von Menschen auf dem Mond stellte in vielfacher Hinsicht eine bemerkenswerte Zusammenarbeit von Mensch und Technik dar. Über die Hardware und Software der Mondlandefähre (Lunar Excursion Module, kurz: LEM) wurde und wird viel berichtet. Diese Zusammenarbeit verlief allerdings nicht immer unproblematisch. Dass der Eagle, wie die Fähre der Apollo-11-Mission hieß, ihrem Namen nicht ganz gerecht wurde, weil sie eben nicht genau auf den geplanten Landepunkt zielte, sondern gut 4,5 km abseits davon aufsetzte, war nur eines dieser Probleme. Ein gravierenderes war die Flut ungeplant eingehender Daten, die schließlich dazu führte, dass der Computer in der Landephase selbst keine Hilfe mehr leisten konnte. In seiner Top Five der berüchtigtsten Computerfehler listet Bernd-Holger Schlingloff deshalb an erster Stelle die Mondlandung auf:

„Erste Mondlandung – 21.7.1969: Während des Landeanflugs kam es wegen eines flimmernden Sensors zu einer Überlastung der Software des Bordcomputers; Neil Armstrong schaltete die automatische Steuerung aus und landete die Raumfähre ‚von Hand‘. Durch die somit doch noch erfolgreiche Mission wurde in der Folge eine Reihe von Technologien und Standards der Softwarequalität begründet.“³

Das Ausgangsnarrativ dieses Beitrags ist dieser Fehler – nicht jedoch vor dem Hintergrund einer historischen Diskussion um Softwarequalität und Softwarekrise, sondern als ‚kreativer Trigger‘ eines Computerspiels, welches nach Aussage David Ahls „das populärste alleinstehende Computerspiel“⁴ ist. Die Rede ist von Lunar Lander, das in unzähligen Varianten und Programmiersprachen ab 1969 für Digital- und Analogcomputer implementiert wurde und damit ebenfalls 2019 seinen 50. Geburtstag feierte. Aus dem Fundus von Adaptionen wurden für die folgende Betrachtung vier Versionen ausgewählt, die in der Programmiersprache BASIC als Abtipp-Programme erschienen sind. Deren Sourcecodes werden vor dem Hintergrund des Homecomputing der 1970er/80er-Jahre und des Retrocomputing der Gegenwart miteinander verglichen.

Hierbei sollen drei Themen akzentuiert werden: 1. inwieweit es sich bei den Spielprogrammen um Lernprogramme handeln könnte, die vor dem Hintergrund des zeithistorischen⁵ Ereignisses „Mondlandung“ spezifische Aspekte dieses Ereignisses auf ihren Ober- und Unterflächen⁶ verhandeln. 2. inwiefern der jeweilige Computer dabei selbst als ein Protagonist und/oder Antagonist auftritt, der diese Zeitgeschichte und die damit zusammenhängende Technikgeschichte im Sinne Robin Collingwoods „nachvollzieht“⁷. Und 3. welche Möglichkeiten das Sourcecode-Archiv (hier der Programmiersprache BASIC) eröffnet, um kodifiziertes technisches, wissenschaftliches und historisches Wissen der Entwickler ‚lesbar‘ zu machen.

Nach einer Darlegung der Hintergründe zum Programm und der für die Betrachtung infrage kommenden Methoden sollen die drei historischen Sourcecodes Rocket (1973, Jim Storer, konvertiert durch David H. Ahl) für DEC-BASIC, Lunar Lander Game (1985, N. N.) für Sinclair-Heimcomputer sowie Lunar Lander Construction Set (1986, Daniel Deighan) für Atari-Shepardson-BASIC vor- und in vergleichbaren Details einander gegenübergestellt werden. Den Abschluss bilden Überlegungen zur Gegenwart und Zukunft des Mondlandung-Computerspiels, die anhand der aktuellen BASIC-Version Lander (2019, Kevin Savetz) vorgenommen werden.

Methoden der Mondlandung

Der historische Abstand zwischen dem realen Ereignis der Landung der Eagle-Fähre auf dem Mond am 20./21. Juli 1969 und der Virtualisierung dieses Ereignisses in einem Computerspiel, das diese Landung und (wie geschrieben) ihre Probleme zum Thema machte, war überraschend kurz: Bereits im Herbst desselben Jahres⁸ programmierte es der damals 17-jährige Highschool-Schüler Jim Storer für den PDP-8-Minicomputer seiner Schule in der Sprache FOCAL. Von diesem Zeitpunkt ab zieht sich eine Rezeptions- und Adaptionsgeschichte des Spiels auf unterschiedliche Plattformen und in unterschiedlichen Programmiersprachen, von denen hier zunächst einige kurz mit ihrer Entstehungsgeschichte aufgeführt werden sollen.

Adaption und Rezeption

Am 13. Januar 1970 berichtet die Schulzeitung The System Symptoms der Lexington High School, auf der Storer damals Schüler war, in einem kurzen Text von dem Programm.⁹ Etwa zur selben Zeit reichen der Autor und Walter Koetke (ein Informatik-Lehrer der Schule[?]) den Sourcecode¹⁰ bei DEC ein, um das Programm in deren DECUS-Library aufnehmen zu lassen.¹¹ Dort erscheint es kurz darauf als FOCAL-Abtipp-Listing¹². David H. Ahl, der zu dieser Zeit als Marketing Consultant für DEC eine „educational products line“ entwickeln soll, entdeckt das Programm und adaptiert es in die Programmiersprache BASIC-11. Diese Version lanciert er über den EDU-Newsletter der Firma DEC, um auf diese Weise weitere Spielprogramme in BASIC für die PDP-11-Systeme einzuwerben.¹³ Die BASIC-Version von Storers Programm wird schließlich 1973 in Ahls Buch 101 BASIC Computer Games¹⁴ unter dem Titel Rocket abgedruckt.¹⁵ Als Autor wird Jim Storer genannt. Zusätzlich finden sich dort die Spiele ROCKT1 (von Eric Peters) und ROCKT2 (von William Labaree II) – ersterer ein DEC-Mitarbeiter, letzterer ein Hobbyist – beide sind Ahls Aufruf zur Einreichung von BASIC-Spielen gefolgt und haben eigene Landeprogramme eingesandt.

Abb. 1: Focal

Von diesem Zeitpunkt an explodiert die Versionsgeschichte des Spielprogramms. Ahls Buch wird schnell so erfolgreich, dass eine Fortsetzung¹⁶ und eine Microcomputer-Edition¹⁷ sowie auf spezifische Plattformen spezialisierte Fassungen (z. B. für den TRS-80¹⁸) folgen. Das Programm findet Eingang in Handbücher zu Computern¹⁹ ebenso wie in Zeitschriften²⁰ und die Homecomputer-Sekundärliteratur²¹. Eine vollständige Adaptionsgeschichte von Lunar Lander zu schreiben erscheint nicht nur angesichts der Menge an BASIC-Publikationen zwischen 1970 und 1995 unmöglich, sondern auch, weil gerade diese Sprache ein immenses Konvolut an grauer Literatur hervorgebracht hat (mit Programmen, die unbekannten in Szenezeitschriften abgedruckt wurden oder die in Form selbst programmierter und unpublizierter Versionen in Privatarchiven schlummern oder längst vernichtet wurden).

Mit Einzug von grafikfähigen Displays wurde das Spiel Ende der 1970er-Jahre kommerzialisiert: Atari konstruierte einen Lunar-Lander-Arcade-Automaten, der die Landeszenerie in Seitenansicht auf einem Vektormonitor präsentiert²² und rief damit eine ebenfalls ältere Version für die PDP-11 in Erinnerung, die, in Assembler entwickelt, ein GT40-Vektorgrafik-Terminal zur Anzeige der Mondlandschaft und des LEM nutzte.²³ Der maßgebliche Unterschied dieser Spiele zu den textbasierten von Strorer und anderen war aber nicht die Einführung der Grafik, sondern die Änderung des Spielgenres: Aus einem rundenbasierten „question and answer game“²⁴ wurde ein ein „real time“²⁵ game.

Die Auswirkungen des Programms gingen weit über die Computerspiel-Sphäre hinaus: Wolfgang Coy vermutet, dass der Erfolg des frühen Time-Sharing-Betriebssystems Multics in den späten 1970er-Jahren maßgeblich dem Wunsch nach der Implementierung von „,Mondlandung‘ eines der ersten Computerspiele“²⁶ zu verdanken gewesen sei. Und Bill Gates nutzte Lunar Lander, um seinem gerade fertig gestellten BASIC-Interpreter für den Altair 8800 zu testen.²⁷ Es war das erste Programm, das auf dieser später Microsoft BASIC benannten Programmiersprache lief, die zur ersten kommerziellen und für zahlreiche Homecomputer adaptierten Programmiersprache wurde und bekanntlich den Erfolg der Firma Mircosoft begründete.²⁸

Heute kann das Programm als veritables ‚Leitfossil‘ für die frühe Homecomputer-Ära dienen, denn so aktuell es 1969 gewesen ist, so veraltet erschien es schon zehn Jahre danach. Atari veröffentlichte seine Arcade-Version bereits mit Verweis auf das zehnjährige Jubiläum der Mondlandung.²⁹ 1982 schreibt der Computerspiel-Kolumnist Martin Amis über diese Automatenversion: „Lunar Lander is a game for owlish adolescents and gentle old hippies. […] Most games, of course, are games of blasting, wasting, creaming, smashing. Lunar Lander, on the other hand, is simply a game of landing.“³⁰ Vier Jahre später zählt die ANTIC-Autorin Gigi Bisson Lunar Lander bereits zu den Veteranen: „Perhaps the oldest form of computer game, Lunar landers deserve a place on computer memory lane right next to Eliza, Life and Pong.“³¹ Aber nicht nur das Spiel selbst, auch seine Programmierung, der Aufbau des Programms sowie deren „die Aufgabenstellung […] dürfte ziemlich bekannt sein“³² konstatiert Hartnell 1983. Es sind aber gerade diese Bekanntheit und Antiquiertheit des Spiels, die die Grundlage für seine retro-didaktische Wirkung bilden, wie sich zeigen wird.

Rezeptionstheorie auf der Codeoberfläche

An der hier genannten Auswahl sowohl der Adaptionen als auch der Rezeptionen zeigt sich bereits, dass das Lunar-Lander-Motiv seit 1969 kontinuierlich und breitenwirksam diskursiviert wurde. Innerhalb einer Kulturgeschichte der Programmierung könnten deren Basis-Texte (die Sourcecodes) eine zentrale Rolle als Archivalien, Artefakte und Belege einnehmen. Hierzu müssten sie lediglich der Forschung zugänglich gemacht werden. Die Frage, die vor diesem Hintergrund und anlässlich unseres Themas zu stellen wäre, lautet: Sind die genannten Mondlandungsspiele allesamt miteinander verwandt und stammen sie (als Adaptionen) von Storers Lunar Lander ab oder sind (in)direkt von diesem beeinflusst worden? Zur Beantwortung dieser These soll hier ein Verfahren der Philologie hinzugezogen werden.

Die Rezeptionstheorie widmet sich sowohl der Frage, wie Kunstwerke in der synchronen Rezeption aufgenommen und verstanden werden (also in ihrer Wirkung auf den Rezipienten) als auch, wie die Rezeption von Kunstwerken andere Künstler diachron beeinflusst (die Wirkung eines Werks auf die Produzenten der jeweiligen Kunstgattung) und so in eine produktive Rezeption einmündet. Diese, Ende der 1960er-Jahre durch den Literaturwissenschaftler Hans Robert Jauß entwickelte, Theorie diente ursprünglich dazu die Literaturwissenschaft auf einen „informierten Leser“³³ aufmerksam zu machen, der lesend Bezüge zwischen den Werken der Literaturgeschichte herstellt. Die Annahme einer solchen produktiven Rezeption ließe sich mittels Verfahren der Textlinguistik belegen. Zum Verorten von Zitaten, Kommentaren, Referenzen, Querverweisen, Literaturangaben in ‚Texten jenseits des Textes‘ hat der Literaturwissenschaftler Gerard Genette eine umfassende Taxonomie und Methode zur Inter- und Paratextualitätsanalyse³⁴ vorgelegt, die im Prinzip auf jede Textsorte, also auch auf Sourcecodes anwendbar ist.³⁵

Leser von Sourcecode finden sich zuhauf zur Zeit der Homecomputer, wie sich schon am quantitativen Output der Programmier-Sekundärliteratur zeigen lässt. Und weil das Programmieren zu erlernen immer zugleich lesen³⁶ und schreiben erfordert, stellt die Rezeption (das lesende Verstehen) auf Papier gedruckter Sourcecodes das Grundprinzip jeder Programmierdidaktik dar – zumal zu einer Zeit, als diese Codes noch von Hand eingegeben werden mussten (und Erleichterungen wie zusätzliche Datenträger oder gar Downloads mit den Codetexten die Ausnahme bildeten). Inwieweit ein Rezipient dabei kreativ wird, indem er Strukturen umordnet, Funktionen oder Variablennamen ändert und die Programmausgaben an seine Bedürfnisse anpasst, hängt von den jeweiligen Kenntnissen ab. Die meisten Manuals zu Homecomputern und deren Sekundärliteraturen verstehen sich jedoch explizit auch als Lehrbücher – so etwa das Handbuch zum TRS-80³⁷ oder Ahls Computerspiele-Buch, das den „Educational Value of Games“³⁸ sogar als Vorwort diskutiert.

Nicht wenige Begleittexte zu den Programmlistings suggerieren oder fordern überdies explizit dazu auf, die Sourcecodes zu modifizieren, sich also aktiv in die Adaptionsgeschichte des Spiels einzuschreiben. Die Version in der Zeitschrift „Computerkurs“ schlägt die Übersetzung des abgedruckten Programmlistings in BASIC-Dialekte anderer Homecomputer (Acorn B, C64, VC20 und Oric Atmos)³⁹ vor.⁴⁰ In etlichen Publikationen wird markanterweise nicht bloß ein Mondlandung-Programm vorgestellt, sondern gleich zwei oder mehr. Diese unterscheiden sich voneinander zumeist in Spiel-Features wie dem Zeitablauf⁴¹, der Komplexität der implementierten Physik⁴²  und/oder in ihrer didaktischen Qualität.⁴³ Vor dem Hintergrund der hiesigen Überlegungen muten solche Listing-Reihungen wie Synopsen an, die zur vergleichenden Lektüre auffordern.

Abb. 2: Dialekte

Computer als Philologen

Schließlich darf bei aller philologischer Strenge aber nicht ignoriert werden, dass die abgedruckten Sourcecodes eben nicht allein vom Menschen gelesen und verstanden werden sollten, sondern auch von Computern. Während es dem menschlichen Leser zum Teil große Mühe bereitet, den zwar linear angeordneten intern jedoch durch Schleifen, Sprünge und Bedingungsprüfungen semantisch stark delinearisierten Code lesend nachzuvollziehen, hat der Computer damit keinerlei Probleme. Dies zeigt sich besonders deutlich bei der Programmiersprache BASIC, die von der Informatik-Didaktik deshalb als „Spaghetticode“⁴⁴ verschmäht und als Programmiersprache kaum ernst genommen wurde.⁴⁵ Mit ihren GOTO-Anweisungen, die direkt auf Programmzeilen verweisen, Schleifenstrukturen, die ohne Fehler noch vor Beendigung verlassen werden können, weitgehend untypisierten Variablen, (die nicht deklariert werden müssen), mehreren Anweisungen innerhalb einer Programmzeile und der fakultativen Verwendung von Kommentarangaben, ist BASIC genau das Gegenteil von dem, was in professionellen Kontexten ab Ende der 1960er-, Anfang der 1970er-Jahre als „structured programming“⁴⁶ gefordert wird.

Einige dieser ‚Probleme‘ sind bereits 1964 bei der Entwicklung von BASIC angelegt worden – und zwar mit didaktischem Kalkül. Die Sprache war nicht für Naturwissenschaftler und Ingenieure, sondern für Geisteswissenschaftler und Künstler entwickelt worden⁴⁷, weshalb Variablen-Deklaration keinen, die Verwendung englischer Wörter und Zeilennummern als Sprungziele sowie die Überfüllung von Operatoren aber durchaus Sinn hatte. Dass einer der Vorgänger von BASIC ein Lehr-Assembler-Dialekt gewesen ist⁴⁸, mag man dem rein imperativen Paradigma und an den Sprunganweisungen zu Zeilen/Adressen noch ansehen. Die Fehleranfälligkeit beim Programmieren von BASIC ist aufgrund dieses Paradigmas und den schwer nachvollziehbaren Strukturen von Programmen allerdings regelrecht ‚vorprogrammiert‘. Und so nimmt das Tracing des Programmcodes, die Klarheit der Fehlerausgaben und nicht zuletzt die Tatsache, dass BASIC im Homecomputer-Zeitalter nicht mehr ausschließlich kompiliert, sondern interpretiert wurde, einen bedeutenden Teil des Programmierens und Lernens ein.

Wie eine Hochsprache, z.B. BASIC, in eine für Computer ausführbare Maschinensprache übersetzt wird, stellt einen wichtigen Faktor für die Betrachtung von Computern als ‚philologische Maschinen‘ dar. Ursprünglich war BASIC als Compilersprache entwickelt worden. Der Sourcecode wurde zunächst in einem Editor als Textdatei geschrieben. Danach wurde der Compiler auf diese Textdatei angewandt, wobei ein mehrstufiger Prozess von Lesen, Erkennen, Übersetzen und Verknüpfen durchgeführt wurde. Dies geschah nicht in einem Zug, sondern benötigte eineinhalb⁴⁹ Durchläufe, weil der Übersetzer zunächst die (etwa durch GOTO-Anweisungen erzeugten) Sprungziele eines Programms erkennen und prüfen musste. Nach dem Kompilieren lag dann ein für den Computer ausführbares Programm vor, das noch gestartet werden musste und dann lief – sofern es fehlerfrei war. Ein Nachteil von Compilern, der zur Zeit der Homecomputer stark ins Gewicht fiel, war, dass sie vergleichsweise viel Speicher benötigten – zum einen als Programme selbst und dann noch für die Programme, die sie kompilieren sollten. Zudem musste ein Massenspeicher verfügbar sein, von dem der Sourcecode gelesen und auf den das fertige Kompilat geschrieben werden konnte.

Beide Bedingungen lagen bei den kleinen Mikrocomputern der 1970er-Jahre nicht vor. Die Lösung hieß: Interpreter. Hierbei wird das Programm als Sourcecode Schritt für Schritt während der Ausführung in Maschinensprache übersetzt. Der Nachteil geringerer Ausführungszeiten wurde einerseits durch den Größenvorteil, andererseits durch eine didaktisch wertvolle Interaktivität kompensiert. Interpretierte BASIC-Programme können jederzeit unterbrochen, geändert und wieder gestartet werden, ohne über die Umwege des Editor-Compiler-Konzepts gehen zu müssen. Der Wechsel vom Compiler- zum Interpreter-BASIC fand bereits Anfang der 1970er-Jahre statt; DECs BASIC-11 (in dem die Programme der 101 BASIC Computer Games geschrieben sind), wird bereits interpretiert. Das von Microsoft lancierte BASIC für den Altair-Computer griff abermals auf diese neue Tradition zurück und interpretierte den Lunar-Lander-Code zur Laufzeit des Spiels. Der didaktische Vorteil interpretierten BASICs zeigt sich insbesondere bei der Fehlerbehandlung: Tritt ein Syntax-Fehler auf, so wird das Programm in der fehlerhaften Zeile unterbrochen. Die Zeile kann korrigiert oder neu eingegeben und das Programm dann fortgesetzt werden.

Sprachfehler

Anfällig für Programmierfehler ist aber nicht nur der Entwicklungsprozess⁵⁰, sondern auch das Abtippen der Programme. Halbkompilierte BASIC-Dialekte, wie der der Atari-Homecomputer, quittieren Syntax-Fehler gleich nach der Eingabe einer Programmzeile, andere BASIC-Dialekte erst zur Laufzeit des Programms durch Abbruch. Liegt allerdings ein semantischer oder logischer Fehler⁵¹ vor, der das Programm zu einem anderen als dem intendierten Verhalten bringt, so ist die Fehlersuche schwieriger. Hier hilft zunächst nur die close lecture des Codes, bei der man mit den Augen nicht der linearen, sondern vor allem der semantischen Struktur des Listings folgt: „Wenn Sie den Code so lesen, emulieren Sie im Endeffekt das, was der Computer tun wird.“⁵² Ähnlich wie bei Assemblern existiert in vielen BASIC-Dialekten aber auch die Möglichkeit eines Single-Step-ähnlichen Debuggings: Mit einem Programmierbefehl (TRON/TROFF) kann man den Computer diejenige Programmzeile, die er gerade ausführt, auf dem Bildschirm darstellen lassen. Dort, wo eine Abweichung auftritt, kennt man dann bereits eine mögliche Stelle im Code, die zu untersuchen wäre.

Doch viele semantische oder logische Abtipp-Fehler finden sich erst spät oder gar nicht. Der Computer führt das derartig fehlerbehaftete Programm scheinbar ohne Probleme aus. Fehler zeigen neben ihrem destruktiven aber auch ihr konstruktives Potenzial, was uns zurück zum Lunar-Lander-Programm führt. Das Spiel existierte, wie eingangs geschrieben, vor allem deshalb, weil ein Computerfehler der Eagle-Landefähre eine manuelle Landung erforderlich machte. Das ‚Bugging‘ wie auch das Debugging eines Mondlandung-Computerlistings stellt damit bereits einen veritablen Aufruf von Raumfahrt- und Computergeschichte dar – wenn auch sehr subtil und mit wesentlich weniger drastischen Konsequenzen.

Drei Apollo-11-Missionen: 1973, 1975 und 1986

Nach dieser theoretischen Vorrede sollen nun drei BASIC-Versionen des Mondlande-Spiels genauer betrachtet werden. Die Auswahl der Programme hängt damit zusammen, dass diese Versionen interessante Features enthalten, die zu dem hier verhandelten Diskurs beitragen können. Die Programme werden hier einzeln vorgestellt, wobei auf drei spezifische Details besonderes Augenmerk fällt: die Implementierung der physikalischen Gesetze, die Implementierung der Zeitabläufe der Spiele sowie die Beziehung zwischen Code, Mensch und System – in Hinblick auf Programmierfehler, Tracing und Debugging.

Land an Apollo Capsule on the Moon

Abb. 3: ROCKET

Dem studierten Erziehungswissenschaftler David Ahl kam nach seiner Anstellung bei DEC als Manager der Bildungsabteilung recht früh die Idee, Computerlehre und Computerspiele miteinander zu verknüpfen. Von der ‚Gamification‘ des Computerlernens versprach man sich zur Zeit der Homecomputer viel – die Darstellung der Maschinen als Spiel- und Lern(werk)zeuge wurde zum regelrechten Marketing-Argument für Hersteller und Sekundärliteratur-Verlage.⁵³ Ahl schreibt daher gleich in der Einleitung zu seinem 101 BASIC Computer Games:

„Newton's second law is probably the furthest thing from the mind of a person sitting down to play ROCKET. However, when the player finally lands his LEM successfully on the moon, the chances are very good that he has discovered something about gravity varying inversely with the mass of the LEM and the distance from the moon.“⁵⁴

Die Spieler des Spiels machen auf zweierlei Weisen Bekanntschaft mit dem zweiten Newton'schen Gesetz: als formale Darstellung innerhalb des Codes, den sie eintippen müssen, und in operativer Anwendung als ‚virtuelle Gravitation‘, die ihre Landefähre beim Spielen nach unten zieht. Der Abtipper bekommt allerdings die Möglichkeit die in den Spielregeln hinterlegte Physik zu beeinflussen:

„To make the landing more of a challenge, but more closely approximate the real Apollo LEM capsule, you should make the available fuel at the start (N) equal to 16,000 Ibs, and the weight of the capsule (M) equal to 32,500 Ibs“⁵⁵

Die hierfür zu modifizierenden Variablen finden sich in der BASIC-Zeile 15 und lauten im Original:

15 A=120\V=1\M=33000\N=16500\G=1E-3\Z=1.8

Die Bedeutung der Variablen lässt sich aus dem Programmcode entnehmen. Neben M und N (die die Massen der Landefähre und des vorhandenen Treibstoffs in Pfund angeben), steht A für die Flughöhe, V die Geschwindigkeit, G⁵⁶ die Gravitationskraft und Z ist die Kraft, die durch das Verbrennen des Treibstoffs erzeugt wird und der Gravitation G entgegenwirkt. In L ist die Flugdauer in Sekunden gespeichert und in W die Geschwindigkeit beim Auftreffen der Fähre auf der Oberfläche. Diese berechnet sich nach der Formel in Zeile 81:

81 W=(1-M*G/(Z*K))/2 […],

wobei K die eingegebene Menge Treibstoff (vgl. BASIC-Zeile 21) ist, die laut Spielereingabe pro 10 Sekunden verbrannt werden soll. Ziel des Spiels ist es, die Treibstoff-Reserve so zu nutzen, dass sie vor Erreichen der Mondoberfläche noch nicht gänzlich verbraucht sind und die Geschwindigkeit der Fähre damit so zu reduzieren, dass W einen Wert größer als 1 aber kleiner als 60 hat (vgl. BASIC-Zeilen 52-56).⁵⁷

Aus dem BASIC-Programm lässt sich ablesen, dass die Masse des sukzessive reduzierten Treibstoffs N (welcher die Gesamtmasse des Landers mitbestimmt) Einfluss auf die Geschwindigkeit der Fähre hat: Die Treibstoffangabe wird in BASIC-Zeile 21 schon gleich als Differenz M-N (Lander-Masse minus Treibstoff-Masse) angegeben. Leeren sich die Tanks der Fähre, bekommt jeder weitere Schub eine größere Effektivität, weil der Gravitation nun weniger Masse entzogen werden muss.

Die hier benannten Variablen sind nicht die einzigen, die im ROCKET-Programm angegeben sind. Der Sinn dieser und der anderen Variablen und Konstanten lässt sich selbst bei Kenntnis der physikalischen Gesetze dem Quelltext nur schwer entnehmen. Dies liegt einerseits an der Konvention des DEC-BASIC-Dialektes, der nur Variablennamen aus einem Buchstaben (und maximal einer zusätzlichen Zahl, wovon hier allerdings kein Gebrauch gemacht wird) zulässt.⁵⁸ Zum anderen löst die BASIC-Syntax zweidimensional strukturierte Formeln (wie etwa Brüche, Potenzen und Wurzelausdrücke) in eine lineare Schreibweise auf. Und schließlich führt die Verkettung mehrerer Variablenänderungen (z.B. in den BASIC-Zeilen 61, 71, 81, 91 und 94), von denen zudem mehrere in einer Programmzeile vorgenommen werden, zu einer erschwerenden Lektüre.

Abb. 4: rockt1

Diesem Umstand schafft das zweite Listing ROCKT1 etwas Abhilfe, erinnert sich dessen Autor Eric Peters doch offenbar an die Vorgabe der BASIC-Entwickler „Eine Zeile, eine Anweisung“⁵⁹ und löst die Formeln so auf, dass jede Variable in einer eigenen BASIC-Zeile (re)definiert wird. Überdies nutzt Peters den Variablennamen nachgestellte Ziffern, um Zugehörigkeiten (etwa zwischen V und V1) zu kennzeichnen. Sein Programm berücksichtigt die Massenabnahme der Fähre durch Brennstoffverbrauch allerdings nicht; weder für die Fähre noch für den Brennstoff findet sich eine Massenangabe im Programm. Dafür erhält der Spieler eine rudimentäre grafische Ausgabe in Form eines Asterisks (als Symbol für die Fähre), das sich von rechts einer senkrechten Geraden (die Mondoberfläche) annähert, je nach Abstand beider voneinander.⁶⁰

Abb. 5: rockt1_run

Das dritte Programm ROCKT2 ist (in Hinblick auf die BASIC-Zeilen) die längste aber auch „most comprehensive of the three versions“.⁶¹ Diese Verständlichkeit basiert nicht nur auf dem klareren Variablen-Konzept, sondern auch auf der (wahlweisen) Übertragung der Werte ins metrische System und der besseren Strukturierung des Programmcodes. Abermals wird die Massenverringerung der Fähre durch Brennstoffverbrauch nicht berücksichtigt; dafür gibt es nun auch seitliche Steuerdüsen, die eine horizontale Navigation ermöglichen, um die Fähre zur Landung an die vorgesehene Position zu bringen – und nicht etwa 4,5 km abseits davon.

Abb. 6: rockt2

Wie Ahl in der Einleitung zum Programm betont, entstanden die drei Versionen völlig unabhängig voneinander.⁶² Dies lässt sich an den sehr unterschiedlich aufgebauten Listings und sogar an den unterschiedlich gewählten Variablennamen erkennen. Aus der Zeilennummerierung lassen sich zudem Annahmen über die Programmierung aufstellen: BASIC-Programme werden usuell mit einem ‚Abstand‘ von 5 oder 10 Zeilennummern programmiert.⁶³ Dies eröffnet nicht nur dem Entwickler die Möglichkeit nachträglich Funktionen einzufügen, sondern auch dem Abtipper und Spieler den Sourcecode durch eigene Erweiterung zu modifizieren. Die sehr unregelmäßigen Zeilenabstände von ROCKET erscheinen willkürlich gewählt. Ähnlichkeiten zum FOCAL-Sourcecode, der ebenfalls durch Zeilennummern strukturiert ist, finden sich an dieser Stelle nicht. ROCKT1 nutzt einen zehnzeiligen Abstand und ROCKT2 einen fünfzeiligen. Dies deutet ebenfalls darauf hin, dass die Codes unabhängig von der FOCAL-Version als ‚reine‘ BASIC-Entwicklungen entstanden sind.

Zeitachsen-Manipulation

Die Zeitschrift Computer Kurs, die in 83 Ausgaben wöchentlich zwischen 1984 bis 1985 in deutscher Sprache erschien, hat, wie der Titel bereits andeutet, einen vorrangig didaktischen Fokus auf ihren Gegenstand. Neben Themen aus der Informatik, Mathematik, Elektronik, Technikgeschichte und Beschreibungen zu zeitgenössischen Homecomputer-Plattformen enthalten die Ausgaben auch Programme in verschiedenen Sprachen zum Abtippen – vorrangig in BASIC. In der Ausgabe 40 nimmt sich das Magazin auch dem Mondlandungsmotiv an und bietet mit dem Lunar Lander Game⁶⁴ ein sehr kurzes (36 BASIC-Zeilen langes) Listing zum Abtippen. Aber nicht nur im Umfang und im Aufbau weicht dieses Programm von den Versionen aus Ahls Buch ab. Weil der didaktische Fokus auf dem Prinzip der Simulation liegt, spielen hier die Themen „mathematische Simulation“⁶⁵ und „Echtzeit-Simulation“⁶⁶ eine zentrale Rolle; die Frage, wie sich physikalische Vorgänge formalisieren (Mathematik) und authentisch implementieren (Zeitachsenmanipulation) lassen, so dass dabei ein Programm herauskommt, das einen realen Vorgang simuliert, steht bei dieser Version vor der Wiederholung des historischen Ereignisses „Mondlandung“, welche daher auch im Begleittext – mit Ausnahme des Umstands, dass „der Bordcomputer ausgefallen“⁶⁷ ist – keine Erwähnung findet.

Abb. 7: Computerkurs

Der maßgebliche Unterschied im Gameplay des Lunar Lander Game liegt in den veränderten Zeitverhältnissen: In „Rocket“ wird der Spieler aufgefordert einzugeben, wie viel Treibstoff (0-200 Pfund) ‚pro Sekunde‘ über einen ‚zehn Sekunden‘ langen Brennzyklus einsetzen will. Diese Zeitangaben meinen dabei bloße Spielzeit⁶⁸ – also ein erzählerisches Konstrukt. Die gespielte Zeit konnte davon stark abweichen – hat der Spieler doch beliebig viel Zeit, seine Eingabe zu planen und auszuführen. Diesem Timing schreibt das Spiel in das Genre des rundenbasierten (Text-)Adventures⁶⁹ ein. ROCKT1 und ROCKT2 eskalieren diese Manipulation der Spielzeitachse zwar, indem die bei ihnen einzugebenden Treibstoffmengen ‚pro Sekunde‘ verbrannt und auch dokumentiert werden. Die Form der Eingabeaufforderung mittels INPUT, bei der der eingegebene Wert erst an das Programm übergeben wird, nachdem die Return-Taste gedrückt wurde, zeigt allerdings, dass die Spiele trotz dieser Beschleunigung der gespielten Zeit keine Hektik beim Spielen auslösen. Im Lunar Lander Game sind die Zeitverhältnisse jedoch anders, wie der Begleittext zeigt:

„Eine weitere Schwierigkeit [...] ist die ‚Real Time‘-Simulation. Dies ist ein inzwischen sehr geläufiger Begriff, der nicht mehr bedeutet, als daß das Programm kontinuierlich weiterläuft und der Anwender ständig Daten oder Befehle eingeben muß. Oft besteht bei der Programmierung der einzige Unterschied darin, daß statt der INPUT-Anweisung die Abfragen INKEY$ oder GET verwendet werden müssen.“⁷⁰

Nach dem Start des Spiels beginnt der kontinuierliche Sturz in Richtung Mondoberfläche, der allein durch das Drücken der Tasten 0-9 gebremst wird. Diese Tasten werden einmal pro Durchlauf des Game-Loop abgefragt; ändert der Spieler die Eingabe nicht, wird die zuletzt getätigte Wahl beibehalten. Die Veränderung der Höhe, der Geschwindigkeit und des Treibstoffvorrates werden kontinuierlich angepasst, was dem Spielverlauf deutlich dramatische Züge verleiht. Lunar Lander Game gehört damit zu einem anderen Genre – dem Action-Spiel, bei dem es laut Claus Pias zeitkritisch zugeht: „Sie fordern Aufmerksamkeit bei der Herstellung zeitlich optimierter Selektionsketten aus einem Repertoire normierter Handlungen.“⁷¹ Der Spieler spielt hier also nicht nur gegen die Verknappung seiner Treibstoff-Ressourcen und gegen das zweite Newton'sche Gesetz, sondern auch noch gegen die Zeit, weil der Zeitpunkt seiner Eingabe nun selbst zu einem Faktor des Gameplay wird.

Das ist nur deshalb dramatisch, weil das Lunar Lander Game schneller abläuft als die reale Mondlandung, deren Dramatik auf einem anderen Gebiet zu suchen wäre. Wofür der Eagle-Lander 148 Minuten⁷² gebraucht hat, läuft im BASIC-Programm, abhängig von verwendetem System, innerhalb weniger Sekunden ab. Diesem Umstand kann Abhilfe geschaffen werden, wie ein Modifikationsvorschlag lautet:

„Im Landeprogramm ist eine Zeitschleife eingebaut [in BASIC-Zeile 250, S. H.], die für jedes Zeitintervall einmal aktiviert wird. Verändert man das Zeitintervall derart, daß es der Zeit entspricht, die zur Ausführung der Schleife benötigt wird, arbeitet die Simulation in Echtzeit. Das bedeutet, daß die Landung des Raumschiffes in der Simulation genauso viel Zeit in Anspruch nimmt, wie es in der Realität auch dauern würde. Obwohl dies für eine Simulation sehr wünschenswert ist, wird ein Spiel dadurch oft uninteressant, da es zu lange dauert.“⁷³

Abbruch statt Absturz

Die Implementierung des Lunar Lander Game auf einem modernen Computer (hier in BBC-BASIC auf einem iMac von Ende 2015) hat gezeigt, welche Schwierigkeiten sich bei der Aktivierung historischer Sourcecodes ergeben, sofern sie nicht auf den Originalsystemen implementiert werden: Die Warteschleife, die von 1 bis 50 zählt, wird im modernen BBC-BASIC-Interpreter innerhalb von Bruchteilen einer Sekunde durchlaufen. Das Programm endet mit einem ‚Absturz‘ auf der Mondoberfläche beinahe sofort nach dem Programmstart. Die Warteschleife erzeugt also eine maschinenabhängige Wartezeit; durch Änderung der BASIC-Zeile 250 in

250 WAIT 50

erhält man eine systemunabhängig Wartezeit: die Parameterangabe n des WAIT-Befehls bedeutet n/100 Sekunden; die Änderung erzeugt hier eine also eine Wartezeit von 0,5 Sekunden.⁷⁴ Dieser Fehler hat sich erst zur Laufzeit des Spiels gezeigt und hat das Programm weder unterbrochen noch konnte er durch einen Trap abgefragt werden, wie etwa die Eingabe einer zu großen Treibstoffmenge in ROCKT2 zu einer Neueingabe aufgefordert hätte (BASIC-Zeilen 905-990).

Das letzte hier diskutierte Programm Lunar Lander Construction Set⁷⁵ für Ataris 8-Bit-Homecomputer, verfasst in Shepardson-BASIC, stellt so etwas wie ein ‚Meta-Spiel‘ dar, weil es ermöglicht ganz eigene Landeszenarien zu entwerfen – und zwar während des laufenden Spiels und weil sich dies hierfür selbst unterbricht. Deighans Programm gehört zu den grafikbasierten Lande-Simulationen; gezeigt wird eine zufällig generiert oder vom Spieler entworfene Landeszenerie in Seitenansicht, auf der die Fähre nach den bekannten Methoden gelandet werden soll. Die Eingaben werden hier jedoch nicht über die Tastatur vorgenommen, sondern mittels Joystick, „so you won't have to deal with mathematical equations“.⁷⁶

Die Mathematik wurde auf die Unterfläche des Spiels ‚verbannt‘, um von dort aus die Eingaben auszuwerten und die Ausgaben zu generieren, was bedeutet, dass der Spieler, der auch hier zuvor Abtipper gewesen sein muss, sich doch mindestens einmal mit ihnen auseinander zu setzen hat. Die formalisierte Physik kehrt allerdings dann wieder auf die Oberfläche zurück, wenn der Spieler ein eigenes Landeszenario entwerfen möchte: Dann hat er nicht nur die optische Ästhetik des Himmelskörpers zu wählen, sondern muss auch dessen Gravitationskonstante angeben.

Ein eigenes Spielszenario und die dazugehörige Physik innerhalb des Spiels entwerfen zu können, wird durch einen Hack möglich:

„[..] you can watch as the computer writes the program lines that will create your new landing site. This is done with the Atari's forced read mode. (POKE location 842 with 13 and the computer will accept information from the screen as if it were typed from the keyboard.)“⁷⁷

Dieser ‚forced read mode‘ ist allerdings keine intendiert implementierte Funktion des Atari-BASIC-Interpreters, sondern simuliert im Prinzip eine Fehleingabe: Hierzu wird in BASIC-Zeilen 515 und 520 zunächst der Textcursor mit POSITION auf die zuvor definierte Bildschirmposition gesetzt, danach wird über den Befehl POKE 842,13 das Append-Bit in der I/O-Kontrolle für das aktuelle Ein-/Ausgabe-Gerät (in diesem Fall die Tastatur) gesetzt, was dazu führt, dass die Tastatur ein Signal abgibt, als würde die Return-Taste ohne Unterlass gedrückt⁷⁸ und schließlich mit STOP die Ausführung des BASIC-Programms unterbrochen.⁷⁹

Abb. 8: Atari

Der Cursor läuft nun Zeile für Zeile den Bildschirm hinab, bis er auf die Textausgaben trifft, die in den BASIC-Zeilen 515 und 520 dorthin geprintet wurden. Diese Ausgaben stellen aber selbst BASIC-Programmzeilen dar; indem der Cursor über sie hinweg läuft und dabei ein Return-Signal auslöst, implementiert er diese BASIC-Zeilen in das im Speicher befindliche Programm (Lunar Lander Construction Set). Am Ende dieser automatisierten Programmierung trifft der Cursor auf den Befehl CONT, womit das Programm ab Zeile 525 fortgesetzt wird. Darin wird dann mittels POKE 842,12 das Append-Bit wieder gelöscht und die automatische Return-Kaskade beendet.

Wie bereits geschrieben, handelt es sich bei Ataris Shepardson-BASIC um einen halbkompilierten Dialekt. Damit ist gemeint, dass der Interpreter die Programme nicht erst zur Laufzeit liest und erkennt, sondern bereits dann, wenn sie eingegeben werden. Auf diese Weise können Programmier- und Abtipp-Fehler vermieden werden, die nicht zur Kategorie der logischen oder semantischen Fehler zählen. Dieser Prozess wird in dem Moment gestartet, wenn am Ende einer Eingabe die Return-Taste gedrückt wird. Damit ergibt sich eine markante Ähnlichkeit zu einem rundenbasierten Textadventure wie Lunar Lander. Hier wie dort hat der Programmierer/Spieler die Möglichkeit, seine Eingabe abzuwägen, bevor er sie dem Computer übergibt und von diesem auswerten lässt, was schlimmstenfalls in beiden Fällen zu einem ‚Crash‘ führen könnte.

Hatten wir oben bei der Beschreibung des BASIC-Interpreters bemerkt, dass Computer beim Lesen, Erkennen und Übersetzen von Sourcecode in den Kreis der Rezipienten zu rücken sind, so zeigt sich sowohl an der Arbeitsweise des Shepardson-BASIC-Interpreters als auch am Lunar Lander Construction Set, dass Computer nicht nur zur aufmerksamen und informierten Lektüre, sondern auch zur produktiven Rezeption fähig sind, der Code zugleich schreibt und liest. Die automatische Erweiterung des Programms kann dabei auch als ein Eingriff in den (immer schon historischen) Sourcecode gewertet werden, der durch das Programm selbst ‚aktualisiert‘ wird. Das Lunar Lander Construction Set tritt damit als veritabler (und automatischer) Archäograph⁸⁰ auf die Bühne der Software-Geschichte.

Retro Rocket

In zehnjährigem Rhythmus feiert die erste Mondlandung ein multimediales Jubiläum. Bücher, Filme, Dokumentationen aber auch Computerspiele erscheinen dann, um an dieses Ereignis zu erinnern. Die Mondlandung als Mediengeschichte ergänzt und bereichert sich dabei jedes Mal um neue Monumente, die selbst wiederum zu neuen Beiträgen der Historiografie werden. Ab Mitte der 1990er-Jahre und dem Verschwinden der Homecomputer hat die Programmiersprache BASIC an Bedeutung verloren.  Als Lern- und Anfängersprache wurde sie durch modernere Programmiersprachen wie Python oder Scratch ersetzt. Weil BASIC wie keine andere Programmiersprache aber direkt an eine spezifische Epoche der Hardware (nämlich der 8- und 16-Bit-Mikrocomputer) gekoppelt ist, in deren RAM-Bausteinen sie fest implementiert wurde, hat sie in den Retrocomputer-Szenen als ‚untote Sprache‘ überdauert. Und mehr noch: Seit langem werden auf historischen Systemen neue BASIC-Programme entwickelt. Dabei hat sich das Augenmerk von den Standard-Anwendungen allerdings in Richtung Programmierkunst verlagert.

Das Computerspiel Lander⁸¹, das für den Dialekt TurboBASIC XL für Ataris 8-Bit-Systeme programmiert wurde, ist im März 2019 – mit Verweis auf das Mondlandungsjubiläum – innerhalb eines BASIC-Tenliner-Contests publiziert worden. Der Autor, Kevin Savetz, notiert hierzu:

„I've wanted to program a Lunar Lander-type game since I was a teen [...] but I never could get the movement with respect to thrust and gravity right. I didn't have the math concepts.“

Nach eingehender Beschäftigung mit dem Thema und der Hilfe eines Freundes ist es Savetz aber nun gelungen ein Spiel fertig zu stellen, das ein Hybrid zwischen den grafischen Versionen (nach Ataris Lunar Lander und dem Lunar Lander Construction Set) und den Text-basierten Versionen darstellt:

„The first Lunar Lander that I was exposed to was Atari's vector arcade version, which seemed amazing — and impossibly difficult. Later, my dad bought the Adventure International version of Lunar Lander for his Atari 800. (It was one of the few pieces of Atari software that he didn't pirate.) In that version, the LEM doesn't rotate. Instead, side thrusters push the ship horizontally while it remains in a vertical position. I did the same in my version.“

Abermals wird hier also die Landezone in Seitenansicht präsentiert, während jedoch aber am oberen Bildschirmrand Textausgaben für die vertikale (↓) und horizontale (→) Geschwindigkeit sowie die Gravitationskonstante (G) und der verbleibende Treibstoff (F) angezeigt werden. Gesteuert wird die Landefähre mit dem Joystick, dessen Feuerknopf die Bremstriebwerke zündet.

Die Besonderheit an diesem Abtippspiel ist, dass es nur 10 BASIC-Zeilen lang ist, von denen jede maximal 120 Zeichen Code enthält. Dies stellt die Bedingung zur Teilnahme am jährlich stattfindenden BASIC Tenliner Contest⁸² dar. Erreicht wird diese Kürze nur durch massive Ausnutzung unsauberer Programmiertechniken und – wie in Lunar Lander Construction Set – die direkte Ansprache der Hardware. So werden die Grafikdaten des Raumschiffes nicht etwa gelöscht, indem die Register innerhalb einer Schleife mit Nullen gefüllt werden, sondern durch einen Hack:

M=DPEEK(88):'top of screen RAM
MOVE M,P+512,384:'zero Player data, copying 0s from the fresh blank screen

Der MOVE-Befehl stellt eine Speicher-Blockkopier-Operation zur Verfügung. Hier werden einfach 384 Byte des zuvor gelöschten Bildschirms (beginnend bei Adresse M) per MOVE in den Grafikdatenspeicher (beginnend bei Adresse P+512) kopiert, um ihn zu löschen – und dabei Code zu sparen. Der „hybrid[e]“⁸³ Zugriff über BASIC und Maschinenoperationen zeigt, dass ein zentrales Ziel der Mondlande-Simulationsprogrammierer immer schon auch der Computer selbst und seine Hardware gewesen ist: „what I was most interested in were the computer“, erinnert sich Storer,⁸⁴ der heute Informatik-Professor an der Brandeis University (Waltham, USA) ist, an seine Motivation Lunar Lander zu programmieren.

Programmierverfahren wie die in Lander obfuskieren den Sourcecode so stark, dass er ohne intime Hardware- und Programmiersprachkenntnisse für Menschen kaum lesbar und verständlich ist. Der Vorwurf der Programmiersprachen-Didaktiker der 1970er-Jahre hallt hier förmlich nach, denn in den Tenliner- und Onliner-Programmen⁸⁵ ist die Entwicklung von Spaghetticode geradezu Pflicht, um Codemenge und Speicherplatz zu sparen. Mit der Lektüre haben jedoch nicht alle Leser Probleme: Der Atari-Computer übersetzt Savetz' Code des Mondlandung-Spiels anstandslos, führt ihn aus und legitimiert damit zugleich den BASIC-Hacker in seinem Tun: „Die Autorität, die seine autodidaktischen Basteleien legitimiert, ist die je konkrete Technik selbst“, wie Pias schreibt.⁸⁶ Dieses „Spielen mit der Technik exploriert deren Grenzen, die dadurch zugleich immer aufgelöst und woanders wieder fixiert werden. […] Der Hacker schleppt also die Grenze, die er zu überwinden scheint, immer mit und zieht sie ununterbrochen neu.“⁸⁷

Im Retrocomputing werden diese alten, längst überwunden geglaubten Grenzen programmierend erneut gestürmt. Systeme, die ihre Zeit längst hinter sich haben und keine Geheimnisse mehr zu bergen scheinen, werden aus purem (Mut-)Willen zum Wissen immer wieder an neue Grenzen geführt. Und dabei werden erstaunliche Entdeckungen gemacht, die zeigen, dass die Maschine namens Computer immer „zugleich weniger und mehr [kann], als ihre Datenblätter zugeben.“⁸⁸, wenn bislang unbekannte Hardware-Features (zumeist Design-Fehler) oder unorthodoxe Möglichkeiten von Programmiersprachen ausgenutzt werden. Im Dialog mit den Computern vollziehen die BASIC-Retro-Hacker auf diese Weise nicht nur Softwaregeschichte nach und aktualisieren sie mit archäographischen Methoden. Sie nähern sich dabei auch der Hardware und ihrer Geschichte an, indem sie sie durch die Programme in Vollzug setzen.

Diese Bewegung lässt sich für Außenstehende (z.B. Historiker, Kultur- und Medienwissenschaftler usw.) nachvollziehen, indem das Sourcecode-Archive für die Lektüre fruchtbar gemacht wird. Die Textsorte „BASIC-Programm“, aus welcher 1973 das Genre „Mondlandesimulation“ evolviert ist, bietet über die Rezeptionsanalyse hierfür ausgezeichnete Möglichkeiten. Entscheidend dabei ist, dass die (Be-)Funde gesichert und gesichtet werden können, wozu sowohl der Auf- und Ausbau eines Code-Archivs als auch Lektürekompetenz nötig ist.

Verzeichnis der verwendeten Texte und Medien

Spiele

• Lunar Lander (1979, ATARI)
• Rocket (1969, Jim Storer)
• ROCKET (1973, Jim Storer, von FOCAL in BASIC konvertiert durch David H. Ahl)
• ROCKT1 (1973, Eric Peters)
• ROCKT2 (1973, William Labaree II)
• Lunar Lander Game (1985, N. N.)
• Lunar Lander Construction Set (1986, Daniel Deighan)
• Lander (2019, Kevin Savetz)

Literatur

• Ahl, David H.: BASIC Computer Games. Maynard: digital 1973.
• Ahl, David H.: 101 BASIC Computer Games Vol. II – TRS-80 Edition. Morristown: Creative Computing Press 1980.
• Ahl, David H.: BASIC Computer Spiele. Microcomputer Ausgabe. Band 1. Düsseldorf: Sybex 1982.
• Ahl, David H.: More BASIC Computer Games. New York: Workman 1979.
• Amis, Martin: Invasion of the Space Invaders. London: Jonathan Cape 1982/2018.
• Bachfeld, Daniel:  Lesestoff: Die Kunst der Basic One Liner. In: heise online. 19.01.2018. < https://www.heise.de/make/meldung/Lesestoff-Die-Kunst-der-Basic-One-Liner-3944822.html> [10.10.2019]
• Ball, Andrew; Garry, James; Lorenz, Ralph; Kerzhanovich, Viktor: Planetary Landers and Entry Probes. Cambridge u.a.: Cambridge Univ. Press 2007.
• Bisson, Gigi: Lunar Lander Construction Set. In: ANTIC, March 1986, Vol. 4, No. 11, S. 73-74.
• Collingwood, Robin S.: The Idea of History. Oxford u. a.: Clarendon Press 1945.
• Coy, Wolfgang: Aus der Vorgeschichte des Mediums Computer. In: Bolz, Norbert; Kittler, Friedrich; Tholen, Georg C. (Hg.): Computer als Medium. München: Fink 1993, S. 19-38.
• Dijkstra, Edsger W.; Dahl, Ole-Johan ; Hoare, Tony: Structured Programming. Reihe: A.P.I.C. Studies in Data Processing, Vol. 8. London/New York: Academic Press 1972.
• Dartmouth College Computer Center: A Manual for BASIC, the elementary algebraic language designed for use with the Dartmouth Time Sharing System. 1 October 1964. Hannover: Dartmouth College 1964.
• DEC: FOCAL LUNAR LANDING SIMULATION (APOLLO). In: DECUS Program Library, No. FOCAL8-81, 1970. <http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/decus/focal/FOCAL8-81_LunarLanding.pdf> [08.10.2019]
• DEC: PDP-11 BASIC Programming Manual. Single User Paper-Tape Software. DEC-11-AKPB-D. Maynard: Digital Equipment Corporation 1970.
• Deighan, Daniel: Lunar Lander Construction Set. In: ANTIC, March 1986, Vol. 4, No. 11, S. 91-94.
• Dijkstra, Edsger W.: How do we tell truths that might hurt? (EWD 498) In: Ders.: Selected Writings on Computing: A Personal Perspective, Berlin u.a.: Springer 1982, S. 129-131.
• Edwards, Benj: Forty Years of Lunar Lander. In 1969, an Apollo-crazy high school student wrote one of the most influential computer games of all time. In: Techologizer, 19.07.2009, <http://technologizer.com/2009/07/19/lunar-lander> [08.10.2019]
• Eggeling, Jörn: GOTO – REPEAT UNTIL. Schwierigkeiten mit der Software. In: Kursbuch 75: Computerkultur, März 1984, S. 75-88.
• Fish, Stanley: Literatur im Leser. Affektive Stilistik. In: Warning, Rainer (Hg.): Rezeptionsästhetik. Theorie und Praxis. Reihe: UTB. München: Fink 1975, S. 196-227.
• Genette, Gerard: Palimpseste. Die Literatur auf zweiter Stufe. Frankfurt a. M.: Suhrkamp 1993.
• Genette, Gerard: Paratexte. Das Buch vom Beiwerk des Buches. Frankfurt a. M.: Suhrkamp 2001.
• Hartnell, Tim: Das große Buch der Computerspiele. München: Huber & Co. 1983.
• Höltgen, Stefan: Sprachregeln und Spielregeln. Von Computerspielen und ihren Programmierfehlern. In: Huberts, Christian; Standke, Sebastian (Hg.): Zwischen | Welten. Atmosphären im Computerspiel. Glückstadt: vwh 2014, S. 295-315.
• Höltgen, Stefan: Compute/sprachen. ELIZA und BASIC. Urszenen des Homecomputings (und) künstlicher Intelligenz. In: Höltgen, Stefan; Baranovska, Marianna (Hg.): Hello, I‘m Eliza. Fünfzig Jahre Gespräche mit Computern. Reihe: Computerarchäologie, Band 4, Bochum/Freiburg: Projektverlag 2018, S. 97-122.
• Höltgen, Stefan: DaimoGraphien. Für ein Argumentieren jenseits des Diskursiven. In: Höltgen, Stefan; Hiller, Moritz (Hg.): Archäographien. Aspekte einer radikalen Medienarchäologie. Berlin: Schwabe 2019, S. 295-307.
• Höltgen, Stefan: OPEN HISTORY. Archäologie der frühen Mikrocomputer und ihrer Programmierung. (Dissertation 2020). <http://txt3.de/open-history> [03.03.2020]
• Kahn, Bob: What to do after you hit RETURN. Menlo Park: People‘s Computer Company 1980.
• Kittler, Friedrich: Protected Mode. In: Ders.: Draculas Vermächtnis. Technische Schriften. Leipzig: Reclam 1993, S. 208-224.
• Kurtz, Thomas E.: BASIC. In: Biancuzzi, Federico; Warden, Shane: Visionäre der Programmierung. Die Sprachen und ihre Erfinder. Bejing u.a.: O‘Reilly 2009, S. 81-201.
• Kurtz, Thomas E.: BASIC Session. In: Wexelblat, Richard L. (Hg.): History of Programming Languages. New York u.a.: Academic Press 1981, S. 515-549.
• Kwiatkowski, Josef; Diering, Norbert Achim: BASIC Computerspiele für Mikrocomputer. Band 1. Stuttgart: Frech 1984.
• Lowood, Henry: Videogames in Computer Space. The Complex History of Pong. In: IEEE Annals of the History of Computing, July-September 2009, S. 5-19.
• Müller, Günther: Erzählzeit und erzählte Zeit. In: Ders.: Morphologische Poetik. Gesammelte Aufsätze. Tübingen: Niemeyer 1974, S. 269-286.
• N. N.: Moon Landing. In: The System Symptoms, 2.07, 1970. < https://www.cs.brandeis.edu/~storer/LunarLander/LunarLander/Articles/LunarLander-LexingtonHigh1970.pdf> [08.10.2019]
• N. N.: Mondlandung. In: Computerkurs, Heft 40, 1985, S. 1112-1113.
• N. N.: Korrektur des Virusprogramms. In: HC – Mein Home-Computer, Nr. 10, Oktober 1986, S. 50.
• Nake, Frieder: Das doppelte Bild. In: Pratschke, Margarete (Hg.): Bildwelt des Wissens, Band 3,2: Digitale Form. Berlin: Akademie-Verlag 2005, S. 40-50.
• Pias, Claus: Computer Spiel Welten. Zürich: diaphanes 2002.
• Pias, Claus: Der Hacker. In: Horn, Eva (Hg.): Grenzverletzer. Von Schmugglern, Spionen und anderen subversiven Gestalten. Berlin: Kadmos 2002, S. 248-271.
• Radio Shack: Level II BASIC Reference Manual First Edition. Fort Worth: Tandy 1978.
• Schlingloff, Bernd-Holger: Softwarequalität – Geschichte und Trends. In: Freytag, Johann Christoph; Reisig, Wolfgang (Hg.): Informatik. Aktuelle Themen im historischen Kontext. Berlin; Heidelberg: Springer 2006, S. 329-345.
• Stuart, Keith: How the Moon Landing shaped Early Video Games. In: The Guardian, 18.07.2019. <https://www.theguardian.com/games/2019/jul/18/how-the-moon-landings-inspired-a-generation-of-game-designers> [08.10.2019].
• Tringham, Neil: Science Fiction Video Games. Boca Raton; New York: CRC Press 2015.
• Wallace, James; Erickson, Jim: Hard Drive. Bill Gates and the Making of the Microsoft Empire. New York: Wiley 1992.
• Wang, Li-Chen: Palo Alto Tiny BASIC. User Documentation & Complete annotated Source-Code. In: Dr Dobb‘s Journal of Computer Calisthenics and Orthodontia. Running Light without Overbyte. May 1976, Vol. 1, No. 5, S. 12-24.

1. Jim Storer, zit. n. Stuart: How the Moon. 2019.[↩]
2. Bisson: Lunar Lander. 1986, S. 73.[↩]
3. Schlingloff: Softwarequalität. 2006, S. 335.[↩]
4. Ahl: BASIC Computer Spiele. 1982, S. 109.[↩]
5. Als Zeitgeschichte wird jener vergangene Zeitraum bezeichnet, den der Historiker bewusst selbst miterlebt hat.[↩]
6. Vgl. Nake: Das doppelte Bild. 2005, S. 47.[↩]
7. Collingwood: Idea of History. 1945.[↩]
8. Vgl. Edwards: Forty Years. 2009.[↩]
9. N. N.: Moon Landing. 1970[↩]
10. https://www.cs.brandeis.edu/~storer/LunarLander/LunarLander/LunarLanderListing.jpg [08.10.2019][↩]
11. https://www.cs.brandeis.edu/~storer/LunarLander/LunarLander/LunarLanderDecusSubmission.jpg [08.10.2019][↩]
12. DEC: FOCAL LUNAR LANDING. 1970.[↩]
13. Vgl. Edwards: Forty Years. 2009.[↩]
14. Ahl: 101. 1973[↩]
15. Ahl: 101. 1973, S. 182.[↩]
16. Ahl: More BASIC. 1979[↩]
17. Ahl: BASIC. 1982.[↩]
18. Ahl: More BASIC. 1979.[↩]
19. Radio Shack: Level II. 1978, S. H1-2.[↩]
20. N. N.: Mondlandung. 1985, S. 1112f.[↩]
21. Kwiatkowski/Dierig: BASIC. 1984, S. 91-94.; Hartnell: Computerspiele. 1983, S. 223-226.; Kahn: RETURN. 1980, Ss. 103-107,128f., 139.[↩]
22. Vgl. Lowood: Videogames. 2009, S. 19.[↩]
23. Tringham u.a.: Science Fiction. 2015, S. 450.[↩]
24. Storer zit. n. Stuart: How the Moon. 2019.[↩]
25. Tringham: Science Fiction. 2015, S. 450.[↩]
26. Coy: Vorgeschichte. 1994, S. 28.[↩]
27. Vgl. Wallace/Erickson: Hard Drive. 1992, Ss. 22, 80.[↩]
28. Ob sich Lunar Lander allerdings wirklich als Übung für echte Landungssituationen verwenden ließ oder lässt, wie Ball (Ball: Planetary Landers. 2007, S.50) andeutet, sei dahingestellt.[↩]
29. Vgl. Edwards: Forty Years. 2009.[↩]
30. Amis: Invasion. 1982/2018, S. 66.[↩]
31. Bisson: Lunar Lander. 1986, S. 73.[↩]
32. Hartnell: Computerspiele. 1983, S. 223.[↩]
33. Fish: Literatur im Leser. 1975, S. 215-217.[↩]
34. Genette: Palimpseste. 1993 sowie Genette: Paratexte. 2001.[↩]
35. Feingranularere Analysen jenseits der Textanalyse (auf Satz- und Wortebene) erlauben sprachwissenschaftliche Methoden der Textkohäsionsforschung. Mit ihnen lassen sich Bezüge zwischen verschiedenen Programmteilen und Programmen analysieren. Da dies für die vorliegende Fragestellung nicht einschlägig ist, verweise ich auf (Höltgen: OPEN HISTORY. 2020, S. 100-123).[↩]
36. Thomas Kurtz, der Miterfinder der Programmiersprache BASIC, meint sogar, dass zum Programmierenlernen der Besuch eines Kurses unnötig ist: „Neue Sprachen lernt man, indem man die Anleitung liest.“ (Kurtz: BASIC. 2009, S. 93.[↩]
37. Radio Shack: Level II. 1978, S. 1.[↩]
38. Ahl: 101. 1973, S. 1.[↩]
39. Die Übersetzung in eine andere Programmiersprache (wie anfänglich von FOCAL in BASIC) oder einen anderen Dialekt stellt dabei eine besondere Form der Rezeption dar, die mittels interlinguistischer, komparatistischer Verfahren und Übersetzungstheorien nachvollzogen werden kann. Hier, wie auch schon bei der Rezeption des Sourcecodes, nimmt die ‚maschinelle Übersetzung‘ durch den Computer allerdings eine vorrangige und besondere Rolle ein.[↩]
40. Vgl. N. N.: Mondlandung. 1985, S. 1113.[↩]
41. Hartnell: Computerspiele. 1983, S. 224-226.[↩]
42. Kahn: RETURN. 1980, S. 107.[↩]
43. Ahl: 101. 1973, S. 107.[↩]
44. Eggeling: GOTO. 1985, S. 81.[↩]
45. Vgl. Dijkstra: EDW 498. 1982, S. 140.[↩]
46. Dahl/Dijkstra/Hoare: Structured Programming. 1972.[↩]
47. Kurtz: BASIC Session. 1981, S. 518.[↩]
48. Kurtz: BASIC Session. 1981, S. 517f.[↩]
49. Vgl. Kurtz: BASIC. 2009, S. 89.[↩]
50. In historischen Computerzeitschriften finden sich nicht selten fehlerbehaftete BASIC-Programmlistings, die in späteren Ausgaben mit ‚Patches‘ versehen wurden (vgl. exemplarisch N. N.: Korrektur. 1986, S. 50). Zur Vorbeugung von Abtipp-Fehlern wurden in Zeitschriften oft Checksummen für Programmlistings angegeben. (Diese finden sich beispielsweise im Sourcecode zum Lunar Lander Construction Set – links neben den BASIC-Zeilennummer [vgl. Deighan 1986:91-94].[↩]
51. Vgl. Höltgen: Sprachregeln. 2014, S. 299f.[↩]
52. Kurtz: BASIC. 2009, S. 98.[↩]
53. https://www.c64-wiki.de/wiki/C64/C128_%E2%80%93_Spielend_BASIC_lernen [09.10.2019][↩]
54. Ahl: 101. 1973, S. 7.[↩]
55. Ahl: 101. 1973, S. 182.[↩]
56. Die Angabe 1E-3 ist eine Gleitkommazahl, die 1x10^-3 = 0,001 bedeutet (vgl. DEC: PDP-11 BASIC. 1970, S. 2-4).[↩]
57. Dass noch Treibstoff für die Rückkehr zum Orbiter benötigt wird, findet in keinem der Spiele Berücksichtigung.[↩]
58. Vgl. DEC: PDP-11 BASIC. 1970, S. 2-5.[↩]
59. Kurtz: BASIC. 2009, S. 81.[↩]
60. Vgl. Ahl: 101. 1973, S. 185.[↩]
61. Ahl: 101. 1973, S. 182.[↩]
62. Vgl. Ahl: 101. 1973, S. 183.[↩]
63. Vgl. Dartmouth College Computer Center: A Manual for BASIC. 1964, S. 22.[↩]
64. N. N.: Mondlandung. 1985, S. 1111f.[↩]
65. N. N.: Mondlandung. 1985, S. 1111.[↩]
66. N. N.: Mondlandung. 1985, S. 1112.[↩]
67. N. N.: Mondlandung. 1985, S. 1111.[↩]
68. Dieser Begriff wird analog zur „erzählten Zeit“ (Müller: Erzählzeit. 1974) verwendet und meint die in der Narration des Spiels dargestellten Zeitabläufe, die durchaus unterschiedlich zur Spielzeit („Erzählzeit“) sein können.[↩]
69. Vgl. Pias: Computer Spiel Welten. 2002, S. 11.[↩]
70. N. N.: Mondlandung. 1985, S. 1112.[↩]
71. Pias: Computer Spiel Welten. 2002, S. 9.[↩]
72. https://history.nasa.gov/SP-4029/Apollo_11i_Timeline.htm [09.10.2019][↩]
73. N. N.: Mondlandung. 1985, S. 1112.[↩]
74. http://www.bbcbasic.co.uk/bbcwin/manual/bbcwin7.html#wait [09.10.2019][↩]
75. Deighan: Lunar Lander Construction Set. 1986.[↩]
76. Bisson: Lunar Lander Construction Set. 1986, S. 73.[↩]
77. Bisson: Lunar Lander Construction Set. 1986, S. 91.[↩]
78. Der Effekt wird hier genauer beschrieben: https://retrocomputing.stackexchange.com/questions/611/what-did-poke-842-13-on-atari-do-jamming-the-return-key [09.10.2019][↩]
79. Vgl. Höltgen: Computer/sprachen. 2018, S. 116.[↩]
80. Vgl. Höltgen: DaimoGraphien. 2019, S. 297.[↩]
81. https://atariaction.tumblr.com/post/183733072617/lander-basic-tenliners-contest-2019-entry [09.10.2019]. Alle nachfolgenden Zitate des Autors und des Codes stammen aus dieser Quelle.[↩]
82. https://gkanold.wixsite.com/homeputerium [09.10.2019][↩]
83. https://gkanold.wixsite.com/homeputerium [09.10.2019][↩]
84. Zit. n. Stuart: How the Moon Landing. 2019.[↩]
85. Vgl. Bachfeld: Lesestoff. 2018.[↩]
86. Pias: Hacker. 2002, S. 254.[↩]
87. Pias: Hacker. 2002, S. 263.[↩]
88. Kittler: Protected Mode. 1993, S. 221.[↩]