Wie der Bordcomputer der Apollo-Kapsel die ersten Menschen zum Mond brachte

Inhaltsverzeichnis

Man stelle sich vor: Da sitzt man in einer winzigen Kapsel im Anflug auf die Mondoberfläche und wenige Minuten vor dem Aufsetzen meldet der für die Landung elementar wichtige Bordcomputer plötzlich einen „Program Alarm 1202“, kurz darauf einen „1201“. Eilig werden die Fehlermeldungen an die Bodenstelle in Houston weitergegeben. Dort berät man sich kurz und gibt das „Go“ zur Landung – der vorgesehene Landepunkt im Meer der Ruhe ist da aber schon passé.

Die Kapsel befindet sich bereits in der letzten Landephase „Terminal Decent, Program 66“ in wenigen hundert Fuß Höhe, etwa eine Minute vor dem Aufsetzen. Bis dahin hatte die Automatik das Lunar-Modul auf einen fußballfeldgroßen, mit Steinen übersäten Krater hin gesteuert. Eilig stellen Buzz Aldrin und Commander Neil Armstrong auf Handsteuerung um. Sie müssen schnell einen neuen Landeplatz suchen. Derweil zählt in Houston der Capsule Communicator die noch verbleibende Treibstoffmenge runter: „Noch 40 Sekunden, 30, 20…“ – der Puls von Armstrong steigt auf 155 Schläge pro Minute.

Sekundenlange Stille – bis endlich die Erlösung kommt. Zunächst kurz von Buzz „Is in“, dann mit wesentlich mehr Verve vom Commander Armstrong „Houston, Tranquility Base here. The Eagle has landed“.

Okay, spätere Berechnungen haben ergeben, dass man noch genügend Treibstoff für 45 statt nur 20 Sekunden für die Landung gehabt hätte, ohne auf dem Mond verbleiben zu müssen. Aber was war da los mit dem Bordcomputer? Was war der Apollo Guidance Computer (AGC) überhaupt für ein Ding und wie kann man heute noch damit spielen? Um diese Fragen zu beantworten, muss man weit zurückblicken, wie der damals hochmoderne AGC überhaupt zustande kam.

Zum 50. Jahrestag der Mondlandung siehe auch den Schwerpunkt auf heise online:

• Tollkühne Männer in ihren fliegenden Dosen: Die Apollo-Mondmissionen

Vorreiter

In der Ära der Space Shuttles, die bis 2011 rund 30 Jahre lang ins All geflogen waren, galt die NASA zuletzt als „retro“. Denn in der Spätphase musste sie für die betagte IT-Technik ihre Ersatzteile, insbesondere den 8086-Prozessor, über eBay im Internet kaufen. Doch das war nicht immer so: Als John F. Kennedy 1961 das ehrgeizige Ziel ausgab, bis zum Ende der Dekade einen Amerikaner auf den Mond zu schicken und heil wieder zurückzubringen, kam die NASA nicht umhin, volles Risiko zu gehen und damals nagelneue und kaum erprobte Technologien einzusetzen. Dazu gehörten im IT-Bereich die allerersten integrierten Schaltungen, neue Speichertechniken und neuartige Betriebssysteme.

Elementar wichtig war die Zusammenarbeit mit dem Massachusetts Institute of Technology (MIT) in Boston. Doch die Entscheidung war umstritten: Das MIT galt einigen NASA-Managern als zu akademisch. Man einigte sich darauf, die Designs des MIT von Industrieexperten überprüfen zu lassen, etwa von der Elektronik-Sparte von General Motors.

Bei der Entwicklung der Rechner-Hardware arbeitete man ansonsten mit der erfahrenen Rüstungs- und Elektronikfirma Raytheon zusammen. Die hatte in den 50er Jahren nicht nur militärische, sondern auch wichtige zivile Meilensteine gesetzt, darunter den ersten Mikrowellenherd oder den ersten kommerziell erhältlichen Transistor. Und so war es Raytheon, die die ersten Computer mit integrierten Schaltungen fertigten. Raytheon konnte zwar selber integrierte Chips backen, die meisten Chips kamen aber von Fairchild, wo die späteren Intel-Gründer wie Robert Noyce, Gordon Moore und Andrew Grove wirkten.

Als zweite Lieferquelle diente Philco (ab 1961 Philco Ford), eine alteingesessene amerikanische Radio- und Fernsehfirma, die schon früh Transistoren einführte, etwa 1955 das erste transistorisierte Autoradio. Philco Ford war zudem für alle Konsolen in den NASA Control Centers verantwortlich, insbesondere im Lyndon B. Johnson Center in Houston. Die Zusammenarbeit mit der NASA ging in den 60ern beim Mercury-Programm los und zog sich über Gemini, Apollo und Space Shuttle bis hin zur ISS. Zwischendurch wechselte Philco den Besitzer. Seit Anfang der 80er gehört die Firma zum Philips-Konzern, was auch vom Namen her gut passt.

