DOOM — What a Doom Port Proves

The sibling dive on “Bad Apple!!” closes by asking what a successful port of that animation actually demonstrates, and answers, with some severity, that it usually demonstrates less than is claimed. This volume asks the same question of Doom, and is written to be read against that one.

Its conclusion is not the mirror image. A Doom port genuinely does prove more than a Bad Apple port — the difference is real, and volumes one and two set out exactly where it comes from. But the sentence that is usually used to express that difference is wrong in a way that matters, and getting it right requires giving up a slogan that both communities are fond of.

5.1 What is actually being demonstrated

A Doom port demonstrates one or more of four things, and as with the sibling dive they are not equally interesting.

That a general-purpose computer was in there all along. This is what the class B cases of volume three establish, and it is the most common finding in the whole field. The ATM was a Windows XP machine. The ultrasound scanner was a Geode running Windows XP Embedded. The kitchen bump bar booted DOS. None of these is a statement about Doom or about the limits of hardware. Each is a statement about how much ordinary computing is concealed inside objects that present themselves as appliances, and that is a genuinely useful thing to know — about repairability, about security, about what happens to these devices when their software is abandoned. But the capability was never in question, and the work was access rather than engineering.

That a very small machine can host a mutable world. This is the real technical result of the field, and it belongs to the class A microcontroller ports. rp2040-doom puts the nine-level shareware game, music synthesis, sound effects, four-player networking and demo-verified compatibility into 264 kB of RAM and 2 MB of flash. The nRF52840 port holds the full engine with vanilla limits restored in 256 kB. These are not display tricks. They are demonstrations that a 1993 personal computer’s workload fits on a part costing a few dollars, and the techniques that get them there — short pointers, object pools, random-access compression, immutable data executed in place from flash — transfer directly to any other embedded problem.

That arbitrary code execution was achieved. Volume four set this out. In security work the claim is precise and the evidence is the point.

That a mechanism exists where none was intended. Doom inside a PDF is the clearest example: what is being demonstrated is not that a document can display a game but that a document viewer contains a programmable interpreter powerful enough to host one. The firmware payloads make the same kind of point about a privilege layer. These are capability demonstrations wearing a costume, and they are among the most valuable things in the field, because the costume is what makes people look.

5.2 What it does not prove

That the device is fast, or good. The Sansa Clip port executes the engine correctly on the player’s own processor and is, by its own coverage’s assessment, unplayable — the monochrome screen dithered to the point where little beyond the weapon is legible. A successful port is a statement about capacity, not about quality, and the field contains a great many ports that work and are miserable.

That the frame rate is meaningful. CSS-DOS satisfies every structural requirement and runs at roughly two instructions per second, which its own coverage puts at around 0.0001 frames per second and three months to load a level. There is no principled threshold at which “slow” becomes “not running”, and the absence of one is a real limit on the taxonomy rather than an oversight in it.

That the named device did the computing. This is the one that matters, and volumes three and four are largely about it. In class D the device is a display fed by a computer elsewhere. In class C the device’s own processor was removed or bypassed. In class G nothing was computed during the demonstration at all. The headline is identical in every case.

That the object is unmodified. The pregnancy test is the famous instance, but the milder version is everywhere and is not deceptive: the nRF52840 dongle acquired 16 MB of external flash and a separate wireless gamepad; the LEGO brick is a microcontroller in the shape of a brick rather than a brick that computes. Nobody concealed any of this. It simply does not survive summarisation, and summarisation is how the claims travel.

5.3 The line, and where it actually falls

The sibling dive states the distinction in a single sentence: “Getting Doom onto a device proves the device is a computer.” Against a Bad Apple port — which, as that dive says, needs no logic at all, only that a device be made to emit the right pattern at the right time — this is the right contrast, and everything in volumes one and two supports it. Doom needs mutable state, live input, a traversal that depends on where the player is standing, and a clock the simulation can trust. A ROM wired to a display cannot produce that, and no amount of ingenuity will make it.

But the sentence is a claim about devices, and the evidence is always a claim about demonstrations, and the two come apart exactly where this dive has spent its time. Sharpened, it becomes:

A Doom port, correctly classified, proves that some computer held a mutable world and ran a simulation against live input. Which computer that was is a separate question, and the headline is not evidence about it.

