So funktionierte der Bordcomputer des Apollo-Programms, der AGC

Warum der AGC ikonisch ist

Der Apollo Guidance Computer (AGC) war nicht einfach nur ein Computer seiner Zeit – er verkörperte eine gesamte Entwurfsphilosophie. Er wurde für eine Umgebung entwickelt, in der Fehler unbezahlbare Folgen gehabt hätten, Ressourcen extrem knapp waren und Software-Updates praktisch „in Stein gemeißelt“ in den Core-Rope-Speicher eingewoben wurden. Diese Zwänge führten zu einer strengen Disziplin in Hardware- und Softwaredesign, deren Lehren bis heute in eingebetteten Systemen, Robotik, Raumfahrt und Echtzeitsteuerungen gültig sind. In diesem Artikel werfen wir einen detaillierten Blick auf den Aufbau: Wortformat, Registersatz, Speicherorganisation, Bankumschaltung, I/O und DSKY; wir beleuchten das Executive/Waitlist-Scheduling, die berühmten 1201/1202-Alarme und vergleichen schließlich die Leistungsfähigkeit mit modernen Smartwatches und Smartphones.

Physische und Umweltanforderungen

Der AGC war sowohl im Kommandomodul (CM) als auch in der Mondlandefähre (LM) installiert und wurde so entworfen, dass er die extremen Bedingungen der Raumfahrt überstand: Vibrationen, Temperaturwechsel, Vakuum, Strahlung und elektromagnetische Störungen. Das gesamte System wog etwa 30–32 kg und benötigte rund 50–60 W Leistung. Die modulare Bauweise mit Löt-Platinen und standardisierten Steckverbindern minimierte mechanische Ausfallpunkte. Ziel war: kompakter Aufbau, stabiles Wärmemanagement, einfache Wartung und schnelle Diagnose.

Integrierte Schaltungen und Logik: die „alles NOR“-Philosophie

Das Block-II-Design zeichnete sich durch die massenhafte Nutzung von Silizium-ICs aus. Die Logik basierte auf RTL (Resistor-Transistor-Logic) mit 3-Eingangs-NOR-Gattern. NOR ist ein universelles Gatter: jede boolesche Funktion lässt sich damit realisieren. Der CPU-Kern – ALU, Steuerlogik, Multiplexer, Zustandsmaschinen – bestand vollständig aus diesem einen Gattertyp. Das vereinfachte Produktion, Lagerhaltung und Qualitätssicherung und erhöhte die Zuverlässigkeit. Weniger ICs, weniger Lötstellen, weniger Fehlermöglichkeiten – ein versteckter Vorteil des AGC.

Wortformat und Arithmetik

Der AGC nutzte ein 16-Bit-Wort, davon 15 Datenbits und 1 Paritätsbit. Das Paritätsbit diente der Fehlererkennung; die Arithmetik arbeitete mit Einerkomplement und einem speziellen Überlaufbit. Dieses Konzept war einfach, deterministisch und für die damalige Technologie ideal. Festkommaarithmetik ersparte teure Gleitkomma-Hardware, Algorithmen für Navigation, Steuerung und Filterung wurden bewusst darauf zugeschnitten.

Registersatz und Befehlssatz

Wichtige Register im Programmiererblick:

• A – Akkumulator, Ergebnisregister der ALU

• Z – Befehlszähler (PC)

• Q – Divisionsrest / Rücksprungadresse bei Transfer Control

• LP – Unteres Wort bei Multiplikation

Der Befehlssatz war kompakt (etwa drei Dutzend Opcodes), aber auf die Missionsaufgaben zugeschnitten. Einfache ALU-Operationen liefen schnell, speicherintensive oder Multiplikations-/Divisionsbefehle langsamer. Ausführungszeiten: 10–100 µs, entsprechend Zehntausenden bis Hunderttausenden Befehlen pro Sekunde. Entscheidend war weniger die rohe Geschwindigkeit als die vorhersehbare Ausführung.

Takt und Zeitbasis

Ein 2,048-MHz-Quarz diente als Referenz, geteilt auf einen internen 1,024-MHz-Vierphasen-Takt, der CPU-Zustandsmaschinen, Speicherzugriffe und Interruptsystem steuerte. Niedrigere Frequenzen (~100 Hz) wurden für Echtzeitzähler und periodische Aufgaben genutzt. Diese deterministische Zeitbasis stellte sicher, dass die GN&C-Schleifen (Guidance, Navigation & Control) konsistente Verzögerungen hatten.

Speicherarchitektur: Core-RAM und Rope-ROM

Der erasable Speicher war magnetischer Kern-RAM mit 2.048 Worten (~4 kB). Der fixed Speicher war der legendäre Core-Rope-ROM mit ~36.864 Worten (~74 kB). Rope-ROM-Bits wurden physisch „verwoben“: Draht durch den Kern = 1, daneben = 0. Damit war die Software fest in der Hardware eingebrannt. Konsequenz: extrem strenge Build- und QA-Prozesse, Änderungen am Flugexemplar waren praktisch unmöglich.

