Running Doom on the impossible – how one game became the benchmark of absurd hardware experiments

Very few video games have left a technological and cultural footprint as deep as DOOM (1993). id Software’s legendary title did not only redefine the first-person shooter genre, it eventually turned into something far stranger:
a universal engineering joke, challenge, and benchmark summarized in one sentence:

“If it can run Doom, it can run anywhere.”

Over the last three decades, engineers, hackers, researchers, and hobbyists have pushed Doom onto hardware it was never meant to touch. These projects were rarely about playable gaming. They were about technical curiosity, extreme optimization, creative abuse of hardware, and sheer engineering stubbornness.

This article is a comprehensive, technically grounded overview of the most surprising, bizarre, and unexpected pieces of hardware that have successfully run Doom.

Why Doom, of all games?

Doom became the perfect candidate for impossible ports because of several key factors:

  • Open-sourced engine (since 1997)

  • Clean, modular architecture

  • Software-based rendering (no GPU required)

  • Predictable game loop and timing

  • Portable C codebase

  • One of the most active porting communities in software history

These properties made Doom uniquely adaptable to microcontrollers, embedded systems, firmware environments, and devices that were never intended to execute games at all.

Calculators – when math fights back

One of the earliest “how is this even possible?” Doom ports ran on graphing calculators, most famously the TI-83 and TI-84 series.

Hardware

  • Z80 CPU (6–15 MHz)

  • 24–48 KB RAM

  • Monochrome LCD

How it worked

  • Extremely reduced resolution

  • Simplified textures and levels

  • No sound, or heavily approximated audio

  • Button-based movement and aiming

Painfully slow, barely playable, yet technically valid. Doom on calculators proved that even an educational tool could host a real-time 3D game engine—barely.

Smartwatches – Doom on your wrist

Modern smartwatches unexpectedly became a popular Doom target.

Typical platforms

  • Apple Watch

  • Samsung Galaxy Watch

  • Wear OS devices

Limitations

  • Tiny displays

  • Touch or rotating bezel input

  • Severe battery constraints

In most cases, Doom ran with custom UI scaling and often relied on external Bluetooth controllers. Playable? Technically. Comfortable? Absolutely not.

ATMs and banking terminals

Several demos showed Doom running on ATM machines and POS terminals.

Why this works

  • x86 or ARM-based industrial PCs

  • Windows CE or embedded Linux

  • VGA-compatible displays

Why it matters

These ports highlighted how:

  • Many “secure” financial devices are just PCs in disguise

  • Poor system hardening can turn infrastructure into playgrounds

  • Doom often doubles as a security demonstration tool

The pregnancy test – Doom’s most iconic stunt

Perhaps the most famous modern Doom port ran on a digital pregnancy test.

Hardware

  • Tiny microcontroller

  • Segment-based LCD

  • One button

What actually happened

  • Original electronics were replaced

  • The LCD was repurposed for crude pixel output

  • Doom frames replaced the “Yes / No” indicator

This wasn’t a game. It was engineering performance art, and it went viral for good reason.

Printers – Doom you can hold in your hands

Both inkjet and laser printers have been used to “run” Doom.

Implementation

  • Printer CPU computes each frame

  • Every frame is printed on paper

  • One page equals one frame

Completing a single level could consume hundreds of printed pages, turning Doom into a physical artifact.

Refrigerators and household appliances

Smart appliances opened yet another absurd frontier.

Examples

  • Doom running on smart fridge touchscreens

  • Modified firmware on ovens and coffee machines

The lesson

If a device:

  • Runs Linux

  • Has a framebuffer

  • Accepts input

then Doom is never far behind.

Car infotainment systems

Modern vehicles have also fallen victim to Doom.

Platforms

  • Android Automotive

  • Linux-based infotainment systems

  • QNX environments

Controls

  • Touchscreens

  • Steering wheel buttons

  • External controllers

This category edges closer to a “normal” computing environment, yet running Doom in a car still feels fundamentally wrong—and therefore irresistible.

BIOS and UEFI Doom

One of the most technically impressive ports runs Doom before the operating system even loads.

What’s special

  • Runs inside UEFI firmware

  • No OS

  • No graphics stack

  • Direct hardware access

