DOOM — Notable Ports, Classified

The sentence “it runs Doom” is asked to carry at least seven different situations, and the aggregated lists that dominate this subject treat them as one. A microcontroller executing the engine from its own flash, a cash machine that was a personal computer all along, a wall of seven-segment digits fed by a Raspberry Pi in the same room, and a panel of bacteria displaying frames computed months earlier all arrive at the same headline.

They are not the same claim, and the difference is decidable. What follows is a taxonomy built from four questions that can be asked of an artefact rather than of a press release, and an attempt to classify the well-known cases against it. Each classification is attached to the evidence it rests on, because a classification without a source is only an assertion.

3.1 The four questions

Does the engine execute on the device’s own processor? Not on a computer attached to it, not on a replacement board fitted inside its case — its own.

Does the device’s own display show the frame? A screen in another room, or a browser window, is a different answer from the panel in the object.

Does live input reach the game? A running simulation that nobody can steer is a different artefact from a game.

Are the frames computed rather than replayed? This is the question the aggregators never ask, and the one that separates the most celebrated cases from the rest.

Seven classes follow. Classes A and B both execute the game honestly and differ only in where the surprise lies. C, D, E, F and G each fail a different question, and failing a question is not a verdict on the work’s quality — two of the most interesting projects in this dive are not class A.

3.2 Class A: native ports

The engine, compiled for the device’s own processor, drawing on the device’s own screen, driven by input from the device’s own controls.

The purest recent example is Doom in a LEGO brick, built by James Brown. Its coverage records an RP2040 microcontroller and a small OLED cast in a silicone mould and set in transparent resin in the shape of a brick, running the RP2040 Doom codebase, with tilt steering from an accelerometer and capacitive touch to fire. A custom library drives the monochrome display fast enough to produce three grey levels. The brick itself is inert plastic and does nothing computational — the object’s shape is the joke, and the computer inside it is doing the entire job.

RP2040 Doom itself, by Graham Sanderson, is the reference work of the field. The author’s own write-up and repository document 264 kB of RAM, 2 MB of flash, dual Cortex-M0+ cores overclocked to 270 MHz, VGA generated directly from the chip at 320 × 200, generally 30–35 frames per second, OPL2 music, ADPCM sound effects, four-player networking over I2C, and a custom WAD container that fits the nine-level shareware game into the flash. Hackaday’s account confirms the scope. It is class A without qualification, and it is also the port against which claims about what small hardware can do should be measured.

The nRF52840 bluetooth dongle port by next-hack is class A with a caveat worth stating. The author’s write-up and repository document 256 kB of RAM, 1 MB of internal flash, a 240 × 240 ST7789 display and 34.5 frames per second on the early levels. The caveat is that the WAD lives on 16 MB of external QSPI flash added for the purpose and the controls come from a separate wireless gamepad. Neither changes the classification — the engine runs on the dongle’s own processor and its own attached display — but it is the first sign that “the device” is a fuzzier object than the headline implies.

The TXW818 video walkie-talkie port by Aaron Christophel is class A on hardware that was never meant to be reprogrammed at all. Its coverage records a CK803 core at 240 MHz with 272 kB of SRAM, 4 MB of PSRAM, 2–4 MB of SPI flash and a 240 × 320 LCD, with the WAD compressed to fit and the radio’s own side buttons — admittedly poor ones — as the controls. Every question answers yes.

The iCE40 FPGA port by Sylvain Munaut is class A by a route that deserves its own note, because the account of it describes a device whose processor did not exist until it was made to. The engine runs on a RISC-V softcore synthesised into the FPGA fabric at 25 MHz, with 8 MB of SPI storage, video out through a PMOD to HDMI, and keystrokes over serial. Whether an FPGA “runs” Doom or merely “becomes something that runs Doom” is a genuine question, but the computation is happening in that chip and nowhere else.

The firmware-level ports are class A in an unusual place on the machine rather than an unusual machine. Two independent implementations put Doom below the operating system on ordinary x86 hardware: a coreboot payload by nic3-14159 that fits in the BIOS flash chip, and a UEFI application by Warfish and Cacodemon345 launched from the firmware shell. The processor is an ordinary one; what is notable is that nothing else is running.

Two class A ports are worth recording precisely because they are bad. The Sansa Clip port, built on the Rockbox firmware’s Rockdoom plugin and covered in 2016, executes correctly on the player’s own processor and is nonetheless unplayable: the monochrome screen is dithered in an attempt to convey the picture and little beyond the weapon can be made out. And Doom in a PDF, by ading2210, compiles the engine through an old Emscripten targeting asm.js and runs it in the JavaScript interpreter that Chromium and Firefox provide to PDF documents, rendering into stacked text fields as ASCII in six colours at 320 × 200, with the author reporting about 80 ms per frame — “pretty poor but playable”. Both satisfy all four questions. Neither is pleasant. The taxonomy is about what is demonstrated, not about whether anyone would want to play it.