Für den Einbau aller Komponenten inklusive der Guidance-Systeme waren erfahrene Flugzeugbauer vorgesehen: für die Apollo-Kapsel die Space and Information Division of North American Aviation und für das Luna Excursion Module (LEM), hier Landefähre genannt, die Grumman Aicraft Engineering Corporation.

Für das Design der IT-und Navigationstechnik sowie die Software des Apollo-Programms war Dr. Charles Stark Draper vom MIT Instrumentation Lab verantwortlich, der daraufhin sein ohnehin schon großes Entwicklerteam auf mehrere hundert Ingenieure ausweitete. Seine Mitarbeiter Richard Battin und Hal Laning hatten – Jahrzehnte vor Windows – ein kooperatives Multitasking-Betriebssystem mit Time Slices und Prioritäten entwickelt, dass dann später für das Apollo-Programm von der Softwarechefin Margaret Hamilton weiterentwickelt wurde. Als Hardware-Spezialist war MIT-Ingenieur Eldon C. Hall für den Apollo Guidance Computer verantwortlich.

Anfänge der AGCs

Das erste Konzept vom MIT für einen Bordcomputer, das Modell 1A, wurde schon einige Zeit vorher als „Christmas Computer“ zu Weihnachten 1959 fertiggestellt. Nach dem Vertrag mit der NASA kam es dann in erweiterter Form im Dezember 1961 „als Apollo Guidance Computer, AGC Block 0, Preliminary Modul 3C“ heraus. Zunächst wurde es auf IBM 360 und Honeywell 800 simuliert, dann als Prototyp mit diskreten Bauelementen aufgebaut.

Zum realen Flugeinsatz kam allerdings erst der Nachfolger AGC Block 1 – jedoch verspätet. Grund war die große Katastrophe von Apollo 1, bei der drei Astronauten bei einem Test in der Raumkapsel verbrannten. Bis zu Apollo 6 gab es deshalb erst einmal nur unbemannte Missionen. AGC Block 1 war bereits für die beiden Konfigurationen CM (Command Module) und das nur halb so große LM (Lunar Module) ausgelegt. Letzteres kam aber offenbar nie zum Flugeinsatz.

Die AGC-Ausführungen Block 1 für die unbemannten Apollo-Missionen 3, 4 und 6 wurden jedes Mal erheblich modernisiert. So war der AGC4 etwa beim Multiplizieren gleich sechsmal so schnell wie der AGC3. Für Apollo 7 kam 1965 dann die nächste Generation AGC Block II mit höher integrierten Bausteinen, die dann auch bei Apollo 11 sowohl in der Apollo-Kapsel als auch in der Landefähre eingesetzt wurde.

RTL und DCTL

RTL, hierzulande als Fernsehsender bekannt, steht in der Fertigungstechnik für Resistor Transistor Logic. Der schon erwähnte Intel-Gründer Robert Noyce hatte im Jahre 1959 gezeigt, wie man auf einem monolithischen Silizium-Substrat mehrere Transistoren, Dioden und Widerstände mithilfe von fotochemischer Lithografie auftragen konnte. Seitdem waren die Firmen Fairchild und Texas Instruments mit der Umsetzung für die industrielle Massenproduktion beschäftigt. 1962 konnte der Division Director of Digital Computer Development, Eldon C. Hall die NASA davon überzeugen, dass man für den Bordcomputer zur Mondlandung auf die neuen integrierten Schaltungen setzen sollte.

Für das zuvor geplante Gemini-Raumfahrtprogramm verwendete man zunächst aber noch von IBM gefertigte Systeme mit diskreten Bauelementen. Währenddessen war das MIT kräftig mit der Evaluation der ersten integrierten Schaltungen beschäftigt. Fairchild baute inzwischen Prototypen mit den neuen „Micro Logic Elements“ Typ-G – ein RTL-NOR-Gatter mit drei Eingängen pro Chip, bestehend aus drei Transistoren und vier Widerständen. Die Gatter-Ausgänge ließen sich direkt verkoppeln, weshalb diese Schaltungstechnik den Namen „Direct Coupled Transistor Logic“ (DCTL) trägt.