Bankumschaltung und Disziplin im Code

Das 12-Bit-Adressfeld reichte nur für 4k-Worte; daher war Bankumschaltung nötig. RAM war in 256-Wort-Seiten organisiert, ROM in größeren Bänken. Strikte „Bankhygiene“ galt: klar definierte Aufrufkonventionen, Sprung- und Rücksprungregeln, Makros und Linkerregeln stellten sicher, dass der Code im richtigen Bankbereich landete. Diese Disziplin erinnert an moderne Speicherfenster und Peripherie-Paging.

I/O-System und Peripherie

Der AGC kommunizierte über I/O-Kanäle mit:

• IMU (Inertial Measurement Unit): Gyros und Beschleunigungsmesser mit Driftkompensation

• Radare: Landungsradar und Rendezvous-Radar im LM

• Triebwerkssteuerung: Haupttriebwerk und RCS-Düsen

• Telemetrie und Uplink: Datenaustausch mit der Erde

• DSKY: Display & Keyboard, die Bedienoberfläche der Crew

Die I/O-Kanäle übertrugen 15-Bit-Worte mit Redundanz und Parität, streng getaktet und deterministisch.

DSKY: das Verb–Noun-Interface

Das DSKY (Display & Keyboard) war eine frühe, bewusst gestaltete Benutzeroberfläche. Befehle wurden als Verb (Aktion) und Noun (Objekt) eingegeben (z. B. Verb 06 Noun 20: Anzeige eines Vektors). Drei fünstellige elektrolumineszente Anzeigen und Statuslampen (PROG, UPLINK ACTY etc.) gaben Rückmeldung. Kompakt, konsistent, leicht einprägsam – ideal unter Stress. Das CM hatte zwei DSKYs, das LM eines.

Echtzeit-Betriebssystem: Executive und Waitlist

Das Herzstück der Software war der Executive, ein prioritätsgesteuerter, präemptiver Scheduler. Kritische GN&C-Aufgaben hatten höchste Priorität, weniger dringende wurden in der Waitlist abgelegt. Bei Überlast verwarf der Executive Niedrig-Prioritäts-Aufgaben und ließ nur die wichtigsten Schleifen laufen. Dieses Schutzprinzip hielt das System auch unter Extremlast stabil.

Die 1201/1202-Alarme erklärt

Während der Apollo-11-Landung traten 1201/1202-Alarme auf – Zeichen für Executive-Überlastung. Zusätzliche Interrupts vom Rendezvous-Radar überlasteten die CPU. Das System reagierte wie vorgesehen: kritische Steuerungen liefen weiter, Unwichtiges fiel aus. Wichtige Navigationsdaten blieben erhalten. Kein Absturz – sondern ein bewusstes fail-operational Verhalten, ein Triumph der Systemarchitektur.

Navigation und Steuerung: Sensorfusion, Δv, DAP

Die Software integrierte kontinuierlich IMU-Daten, korrigiert durch Driftmodelle und Ausrichtungen. CM-Optiken (Sextant, Teleskop) gaben Sternreferenzen, LM-Radare ergänzten Messungen. Sensorfusion geschah in Festkomma. Für Bahnänderungen berechnete der AGC Δv, Brenndauer und Profile; der DAP (Digital AutoPilot) steuerte Triebwerke und RCS.

Softwarelinien: Colossus und Luminary

Das CM lief mit Colossus, das LM mit Luminary. Beide in AGC-Assembler, streng dokumentiert, modular und mit vielen Kommentaren. Rope-ROMs hatten lange Produktionszeiten – Releases waren selten, aber stabil. Änderungen im letzten Moment waren praktisch ausgeschlossen – daher dominierte präventive Qualitätssicherung.

Entwicklung und QA

Der Code entstand auf Großrechnern mit speziellen Assembliern und Simulatoren (IMU-, DSKY-Emulation). Der Build erzeugte eine „Weaving List“ für das Rope-ROM, anschließend folgten elektrische, funktionale, thermische und Vibrations-Tests. Codierdisziplin war nicht Stilfrage, sondern Lebensversicherung.

Leistung in Zahlen

• Wortlänge: 15 Datenbits + 1 Parität

• RAM: 2.048 Worte (~4 kB)

• ROM: ~36.864 Worte (~74 kB)

• Takt: 2,048 MHz Referenz → 1,024 MHz intern

• Instruktionszeiten: 10–100 µs

• Durchsatz: zehntausende bis hunderttausende Instruktionen/s

• Leistungsaufnahme: ~50–60 W

• Masse: ~30–32 kg

Heute Mikrocontroller-Niveau – damals die Steuerung für die komplexeste Mission der Menschheit.