3.3 Class B: the computer that was already inside

These devices execute Doom honestly, on their own processors, with their own displays and controls. What makes them famous is not that the hardware turned out to be capable but that the appliance turned out to be a personal computer in a costume. The engineering content is getting in, not getting it working.

The ATM is the canonical case. The 2014 account describes a machine running Windows XP, acquired at a surplus auction by Edward Jones and a collaborator, with the front-panel buttons rewired through an I-PAC2 USB keyboard-emulation board in place of the original button controller. No port was written.

The Mediwatch Bardscan II ultrasound scanner, examined in 2022, is an AMD Geode running Windows XP Embedded from a CompactFlash card; the work was recovering a settings password and editing configuration files. The kitchen bump bar booted straight into DOS and ran the game without modification, slowly.

The John Deere tractor console is the most consequential of the group. Reported from DEF CON in 2022, with the talk itself covered a month later, the researcher known as Sick Codes jailbroke a Linux-based display unit using a pogo-pin adapter and a cron job to keep the filesystem writable, and ran a farming-themed Doom level made by the modder Skelegant. The demonstration was performed on the console module rather than on a tractor in a field. Its significance is a right-to-repair argument about who controls agricultural equipment, and Doom is the proof of arbitrary code execution rather than the point.

The Canon PIXMA printer belongs here for the same reason, and carries a sourcing caveat. Hackaday’s 2014 links column records that the security researcher Michael Jordan demonstrated Doom on a Canon PIXMA to prove a network vulnerability, and quotes the principle plainly: the best way to show a piece of hardware has been compromised is to run Doom on it. The original research write-up was published by Context Information Security and could not be retrieved during this research, so the detail of how the game was loaded and what exactly executed it is reported here only at second hand.

The Husqvarna Automower is the odd member of the class, because the manufacturer did it. The 2024 coverage describes an official release, distributed through Husqvarna’s own app as a software update, played on the mower’s small screen with the control knob to turn, the start button to move and a press of the knob to fire. It executes on the mower and answers all four questions, so it classifies as a genuine port. Several commenters felt an official marketing release was against the spirit of the tradition, which is a fair observation about the culture and no objection at all to the classification.

The graphing calculators sit at the boundary between A and B and are worth a note because they are among the oldest cases. Hackaday’s 2012 account covers a colour upgrade to nDoom for the TI-Nspire, reached through the Ndless jailbreak. The encyclopaedia entry dates the first calculator port to February 2011 via the Omnimaga forums. The engine runs on the calculator’s own ARM processor and draws on its own screen, so this is class A; the reason it feels like class B is that a modern graphing calculator is a competent handheld computer that has been marketed as something humbler.

3.4 Class D: the device is only a display

Here the engine runs on an ordinary computer and the famous object receives finished pixels. The work is real and often considerable, but it is display-driving work, and it establishes nothing about the object’s capacity to compute.

The seven-segment display wall is the clearest instance. Its coverage describes 1,152 seven-segment digits in a 48 × 24 array driven by daisy-chained MAX7219 chips, with a Python script on a Raspberry Pi running the game and sending the frames out. The array is an output device. It is also, incidentally, the closest thing in the Doom world to what the sibling dive’s oscilloscope and character-LCD ports are in the Bad Apple world — and the comparison is exact, because those too are demonstrations that a display can be driven.

The thermal receipt printer is class D with a twist that makes it almost class G. The account of it records that Bringus Studios extracted the computer attached to the printer, fought its operating system between Windows 7 and Linux, and then wrote a script to print a frame of the display at a time, producing what the article calls visible gameplay, with heat problems from the thermal paper. The computation is genuine and happens on the extracted machine; the printer emits frames onto paper. Whether a picture that arrives one sheet at a time constitutes a display is left to the reader.

3.5 Class E: the device computes and shows nobody

The inverse of class D, and rarer. The Pinebuds Pro earbuds port by Arin Sarkisian runs the engine on the earbuds’ own Cortex-M4F, pushed from 100 MHz to 300 MHz, and then — having no screen — compresses each frame as MJPEG and streams it out of the UART at 2.4 megabits per second, up to 18 frames per second at 320 × 200, to a web server elsewhere that renders it and sends keypresses back.