Anfang der 60er Jahre konnte Fairchild die Produktionsausbeute der neuen integrierten Chips von anfangs 3 Prozent auf satte 30 Prozent steigern. Dementsprechend fiel der Stückpreis zwischen Dezember 1961 und Oktober 1962 von 120 auf 10 Dollar. Legendär ist die erste „Purchase Order“ des MIT von 100 Stück vom 16. Februar 1962 für 4350 Dollar. Im Verlauf des Jahres kaufte das MIT viele tausend weitere Mikrologikelemente zu deutlich günstigeren Preisen. Daneben ließ sich das MIT-Lab auch von anderen Herstellern wie Texas Instruments, Transitron, Westinghouse und Motorola bemustern. Dabei checkte es neben der Qualität der Chips auch die Liefertermine. Die beiden letztgenannten Zulieferer erwiesen sich jedoch als unzuverlässig und flogen schnell aus dem Programm.

Der größte Fairchild-Konkurrent, Texas Instruments, hatte damals bereits „höherwertige“ Logikbausteine wie Flip-Flops, Zähler und anderes im Angebot. Weil das MIT für das Apollo-Programm aber Fairchild bevorzugte, bekam TI zum Ausgleich andere Aufträge – von der NASA als auch insbesondere vom Militär für die Ausstattung der Minuteman-Interkontinentalraketen.

Die ersten „mikrologischen Elemente“ wurden zunächst im runden TO-47-Gehäuse mit acht Pins ausgeliefert (davon wurden sechs benutzt). Deren Belegung findet man in den Datenblättern der späteren baugleichen Raytheon RC-1031 bis 1033: 3 V, 15 mW, Fan in 3, Fan out 4 oder 5, Propagation Delay 25 ns. Wann man auf das rechteckige Dual-Inline-Format (DIL) mit 10 Pins umstieg, ist etwas unklar. Die auf der amerikanischen Wikipedia-Seite gezeigten angeblichen Block-1-Logikmodule im Computer History Museum besitzen jedenfalls schon die DIL-formatigen Chips – vielleicht war das aber doch schon der Block 2.

Die typische Silizium-Prozesstechnik jener Zeit besaß eine Strukturgröße von 25 bis 50 µm, also etwa das 5000-Fache der heute aktuellen Chip-Strukturen. Ein einzelnes NOR-Gatter belegte etwa 1/4 mm² – allerdings brauchten die Anschlüsse weitaus mehr Platz. Die Plättchen in den DIL-Gehäusen mit den späteren Dual-NOR-Chips waren etwa 5,7 mm² groß.

Für den Block-1-Rechner wurden insgesamt 4100 Chips mit Single-NOR-Gatter eingebaut. Ab Apollo 7 kam dann der weitgehend überarbeitete AGC Block II, der insgesamt rund 2800 dieser höher integrierten Schaltungen mit jeweils zwei NOR-Gattern pro Chip besaß. Diese waren auf 24 Logikmodule mit je zwei Boards verteilt, jedes Board mit zwei Reihen à 30 Chips bestückt. Nicht alle Reihen waren immer voll besetzt – Platz wäre für 5760 Gatter gewesen.

Auch wenn es auf dem Bild unten so aussieht, die Chips waren nicht aufgelötet, sondern punktgeschweißt und die Verbindungen auf der Rückseite gefädelt. Dem liegen Erfahrungen aus der Militärtechnik zugrunde, dass Schweißen, Fädeln und Klemmen erschütterungssicherer ist als Löten.

Aus NOR-Gattern kann man alle logischen Komponenten wie Flip-Flops oder Zähler, Addierer et cetera zusammenbauen. Ein sogenannter Halbaddierer braucht fünf solcher Gatter, ein Volladdierer, inklusive Carry-Bit, benötigt derer 12. Für die Addition von 14 Bit wären das 168 Gatter.

Das Standard-AGC-Zahlenformat (mit Ausnahmen) ist Integer mit 16 Bit, davon ein Bit fürs Vorzeichen und eins für die Parität. Das gesamte Rechenwerk samt Akkumulator wurde auf vier Module aufgeteilt, die jeweils für 4 Bit verantwortlich waren. Dafür brauchte es pro Modul rund 120 Gatter.

Auch wenn das AGC-Design einen Sequenzer besitzt, der mit einem festen Takt von 1024 kHz läuft, arbeitet es schaltungstechnisch gesehen asynchron und verwendet zum Teil sogar Timings mit Laufzeitverzögerung über Gatter (20 bis 25 ns). Das macht die Retro-Generierung des AGC in einem FPGA recht schwierig. Mike Steward hat es trotzdem geschafft und den AGC in das Experimentier-Board DE0-Nano mit Altera Cyclone IV gegossen (ab 80 Dollar). Seine Verilog-Software findet man auf Github unter /virtualagc/agc_simulation.

AGC-Simulator

Über den AGC-Prozessor gibt es zahlreiche, zum Teil gar widersprüchliche Literatur. Wir haben hier das Wichtigste zusammengetragen, zum Teil auch debuggt. Die wohl vollständigste Darstellung dürfte das Projekt „Virtual AGC“ von Robert Burkey bieten sowie „The Apollo guidance computer“ von Frank O’Brien. Und dann gibts vor allem noch die beiden Primary Guidance Navigation Control Manuals ND1021042 und ND1021043. Auf Wikipedia geht das oft mit AGC Block 1 und Block 2 ziemlich durcheinander.

