Rebuilding Apollo'sview program
I had an agent rebuild the NASA program that drew what Apollo crews would see, working from the documents and pictures it left behind.
Noah Bolanowski posted a thread on X with clips of computer-drawn views from the Apollo missions: the Earth turning in a spacecraft window, star fields in a telescope, a lunar module drawn in white lines. NASA's Manned Spacecraft Center (MSC) in Houston made them with a program that showed crews what they would see before they flew.
It made me want to build an online Apollo software library: working recreations of the software behind the missions, each shown next to the documents it came from. This program is the first entry. You can try it here, and the code is on GitHub.
What the program did
The main source is a 1972 NASA report, TN D-6853, by Charles T. Hyle and Alfred N. Lunde. It describes a "somewhat dormant" program, first written for Gemini rendezvous and docking studies, that MSC revived and extended for Apollo. It ran in FORTRAN V on a UNIVAC 1108. The output was microfilm: a camera photographed pictures made of dots and straight lines on a cathode-ray tube. The frames were printed for mission documents and crew charts, and some were cut together into a film, View from a Spacecraft.
The report lists how the missions used it:
- For Apollo 8, it showed that the lunar horizon's position against a mark on the window could support an onboard go/no-go check for lunar orbit insertion.
- The Apollo 11 crew asked for views through the command module's scanning telescope and the lunar module's alignment telescope, and used them to choose stars before the flight.
- For the landing, views through the LM windows showed which craters should cross which marks on the landing point designator, and when.
- On Apollo 13, views of the Earth were the only attitude reference for a midcourse correction.
The Apollo 11 edition of these views, 69-FM-197, runs 321 pages. It credits G. B. Roush with developing the program's major analytical tool.
No source code
The program's source code isn't known to survive in public. What does survive is a lot of its output and a good description of how it worked. So the recreation works backward: it recomputes each published figure from the inputs printed on it, then checks the result against a scan of the original.
The inputs come from the 1969 documents themselves. 69-FM-197 prints each view's time, platform alignment and gimbal angles, plus the LM window geometry and a sequence of frames through the powered descent. The Apollo 10 edition, 69-FM-107, includes the program's 1,078-star catalog as a line-printer table. OCR recovered 826 verified rows of it. The Apollo 11 Mission Report gives the spacecraft's position and velocity at points through the flight, and the Apollo 11 press kit gives the dimensions for the vehicle models.
The rest is public data: the Yale Bright Star Catalogue, the guidance computer's own star table from Virtual AGC, Natural Earth coastlines, and lunar crater positions from the IAU/USGS gazetteer.
How it's built
I had Claude Code build it. I gave it the report and the goal, and let it work through the whole plan on its own and report back at the end. It took a day.
One rule shaped the project: never change an input to make a comparison pass. Each comparison has a pass mark written down before the scan is measured. When a comparison fails, the failure stays in the results with its analysis. Where the documents never printed an input, usually the spacecraft's attitude, the recreation solves for it from the figure and calls the result a fit instead of a prediction. Every decision is in a ledger in the repo.
The engine is TypeScript with no framework, and it follows the original's two halves. TN D-6853 says the first half integrated trajectories for up to four vehicles, by Encke's or Cowell's method, and the second half drew what an observer would see.
The recreation integrates the trajectory with Cowell's method, starting from the Mission Report's state vectors and never integrating across a burn. It points the spacecraft with a platform alignment matrix (REFSMMAT) and gimbal angles, the same quantities the guidance computer used, so a figure's printed inputs go in unchanged. The drawing side covers the star catalogs, the Earth and Moon as globes with coastlines, craters and the day/night terminator, the window outlines, and hidden-line models of the LM and the S-IVB.
The output is SVG, in a microfilm style or the style of the printed reports. There's also a 132-column line-printer version, because the report mentions the program could print "crude printer-plot images" for a quick look before the microfilm came back.
On the site, you can compare each figure with its scan, change the time or the gimbal angles and watch the view recompute, and play the film. The film is computed in your browser one frame at a time, by the same engine.
What it found
Some of it matches well. Figure 3b, twenty minutes after 3a, comes within 0.52° RMS of the printed positions with nothing fitted, against a limit of 1°. The Earth views in Figure 6 match their disc, terminator and 30 coastal landmarks.
Some misses turned out to be problems in the original documents:
- As printed, Figure 3c points the telescope the opposite way. Both 69-FM-197 and TN D-6853 print the inner gimbal angle with the wrong sign, and both label the star Alphecca as Alpheratz. The figure's own stars show both errors.
- Seven rows of the Mission Report's trajectory table are misprinted or inconsistent with the rest of the table.
- Figure 1 draws the Sun and Venus about where they would have been three days after launch. The best explanation in the ledger is a study run for a later launch date, but that's unconfirmed.
Some misses are still open. The biggest is the horizon. On Figures 1, 2 and 3b, the 1969 program drew the Earth's or Moon's horizon as a clean circle much smaller than the true one, and the recreation hasn't recovered the rule it used. Figure 7 doesn't match its own printed times. The star catalog stopped at 826 verified rows, short of the project's target of 1,000. All of these stay in the results.
If you know anything about that horizon rule, or where the program's listings ended up, the repo is the place.