DOOM — The Ones That Are Not What They Seem

The two most widely repeated facts about this phenomenon are that Doom runs on a pregnancy test and that Doom runs on potatoes. Neither is true, and the manner in which each became untrue is more interesting than the correction.

This volume takes the remaining two classes from volume three’s taxonomy — C, where the original hardware was replaced, and G, where nothing was computed at all — and examines the famous cases that occupy them. It ends with an explicit list of claims this research could not settle, because the honest response to an unverifiable assertion is to say so rather than to soften it into something defensible.

4.1 The pregnancy test

In September 2020 a photograph circulated of a digital pregnancy test displaying Doom, and the coverage was immediate and uniform. The encyclopaedia’s entry on the phenomenon still cites it through a headline — IGN, 7 September 2020, “Programmer Has Made 1993’s Doom Playable on a Pregnancy Test” — which is itself worth pausing on, because the documentary basis for the single most famous case in the field is a headline rather than a description of what was built.

Two days later, Hackaday published a teardown of the same class of device by the same researcher, Foone, and it contains the fact that settles the matter. Inside a digital pregnancy test there is a CR1616 coin cell, a small screen, an arrangement of LEDs and a phototransistor that shines light through the test strip and reads what comes back, and an 8-bit microcontroller to interpret it. And, in the article’s own words, “the micro is the mask ROM version, so [Foone] can’t reprogram it to run Doom.”

That sentence is decisive, and it is worth being precise about why.

A mask ROM microcontroller has its program fixed during fabrication. The code is not written into the part after manufacture, as it is with flash or EEPROM; it is physically encoded in one of the photolithographic masks used to make the chip, in the arrangement of the silicon itself. There is no programming interface because there is nothing to program. No amount of skill, access, equipment or persistence will make a mask ROM part execute software it did not leave the factory with. This is not a difficulty to be overcome. It is a property of the object.

Manufacturers choose mask ROM for exactly the reason it appears here: for a device made in enormous quantities that will run one program once and be thrown away, it is the cheapest possible arrangement. The economics that make a disposable pregnancy test viable are the same economics that make it incapable of running anything.

So what was in the photograph? The Hackaday piece, describing the widely shared demonstration, states that it involved replacing the original hardware rather than reprogramming the existing microcontroller. That places the case squarely in class C: substituted hardware. The artefact retains the pregnancy test’s shell and, on the common account, its display, while the computation happens on a microcontroller that was not there when it was bought.

Here this dive has to record the limit of what it established. The exact substitution — whether the original display was retained and driven by a replacement microcontroller, or whether the display was also replaced, and which part was fitted — could not be confirmed from any primary source retrieved during this research. The original social-media thread in which the work was described could not be retrieved. What is established, and established from the researcher’s own teardown, is the negative claim: the pregnancy test’s own processor did not and could not run Doom. What replaced it is reported here at second hand and should be treated accordingly.

It is worth adding that nothing in this reflects badly on the person who built it. There is no indication that Foone ever claimed the original microcontroller was executing the game, and the teardown that disproves the popular version of the story is hers. The error belongs to the coverage, which took a photograph of a modified object and reported it as a discovery about an unmodified one. That pattern recurs through everything below.

4.2 The potato

The second most repeated claim in the field is the purest example of the same failure, and it is unusually easy to check.

In October 2020 a YouTube user, Equalo, was widely reported to have run Doom on potatoes. The encyclopaedia’s entry describes what actually happened: Doom was run on a graphing calculator that was powered by roughly a hundred pounds of boiled, aging potatoes acting as a battery.

The potatoes were a power source. The computation happened in a TI-84, which is an ordinary and entirely capable target, and which had been running Doom for years before anyone electrified a vegetable. Nothing about the potatoes touched the game. They occupied the position of a wall socket.

The headlines recorded in the encyclopaedia’s own reference list show the myth forming in real time across a single week: “Doom Is Now Playable On Potatoes”, “Here’s Doom Running On A Calculator Powered By Potatoes”, “We Finally Know How Many Potatoes It Takes To Play Doom”, “Here’s Doom running on 100 pounds of moldy potatoes”, “Doom Running On A Calculator Powered By Old Potatoes”. Some of those are accurate and some are not, and they are describing the same video. The accurate ones name the calculator; the inaccurate ones drop it. What propagated afterwards is the shorter sentence, because the shorter sentence is the better story.