Burkey hat den Simulator Virtual AGC in C programmiert und stellt ihn quelloffen für Linux und Windows zur Verfügung – wer also mal mit dem Apollo Guidance Computer selber spielen will …

So rechnet der AGC

Der AGC-Prozessor entspricht im Prinzip der Harvard-Architektur mit getrennten Daten- und Programmwegen – mit einigen Ausnahmen. So gibt es einen etwas urigen Index-Befehl, der es erlaubt, den nächsten Opcode und/oder dessen nächste Adresse zu ändern. Selbstveränderlicher Code ist eigentlich kein Bestandteil der Harvard-Architektur. Außerdem liegen Code und Daten im gemeinsamen Festwertspeicher – ist dann also doch eher eine Mischarchitektur.

Die Daten haben, wie schon erwähnt, ein 14-bittiges Festpunktformat plus Vorzeichen plus Parity Bit. Das Format ist aber ein bisschen tricky, denn es verwendet das Einer-Komplement, das heißt, –1 ist nicht etwa 100 000 000 000 001, sondern 111 111 111 111 110. Somit gibt es zwei Darstellungen für die Null: +0: 000 000 000 000 000 und –0: 111 111 111 111 111 Auch das Parity Bit enthält nicht immer die Parität, sondern wird zuweilen für einen Überlauf verwendet. Der YaYuL- Assembler für den AGC bietet zudem eine gleitkommaähnliche Single-Precision-Sicht auf dieses Datenformat, indem er es als eine rationale Zahl x/2^14 zwischen 0 und 1 betrachtet. Man kann es zudem im Assembler-Befehl sowohl mit 10er- als auch mit 2er-Potenzen skalieren. 656.0 E-4 etwa steht für 0,656 ~= 10748/2^14 = 10 100 111 111 100. oder auch -656.0 E-5 B3 für -0,5248 ~= -8598/2^14 = 01 111 001 101 001

Für eine höhere Genauigkeit kann der Assembler auch „Double Precision“ verwalten und entsprechende Routinen im Festwertspeicher anwerfen. Genauer gesagt, gab es im Festwertspeicher einen Interpreter, der Code für eine virtuelle CPU in nativer AGC-Sprache erzeugte, so wie Java oder LLVM heutzutage. Die Assembler waren dann zum Teil schon eine Art Hochsprache. Das sparte viel Platz, kostete aber viel Zeit – Interpreter sind nun mal langsam. Eine Multiplikation über den Interpreter dauerte mehr als doppelt so lange. Bei hohen Performance-Anforderungen haben die Programmierer dann doch lieber die Basisbefehle mit ihren Subinstruktionen benutzt.

Booten vom Lochstreifen

Man sollte bedenken, dass man 1965 etwa für den schrankgroßen Rechner PDP 8 von DEC mit 4 KWords à 12 Bit für BIOS, Betriebssystem und Interpreter (Focal) auskommen musste. Festwertspeicher kannte die PDP 8 nicht. Man musste zum Booten von Lochstreifen zunächst 17 Werte per Hand eingeben. Dagegen war der AGC II mit 72 KByte Festwertspeicher purer Luxus. Wie bei der PDP 8 wurden übrigens auch beim AGC alle Adressen oder Werte üblicherweise oktal und nicht hexadezimal angegeben (hier im Folgenden in der C-üblichen Oktalschreibweise 07777 für 4075).

Bei den Instruktionen waren drei Bit für den Opcode, 12 Bit für Adressen und eins für Parität vorgesehen. Drei Bit für den Opcode würden allerdings gerade mal für acht Basisinstruktionen ausreichen, also nicht einmal für die elf Befehle des AGC I, geschweige denn für die 34 Befehle des AGC II.

Also braucht man noch trickreiche Interpretationsmöglichkeiten, um mehrere Opcodes verwenden zu können. Und davon gibt es beim AGC einige: einfache und kompliziertere.

So ergeben Schreib- oder Exchange-Operationen auf den Festwertspeicher keinen Sinn. Der Prozessor interpretiert das dann als einen anderen Opcode, etwa XCHG zu CAF – lade Akku aus dem Festwertspeicher. De facto ist das ja eh eine Art Exchange mit Schreibschutz im Speicher. Daneben gibt es bestimmte reservierte Adressen. Der Befehl INDEX 17 etwa schaltet Interrupts ab (INHIBIT). Ansonsten kann man mit INDEX wie schon erwähnt den darauffolgenden Befehl mit einem aus dem Speicher geladenen Wert überladen beziehungsweise ihn hinzuaddieren – sei es dessen Opcode, dessen Adresse oder beides. Zu den Basisbefehlen gehören auch Multiplikation (MP) und Division (DV). Wenn man bedenkt, dass noch zehn Jahre später die erfolgreichen 6502- und Z80-Prozessoren so etwas noch nicht kannten … Okay, natürlich hat auch der AGC das nicht mit aufwendiger spezieller Hardware ausgeführt, sondern über den Interpreter und den virtuellen Prozessor unter Nutzung der einfachen ALU.

