# Virtual AGC: running the Apollo Guidance Computer's original assembly code

> virtualagc/virtualagc pairs an assembler and a CPU simulator with the transcribed Apollo flight software, so the AGC's real instruction stream can be executed and inspected. The judgement: it is a faithful emulation project, not a plug-and-play app, and its build wants a Unix toolchain.

**virtualagc/virtualagc** — Virtual Apollo Guidance Computer (AGC) software

- Repository: https://github.com/virtualagc/virtualagc
- Website: http://www.ibiblio.org/apollo
- Stars: 3,239 · Forks: 408
- Language: Assembly
- License: NOASSERTION
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/virtualagc-virtualagc

## What virtualagc actually solves, and for whom

The repository exists to make the Apollo Guidance Computer inspectable rather than merely described. Its README frames the goal plainly: given the same software the real AGCs ran and the same input signals, yaAGC "will respond in the same way as the real AGCs did." That is a narrower claim than a flight simulator. Nothing here models aerodynamics or orbital mechanics for its own sake; the target is the computer and its peripherals.

The audience follows from that. Historians of computing who want to read the actual assembly listings, engineers curious about how a 15-bit machine with 2048 words of RAM handled multitasking, and people building hardware replicas that need a DSKY to talk to. The README lists the AGC's numbers without romance: 2048 words of RAM at 15 bits per word (just under 3840 bytes), 36,864 words of read-only memory (69,120 bytes), and a maximum of about 85,000 CPU instructions per second. Anyone expecting a general-purpose retro-computing sandbox will find the scope much tighter and the payoff much more specific.

## Assembler, simulator and peripherals: the shape of the toolchain

The README names the principal tools directly: an assembler that turns AGC source into executable code, a CPU simulator that runs that code, and simulated peripherals such as the DSKY. In the repository those map onto yaYUL for assembly and yaAGC for the AGC simulation, with yaAGS covering the very different Abort Guidance System that lived in the Lunar Module. The Makefile's own build targets are the clearest statement of the split: yaLEMAP, yaAGC, yaAGS, yaYUL, missions, corediffs.

The mission directories are where the data flow starts. Entries such as Luminary099, Luminary131, Colossus249, Comanche055 and Artemis072 hold source transcriptions for specific spacecraft and mission eras, and the README is explicit that the software evolved, so Apollo 17's AGC code differs from Apollo 8's. The missions target assembles those listings; the simulator then executes the result and the DSKY peripheral provides the astronaut-facing interface the real AGC lacked on its own. AGS and Gemini OBC material is present but the README calls the Gemini and Saturn Launch Vehicle Digital Computer material minimal at present, which is worth knowing before planning anything around them.

## Building it: Dockerfile or a local make

The repository ships a Dockerfile that layers on top of an existing image, copies the working tree to /virtualagc, and runs the build targets. The comment in the file notes that it can also clone from GitHub instead of copying the local directory.

```dockerfile
FROM jlawton/virtualagc
MAINTAINER Jim Lawton
RUN mkdir /virtualagc
COPY . /virtualagc
RUN cd virtualagc && make clean
RUN cd virtualagc && make yaLEMAP yaAGC yaAGS yaYUL missions corediffs
```

If you build on the host instead, the Makefile header describes it as the recursive makefile for Linux and similar targets, and notes that a PREFIX can be set for the installation directory. The same target list applies:

```bash
make yaLEMAP yaAGC yaAGS yaYUL missions corediffs
```

Expect a long first build, because the missions target assembles the flight software listings rather than compiling a handful of C files. There is also a CMakeLists.txt and a CMakePresets.json at the top level, so a CMake path exists, but the README does not document it and the Dockerfile does not use it. Treat make as the documented route.

## A first run against a mission's flight software

The README does not give a numbered quickstart, so the honest first step is to build the tools and then look at what the missions target produced. After a successful build, the yaAGC simulator is the entry point, and the DSKY peripheral is what you interact with. The repository's Sim* shell scripts are named in the Makefile's modification log as installable files, which is the closest thing to a documented launcher; the README itself does not walk through invoking them.

```bash
make yaYUL yaAGC missions
ls Luminary099
```

The listing step is not decoration. Because each mission directory holds a different software revision, confirming which one you assembled is the difference between simulating Apollo 11 and simulating a later flight. The README's own point is that the two AGCs on a mission were identical and interchangeable but ran different software, so a Command Module build and a Lunar Module build are not the same artifact even when they came from the same era.

## Where virtualagc is the wrong tool