Zuverlässigkeit und Fehlertoleranz

• Parität auf jedem Wort

• Watchdog/Reset mit Zustandsdaten-Erhalt

• Prioritätenschutz: kritische Tasks liefen immer

• Physische Robustheit: Raumfahrt-Qualifikation

• Einfachheit: kleine Codebasis, wenige Opcodes

Warum keine Gleitkomma-Einheit?

Die meisten Aufgaben ließen sich in Festkomma formulieren, mit Skalierung und Normalisierung. Gleitkomma wurde nur selten und softwareemuliert benötigt.

„War er schwach?“ – im Kontext

„Dein Handy ist tausendmal stärker“ – stimmt bei MIPS, verfehlt aber den Punkt. Smartphones optimieren auf Durchsatz und Multimedianutzung; der AGC garantierte deterministische Echtzeit. Nicht schneller – sondern vorhersagbarer, dort wo es ums Überleben ging.

Vergleich mit modernen Smart Devices

Rohdaten

• AGC: ~0,1 MIPS, ~4 kB RAM, ~74 kB ROM, ~1 MHz intern

• Smartwatch: Multicore 1–2+ GHz, 1–2 GB RAM, 8–64 GB Flash, oft DSP/NPU

• Smartphone: big.LITTLE, 3+ GHz Kerne, 6–16 GB RAM, 128 GB–1 TB Speicher, GPU/NPU

Unterschiede: tausend- bis millionenfach. Doch der AGC hatte nur wenige kritische Schleifen zuverlässig zu versorgen.

ISA und Programmierbarkeit

Der AGC: kleiner Befehlssatz, manuelle Bankumschaltung, Festkomma. Heute: 64 Bit, Out-of-Order, SIMD, JIT, Hochsprachen. Produktivität heute immens höher – Echtzeitgarantien aber oft nur über RTOS oder Co-Controller.

Echtzeit und Jitter

Der AGC lief deterministisch. Moderne SoCs auf Durchsatz und mittlere Latenz optimiert; Jitterkontrolle durch isolierte Kerne, RT-Prioritäten oder Always-on-MCUs.

Energie und Wärme

Pro Operation sind heutige Chips viel effizienter – aber ihre Aufgaben viel breiter. AGC verbrauchte ~50–60 W in einer klar definierten Lastumgebung – sinnvoll im Energiehaushalt der Apollo-Kapsel.

Zuverlässigkeit und Updates

Rope-ROM unveränderlich, extrem geprüft. Smartphones/Smartwatches flexibel, OTA-Updates, aber schwerer formal beweisbar. Dafür schnelle Fehlerbehebung und Feature-Updates.

Systemingenieur-Lehren

1. Strenge Prioritäten: kritische Schleife gewinnt immer

2. Deterministische Zeitbasis: Jitterprofile bekannt, Ausführungsfenster garantiert

3. Speicherdisziplin: Bankumschaltung, Modulgrenzen, klare Konventionen

4. Fail-Operational-Mentalität: Reset ≠ Scheitern, wenn Zustände gesichert

5. Einfachheit + QA: weniger Gatter/ICs → bessere Fertigung, bessere Tests

Häufige Missverständnisse

• „Der AGC war nur ein Taschenrechner.“ Nein – niedrige MIPS, aber extreme deterministische Zuverlässigkeit.

• „1201/1202 hätten fast Apollo 11 zerstört.“ Im Gegenteil: sie zeigten das Schutzprinzip in Aktion.

Kurzdatenblatt

• Entwickler: MIT Instrumentation Lab / Raytheon

• Architektur: RTL-NOR-Logik, 16-Bit-Wort (15 Daten + 1 Parität)

• Speicher: 2k Worte RAM, ~36k Worte Rope-ROM

• Takt: 2,048 MHz Referenz → 1,024 MHz intern

• Betriebssystem: Executive/Waitlist, präemptives Echtzeit-Scheduling

• UI: DSKY Verb/Noun, EL-Anzeigen, Statuslampen

• Peripherie: IMU, Radare (LM), RCS/Engine, Telemetrie, Uplink

Die Geschichte des Apollo-Computers handelt nicht davon, wie „wenig“ er konnte, sondern dass er genau das konnte, was nötig war – absolut zuverlässig. Strenge Einfachheit, disziplinierter Umgang mit Speicher und Zeit, rigoroses Testen. In den Momenten der 1201/1202-Alarme zeigte sich nicht Schwäche, sondern Stärke: der AGC tat, wofür er gebaut wurde – er sicherte die Mission. Heute verlassen wir uns auf rohe Rechenleistung. Der AGC erinnert uns: gute Architektur und Echtzeitdisziplin sind unersetzlich. Dieses „weniger, aber sicher“ brachte uns zum Mond – und unterscheidet bis heute einen Prototypen von einem betriebszuverlässigen System.