You are watching a Space Shuttle computer think.

The run, narrated

The machine vs. the phone in your pocket

Three stories about this technology

The vote — all five computers, live

This is the part the single-program console can’t show: five emulated AP-101s running at once, exchanging their answers over shared serial buses in the pattern the orbiter’s used. One of them — GPC 2 — has been given a corrupted sensor. Watch it compute 13 where everyone else computes 42, watch the values cross the buses into every machine’s mailboxes, and watch the healthy majority vote it out while the force-voting actuator physically ignores its command.

What you are watching is a reconstruction. The buses, the listen mode, the sync discretes and the timeout behaviour are emulated from IBM’s and Rockwell’s documentation, and they are cited. But the redundancy-management software itself — the code that actually decided which computer to believe — lived in the primary flight software, which is not among the recovered artifacts. This demonstrates the mechanism the orbiter used. It does not run the orbiter’s own voting code, because nobody outside NASA has it.

The source, and the machine code it became

Three real programs, each one traced instruction by instruction. Two things move together: the statement a programmer wrote, and the code the compiler turned it into. Neither mapping is ours — the compiler emitted a table saying which addresses belong to which statement, the linker emitted another saying which routine owns which address, and this panel only reads them.

When the badge turns amber the processor has left the program entirely and is down inside the flight runtime library — NASA’s own code, linked in behind every WRITE. That is where nearly all of the time goes.

What this software actually did

The routines on this page are pieces of a much larger job. The Shuttle’s primary flight software — about 400,000 lines of HAL/S and assembly — was not one program but a set of them, and the crew switched between them in flight by typing OPS numbers on the keyboard you saw above. Each “operational sequence” loaded the software for one phase of the mission, because a megabyte of memory could not hold the whole flight at once.

Underneath all of it ran the same machinery you have been watching: the computers voting, the crew typing at DEU keyboards, and the runtime library doing the arithmetic. When guidance needed the angle between the orbiter’s nose and its velocity vector, it called a dot product. When it needed a pure heading, it normalized. When it composed one frame of reference into another, it multiplied 3×3 matrices. Those exact routines run again in the table below — not a re-creation, the code itself.

Ambition worth stating plainly: the Shuttle’s complete flight software is not public, and much of it never will be. What survives — the compiler, the assembler, the runtime library, the computer’s own manual — is what this project has resurrected, and it is enough to run real programs on a faithful machine.

The flight math lab

The Shuttle’s runtime library survives as original AP-101S assembly — 205 routines, of which 202 assemble today with the genuine flight assembler. These are the 35 verified so far — single- and double-precision, one- and two-argument: each was assembled, linked, and executed on this emulator, and its answer compared against the same function on a modern machine. The “calls” column matters — when SINH runs, the exponential underneath it is the Shuttle’s own EXP; ASINH reaches down through its LOG and its SQRT. The library is running as a library.

Differences appear in the seventh decimal place — the limit of the machine’s 24-bit hexadecimal fractions, not an error. Reproduce any row with tools/resurrect.py SQRT:2.0, which finds the routine’s dependencies, writes a driver, assembles it with ASM101S, links it, runs it, and checks the answer.

The crew station — keyboard and CRT

This is how astronauts talked to the computers. There was no keyboard on a GPC — the crew typed on Display Electronics Unit keyboards, and every keystroke travelled a serial data bus to whichever computer was driving that screen. The panel below replays a real session on this emulator: each key you see light up was queued in the DEU, polled across the display bus by a bus-control program, and delivered into the GPC’s memory — the numbers under “GPC heard” are read out of that memory, not the keyboard.

Run it live in a terminal: cargo run --bin lazap-dps — type on your own keyboard and watch the emulated GPC poll your keystrokes.

Defect report — filed against a retired spacecraft

These are defects in the flight system itself. Three of the four are the original engineers’ own admissions, printed in the Principles of Operation under headings that read ANOMALY NOTE — documented, shipped, and flown for thirty years. Written the way you would file them today.

