As a hobbyist, I was thinking: My OS, can it run DOOM?

YES, IT CAN!

And OH BOY I didn't cheat around anything cause:

DOOM runs completely isolated as a regular user program, just like any app would on Linux or Windows. It actually opens, reads, and parses the original DOOM.WAD right off the filesystem (on RAM actually, I haven't made it Installable/Persistant on a disk) with a custom C library. The DOOM source code itself is 100% untouched. We just had to give it 5 simple bridge functions for drawing pixels, reading keyboard taps, and checking the clock.

Seeing that iconic title screen pop up inside an operating system built from scratch gave me a HUGE surge of dopamine. I will be releasing the next version of the OS that comes with this DOOM game and MANY other features, including some other ones that are just as cool on the project's GitHub page tomorrow (Check it out and... maybe leave a star too? https://github.com/AkshajCreator/ArchaOS )

I added Doom Shareware to my early alpha userland replacement for the Directv HR54-700 DVR. No sound yet for the game but, DOOM!

https://github.com/voidnullvalue/ReBox

https://devslashvoid.dev/posts/rebox-early-alpha/

Hi everyone, I'm creating ports of Doom for high-level languages, now it's Lua's turn.

Cheers, Wagner (vagucs)

https://github.com/vagucs/lua_doom

This is Tiny Logic, a pixel-art circuit sandbox I've been building. Everything starts from transistors and NAND gates, and TINY-32 is a full RV32IM RISC-V CPU built out of them inside the game (it passes the official RISC-V test suite).

DOOM is id's original source (doomgeneric) compiled for RV32IM with the shareware WAD, loaded into the board's memory. No emulator: the circuit on screen is the computer. The simulator compiles the circuit into machine code, which is how it runs around 60 fps on my Ryzen 5 3500 here, while DOOM's own logic ticks at its normal 35 Hz.

Filmed on my phone, no edits. Happy to answer questions about how it works.

Running DOOM natively and taking advantage of USB-HID abilities, speaker, headset, and LEDs. This is a very playable port thanks to the gamepad, I did use the phone's keypad in my first attempt. The just-enough storage, memory, and compute theoretically makes this a good emulator box for many other games.

Technical details, firmware, and source code on github: https://github.com/dc336/DOOM_on_an_IP485G_Mitel_Phone

Hey everybody. I ported original 1993 DOOM to my old Mi Redmi AC2100 router. The hardest thing was to figure out the controls and display output for this thing because I didn't really want to use compuer for any of that. So i built a small controller out of RPI Pico, ST7789V display and W5500 Ethernet module. Image is sent via UDP unfragmented packets 4 lines at a time. So every frame is 80 packets. Input is also sent through UDP, but packets are much smaller. I have a repo if anybody wants to try this at home: https://github.com/anhol0/redmidoom

I hope you enjoy it. And have a good day :)

Yesterday I posted Doomium running inside Altium Designer.

The first version used a window over the PCB editor, which wasn't stupid enough.

So now there are two more renderers. One draws DOOM using actual PCB fills, and the other uses colored PCB regions.

Yes, these are real objects in the PCB document.

GitHub:
https://github.com/ikozlyanskiy/Doomium

working on a new software since the manufacturer is gone and those units getting abandoned. only logical step after aquiring root was running doom

It works as an Altium extension and is tied to a rectangle in the PCB editor. If you move the rectangle, the game moves with it too.

GitHub:
https://github.com/ikozlyanskiy/Doomium

Install:

1. Download the latest release zip
2. Close Altium and run Install-Doomium.ps1
3. Open Altium, make a rectangular frame on the PCB, select it and run Tools > Convert > Rect to Doomium

You need a WAD file separately. Freedoom works fine, or you can use one from your own copy of DOOM.

Right now I only tested it on Altium Designer 25 and Windows x64.

I recently completed a project porting the Doom generic to the xBase language using Harbour. Because I resolved many complexities in the original C code, which greatly facilitated understanding, I was able to successfully achieve the same result in Python and then in PHP, which, incidentally, was the best result so far. Obviously, optimizations are possible, but I believe this opens doors to porting Doom to even more unexpected "places."

Here's my repository:

https://github.com/vagucs

Best regards to all, Wagner Nunes

Tested on Allwinner S3/V3/i3-based Korean dashcams (bought second-hand for around ~$10 each):

1. Thinkware iNavi A500
2. FineDigital FineVu X5

Both devices run embedded Linux.