This port demonstrates just how low-level and portable the Doom engine truly is.

Microcontrollers and “potato-tier” hardware

Doom has been ported to:

  • Arduino Due

  • ESP32

  • STM32

  • Raspberry Pi Pico

Constraints

  • Severe RAM limitations

  • Fixed-point math

  • External SPI displays

  • Minimal input methods

These builds are more about proof of render capability than real gameplay.

Oscilloscope Doom – when signals become graphics

One of the most beautiful Doom hacks involved:

  • Converting Doom frames into vector graphics

  • Displaying them in X-Y mode on an oscilloscope

  • Sending image data through audio signals

At this point, Doom becomes electronic art rather than software.

Doom in Excel, PDFs, and DNS

Creativity eventually crossed into the absurd:

  • Doom rendered using Excel cells

  • Frame-by-frame Doom embedded in PDFs

  • Game state reconstructed via DNS queries

Here, Doom stops being a program and becomes a data representation problem.

Medical and industrial systems – Doom where it shouldn’t be

Some of the most unsettling Doom ports appeared on critical systems.

Medical equipment

Documented demos include:

  • Ultrasound machines

  • Patient monitors

  • Infusion pump displays

These systems typically run:

  • Embedded Windows

  • Linux

  • ARM or x86 CPUs

Doom here acts as a security warning, not entertainment.

Industrial control panels

  • PLC-connected HMI screens

  • SCADA terminals

  • Factory control displays

These ports exposed how:

  • Industrial systems remain unpatched for years

  • Physical access often equals total compromise

Aviation and space-adjacent systems

Aircraft systems

  • In-flight entertainment displays

  • Maintenance terminals

Often running:

  • QNX or Linux

  • Deterministic real-time operating systems

Porting Doom here required careful handling of timing and scheduling.

Space simulations

While no public evidence confirms Doom running on an actual satellite, it has appeared on:

  • CubeSat simulators

  • Radiation-hardened ARM development platforms

Cameras, routers, and storage devices

Digital cameras

  • Canon DSLRs with Magic Lantern firmware

  • Compact cameras with ARM CPUs

Routers and modems

  • OpenWRT-based routers

  • Headless Linux devices using serial output

Storage devices

  • HDD controllers

  • SATA bridge firmware

At this point, Doom becomes a reverse-engineering challenge, not a game.

Physical, analog, and artistic Doom

LED walls

  • Thousands of LEDs displaying Doom frames

  • Refresh rate and multiplexing as the real challenge

Relays and motors

  • Mechanical relays clicking out frames

  • Stepper motors forming moving images

Paper, books, and CNC

  • Flipbook Doom

  • Laser-cut Doom frames

  • CNC-milled levels

Doom transforms into a physical medium.

What does “running Doom” even mean?

Within the community, “running Doom” can mean several things:

  • The game logic executes

  • Frames are rendered

  • Frames are visible

  • User input works

  • The game is actually playable

Many extreme ports only satisfy the first two—but still count.

Why Doom, not Quake or Duke Nukem?

The answer is purely technical:

  • Software rendering

  • Deterministic behavior

  • Minimal hardware assumptions

  • Clean engine structure

Doom was written with a level of foresight that makes it uniquely portable.

Doom as an engineering benchmark

Today, Doom serves as:

  • An alternative benchmark

  • A reverse-engineering playground

  • An educational tool

  • A piece of digital folklore

Running Doom on a device often reveals more about the system than any synthetic test.

How far can this go?

Current frontiers include:

  • Ultra-low-power Doom

  • FPGA-only implementations

  • Neuromorphic hardware

  • Quantum simulation (logic-level)

  • Biological computation experiments

The question is no longer where Doom can run, but what we even consider a computer.

Doom has run on calculators, pregnancy tests, medical devices, printers, routers, BIOS firmware, microcontrollers, oscilloscopes, LED walls, and even paper. These projects are not about gaming—they demonstrate the power of good software architecture, human curiosity, and the joy of pushing hardware far beyond its intended purpose. Doom is no longer just a game. It is a philosophy of computing.



Image(s) used in this article are either AI-generated or sourced from royalty-free platforms like Pixabay or Pexels.

Similar Posts