That is less quotable and considerably more useful. It preserves the real asymmetry with the sibling phenomenon while accounting for the pregnancy test, the seven-segment wall, the bacteria and the potatoes, none of which the shorter version can survive.

It is also worth being honest that the line is blurrier than either version suggests, and volume three’s strained cases are where it blurs. A softcore CPU synthesised into an FPGA is a computer that did not exist until someone made it. An emulated 486 inside an ATM is the ATM doing more work than a native port, not less. An earbud that computes every frame and streams the picture out of a UART is a stronger demonstration of hardware capability than several ports that comfortably qualify as class A. A biological neural culture playing Freedoom occupies the position of the player, not the processor, and is described by the same four words as an ATM.

The boundary is real. Its edges are genuinely contested, and a taxonomy that pretended otherwise would be a worse instrument.

5.4 Why Doom, and not something else

The sibling dive asks why that particular animation, and finds that its one-bit depth, its large smooth shapes, its recognisability at tiny sizes and its permissive derivative culture combine to make it the one that travelled. Doom’s reasons are different in kind, and there are five.

It is the smallest thing that is unambiguously a computer’s job. A port has to do everything that distinguishes a computer from a playback device: hold state, respond to the unforeseen, decide what is visible, keep time. Almost nothing else of comparable fame requires all four.

It is recognisable instantly. This matters exactly as much as it does for the animation and for the same reason: a demonstration nobody can identify has failed at its actual job. A few frames of Doom’s corridors at 320 × 200 are unmistakable, which is why a photograph works as evidence at all.

It is free, by licence rather than by custom. This is the sharpest difference between the two phenomena. As volume one set out, the engine has been under the GPL since 3 October 1999. That is enforceable and transitive, which is why Doom ports are published as repositories that the next person forks and improves, while the animation’s ports are typically published as videos of a result. The community engines that nearly every port in this dive descends from exist because permission was granted in a form that could be built upon.

It carries its own correctness test. Doom’s demo files record inputs rather than pictures, so replaying one re-derives every frame from the engine. Nothing else in popular computing ships with a published, deterministic regression test that an unrelated porter can run thirty years later to prove their build computes what the original computed — and the Pico port’s author’s account of losing demo compatibility to trigonometric errors of one part in 65,536 shows how sharp an instrument it is.

And the hardware boundary has moved to exactly the right place. Doom was written for machines of the i486 era. The parts that now cost a few dollars — the RP2040, the nRF52840, the CK803 in a walkie-talkie — sit within an order of magnitude of that class of machine in processing terms while having a hundredth of its memory. That is what makes the question interesting rather than trivial or impossible: the answer is usually “yes, but only after real work”, which is the ideal property for a benchmark. Had Doom been written five years earlier it would run on everything and prove nothing; five years later and it would run on nothing small and prove nothing either.

5.5 The arithmetic of the boundary

The last of those five reasons repays being worked out, because it explains why every port in this dive struggled with the same thing.

A microcontroller of the sort these ports target is, in raw processing terms, comfortable against a 1993 desktop. The RP2040 runs two Cortex-M0+ cores overclocked to 270 MHz in its Doom port; the nRF52840 is a 64 MHz Cortex-M4; the TXW818 in the walkie-talkie runs at 240 MHz. Doom’s own recommended hardware was an i486-class machine running at tens of megahertz. On clock speed and instructions per cycle the modern parts are ahead, and the iCE40 port’s author makes precisely this argument about a 25 MHz softcore: many instructions complete in a single cycle that took a 486 several, which is how it compensates for a clock an order of magnitude lower.

Memory is where the comparison inverts, and it inverts violently. A 1993 machine had megabytes; the released source claims six of them for its zone heap at startup without being asked. The RP2040 has 264 kB, the nRF52840 256 kB, the TXW818 272 kB. These parts have roughly a fortieth of what the engine allocates by default, while having more processing power than the machine it was written for.

That single asymmetry explains the shape of the entire field. It is why volume two is mostly about memory and storage rather than about speed; why the techniques that recur — short pointers, object pools, immutable data read in place from flash, compression that supports random access so nothing need be unpacked — are all memory techniques; why the frame rates that get reported cluster at the engine’s own 35 Hz ceiling rather than straining below it; and why the display path, not the processor, turns out to be the binding constraint on the nRF52840.