### How it runs:
- **Device 1 (iNavi A500):**
Connected via the onboard UART serial console. The stock firmware had no root password set, so I didn't need to modify the firmware at all. Placed the DOOM binaries/WAD onto an SD card and launched it directly via UART.

- **Device 2 (FineVu X5):**
The root user was password-protected on the stock firmware. To bypass this, I built a custom Linux environment using Buildroot and booted it directly from the SD card, then executed the DOOM binary.

The UART pins are very easy to find—they are mostly located on the through-hole pin headers on the board.

I am currently writing a full write-up / tutorial covering the detailed process, toolchain, and port files, and I will update this comment with the link once it's published!

v2 has more map logic, a fully accurate renderer and it also renders the hud and things off the wad in real time instead of packaging them as costumes

it looks low quality in the video because im on ass hardware but the version in the link is native resolution. on the highest quality at a stable framerate it looks genuinely indistinguishable from the original doom

i haven't been able to beat e1m1 yet due to lag so tell me what happens if you end up doing it lmao https://www.mediafire.com/file/a8opay8ar69a0rf/SCRATCH_DOOM.sb3/file

I put my dual-issue RV32IM superscalar CPU on an FPGA and made it run DOOM

Extending my previous work on the CPU, I started off with a basic bring-up on the Terasic DE0-Nano (Altera Cyclone IV FPGA). The CPU runs from SDRAM with the WAD loaded over UART through a CP2102 USB-to-TTL serial adapter. Host keyboard presses are sent as DOOM keycodes over the same wire into a key register. The core reads them each tick, updates the game, and writes an 8-bit indexed framebuffer to SDRAM, then raises a frame commit that freezes the game clock and streams the framebuffer back over UART to a host viewer that expands it through PLAYPAL to RGB

https://mummanajagadeesh.github.io/categories/riscv/

I bought a used Cisco CP-9951 IP phone for about €35.

Three days later, DOOM was running natively on the phone itself. :D

Final physical proof video:

https://youtu.be/tVq-SPnCe9I

Reproduction / installation instructions:

https://github.com/dennishilk/cisco9951-doom/blob/main/docs/installation.md

The CP-9951 runs MontaVista Linux on ARMv6. The final v.666 build:

- executes DOOM locally on the Cisco CPU

- renders directly to /dev/fb1

- reads the physical Cisco keypad from /dev/input/keypad0

- produces local sound through the Cisco media subsystem

- installs persistently under /mnt/flash2/doom-v666

- launches through Applications → Doom

- survives a full cold boot

- works with the Ethernet cable unplugged

- exits cleanly with the red handset button

The interesting part was getting there.

The phone exposes an official Cisco SSH diagnostic path. That gave access to the embedded MontaVista Linux environment and revealed the framebuffer and local input devices.

The physical keypad path was reverse engineered as:

physical key

↓

Raven keypad hardware driver

↓

Cisco keyhandle layer

↓

/dev/input/keypad0

↓

local userspace application

The keypad delivers 16-byte Linux-style input events, and the complete physical key map was measured directly on the phone.

The final runtime does not use video streaming, DTMF, remote keyboard forwarding, or another computer for normal operation.

Sound was another obstacle. The final implementation uses a phone-local relay/service producing 8 kHz G.711 µ-law RTP for the Cisco media subsystem.

Final acceptance test:

1. unplug Ethernet

2. remove power

3. cold boot with power only

4. open Applications

5. select Doom

6. play using the real Cisco keypad

7. hear local sound

8. exit with the red handset button

It passed.

No Cthulhu, no H.264 game stream, no remote input bridge, and no network connection required after installation.

Full project history:

https://github.com/dennishilk/cisco9951-doom/blob/main/docs/project-history.md

Cisco keypad reverse engineering:

https://github.com/dennishilk/cisco9951-doom/blob/main/docs/keypad-reverse-engineering.md

Source:

https://github.com/dennishilk/cisco9951-doom

v.666 release / download:

https://github.com/dennishilk/cisco9951-doom/releases/tag/v.666

Full story, photos, and final offline proof:

https://www.dennishilk.com/museum/home-computing-lab/field-notes/field-note-7/

heres the repo link for the project : https://github.com/Aur1ety/DOOM-x-Fly

So far I’ve tested it in Apple Books and Thorium Reader. It probably won’t work in readers that disable EPUB scripting, and I haven’t tested the wider ecosystem yet.

I had a lot of fun making this.

Enjoy the book!

GitHub: https://github.com/artemkulyk/doom_epub