This is the mechanism that produces almost every false claim in this subject. Nobody fabricates anything. A demonstration is built and described correctly by the person who built it, and each retelling discards the qualifying clause — powered by, displayed on, streamed to, with the internals replaced — until what remains is “it runs Doom”.

4.3 The bacteria

Class G is the class in which nothing is computed, and the best-known occupant is a display made of living cells.

In 2024 an MIT researcher, Lauren Ramlan, built what the encyclopaedia describes as a 32 × 48 one-bit display using the cell walls of E. coli bacteria, and used it to display Doom. The coverage titles catalogued in the same reference list convey the shape of it accurately enough — “Running ‘Doom’ on E. coli cells… very, very slowly”, “You can play Doom using gut bacteria, but the framerate is atrocious” — and rather less accurately elsewhere: “Here’s a video of Doom running on gut bacteria”.

The bacteria are a display. They are a genuinely remarkable display, and building a addressable one-bit panel out of engineered cells is serious work, but the engine did not execute in the culture and could not. Frames were computed on a computer and then rendered biologically. By the four questions of volume three this answers no to all of them except, arguably, a partial yes on the second, and it is the cleanest example in the entire field of the sibling dive’s phenomenon rather than this one: it is a demonstration that an improbable display can be driven, which is precisely what a Bad Apple port demonstrates and precisely what a Doom port is supposed not to.

The widely quoted figures for how long a single frame took, and for how long a full playthrough would take, could not be verified from a primary source during this research; the project’s own publication was not retrieved, and the secondary accounts that were reachable do not agree in detail. The qualitative claim — that it is far too slow to be played, by many orders of magnitude — is not in dispute anywhere.

4.4 The satellite, described badly

Volume three classified the OPS-SAT project as class F: genuinely computed, genuinely executed on the satellite’s own ARM processor, and not played by anybody, because the frames came from recorded demo files and were downlinked as images.

It appears in aggregated lists beside the ATM as though the two were the same kind of event. They are not, and the interesting thing is that the correction runs in the opposite direction from the others in this volume. The satellite case is usually undersold rather than oversold: describing it as “Doom running on a satellite” is true but conceals the more impressive fact, which is that a spacecraft re-derived every frame of a recorded session from the original engine and the original input stream, in orbit, on a computer that had to be sure it would not compromise the vehicle. The thing worth reporting is exactly the thing that gets dropped.

4.5 The cases this dive could not settle

The following claims are widely repeated and could not be confirmed from a primary artefact during this research. They are listed rather than omitted, because omission would imply they had been checked and rejected, and they have not been.

The MacBook Pro Touch Bar port. The meme entry dates it to November 2016. No repository, author write-up or contemporaneous technical account was located. If it exists as described it would be class D — a host computer rendering to a novelty strip — but that classification is inference from the hardware, not evidence.

The Canon PIXMA write-up. The demonstration by Michael Jordan is recorded in contemporaneous coverage, which names the researcher and the vulnerability. The original Context Information Security publication was not retrievable, so what executed the game and how it was loaded are reported here at second hand only.

The pregnancy test’s substituted hardware. As above: the negative claim is sourced to the researcher’s own teardown; the positive account of what replaced the original is not.

The E. coli frame timings. As above.

The early platform dates. The meme entry gives a Nintendo DS demonstration in August 2006, a fifth-generation iPod in April 2007, and a ZX Spectrum in March 2009. None was traced to a primary artefact here. The Spectrum case in particular could not be resolved as between a port of this engine and an independently written game in a similar style — a distinction that matters, since volume one showed the Super Nintendo version was the latter.

The total number of platforms. There is no registry and cannot be one. The practice is decentralised, much of it is published only as video, and a great deal is never published at all. Any figure for how many devices run Doom is unverifiable, and this dive offers none.

4.6 What counts as “the device”

Class C is defined by the original hardware having been replaced, and stated that baldly it sounds like a bright line. It is not, and the cases that sit near it are mostly honest ones.

Consider what several of volume three’s undisputed class A ports actually involved. The nRF52840 dongle needed 16 MB of external QSPI flash added to hold the converted WAD, a display that the dongle never had, and a separate wireless gamepad to play with. The LEGO brick is a microcontroller and an OLED cast in resin in the shape of a brick — no LEGO element computes anything, and none was modified, because none was used. The receipt printer project extracted the computer that came attached to the printer and reinstalled its operating system twice.

None of these is a deception and none is reported as one. But they show that “the device ran Doom” is doing quiet work in every case, and that the interesting question is not whether anything was added but whether the thing named in the claim is the thing that computed.