The project models inner workings, and the README says so explicitly: it does not try to mimic superficial behavioral characteristics. If you want a polished interactive recreation of a lunar landing, with graphics and a forgiving interface, this is not that. You will be assembling 1960s assembly language and driving a DSKY.

The second limitation is the build. The README's own commented-out Travis CI block records that the free open-source build tier went away, so the visible continuous-integration signal is gone. The Dockerfile depends on an external base image, jlawton/virtualagc, which means the container route inherits whatever that image contains. Nothing in the README documents an uninstall, a rollback, or a versioned release channel beyond the single 20221005 release; the Makefile's PREFIX controls where files land, which is the only lever shown for keeping an installation contained. And the non-AGC material is thin: the README calls the Gemini OBC and Launch Vehicle Digital Computer contributions minimal, so a project that needs those should not assume parity with the Apollo tooling.

## Compared with a browser-based AGC emulation

The alternative most people encounter is a JavaScript AGC emulator that runs in a browser tab, which is what the search phrase Moonjs points at. The difference in approach is where the machine lives. A browser emulator reimplements the AGC in a language the browser executes, and typically ships a self-contained page that needs no toolchain; you open it and press DSKY keys.

virtualagc takes the opposite route. It assembles the original transcribed source with yaYUL and executes it in yaAGC, so the artifact you run is derived from the mission listings in directories such as Luminary099 and Colossus249 rather than from a fresh implementation. That buys fidelity to the specific software revision and lets you modify the assembly and reassemble. It costs you a build environment. If your interest is the source code and the assembler, virtualagc is the only one of the two that gives you either; if your interest is showing someone a DSKY on a laptop in under a minute, the browser route wins on setup alone.

## Licence and the cost of staying current

The repository's licence field is NOASSERTION, and the top level carries both COPYING and LICENSE.txt. The Makefile header states that yaAGC is free software under the GNU General Public License, version 2 or later, and reproduces the warranty disclaimer. That covers the emulator code. It does not automatically settle the status of the transcribed Apollo flight software, which came from a different origin; the README describes the repository as containing source-code transcriptions of the original Project Apollo software. Anyone redistributing mission listings should read COPYING and LICENSE.txt rather than assume the GPL header on the Makefile applies to everything in the tree. This is a description of what the files say, not legal advice.

On maintenance: the last push was on 2026-09-19, and the most recent release is 20221005 from 2022-10-05. So the tree is still receiving changes while the tagged release is years behind it. Practically, that means building from master is the normal route, and there is no documented upgrade path from one build to the next beyond rebuilding. Keep your PREFIX choice and your Dockerfile base image noted down, because those are the two things a rebuild will not restore for you.

## Conclusion

Adopt virtualagc if you want to assemble or step through the original Apollo AGC and AGS flight software, or to drive a simulated DSKY from mission source rather than a reimplementation. Do not adopt it if you need a supported binary, a Windows-first install, or a packaged application with a documented uninstall. Before building, confirm that your toolchain satisfies the Makefile targets (yaLEMAP, yaAGC, yaAGS, yaYUL, missions, corediffs), decide whether you are using the Dockerfile or a local make, and check COPYING and LICENSE.txt for the terms that apply to the mission source you intend to redistribute.

## FAQ

### What did the Apollo 11 1201 alarm mean?

The repository does not explain the 1201 alarm, and the README contains no discussion of it. Nothing here describes that program alarm or its cause.

### How powerful was the Apollo 11 computer?

The README gives the AGC's specifications: 2048 words of RAM at 15 bits per word, just under 3840 bytes; 36,864 words of read-only memory, or 69,120 bytes; and a maximum of about 85,000 CPU instructions per second. It also notes the AGC was multi-tasking and was severely underpowered by modern standards.

### Who wrote the software for Apollo 11?

The README attributes the guidance system to MIT's Instrumentation Lab, now the Charles Stark Draper Laboratory. It does not name the individual programmers.

### What was NASA's computing power in 1969?

The README covers only the AGC and AGS, not NASA's computing capacity as a whole. The AGC figures it gives are 3840 bytes of RAM and 69,120 bytes of read-only memory.

## Sources

- [Issues](https://github.com/virtualagc/virtualagc/issues)
- [Project website](http://www.ibiblio.org/apollo)
- [README](https://github.com/virtualagc/virtualagc/blob/master/README.md)
- [Releases](https://github.com/virtualagc/virtualagc/releases)
- [virtualagc/virtualagc on GitHub](https://github.com/virtualagc/virtualagc)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/virtualagc-virtualagc