For decades, one question has haunted hardware hackers, retro gamers, bored engineers, and anyone standing too close to a device with a screen: Can it run DOOM? The 1993 id Software classic has appeared on calculators, printers, pregnancy tests, ATMs, smartwatches, earbuds, receipt printers, and, depending on how philosophical you want to get, possibly your toaster’s deepest dreams. But the more interesting question is not whether some weird gadget can host DOOM. It is whether DOOM itself can become the host.
That is where the wonderfully backwards idea behind “Not Can It Run DOOM, But Can DOOM Run It?” begins. Instead of treating DOOM as software to be squeezed into hostile hardware, makers have started treating DOOM as a world that can perform computation. In other words: what if the demons, doors, switches, hallways, and monster behaviors inside DOOM could act like parts of a machine? What if a level were not just a place to shoot imps, but a kind of crude circuit board with terrible lighting and an alarming number of fireballs?
Why DOOM Became the Universal Tech Test
DOOM is not merely an old first-person shooter. It is one of the load-bearing walls of modern gaming culture. Released in December 1993, it helped define the first-person shooter genre, popularized networked deathmatch, and demonstrated the power of shareware distribution. It also introduced a modular design philosophy that separated the game engine from game data, allowing players and creators to build new levels and modifications. That separation helped make DOOM more than a game; it became a toolkit, a platform, and eventually a meme with a chainsaw.
The reason “DOOM runs on everything” became such a durable challenge is partly technical. The original game was built for early 1990s PCs, which means its requirements are laughably small by modern standards. A machine that seems pitiful today may still have more power than the computers DOOM was originally designed to conquer. Add the later source-code release, decades of community source ports, and a fan base that treats inconvenience as seasoning, and suddenly DOOM is not just portable. It is practically migratory.
Yet there is another reason DOOM became the standard test. It is instantly recognizable. A tiny monochrome corridor may be ugly, slow, and barely interactive, but if an imp shows up, people understand the joke. DOOM is the digital equivalent of a rubber duck in engineering culture: familiar, silly, useful, and somehow always present when a machine needs to prove it has a soul.
From Running DOOM on Things to Running Things in DOOM
The classic challenge asks whether a device can execute DOOM. That challenge has produced masterpieces of technical comedy. Hackers have displayed DOOM on printers. Others have pushed it onto calculators, powered versions through potato batteries, or squeezed it into novelty shells that were never meant to host a demon invasion. Some projects are true ports, some are demonstrations, and some are more like “DOOM-adjacent performance art,” but each one expresses the same impulse: take a system that says “no,” and make it whisper “E1M1.”
“Can DOOM run it?” flips the relationship. Instead of asking whether a machine can run the game, it asks whether the game can behave like a machine. A memorable example came from Danny Spencer, who demonstrated a working adding machine built inside a DOOM level. The design did not rely on DOOM secretly having redstone-like logic, as Minecraft does. Instead, it used ordinary game behaviorsmonster movement, doors, buttons, rooms, and trigger actionsto create logic elements.
At the heart of that idea is the NAND gate, a basic logic operation famous in computer science because NAND gates are functionally complete. In plain English, that means if you have enough NAND gates, patience, and questionable weekend plans, you can build other logic operations and eventually more complex computation. In Spencer’s DOOM experiment, monsters and level mechanics become the moving parts of logic. The result is not a sleek silicon chip; it is more like a haunted warehouse where arithmetic happens because demons are being herded into the right rooms.
Is DOOM Turing Complete?
This is where things get deliciously nerdy. When people hear that computation can happen inside DOOM, they may jump to the phrase “Turing complete.” A Turing-complete system can, in theory, perform any computation that a general-purpose computer can, assuming unlimited time and memory. But the DOOM adding-machine experiment was careful not to claim too much. It showed bounded computation inside a DOOM level, not an infinite universal computer hiding behind a slime-textured wall.
That distinction matters. DOOM levels have size limits. Game behavior has constraints. Monsters are not ideal electrons, no matter how confidently a Baron of Hell walks into a logic gate. Still, the experiment is impressive because it demonstrates that a game not designed for logic automation can still be coaxed into acting like a computational system. DOOM does not need a built-in programming language to become programmable. It just needs rules that can interact predictably enough for a determined human to exploit them.
That is the real magic. Computation does not only live in CPUs. It can appear in marbles rolling through wooden tracks, water flowing through pipes, cellular automata, Minecraft contraptions, spreadsheets, or, apparently, demon traffic management. When rules create repeatable cause and effect, clever people start building machines out of them. DOOM simply adds a soundtrack and a health bar.
The DOOM Engine Was Already a Playground
Long before anyone built arithmetic inside a level, DOOM was designed in a way that invited tinkering. Its engine used binary space partitioning to render fast 3D-like environments on modest hardware. Its WAD files stored maps, graphics, sounds, and other data in a way the community could alter. That structure made it easier for fans to create custom levels and total conversions. In the 1990s, that was not just fun; it was educational. Many future developers learned design, scripting logic, file structures, and performance constraints by poking around in DOOM.
When id Software released the DOOM source code in 1997, it gave the community another gift. The release was not a magic wandthe original game data still required ownership, and the initial code release had its limitationsbut it opened the door to source ports and long-term preservation. Projects inspired by that release have helped DOOM remain playable on modern systems, old systems, strange systems, and systems that would probably prefer not to be involved.
The Weirdest DOOM Projects Teach Real Lessons
1. A Pregnancy Test Is Not Just a Joke
The famous “DOOM on a pregnancy test” project became viral because the phrase itself sounds impossible. In reality, the project involved hardware modification and was not simply a stock drugstore test suddenly becoming a gaming PC. That nuance makes the project more interesting, not less. It reveals how much disposable electronics contain: microcontrollers, displays, sensors, batteries, and tiny pieces of computing power that are usually used once and thrown away. The joke points toward a serious conversation about e-waste and hidden computers in everyday life.
2. A Printer Running DOOM Can Expose Security Problems
When researchers and hackers put DOOM on printers, they are often doing more than showing off. Printers are networked computers with firmware, memory, interfaces, and security weaknesses. A DOOM demonstration can make a boring firmware vulnerability suddenly visible. Nobody at the office wants to read a 40-page report on insecure update mechanisms, but show them a printer playing DOOM and everyone gathers around like the copier has achieved consciousness.
3. Potato-Powered DOOM Explains Constraints Better Than a Lecture
The potato-battery DOOM stunt is ridiculous in the best possible way. It turns electrical constraints into something you can smell from across the room. Producing enough voltage and current from potatoes requires chemistry, wiring, measurement, compromise, and a heroic tolerance for rotten vegetable aroma. The result is funny, but it also demonstrates the difference between running software, powering hardware, and delivering stable current. The potatoes are not merely props; they are a lesson in energy density wearing a brown jacket.
Why “Can DOOM Run It?” Feels Fresh
The reverse question feels fresh because it moves DOOM from object to environment. A device running DOOM proves that hardware can execute familiar software. DOOM running something proves that a designed world can be repurposed into a computational medium. That is a deeper kind of hack. It asks: what are the rules of this universe, and can those rules be persuaded to do math?
This is why the adding-machine project sits in the same family as computers built in Minecraft, cellular automata experiments, and elaborate mechanical calculators. Each one shows that computation is not a brand of laptop. It is a pattern of reliable transformations. Input goes in, rules operate, output comes out. In DOOM, the input might be a switch, the rules might involve monster behavior, and the output might be displayed through an arrangement of rooms or doors. Is it practical? Absolutely not. Is it beautiful? Also absolutely not, but in the way a duct-taped race car is beautiful.
DOOM as Culture, Benchmark, and Punchline
DOOM’s strange afterlife also reveals something about how technology culture measures creativity. Benchmarks are usually sterile: frames per second, memory use, battery life, latency, throughput. DOOM adds personality to the benchmark. If it runs, people smile. If it runs badly, people smile more. If it runs inside itself, the internet briefly becomes a philosophy department with shotguns.
That humor matters. Many technical communities are intimidating from the outside. A playful challenge lowers the barrier. You do not need to understand every detail of firmware hacking to enjoy the absurdity of a printer fighting demons. You do not need a computer science degree to understand that using monsters as logic gates is wildly inefficient and therefore spiritually correct. The joke invites people in, and once they are in, they start learning about architecture, memory, displays, emulation, inputs, power, and code.
What the DOOM Obsession Says About Modern Computing
The “DOOM on everything” tradition also reminds us that computers are everywhere now. Your thermostat, earbuds, car dashboard, kitchen appliances, medical gadgets, and office printer may all contain processors more powerful than early personal computers. The boundary between “computer” and “object” has blurred. DOOM exposes that blur with comic bluntness. If a gadget can display pixels, accept input, and execute code, someone will eventually ask whether it can host a demon outbreak.
The reverse question goes even further. If a virtual space has rules, state changes, and interactions, can it compute? Games are simulations, and simulations can be bent. Players have always used games in unintended ways: speedrunning, modding, glitch hunting, tool-assisted play, custom maps, automation, and emergent design. Building logic inside DOOM is part of that lineage. It treats a game not as a finished product, but as a box of rules waiting to be abused politely.
Specific Examples That Make the Meme Last
Several examples keep the DOOM legend alive. The pregnancy-test project made people rethink disposable electronics. Printer projects highlighted embedded security. Calculator projects proved that constrained screens and low-power devices can still become playgrounds. Potato-power experiments turned electrical engineering into slapstick. Recursive DOOM projectsrunning DOOM inside DOOM or simulating DOOM-like behavior inside another environmentgave the meme a mirror and told it to stare into itself.
Then there is the in-DOOM adding machine. It is not as visually famous as DOOM on a tiny screen, but conceptually it may be one of the richest examples. It shows that DOOM can be more than a passenger. It can become a clumsy, demon-powered engine for computation. That shift from “software being run” to “software doing the running” is the whole punchline of the title.
My Experience With the Question: Not Can It Run DOOM, But Can DOOM Run It?
The first time you encounter a “DOOM runs on everything” project, the reaction is usually laughter. The second reaction is disbelief. The third reaction, if you are unlucky enough to be curious, is a dangerous little thought: How did they do that? That question is where the fun begins. Suddenly, the joke opens into an entire workshop. You start thinking about screens, input methods, memory limits, power supply, firmware, emulation, and whether a device is truly running the game or merely displaying frames produced elsewhere.
That distinction changes how you see every example. A smart fridge running DOOM may be funny, but if the fridge is basically an Android tablet wearing a refrigerator costume, the technical surprise is limited. A calculator running a simplified port is more interesting because constraints become visible. A receipt printer outputting frames on paper is not practical, but it forces you to rethink what “display” even means. A pregnancy-test build is hilarious because the form factor is absurd, but it also makes you wonder why single-use electronics are so capable in the first place. The best DOOM projects are jokes with a second floor.
The “Can DOOM run it?” angle adds another floor above that. It reminds me of the moment in a puzzle game when you realize the level is not just a challenge, but a language. Doors can mean state. Monsters can mean signals. Rooms can mean memory. Switches can mean input. Movement can mean timing. Once you see those pieces as computational parts, DOOM stops being only a shooter and becomes a bizarre laboratory. It is as if the game says, “Fine, you have used me as a benchmark for thirty years. Now watch me become the computer.”
There is also something charmingly human about the inefficiency. Nobody builds an adding machine in DOOM because society lacks calculators. Nobody powers a calculator with potatoes because batteries have vanished. These projects exist because curiosity likes obstacles. A normal person sees a limitation and works around it. A hacker sees a limitation and says, “That looks load-bearing. Let’s poke it.” DOOM survives in this culture because it rewards that attitude. Its age makes it accessible, its code history makes it portable, and its visual identity makes every successful hack instantly legible.
For writers, developers, and tech fans, the lesson is surprisingly useful: constraints create stories. A perfect modern machine running a modern game is expected. A tiny device struggling to render a corridor becomes memorable. A monster-powered logic gate becomes unforgettable because it is absurd, specific, and technically meaningful. That is why “Not Can It Run DOOM, But Can DOOM Run It?” is more than a clever reversal. It captures the spirit of playful engineering: take a familiar system, ask the wrong question on purpose, and discover that the wrong question is where the best ideas were hiding.
Conclusion: DOOM Is Still Teaching Us How to Play With Machines
DOOM endures because it sits at the intersection of history, design, technology, and mischief. It is important enough to be studied, old enough to be accessible, flexible enough to be modified, and funny enough to keep inspiring unnecessary miracles. The original game helped shape first-person shooters, multiplayer gaming, mod culture, and digital distribution. Decades later, it still helps people explain embedded systems, software portability, energy constraints, security research, and computational logic.
So yes, asking “Can it run DOOM?” will always be funny. But asking “Can DOOM run it?” may be even better. It turns a classic game into a machine, a classroom, and a punchline at the same time. Somewhere in a digital hallway, an imp may be walking into a room, closing a door, triggering a state change, and helping perform arithmetic. That is not efficient computing. That is not elegant engineering. But it is wonderfully, gloriously DOOM.