Speicheradressen

Die Register werden wie Speicheradressen behandelt, wie es früher in vielen Großcomputern üblich war. Heute findet man Ähnliches bei modernen CPUs wie x86 oder ARM, aber zumeist nur für Konfigurations- und nicht für Rechenregister – es ist also eher ein Memory mapped I/O. Es gibt aber auch modernere Designs, die nur Programm- und Stackzeiger intern führen und den Rest über Speicheradressen abwickeln.

Das wichtigste Zentralregister bei den Prozessoren der 60er und 80 Jahre – also auch beim AGC – ist der Akkumulator in der ALU. Er liegt bei beiden AGC-Ausführungen auf Adresse 00000. Die dann folgende Adressbelegung unterscheidet sich (wir beschränken uns hier auf Block II):

Auf Adresse 0001 folgt L, ein 15-Bit-Register, das nach einer Division den Rest und nach einer Multiplikation den „Low Part“ enthält.

Auf 00002 findet man Q, den Speicher für eine Return-Adresse. Einen Hardware-Stack bietet der AGC nicht, das muss man zu Fuß erledigen, was für ein Multithreading-Betriebssystem mit sieben Timern und elf Interrupt-Typen nicht gerade trivial ist.

Danach folgen die wichtigen Speicherbank-Register 00003 für das RAM (EB: Erasable Bank Register) und 00004 fürs ROM (FB: Fixed Bank Register). Auf 00006 gibt es noch ein Kombi-Register für beides, mit einem Schreibbefehl lassen sich beide Bänke einblenden. Die zwölf Adressbits im Opcode reichen ja auch nur für 4096 Adressen, für den AGC II braucht man aber deutlich mehr: 36K Adressen beim Festwertspeicher und 2K für den „Erasable Memory“. Folglich hat man ein Bank-Switching-Konzept, bei dem ein Register die aktuelle Speicherbank enthält.

Man brauchte ja viel Speicher für die zahlreichen Jobs, die parallel laufen sollten. Solches Banking-Switching gab es auch später oft, sei es im Embedded-Bereich, beim C64 oder auch beim PC, um mehr als die laut Bill Gates „von keinem Menschen je gebrauchten“ 640 KByte adressieren zu können. Ohne EMS hätte Doom jedenfalls keinen Spaß gemacht.

Doom hatten die Astronauten damals auf ihrem Rechner so weit man weiß noch nicht, nicht einmal Mastermind, das man sicherlich auf dem AGC hätte spielen können. Und der vorhandene Code unter dem schönen Namen „Pinball Game Buttons and Lights“ war leider kein Pinball-Spiel, sondern das Programm zum Auswerten der Eingabe.

Der Instruktionszeiger heißt beim AGC II Z und ist zwischen den Bank-Registern auf Adresse 00005 zu Hause.

Adresse 0007 ist ein Zero-Register, es hat fix +0 als Wert.

Dann folgen auf 00010 bis 0017 die Register fürs Interrupt-Handling.

Schließlich gibt es noch eine ganze Reihe weiterer 15-Bit-Register, etwa solche, die den Wert beim Hineinschreiben auf bestimmte Weise editieren. Ein Schreiben auf CR (00021) etwa speichert einen Arithmetic Shift Right, entsprechend einer Division durch 2. Bis hin zu 00057 folgen noch zahlreiche Memory-Mapped I/O-Register, etwa die Ausgänge von sechs Timern, für die Lageanzeige des Raumschiffs, Werte vom Accelerator sowie von den Gyratoren.

Daneben hat der AGC II so wie etwa der spätere Z80-Prozessor getrennte Input- und Output-Kanäle mit eigenen I/O-Befehlen, die waren beim AGC I ebenfalls noch memory-mapped. Bei den Input-Kanälen kommen unter anderem die Signale von den Radarsystemen an, vom Keyboard und so weiter.

Handgefädeltes ROM