By that test the cases separate cleanly. The dongle’s own processor executes the engine; the added flash is storage the engine reads, exactly as a desktop reads a hard disk nobody counts as part of the CPU. The brick’s microcontroller executes the engine; the brick is a shape. The printer’s extracted computer executes the engine; the printer prints, and the claim “a receipt printer runs Doom” is therefore already a little generous even though everything in the account is accurate.

And the pregnancy test fails it, because the part being credited — the microcontroller that reads the test strip — is mask ROM and executed nothing. The distinction is not how much was added. It is whether the named component did the work, and that question has an answer in every case above.

4.7 The one field where the claim is rigorous

There is a context in which “it runs Doom” is used precisely, means something exact, and is almost never wrong, and it is worth setting against the rest of this volume.

In security research, running Doom on a device is a demonstration of arbitrary code execution. Hackaday’s contemporaneous note on the Canon PIXMA work states the convention plainly: the best way to show that a piece of hardware has been compromised is to run Doom on it. The logic is sound and the claim is falsifiable. A researcher who can make an unfamiliar embedded device execute a substantial third-party program of their choosing has proved something specific — that the device will accept and run code it was never meant to run — and a photograph of that program is evidence anyone can evaluate at a glance.

The John Deere console is the clearest case. The point of the demonstration was not that a tractor display can render a first-person shooter, which nobody doubted; it was that a jailbreak had been achieved on equipment the manufacturer controls tightly, which bears directly on a live argument about who may repair farm machinery. Doom is the proof, not the product.

The firmware-level ports make a related point about a layer rather than a device: code running as a coreboot payload or a UEFI application has privileges above any operating system, and a game running there is a memorable way of saying so.

What distinguishes these from the cases earlier in this volume is that the security claim is about execution, which is exactly what the four questions of volume three ask about. The consumer-press claim is about appearance, which is what a photograph shows. The two happen to produce the same image, and only one of them is a statement about the machine.

4.8 How to check one of these claims

The four questions are easy to state and, in practice, answerable from a handful of things that a genuine project almost always provides and a misreported one almost never does.

Look for a repository or a build. Every class A port in volume three publishes source: rp2040-doom, nRF52840Doom, doompdf, opssat-doom. A port that exists as code can be read, and what it targets is not a matter of opinion.

Look for the part number. Genuine write-ups name the processor and its memory, because those were the author’s central problem. The absence of a part number in an enthusiastic account is not proof of anything, but its presence settles most questions immediately — as the pregnancy test’s does, in the opposite direction from the headline.

Ask where the WAD is. Doom needs several megabytes of data it cannot generate. A claimed port on a device with no plausible storage for it, and no account of how the data was compressed or attached, is describing something else.

Ask what the controls are. Volume two treated input as a budget for this reason. Real ports describe their controls, often ruefully — tilt and capacitive touch on the LEGO brick, a knob on the mower, poor side buttons on the walkie-talkie. A demonstration with no account of how anyone plays it is usually a demonstration with nobody playing it.

Prefer the builder’s own words to any coverage of them. In every corrected case in this volume, the person who built the thing described it accurately and the retelling lost a clause.

4.9 Why the errors all run the same way

Every misclassification catalogued here inflates. The potatoes are promoted from battery to computer; the bacteria from display to host; the pregnancy test from container to processor. The satellite, uniquely, is deflated — and it is also the only one of the group whose accurate description is more impressive than the myth, which suggests the mechanism is not a bias toward exaggeration so much as a bias toward the sentence that is easiest to repeat.

There is a structural reason the errors survive. The dominant source on this subject is the aggregated list, and aggregated lists have no mechanism for correction. They are compiled from other lists, they cite headlines rather than artefacts, and nothing in their construction ever revisits an entry. The teardown that disproves the pregnancy-test story was published two days after the story and has been available ever since; it has not displaced anything, because nothing in the transmission chain reads teardowns.

The subreddit that serves as the community’s own clearing house could not be retrieved during this research, so no assessment is offered here of whether its standards are stricter than the press’s. It would be worth someone’s time to find out.

What follows from all of this is not that the field is dishonest. Almost every individual project is described accurately by the person who built it, and several of the builders are the source of the corrections. What the field lacks is any institution that checks, and in its absence the four questions of volume three have to be asked one artefact at a time. Volume five asks what a satisfactory answer to them is actually worth.