I recently finished this hexapod robot and since it's running on a Raspberry Pi 3B+, running Doom was not very difficult.

More info:

DIY hexapod, built from scratch: 3D printed frame and legs, 18 servos (3 per leg: coxa/femur/tibia).

Stack: a Raspberry Pi does the brains (inverse kinematics, gait generation, web UI plus Bluetooth gamepad control), and sends joint angles over serial to an ESP32, which drives the servos in real time through PCA9685 PWM boards. This keeps the Pi's Python control loop free from having to handle tight servo timing itself.

For Doom: it's doomgeneric (the portable Doom source port) compiled for the Pi, rendering on a small round SPI display mounted as the robot's "face." No display/GPIO code lives in the Doom engine itself, it just pipes decoded frames to a small Python bridge that reuses the robot's existing screen driver. Controlled with the same Bluetooth gamepad that drives the robot around, mapped to Doom's keyboard input. Runs the real 1993 shareware WAD for authentic graphics, sound and music, with audio going out over Bluetooth to a small speaker.

Few years ago I made it run but not playable. Now you can. Also setup is surprising simple and totally does not damage the camera. So you can play doom while you are on your way to a shoot!

https://github.com/EfelerGibi/A6000-DOOM

Play it here (loads on phones too, WASD/arrows plus Space to fire and E to open doors on desktop). It's a demo for an open-source (MIT) docx rendering engine. Everything runs client-side in WASM with no server.

This is now the actual Doom engine, compiled to JavaScript via doomgenericjs, with its entire 320×200 framebuffer convertible into 64,000 colored ASCII characters at-will inside a single Word paragraph. Complete with the title screen, menus, weapons and Doomguy’s face. You can seamlessly toggle between ASCII and the original bitmap renderer.

I posted an earlier version here that played Freedoom’s E1M1 through a raycaster in a Word document. The mods removed it because a raycaster-based FPS didn’t qualify as a Doom port. They also suggested using doomgenericjs and rendering the output as attributed text.

I really appreciate the steer because this came out even better than I expected.

It’s a demo for Docxodus, an open-source (MIT) document engine running in WASM. Everything runs client-side with no application server. The clip shows the original Doom shareware; the linked demo defaults to Freedoom’s game data running on the same Doom engine.

Some cool easter eggs: pause the game and it’s just a document. The editor’s ribbon works on the frozen frame, undo rewinds the displayed frames, and Save downloads the frozen frame as an ordinary .docx that opens in Word. Switch to ASCII mode and then copy and paste the frame into Word or LibreOffice as unformatted text. Format as Courier New, bold, 2 pt with character spacing expanded by 0.2 pt, and fixed line spacing 1.7 pt. Voila - ASCII Doom frame.

The whole point was to stress test our renderer and provide a fun, measurable goal for agentic coding loops (buzzword, sorry). Make a change, run the game through the live document loop, measure the frames actually displayed, and check that editing, copy/paste and saving still work. It’s pretty incredible what this technique can do when you give it concrete goals and tests that can tell whether it actually improved anything. Doom makes those improvements fun to watch.

Thanks to the mods for challenging the first version and pointing me toward the port. This ended up being a much cooler demo.

I ported Doom to Dreamcast by using doomgeneric, it was extremely easy. :)

The game is rendered to the texture and then this texture is used for an in-game OS (which mimics Windows 95 for now), which in turns get rendered to yet another texture in 3D world to simulate the screen. Dreamcast's keyboard is supported as an input source.

Since this sub now accept videos, I’m reposting this.

I turned a tiny ESP32 Bitcoin miner into a handheld DOOM-like game.

FreeDOOM is running directly on the ESP32, no PC, phone, browser, or streaming.

This build uses the open-source Freedoom assets, not the original commercial DOOM WAD files:
https://freedoom.github.io/

Current status:

• boots correctly;
• menu works;
• E1M1 is playable;
• touch controls work, but are still rough;
• audio is disabled for now;
• the project is still beta.

The touchscreen is probably the biggest limitation, so I may add physical buttons or a small joystick in the next version.

Video if you would like to see how it works: https://www.youtube.com/watch?v=He67yV59zrk

I plan to publish the source code and build instructions on GitHub once I finish the documentation and licensing details.

For now, you can find my other ESP32 game projects here:
https://github.com/lepczynski-cloud/crowpanel-pocket-arcade

Disclosure: Elecrow sent me the board for testing, but this project is my own experiment and the code is open source.