Flash-Chips oder EPROMs gab es damals noch nicht, letztere hat Intel quasi nebenbei erst 1970 erfunden. Einmal programmierbare PROMs existierten 1965 zwar schon, aber die steckten noch in den Kinderschuhen: Sie waren nur 256 oder 1024 Bit (General Microelectronics) groß, langsam und womöglich auch nicht raumfahrttauglich. Maskenprogrammierbare ROMs waren ebenfalls noch nicht in Mode, die wären eh zu unflexibel und zu teuer gewesen. Der raumfahrttaugliche, stabile und vergleichsweise schnelle Festwertspeicher der Wahl war damals der von Textilarbeiterinnen „genähte“ Fädelspeicher (Core Rope Memory). Hierbei wurden 64 Sense Lines entweder durch einen kleinen ferromagnetischen Ring geführt (Bit 1) oder an ihm vorbei (Bit 0). Hinzu kamen noch 22 Steuerleitungen, also insgesamt 86 zu fädelnde Drähte pro Ferritkern. Das war platzsparend und relativ schnell auslesbar – aber eine recht filigrane und mühsame Arbeit.

Später verdichtete man das noch und packte bis zu 192 Bit um einen Ferritkern. Insgesamt waren dafür 212 Drähte nötig. In jedes Rope-Module mit 12 KByte Speicherplatz passten 512 Kerne. Sechs Rope-Module waren vorgesehen, das macht insgesamt also 192 × 512 × 6 = 589.824 Drähte.

Mithin mussten die Weberinnen bei jedem Softwareupdate über eine halbe Million Drähte durch oder um die mickrige Ferrit-Kerne fädeln, es sei denn, ein kleiner Patch reichte. Es gibt auch das Gerücht, dass aber nur 128 Drähte durch den Ferritring passten. Dann müssten zwölf aufeinanderfolgende Words – ein sogenannter Strand – mindestens 84 Nullen besitzen, damit man das hinbekommt. Das ist recht unglaubwürdig, müsste man aber anhand der inzwischen veröffentlichten Software mal checken. Übergeben wurden die Datenmassen in Lochkartenstapeln. Auf den Rope-Memory-Modulen, die ein sehr eigenes Format und spezielle Steckplätze haben, steht zwar „mfg by Raytheon“, aber Raytheon hat die aufwendige Fädelei nicht selbst durchgeführt, sondern über Vertragspartner.

Auch für das „RAM“ oder Erasable Memory wurden Ferrit-Ringe gebraucht. Hier waren vier Drähte pro Bit und Kern nötig, zwei für das Select, eines für das Schreiben eines Bits und eines fürs Auslesen (Sense). AGC Block I besaß ein Modul mit 1 KWord, AGB Block II hatte 2 KWord, also 4 KByte.

Die Speicher waren in einer 64×32-Matrix (X x Y) organisiert. Um ein Word zu adressieren, wurde für jedes Bit eine der 64 X-Leitungen und eine der 32 Y-Leitungen mit recht hohem Strom für einige Mikrosekunden aktiviert (mehrere 100 mA). Das schluckte kräftig Strom. Insgesamt zog ein AGC Block II im Betrieb rund 55 Watt, im Standby ohne Speicherverkehr waren es etwa 10 Watt.

Module

Der AGC-II-Rechner – sowohl der in der Apollo-Kapsel (CGC) als auch der in der Landefähre (LGC) – bestand aus zwei zusammengeschraubten Laden (Trays) mit Steckplätzen für die zahlreichen Module. Er ist 6 Zoll hoch, 12,5 Zoll breit, 24 Zoll tief und wiegt 32 Kilogramm. Hinzu kam das Ein/Ausgabesystem DSKY mit dem Keyboard und den numerischen Anzeigen. Das CPU-Tray enthielt 24 Logic-, fünf Interface- und zwei Power-Module. Das Speicher-Tray beherbergte neben dem Oszillator- und dem Alarm-Modul insgesamt acht Speichertreiber-Module und natürlich den Speicher selber: das zwei Slots umfassende Modul für Erasable Memory (ist im Unterschied zu allen anderen schwarz) und die mit einem völlig anderen Formfaktor daherkommenden sechs Module für den Fädelspeicher

Dem Rechner zur Seite stand eine fast gleich große Coupling Data Unit (CDU) mit all den Digital-zu-Analog- und Analog-zu-Digitalwandlern, Verstärkern, der Navigationshardware et cetera. Die CDUs in der Apollo-Kapsel und in der Landefähre waren etwas unterschiedlich bestückt.

Verb und Noun

Auf dem Keyboard sieht man an prominenter Stelle die beiden Tasten „Verb“ und „Noun“. Diese auch vom Klang her sehr unterschiedlichen Namen wurden gewählt, um bei der Eingabe zwei Aufgabentypen zu unterscheiden: Verb: Was soll getan werden und Noun: womit soll was getan werden. Die Astronauten mussten so einiges im Kopf behalten, es gab etwa 45 Programme für die verschiedenen Abläufe, beim LEM zum Beispiel die Landung in verschiedenen Phasen (Programme 63 … 66) oder zum Andocken an das Mutterschiff et cetera.

