You’re working with vastly more computing power than what put humans on the moon or powered the first genuine 3D shooter. But the architectural decisions made under extreme constraints in the 1960s and 1990s? They still teach crucial lessons about efficiency and design thinking.
NASA’s Apollo Guidance Computer and id Software’s DOOM engine show what happens when limitations force exceptional decisions. The AGC navigated to the moon with 4KB of RAM and 72KB of storage. DOOM rendered real-time 3D on 386/486 processors without floating-point units.
This case study is part of our broader code archaeology series, where we examine historical systems to extract timeless architectural lessons. Both systems’ source code sits on GitHub. You can examine the actual implementation decisions that made the impossible possible. What’s interesting is how mission-critical aerospace software and commercial gaming share surprising commonalities when constraints drive design.
In this article we’re going to examine specific architectural decisions from each system and extract the patterns that connect them. This is a technical deep-dive into core rope memory, priority scheduling, BSP trees, and fixed-point maths. The lessons transfer directly to modern development.
What were the memory constraints of the Apollo Guidance Computer and how did NASA work around them?
The Apollo Guidance Computer operated with 2K words of RAM using 15-bit words and 36K words of core rope ROM. That’s roughly 4KB of volatile memory and 72KB of read-only storage.
Core rope memory was physically woven into wire cores. Each bit existed as an actual wire threaded through or around a magnetic core. NASA chose this for radiation resistance in the space environment and immunity to data corruption. The trade-off: no patching software after manufacturing. Once those wires were woven, that was it. This eliminated any possibility of fixing bugs after the mission launched, so extensive pre-launch verification was essential.
RAM limitations meant only immediate calculations could be stored in volatile memory. All program code had to live in ROM. NASA’s workaround involved an interpretive language layer that compressed complex navigation calculations into compact bytecode.
Here’s the quirk: reading a value from core memory erased the stored value. Every read required a write-back. This added overhead to every memory access. Just one of those constraints that forces you to think differently about every operation.
The 15-bit word size provided sufficient accuracy for moon landing without unnecessary weight from 16 bits. Every decision was optimised for the constraint that mattered: getting to the moon and back.
Half the architecture diagram was devoted to memory systems. Memory management wasn’t a feature of the architecture. Memory management was the architecture.
Modern embedded systems typically have 256KB+ RAM. But how Apollo’s constraints produced superior architectural decisions – forcing better separation between volatile state and immutable logic – demonstrates the value of limitation as a design forcing function. That pattern shows up today in container architectures and immutable infrastructure. Same principle, different scale, but the fundamental design thinking remains valuable.
How did Apollo AGC implement priority scheduling for real-time tasks?
The AGC’s executive program – its real-time OS kernel – managed tasks using priority scheduling. Each task got a priority level from 0 to 7. Navigation-critical functions always received CPU time. Lower-priority operations could wait.
When the system overloaded, the scheduler suspended lower-priority operations while keeping the functions needed to keep the spacecraft working. During Apollo 11’s landing, the rendezvous radar flooded the AGC with data, triggering the 1202 program alarm.
The alarm meant overload. But priority scheduling ensured landing calculations continued. Flight controllers at Mission Control had trained for this scenario and understood the system’s design well enough to make the call. They decided to continue.
Pre-emptive multitasking on 1960s hardware. Tasks could interrupt lower-priority work. Revolutionary for the era.
The extensive real-time I/O capability with 227 interface circuits required this level of control. The AGC wasn’t just calculating trajectories. It was managing a complex machine in real-time.
Modern real-time operating systems like FreeRTOS and VxWorks trace their lineage to this pioneering work. Priority-based scheduling remains fundamental in embedded systems, real-time applications, and modern task queues. These engineering practices from mission-critical NASA software established standards that modern teams can adapt.
The lesson for you as a software leader: explicit priority assignment prevents the “everything is urgent” problem. When everything is important, nothing is. The AGC forced this decision in the architecture, and modern systems benefit from adopting the same discipline.
How did DOOM’s BSP tree algorithm enable real-time 3D rendering on 1993 hardware?
BSP trees solved DOOM’s visibility problem through clever pre-computation.
Binary Space Partitioning trees recursively subdivide 3D level geometry into a spatial hierarchy. The key insight: pre-compute this during level compilation, not at runtime.
The rendering algorithm traverses the BSP tree from the player’s viewpoint. The tree structure determines which surfaces are visible and in what order based on spatial relationships. No sorting polygons every frame. Visibility order is implicit based on player position.
Level compilation took minutes. Runtime rendering achieved 35+ FPS on 386/486 processors. That was the trade-off.
A depth buffer tracks which pixels are in front and which are behind other objects. Consumer hardware in 1993 didn’t have depth buffers, so DOOM used painter’s algorithm rendering instead: draw back-to-front, and later objects naturally paint over earlier ones. Carmack’s insight: spend time upfront during development to save computation during gameplay.
The trade-offs were real. Level size limitations. Long pre-computation times. No truly dynamic geometry. But the performance gain was orders of magnitude over naive polygon sorting approaches that tried to compute everything at runtime.
Modern game engines use more advanced techniques – octrees, portal rendering, GPU-based culling. But the fundamental principle of spatial data structures persists in all 3D rendering.
The same principle applies today to build-time optimisation, asset compilation pipelines, static site generation, and choosing between static analysis and runtime checks. Move work from the hot path to compilation time whenever possible. Your users care about runtime performance, not build time.
Why did DOOM use fixed-point maths instead of floating-point arithmetic?
BSP trees solved DOOM’s geometry problem. But rendering those geometries required another constraint-driven innovation: fixed-point mathematics.
Intel 386 processors lacked floating-point units entirely. The 486 had an optional FPU, but it wasn’t universally available in the target market. Floating-point emulation in software ran 10-100 times slower than hardware FPU operations.
Real-time rendering at acceptable frame rates was completely impractical with emulated floating-point arithmetic. It just wasn’t going to happen.
Fixed-point maths represents fractional numbers as integers with an implied decimal point. DOOM used 16.16 format: 16 bits for the integer part, 16 bits for the fraction. All calculations used fast integer arithmetic – addition, multiplication, bit shifting – available on every CPU.
The trade-offs: limited range and precision compared to floating-point. Careful overflow and underflow management required. Fixed-point arithmetic demands understanding your data ranges and planning for edge cases.
But it worked brilliantly. Positions, angles, distance calculations – all ran at integer arithmetic speeds with no compromise to gameplay.
Market strategy drove the decision too. Targeting only 486DX or Pentium processors with FPUs would have excluded the massive 386 and 486SX installed base. Carmack’s fixed-point solution enabled DOOM to run on millions more PCs.
This demonstrates how limitations shaped superior architectural decisions – fixed-point arithmetic represented a fundamental understanding of hardware capabilities and working within them. The same approach still applies in embedded systems, DSP programming, and performance-critical mobile code.
How did DOOM’s modular architecture enable the modding community?
Beyond performance, DOOM’s constraints shaped another lasting innovation: its approach to separating engine from content.
WAD files – Where’s All the Data – separated the game engine from content. Levels, textures, sounds, sprites all lived in easily replaceable data files.
The engine code remained proprietary until the later source release. But the WAD format was reverse-engineered quickly and became the modding standard.
Players could create new levels and graphics without modifying the executable. Lower barrier to entry. Bigger community. Simple as that.
The architecture decision came from development constraints. A small team needed to iterate on content without recompiling the engine constantly. Make the separation clean, and artists can work in parallel with programmers.
Unintended consequence: a vibrant modding community extended DOOM’s lifespan by years. Total conversions. New level packs. An entire tools ecosystem emerged. Nobody planned for that, but the architecture made it possible.
Modern parallels are everywhere. Plugin architectures. Content/code separation. API-driven design enabling ecosystems. Game engine marketplaces like Unity Asset Store. Microservices architecture.
Designing for modularity and extension creates opportunities for community and ecosystem growth, even if you don’t plan for it initially.
What common architectural patterns exist between Apollo AGC and DOOM despite different domains?
Both systems achieved elegance because of limitations, not despite them. The constraints drove design decisions that proved more elegant than unconstrained alternatives. These architectural principles that endure across technology eras emerge clearly when examining systems built under extreme pressure.
Constraint as forcing function – both systems achieved elegance through working within their limitations rather than fighting against them.
Pre-computation strategy. Apollo’s core rope memory stored programs at compile-time in immutable form. DOOM’s BSP trees processed levels during build-time. Both moved work from runtime to development time.
Modular separation of concerns. Apollo’s interpretive language layer separated stable execution engine from variable calculations. DOOM’s WAD architecture separated stable engine from variable content. Same pattern, different domains.
Resource prioritisation. Apollo’s priority scheduling explicitly managed CPU time. DOOM’s fixed-point maths managed arithmetic precision. Both systems made scarce resources an explicit part of the design rather than hoping resources would be sufficient.
Error resilience and graceful degradation. Apollo’s alarm system continued critical operations under overload conditions. DOOM ran on slower hardware by reducing rendering detail and frame rates. Defensive design principles in both cases meant the systems degraded gracefully rather than failing catastrophically.
Small, focused teams. Margaret Hamilton’s Apollo software team at MIT and id Software’s core group both benefited from tight coordination. Small teams with clear vision execute faster than large teams with diffuse responsibility.
These patterns remain relevant today in embedded systems, mobile development, cloud cost optimisation, and team structure decisions. The domains change. The patterns persist.
Where can I find the Apollo 11 Guidance Computer source code and DOOM source code?
The Apollo AGC source lives on GitHub in the chrislgarry/Apollo-11 repository. Original assembly code with extensive documentation, annotations, and commentary from contributors who have studied the system.
The DOOM source is in the id-Software/DOOM repository. Official 1997 source release with John Carmack’s original comments preserved throughout the codebase.
VirtualAGC provides an emulator and development tools for experimenting with AGC programming. You can run original Apollo 11 code and experiment with modifications. See how the system operated during missions.
For DOOM, Chocolate Doom provides a faithful source port for modern systems. Fabien Sanglard’s “Game Engine Black Book: DOOM” offers annotated source analysis with detailed architectural explanations.
Both repositories are actively maintained with community contributions, issue discussions, and rich historical context from developers and historians. Hands-on code archaeology reveals architectural patterns and design decisions that documentation alone cannot convey. The choices made under extreme constraint teach lessons that persist across decades.
For more insights from historical systems analysis, explore our complete series on learning from legacy code and extracting timeless design principles.
FAQ Section
What programming languages were used for Apollo AGC and DOOM?
Apollo AGC used assembly language (AGC assembly) and an interpretive language layer for complex calculations. DOOM used C for most engine code with assembly language for performance-critical rendering and maths routines on x86 processors.
Could modern developers learn anything from studying 50+ year old Apollo code?
Absolutely. Apollo code demonstrates formal verification practices, defensive programming under constraints, and real-time system design patterns that remain highly relevant in embedded systems, IoT devices, and mission-critical software development today.
How fast was the Apollo Guidance Computer compared to modern processors?
Apollo AGC operated at approximately 0.043 MHz with roughly 85,000 operations per second. A modern smartphone processor is roughly 100,000 times faster. The AGC navigated to the moon and back with these constraints. Think about that for a moment.
Why didn’t DOOM just require computers with floating-point units?
Market strategy. Targeting only 486DX or Pentium processors with FPUs would have excluded the massive 386 and 486SX installed base. John Carmack’s fixed-point solution enabled DOOM to run on millions more PCs, driving commercial success.
What was Margaret Hamilton’s role in Apollo software development?
Margaret Hamilton led the software engineering team at MIT Instrumentation Laboratory that developed Apollo flight software. She pioneered software engineering practices including rigorous testing, formal specifications, and error detection that became industry standards.
Did the 1202 alarm during Apollo 11 landing almost cause mission abort?
The 1202 alarm indicated computer overload but was non-critical because AGC’s priority scheduling ensured landing calculations continued. Flight controllers had trained for this scenario and correctly decided to continue, demonstrating robust system design.
How large was the DOOM codebase compared to modern game engines?
DOOM’s original engine was approximately 35,000 lines of C code. Modern game engines like Unreal or Unity contain millions of lines. DOOM’s compact codebase reflects both the constraints of 1993 and the focused design of a small expert team.
Can I run Apollo AGC code on modern hardware?
Yes. Use the VirtualAGC emulator which accurately simulates the AGC hardware. You can run original Apollo 11 code and experiment with modifications to understand how the system operated during actual missions. It’s genuinely fascinating to see how it all works.
What modern games still use BSP trees like DOOM?
While modern engines use more advanced techniques like octrees, portal rendering, and GPU-based culling, BSP trees remain relevant in Source engine games like Half-Life and Portal. The fundamental principle of spatial data structures persists in all 3D rendering.
How did id Software’s small team create DOOM so quickly?
Focused team (John Carmack, John Romero, plus artists/designers), clear technical vision, modular architecture enabling parallel work, and willingness to make trade-offs for speed. They completed DOOM in roughly 18 months with under 10 people. That’s what focused execution looks like.
Are Apollo’s software engineering practices overkill for commercial software?
Context-dependent. Full Apollo-level formal verification is expensive for most commercial projects. But practices like comprehensive testing, clear specifications, and defensive programming scale down effectively and remain valuable for any quality-focused development team.
Where can I learn more about constraint-driven design principles?
Study historical systems like Apollo, DOOM, Unix, and early microcomputers. Study modern constrained environments like embedded systems and mobile development. Fabien Sanglard’s technical books, NASA technical reports, and practitioner blogs provide deep dives into specific implementations.
