Before most hobbyist projects can boast running Doom on a refrigerator or a calculator, someone took the lighter, older crown of retrocomputing and proved that Zork — Infocom’s iconic text-adventure series — can be coaxed to run on an Intel 4004-based single-board computer, a feat that blends obsessive hardware tinkering with careful software engineering.
Zork began life on large mainframes and became a defining example of portable game design because Infocom packaged the game logic into a platform-agnostic bytecode called the Z-machine, enabling interpreters to run the same story files across wildly different hardware. This virtual-machine approach is the reason Zork shows up in modern archives, browser players, and now on a 4‑bit microprocessor; the Z-machine isolates game logic from machine details. The Intel 4004 is steeped in computing lore as the first commercially available microprocessor. It is a true 4‑bit CPU with a multiplexed bus, a tiny instruction set, and a maximum clock rate measured in kilohertz — not megahertz. Yet the chip’s historical significance and odd constraints make it a natural target for retro‑engineering challenges. Contemporary coverage and datasheets place the 4004’s launch in 1971 and list core specifications such as a 4‑bit data path, a 12‑bit program-address capability (which, in raw form, maps to roughly 4K of ROM addressability), and a very small native RAM window on the order of a few hundred bytes. Scott Baker (the author of the public repository and SBC work) set out to implement a Z‑machine interpreter for the 4004, and in doing so built both a custom single‑board computer and a substantial set of software tools to translate Z‑machine semantics into 4‑bit machine code. His repository documents the constraints and the hardware expansions he used — namely, banked ROM and RAM far beyond the 4004’s vanilla capacity — to make playing Zork feasible on the platform.
For anyone interested in the intersection of vintage computing and systems engineering, Scott Baker’s repository offers both a blueprint and a challenge: the 4004 is tiny, slow, and awkward — and that’s why it’s interesting. The project is a technical artifact worth studying for the lessons it encodes about portability, minimalism, and the persistence of software through hardware change.
Source: Hackaday Zork Running On 4-Bit Intel Computer
Background
Zork began life on large mainframes and became a defining example of portable game design because Infocom packaged the game logic into a platform-agnostic bytecode called the Z-machine, enabling interpreters to run the same story files across wildly different hardware. This virtual-machine approach is the reason Zork shows up in modern archives, browser players, and now on a 4‑bit microprocessor; the Z-machine isolates game logic from machine details. The Intel 4004 is steeped in computing lore as the first commercially available microprocessor. It is a true 4‑bit CPU with a multiplexed bus, a tiny instruction set, and a maximum clock rate measured in kilohertz — not megahertz. Yet the chip’s historical significance and odd constraints make it a natural target for retro‑engineering challenges. Contemporary coverage and datasheets place the 4004’s launch in 1971 and list core specifications such as a 4‑bit data path, a 12‑bit program-address capability (which, in raw form, maps to roughly 4K of ROM addressability), and a very small native RAM window on the order of a few hundred bytes. Scott Baker (the author of the public repository and SBC work) set out to implement a Z‑machine interpreter for the 4004, and in doing so built both a custom single‑board computer and a substantial set of software tools to translate Z‑machine semantics into 4‑bit machine code. His repository documents the constraints and the hardware expansions he used — namely, banked ROM and RAM far beyond the 4004’s vanilla capacity — to make playing Zork feasible on the platform. Overview: Why this matters to retrocomputing and WindowsForum readers
- It’s a preservation-and-portability demonstration: the Z‑machine’s portability is tested in an extreme environment, reinforcing the value of VM-based preservation.
- It’s a showcase of engineering creativity: engineering around the 4004’s tiny word size, minuscule native RAM, and limited instruction set requires clever software and hardware tricks.
- It’s a teaching moment for systems programmers and firmware engineers: the project shows how to map a modern-ish VM (16‑bit Z‑machine semantics) onto a 4‑bit microarchitecture and how to design memory banking and I/O that make such mapping feasible.
The Intel 4004: constraints and capabilities
Anatomy of a 4‑bit CPU
The Intel 4004 is a landmark device but a brutally small one by modern standards. Key technical characteristics that define the engineering problem here:- Data width: 4 bits per register/ALU operation — everything larger must be composed from multiple nibbles.
- Program-address width: 12 bits multiplexed across the narrow bus — the chip’s integrated architecture intended 4K words of ROM addressing in its stock configuration.
- Native RAM: the raw MCS‑4 family supported a few hundred bytes of directly addressable data RAM via companion chips; the 4004 itself was usually paired with supporting ROM/RAM chips. For practical purposes, native RAM is on the order of a few hundred bytes (commonly recorded as ~640 bytes) while program ROM space is 4 KB without external interfacing chips.
- Clock: sub‑1 MHz operation. Expect instruction‑level throughput measured in tens of thousands of instructions per second at best.
What the 4004 doesn’t give you out of the box
- A byte‑oriented ALU (every multi‑byte operation must be emulated).
- Large contiguous RAM for heap and temporary objects.
- Fast I/O or generous address space without external support chips.
The Z‑machine: the portability layer that made this possible
The Z‑machine is a virtual machine designed specifically for Infocom’s interactive fiction. It was conceived precisely to avoid the need to port Zork’s high‑level logic repeatedly to many platforms; instead, Infocom shipped platform‑specific interpreters that executed a common Z‑bytecode (“story files”). The Z‑machine standard evolved over time, and modern standards and interpreters have formalized the VM’s instructions and storage formats. This portability model is the raison d’être for projects like Scott Baker’s: once you implement the Z‑machine on a platform, you can run any game compiled for that Z‑machine version. Important technical facts about the Z‑machine that affect a 4004 port:- The Z‑machine used by early Infocom titles (including Zork I) expects a VM that is effectively 16‑bit in many internal dimensions (addresses and word-size semantics within the spec), plus a rich set of opcodes and an object tree engine. Mapping those semantics onto a 4‑bit architecture requires either a multi‑nibble software ALU or a larger supporting microcontroller to perform complex operations.
- The Z‑machine standards and the IF Archive host a detailed, formal specification that implementers follow; this makes correctness provable and explains why the project can use existing story files without rewriting them. The IF Archive stores the standards documents and community interpreters.
Scott Baker’s approach: expanding the 4004 into a playable platform
The public repository documents the full approach: a custom single‑board computer (SBC) built around the 4004, firmware written in 4004 assembly, and a set of pre‑processing tools that transform Z‑machine data into a format the 4004 firmware can execute. The README and code show several concrete engineering choices:- Memory expansion: Baker’s SBC extends the vanilla 4004 into a board with hundreds of kilobytes of ROM and RAM (the README references a 256 KB ROM and 512 KB RAM configuration on the custom board), implemented with banked address logic and firmware that can switch or page memory banks at runtime. Without this, the 4004’s native 4 KB ROM and tiny RAM window would be insufficient.
- Assembler and tooling: The repository includes tooling to generate the “blocks” of Zork data and to assemble the 4004 firmware. The developer uses Python scripts and an assembler workflow to convert portions of the Z‑machine data into 4004-friendly data blocks and code modules.
- Software VM mapping: A layer in firmware emulates multi‑nibble/big‑word arithmetic and implements Z‑machine opcodes. The code is arranged into functional modules (parse, read, print, run, stack handling, object manipulation), mirroring traditional Z‑machine interpreter modularity but adapted to 4‑bit primitives. The repository lists separate assembly modules for parsing, stack operations, and printing.
- I/O and interface: The project runs on a Heathkit terminal as the user-facing console. Note: the Hackaday article cites a “Heathkit H9” in its writeup; the classic Heath terminal widely used in hobby circles is the H‑19 (Z‑19) and the public gallery and terminal wikis reference the H‑19 as the standard Heathkit terminal hardware. The repository and development notes suggest Baker used a terminal/serial frontend for input/output, consistent with H‑19 style terminals. This is a small but important detail to reconcile when replicating the setup.
Software engineering: mapping a 16‑bit VM to a 4‑bit CPU
Implementing a VM designed around 16‑bit words on a 4‑bit CPU requires a combination of strategies.Multi‑nibble arithmetic and data structures
- Represent 8‑ and 16‑bit values as sequences of 4‑bit nibbles stored in RAM or ROM.
- Build a small library of multi‑nibble routines: add, subtract, shift, compare, and copy — each callable from the core interpreter.
- Keep frequently accessed values in registers where possible and use banked memory for larger datasets to reduce nibble‑churn.
Memory banking and paging
- Implement a compact banked addressing layer in hardware and firmware to expose more ROM and RAM than the processor can natively address.
- Use small control registers to switch active banks for code, data, and heap at runtime.
- Keep critical interpreter loops mapped into a fixed bank for speed, and swap data banks only when necessary.
Performance tradeoffs
- Expect a playable but slow game: the 4004’s instruction throughput is orders of magnitude slower than the microcomputers Zork originally targeted (e.g., Z80 or 6502 class machines). Playability depends on careful profiling, offloading expensive tasks into ROM tables where possible (bigram tables and print routines are examples), and minimizing bank switches in hot code paths. The repository includes bigram and print optimizations that illustrate these classic interpreter performance techniques.
User experience and practical results
The public demo and screenshots show a working Zork interpreter: input is accepted via a serial/terminal interface and responses print to the terminal. The experience is not a high‑speed graphical reimagining — it’s faithful text adventure playback, with typical Zork pacing. The project’s value is not in the polished UX but in the proof of concept and the engineering lessons it records.Risks, limitations, and caveats
- Not a general‑purpose platform: The SBC and firmware are built specifically to demonstrate the Z‑machine; they are not a general 4004 development environment.
- Performance: Even with optimizations, the 4004 is slow; some Z‑machine operations that are instantaneous on later microprocessors will take perceptible time here.
- Hardware fragility: The 4004 and support chips are historic components; reproducing the setup depends on access to vintage parts, careful soldering, or custom modern replacement modules.
- Documentation gaps: The Hackaday report contains a small, verifiable mismatch (it refers to an H9 terminal), and one must reconcile that with the terminal historically used (H‑19). Always check the primary repository and the author’s blog for the authoritative hardware notes.
Why this is an important preservation and engineering story
- The project underscores the original design wins of the Z‑machine: decoupling content from hardware enables the same game to survive multiple hardware transitions, even into the era of 4‑bit ICs.
- It’s a concrete lesson in minimal architecture design: how much of a VM can you reconstruct with only 4‑bit primitives and banking? The project yields reusable patterns (multi‑nibble arithmetic libraries, banked ROM/RAM layouts, and I/O framing for serial terminals) that are relevant to embedded systems and tiny‑core computing today.
- It contributes to open engineering: the repository, build scripts, and firmware help other enthusiasts reproduce, learn from, or extend the work — a form of digital craft documentation that matters for long‑term software and hardware preservation.
Reproducing or building upon the work — practical checklist
- Review the repository thoroughly: read the README and NOTES and inspect assembly modules for constraints.
- Decide whether to emulate first: run the included emulator to validate the Z‑machine block conversions before burning ROMs or building hardware.
- Gather or substitute hardware:
- If you want authentic hardware, source a 4004 CPU and support chips (the MCS‑4 family).
- Alternatively, build a modern FPGA or microcontroller-based replacement that mimics the banked address logic and serial I/O.
- Implement banked ROM/RAM per the repository’s model (Baker’s SBC uses explicit banked ROM and RAM to provide hundreds of kilobytes to the 4004).
- Assemble and burn the ROM image produced by the project’s Makefile or load it into the emulator for testing.
Wider context: why “Can it run X?” still excites us
Running classic software on novel or minimal hardware has become a cultural and engineering pastime — it’s both a benchmark of technical curiosity and a practical exploration of portability, emulation, and software design. Doom running on improbable platforms is the meme many recall, but Zork on the 4004 is arguably a more revealing exercise: it’s not simply a port of compiled C to a tiny CPU, it’s an exercise in mapping a whole virtual machine into the smallest practical silicon. The results teach us about the tradeoffs between hardware and software abstraction in a way that modern systems designers can respect.Critical takeaways and recommendations
- Strengths
- The project is a clear demonstration that well‑designed virtual machines enable portability into extreme environments. The Z‑machine’s architecture made this possible.
- It documents practical engineering solutions for multi‑nibble arithmetic, banked memory, and tight interpreter loops on constrained hardware.
- The public repository and blog posts allow others to learn and reproduce the build, which is excellent for community preservation and education.
- Risks & caveats
- The project is a proof of concept, not a platform for general computing. Expect slow performance and a brittle hardware environment.
- Hobbyists attempting to reproduce it should be careful about component sourcing, electrical safety (historic voltages can differ), and realistic expectations about the time investment.
- Some outward‑facing writeups (including the Hackaday story) contain small discrepancies that need cross‑checking against the primary repo and documentation (for example the terminal model referenced). Always verify hardware details in the source repository first.
Final thoughts
The exercise of running Zork on a 4‑bit Intel 4004 is a delightful hybrid of computer history, systems engineering, and hacker culture. It demonstrates that thoughtful abstraction — the Z‑machine in this case — can dramatically expand the life and reach of software. It also reminds engineers that constraints often lead to elegant, surprising solutions: memory banking, multi‑nibble arithmetic libraries, and careful assembly-level structuring are all tools that still inform embedded systems design today.For anyone interested in the intersection of vintage computing and systems engineering, Scott Baker’s repository offers both a blueprint and a challenge: the 4004 is tiny, slow, and awkward — and that’s why it’s interesting. The project is a technical artifact worth studying for the lessons it encodes about portability, minimalism, and the persistence of software through hardware change.
Source: Hackaday Zork Running On 4-Bit Intel Computer