Insgesamt gab es rund 80 Verbs und 90 Nouns. Damit konnte man Programme starten (Verb 37), Speicher und Werte auslesen und so weiter. Um zum Beispiel abzufragen, wann der nächste „Engine Burn“ in der frühen Landephase in Mission Time ist: Program 63, Verb 06, Noun 33. Wer mal ein bisschen damit spielen möchte: Shahriar Iravanian hat auf seiner Website svtsim/Moonjs/agc.html einen in Javascript geschriebenen Apollo Guidance Computer (AGC) Simulator online gestellt, der auf dem Virtual AGC von Ronald Burkey beruht. Er hat aber offenbar die Programme des Command Module geladen und nicht die der Landefähre.

Colossus und Luminary

Die Software für die Bordcomputer des Apollo-Projekts lief unter den Codenamen Colossus und/oder Comanche für das Command Module, also das Apollo-Mutterschiff, und Luminary für die des Lunar Module. Sie hatten ja unterschiedliche Aufgaben zu erfüllen, benutzten aber beide weitgehend die gleiche Rechnerhardware, das gleiche Display und das gleiche Keyboard (DSKY) sowie das gleiche Betriebssystem. Letzteres wurde in den Grundzügen schon in der 50er Jahren von Hal Laning und Richard Battin am MIT entwickelt. Im Apollo-Projekt war dann hauptsächlich Margaret Hamilton dafür verantwortlich, sei es zunächst als Programmiererin oder dann als „Director of Apollo Flight Computer Programming“. Wer nun welchen Anteil an welchen Code-Schnipseln hat, das war lange Zeit und ist offenbar immer noch Gegenstand eines intensiven Diskussions- und Analyseprozesses.

Das Konzept, das bei dem Betriebssystem dafür sorgte, dass trotz der vielen Sensordaten beim Landeanflug alle wichtigen Programme korrekt ausgeführt wurden und den Rechner nicht überlasteten, beruht auf Zeitscheiben, Job-Prioritäten und Wartelisten. Das Multithreading geschah wie etwa bei Windows 95 kooperativ, jeder Job musste dafür sorgen, dass er Rechenzeit an die anderen wieder abgibt.

Und Linpack?

Der AGC II hatte einen Sequencer-Takt von 1024 kHz. Ein Memoryzyklus (1 MCT) benötigt zwölf Takte, dauerte also 11,7 µs. Jeder Befehl wird dabei in ein bis sieben Subinstruktionen zerlegt, die bis auf zwei Ausnahmen beim Dividieren alle 1 MCT benötigen. Die wichtige 14×14-Bit-Multiplikation wurde gegenüber dem AGC4 noch einmal kräftig beschleunigt, von 8 MCT auf 3 MCT, mithin auf nur 35,1 µs. Eine Addition kostet 2 MCT, ein Inkrement ebenfalls.