It also explains why Doom in particular became the test. A program whose computational demands have been comfortably overtaken but whose memory demands have not sits exactly where a benchmark is useful: the answer is reliably “yes, after real work”, and the work is always the same interesting work.

5.6 What the slogan costs

It would be possible to treat the misclassifications of volume four as harmless fun, and mostly they are. Three consequences are worth naming anyway.

The first is that the security convention gets diluted. As volume four set out, running Doom on an embedded device is a precise demonstration of arbitrary code execution, and the precision is the point — it is why the tractor console jailbreak was legible as a right-to-repair argument rather than as a stunt. Every photograph of Doom on a thing that did not execute it makes that evidence slightly weaker, because it trains readers to treat the image as decoration.

The second is that the genuinely remarkable work gets flattened. The bacterial display, the satellite re-deriving a recorded session in orbit, the neural cultures occupying the position of a player — each of these is more interesting than “it runs Doom”, and each is routinely reported with that phrase, which discards the specific thing that was achieved. Volume four’s satellite case is the clearest instance: the accurate description is the impressive one, and it is the one that gets dropped.

The third is simply that it makes the field harder to learn from. The microcontroller ports contain transferable engineering — a documented method for fitting a 1993 workload into a quarter-megabyte — and it is buried under a list of forty devices with no part numbers, no repositories, and no way to tell which of them computed anything.

5.7 Read alongside the other dive

The two phenomena test different things, and the useful summary is short.

A Bad Apple port proves that a device can be made to emit a predetermined pattern on a schedule. That reaches hardware that is not a computer at all — a ROM wired to a display, a breadboard of logic chips with no processor, a font file — and what it proves about each is correspondingly narrow.

A Doom port, when it is what it claims, proves that a device can hold and evolve a state nobody predicted. That reaches a much smaller set of hardware and says much more about each member of it.

The mistake is to treat them as the same test at different difficulties. They are different tests, and the Doom one has a failure mode the other does not: because its claim is stronger, there is more incentive to make it loosely, and more work required to check it. A Bad Apple port that is really a video playing on a screen is barely distinguishable from a Bad Apple port, because playing a video is most of what a Bad Apple port does. A Doom port that is really a video playing on a screen is a different category of object entirely, and the only way to tell is to ask.

5.8 What a harder test would have to ask

It is reasonable to wonder why the benchmark has not moved on, given that the parts in this dive can now exceed the machine Doom was written for on almost every axis except memory. The five budgets of volume two suggest what a successor would have to demand.

It would have to need floating-point arithmetic, which Doom deliberately does not: the engine’s fixed-point integer maths is what makes it portable to parts with no floating-point unit, and what makes its demo files a deterministic regression test across thirty years of different hardware. A test that required floating point would sort machines by a capability many microcontrollers genuinely lack.

It would have to need an operating system underneath it — a filesystem, memory protection, scheduling — rather than running happily on bare metal from a firmware payload. That would move the question from “can this part compute” to “can this part host”, which is a different and now more discriminating thing to ask.

And it would have to need substantially more memory, because memory is the axis on which the modern parts still lose by a factor of forty and therefore the only axis on which the question remains interesting.

What no successor can easily replicate is the rest of Doom’s apparatus: a free licence that lets each porter build on the last one’s work, a published deterministic correctness test, and an image recognisable at a glance from a photograph. Those are accidents of history rather than properties anyone could design for, and they are why a thirty-year-old shareware game is still the instrument even though the hardware question it answers has narrowed to a single dimension.

5.9 The honest summary

Porting Doom to unlikely hardware is a memory-and-storage exercise, an input-plumbing exercise and a timing exercise, wearing the costume of a capability test — and in this case the costume fits better than it does for the sibling phenomenon, because the underlying claim really is about computation.

The best of these projects are serious engineering whose results transfer: a nine-level game with music and multiplayer in 264 kB, an engine in a quarter-megabyte with the original’s limits intact rather than trimmed, a demonstration that a document viewer contains a programmable machine. A second tier consists of finding out that an appliance was a personal computer, which is worth knowing and required no engineering at all. And a third consists of demonstrations that were misdescribed on the way to the reader, where the potatoes were a battery, the bacteria were a screen, and the pregnancy test’s processor was a mask ROM part that could not have run anything.

All three are worth doing, and the people who did them mostly described them accurately. Only the first kind proves what the phrase is taken to mean.