By the four questions this is the strongest possible answer to the first and a flat no to the second. It is a better demonstration of the hardware’s capability than most class A ports, and if the taxonomy ranked impressiveness it would be near the top. It does not, so it sits in its own row — and it is useful precisely because it separates “this chip can compute Doom” from “this object shows Doom”, which the phenomenon otherwise conflates.

3.6 Class F: computed, but not played

OPS-SAT is the case that justifies asking the fourth question separately from the third.

The European Space Agency’s OPS-SAT was an experimental CubeSat launched on 18 December 2019 into a 515-kilometre polar orbit, built explicitly so that outside parties could upload and run their own software on an onboard computer far more capable than a spacecraft normally carries — an Altera Cyclone V with a dual-core ARM Cortex-A9. It re-entered in May 2024.

In its final months, Ólafur Waage’s opssat-doom cross-compiled the engine for the satellite’s ARM32 computer and ran it in orbit. There was no live input: the repository’s approach is to execute recorded .lmp demo files and downlink the resulting frames and telemetry. The project also fed images from the satellite’s own camera into the WAD between runs, so that photographs taken from orbit appeared as scenery.

The classification matters. A demo file is an input recording, not a video, so replaying one requires the entire engine to run and re-derive every frame. The satellite genuinely computed Doom. Nobody played it, because the round trip to orbit makes live input impractical, and the frames came home as files rather than appearing on any screen. Three of the four questions answer yes and one answers no, and the one that answers no is about the player rather than the machine. Aggregated lists describe this as “Doom running on a satellite”, which is true, and as equivalent to the ATM, which it is not.

3.7 The layer the questions deliberately ignore

One thing the four questions do not ask about is what sits between the engine and the silicon, and the omission is deliberate rather than an oversight.

A great many of the cases above are not running a native binary in any strict sense. The ATM was, by its own coverage’s account, most likely running the DOS game under emulation on Windows XP. Doom in a PDF compiles to asm.js and runs inside an interpreter embedded in a document viewer. The iCE40 port executes on a processor that exists only as a configuration of programmable logic. If “native” meant machine code emitted for a fixed CPU and executed directly, several of the field’s best pieces of work would fall out of class A on a technicality.

The position taken here is that emulation and interpretation are a tax on the timing budget rather than a relocation of the computation. What matters is where the work happens. When an ATM emulates a 486 to run Doom, every instruction of that emulation is executed by the ATM’s own processor; the machine is doing the work, and doing rather more of it than a native build would require. The same is true of the PDF, where the browser’s PDF JavaScript engine is the interpreter and the reader’s own computer is the thing labouring. Nothing has been moved somewhere else, which is the distinction the four questions exist to police.

This is also why CSS-DOS is not disqualified by being an emulator — it is disqualified, if at all, by its rate. And it is why the taxonomy declines to rank an interpreted port below a compiled one: the interpretation shows up honestly as a lower frame rate, and the frame rate is already visible.

The line the questions do police is the one between a machine doing slow work and a machine doing no work. An emulator is the former. A panel receiving finished pixels over a wire is the latter, however sophisticated the panel.

3.8 Where the taxonomy strains

Three cases resist it, and saying so is more useful than forcing them.

The Super Nintendo port of 1995 is a reimplementation, not a port of this engine: Randy Linden wrote his own renderer for hardware that could not run id’s. By the four questions it passes everything, but the program executing is not Doom’s engine. The taxonomy classifies artefacts, and here two artefacts share a name.

CSS-DOS fails no question and is still not a port. Ahmed Amer’s 300-megabyte stylesheet simulates an 8086 with 640 kB of RAM and a VGA controller at roughly two instructions per second — an estimated three weeks to boot DOS and three months to load a level, with a frame rate around 0.0001. Every box can be ticked and the claim is still, as its own coverage says, an exaggeration. The honest conclusion is that the taxonomy needs a rate threshold it cannot supply in principle, and that “runs” contains a hidden assumption about human time.

The biological cases invert the relationship entirely. Rats in an automated VR arena move on an omnidirectional treadmill while an ordinary computer runs the game; a fruit-fly connectome is stimulated per frame with its outputs mapped to game controls; Cortical Labs’ human neurons, which the encyclopaedia entry dates to 2026, control Freedoom while a conventional machine renders it. In none of these does the biological material run Doom. It plays Doom — it occupies the position of the human, not of the processor. That is a genuinely remarkable result and a completely different claim, and the phrase “it runs Doom” obscures rather than conveys it.

Two classes remain unexamined: C, where the original hardware was replaced, and G, where nothing was computed at all. Both are occupied by cases far more famous than most of the ports above, and both are volume four.