Beim Linpack-Benchmark geht es in erster Linie um eine Matrixmultiplikation. Für die innere Schleife benötigt man noch einen Vergleich CCS (2 MCT), der beim AGC II schon auf etwas komplizierte Art mit einem Sprung gekoppelt ist. Dann fehlt noch die Indexierung mit dem vorangestellten Index-Befehl, um die unterste Schleife bei der Matrixmultiplikation abzuarbeiten: C[i][k]= sum (A[i][[j]*B[j][k]). Grob abgeschätzt kommen dann 13 bis 15 MCTs pro Schleifendurchgang für zwei Flops (AD, MP) zustande, macht über den Daumen 12 KFlops/s für Single Precison von 14 Bits.

Für die doppeltgenauen Instruktionen für AGC Block II findet man 3 MCT (35,1 µs) für die Addition und 40 MCT (468 µs) für die Multiplikation. Letztlich dürfte es dann etwa rund vier Mal so lange dauern wie bei Single Precision, der Bordcomputer erreicht also etwa 3 KFlops/s mit 28 Bit Genauigkeit. Ja gut, moderne Handys sind bei der Matrixmultiplikation mit 32-Bit-Gleitkomma (SGEMM) gut 20 Millionen Mal so schnell (Apple Iphone XS Max: 56,7 GFlops) … kommen aber trotzdem nicht zum Mond.

In der Landefähre gab es für den Notfall ein eigenständiges Abort Guidance System (AGS) mit einem komplett anderen Computer. Diesen Notfall gabs zwar nie (Apollo 13 hatte einen anderen …), aber dennoch wurde das AGS von der Apollo-11-Mannschaft beim Rendezvous mit der Apollo-Kapsel aktiviert. Houston befürchtete, dass die Kommunikation mit dem Rendezvous-Radar, das am LGC angeschlossen war, gestört sein könnte und riet zum Umschalten auf AGS.

Programmalarm und Landung

Zum Schluss nun der Exkurs zum vielbeachteten Programmalarm, der wenige Minuten vor der geplanten Landung der Apollo-11-Landefähre Houston in Schockstarre versetzte. Was war geschehen? Buzz Aldrin hatte einen Wert (Delta H) abfragen wollen und dafür Verb 16 (Monitor data in decimal) und Noun 68 (Downrange distance, time-to-go in braking phase (minutes and seconds), velocity) eingetippt. Doch dann meldete der Computer Program Alarm 1202: Job overflow. Schon zwölf Minuten vorher hatte Aldrin Programm-Alarm 500 gemeldet, aber das war ein Versehen, kein Alarmwert, sondern ein Ausgabecode. Nun aber wirklich.

Um 102:38:26 Mission-Zeit berichtete Commander Armstrong das Vorkommnis. Zwanzig Sekunden lang Totenstille in Houston, dann meldete Capsel Commander Charlie Duke das Go, das ihm zwischenzeitlich der zuständige Softwareexperte Steve Bales signalisiert hatte. Bales hatte das nicht selbst entschieden, das sendete Kollege Jack Garman vom AGC Staff Support Room. Der Rechner konnte wegen Überlastung niedrig priorisierte Aufgaben nicht ausführen und hängte sie ab. Garman hatte sich einen Spickzettel gemacht, auf dem gefährliche Alarme, die ein Abbruch erfordert hätten, sowie weniger gefährliche verzeichnet waren. 1202 gehörte glücklicherweise zu den letzteren. Auch das jeweilige Risiko war eingetragen. Betroffen von 1202 war möglicherweise das Auslesen vom Keyboard. Das Risiko nahm man in Kauf.

Wie kam es dazu? Aldrin hatte vorsichtshalber bereits das Rendezvous-Radar eingeschaltet, falls man die Landung hätte abbrechen müssen. Das wäre nicht das Problem gewesen. Aber sei es, dass es Synchronisationsprobleme gab oder einen defekten Sensor, jedenfalls trudelten unsinnige und unnötige Daten ein, die den Rechner zu 15 Prozent belasteten. Das leistungsfähige Betriebssystem konnte jedoch mit dem Problem umgehen und alles Wichtige weiterhin ausführen – das Rendezvous-Radar brauchte man zu dem Zeitpunkt ja nicht. Und den Delta-H-Wert konnte Houston remote ermitteln: „Eagle, Houston, we’ll monitor your Delta-H“. Da waren es noch sechseinhalb Minuten bis zur Landung und Aldrin schaltete noch in der Bremsphase (P63) wieder zurück auf Automatik, etwa eine Minute vor der Annäherungsphase P64. Zwei Minuten später tauchte aber Programmalarm 1201 auf: zu viele Interrupts. Doch das hatte Houston schon erwartet: „Der gleiche Typ, weitermachen!“. Das war etwa eine halbe Minute vor der finalen Phase P65, wo automatisch auf (Semi-)Handbetrieb umgeschaltet werden sollte.

Ein vollautomatisches Landen war bei Apollo 11 nicht vorgesehen, obwohl P65 dafür ausgelegt war. Das war auch gut so, Commander Armstrong berichtete von „Pretty rocky area“ und Steuermann Aldrin musste noch einem Krater ausweichen. Houston zählte derweil die noch vorhandene Treibstoffmenge herunter.

Die Astronauten hatten aber offenbar schon etwas früher als bei 100 Fuß Höhe die halbautomatische Steuerung P66 gewählt und erklärten das kurz nach der Landung so: „Das automatische Zielsystem führte uns mitten hinein in einen fussballfeldgroßen Krater, mit einer großen Anzahl von Brocken und Felsen … und es erforderte ein … in P66 und ein manuelles Fliegen über das felsige Feld, um einen halbwegs guten Platz zu finden“.

Was mit dem Rendezvous-Radar beziehungsweise mit dem Interface zum LGC ganz genau los war, wird man wohl nie mehr herauskriegen – das Aufstiegsteil der Landefähre von Apollo 10 könnte man wohl noch irgendwo im Orbit um die Sonne herum aufspüren. Das von Apollo 11 wurde nach dem Rendezvous abgeworfen, kreiste eine Zeitlang um den Mond und dürfte irgendwann auf ihm aufgeschlagen sein. Da gibts nun einen ganz kleinen Krater namens LEM.

Literatur

• Eldon C. Hall, Journey to the Moon: The History of the Apollo Guidance Computer, 1996 ISBN:156347185X

• Frank O’Brien, The Apollo guidance computer, Springer 2010, ISBN10 1441908765
  

Dieser Artikel stammt aus c't Retro 2019. (as)