Did any of this actually bite in flight? Honestly: there is no public record of a Shuttle mission failing because of these. Two reasons, both worth understanding. First, the flight software was written around them — comparisons used tolerances, block moves avoided the exclusion zone, ON ERROR was not relied on for matrix inversion. Second, and more to the point, this is precisely what four voting computers are for: a fault that corrupts one machine’s arithmetic gets outvoted before it reaches an actuator. These are latent defects in a system engineered on the assumption that latent defects exist. That is the actual lesson — not that the hardware was bad, but that it was known to be imperfect and flown safely anyway.

Items 1 through 3 were open the entire time the Shuttle flew, and are open now. Item 4 is open in any surviving copy of the compiler.

For completeness, this project’s own defects are tracked in the same file. A resurrection that only lists other people’s bugs is not being honest — but ours belong in an appendix, not alongside the flight system’s. Two so far, both fixed. The first was an MVH decrement-order bug that dropped the leading halfword of every block move, caught by a Shuttle physics program and closed with a regression test.

The second is the more instructive one. A linked image shipped with another program’s symbol table — LAZARUS carrying a byte-identical copy of the hello fixture’s. Nothing failed. The emulator reads only the runtime entry points from that file and those were genuinely shared, so every test stayed green while the panel above this one attributed LAZARUS’s instructions to CSECTs that do not exist in it. A project whose entire claim is provenance had a file quietly asserting the wrong provenance. It was rebuilt from LAZARUS’s own object deck, and CI now rejects any symbol table that duplicates another or names a CSECT its object deck never declared.

How long did it take?

Getting the right answer was never the hard part. Getting it in time was. The guidance loop ran at 40 Hz — a new answer every 25 milliseconds, forever, with no option to run late.

These times are the compiler’s own. HAL/S-FC carried a table of per-instruction execution times and printed a TIME: figure beside generated code; this emulator now adds up the same numbers as it runs. One caveat, and it is a real one: the compiler printed the values without a unit. Microseconds is the conventional reading for this hardware and is what the frame column assumes, but we have not confirmed it, so treat that column as indicative rather than settled.

Read the top row again. Printing eight short lines of text costs close to half a guidance frame — because almost all of it is the character formatting you watched earlier. Inverting a 3×3 matrix, the operation that undoes a rotation, costs about a fiftieth of one. That ratio is the whole argument for why flight software does not print things.

What is not here

A resurrection is worth what its boundaries are worth. Everything above is real and checked. These are the things this project does not have, stated plainly so nothing on this page is mistaken for more than it is.

Run all of it yourself

Everything on this page is a program you can run. The emulator is one Rust project; the historical toolchain is Python. No network, no accounts, no cloud — the whole Shuttle computing world fits in a repository — this one.

git clone https://github.com/keithadler/lazarus-ap.git
cd lazarus-ap
cargo test                          # 194 tests
cargo run --bin lazap -- roms/hello/hello.fcm

cargo run --bin lazap-dps          # crew station: type at the DPS keyboard, watch the CRT
cargo run --bin lazap-set          # the five-computer vote, live in your terminal
cargo run --bin lazap-set -- --kill 1   # kill a computer and watch the others outvote its silence

cargo run --bin lazap -- roms/hello/hello.fcm        # a HAL/S program, byte-identical to the reference
echo "42, 3.14" | cargo run --bin lazap -- roms/read_write/read_write.fcm
cargo run --bin lazap -- roms/lazarus/LAZARUS.fcm    # written for this project, compiled by the real Shuttle compiler

tools/resurrect.py SQRT:2.0 EXP:1.0 EPROD:2,3,4
# finds the routine's dependencies, writes a driver, assembles it with the
# genuine ASM101S, links it, runs it, and checks the answer against math.h

cargo run --bin lazap-trace -- roms/lazarus/LAZARUS.fcm   # the JSON trace behind this page
cargo run --bin lazap-call -- roms/nasa/VV6RUN.fcm --at 11E
cargo test                          # 191 tests: every instruction, the vote, the flight math

This page is a single self-contained file — it runs from a repository, from a laptop, or from GitHub Pages with nothing but a browser.

The people