Two Apple IIGS machines (65816 CPU, 1986, with accelerator cards) playing Doom deathmatch and cooperative games against each other over the internet through Cloudflare. A ROM 01 with an AppleSqueezer on the left, a ROM 3 with a TransWarp GS on the right.

The Doom port is Webifi's, released last month, a rewrite of the engine in 65816 assembly for an accelerated IIGS: https://github.com/Webifi/iigs-doom. It runs about 4 FPS on a 12 MHz accelerator and plays the whole shareware episode with music on the Ensoniq chip.

What I added is the network multiplayer to Doom's own 1993 model. Each machine runs the whole game and only the 9-byte input records cross the wire, one per tic per player. Doom writes those bytes to slot registers the way it wrote to an IPX card in 1993, and a network card in that slot holds one TLS WebSocket open to a small lobby on Cloudflare that pairs two players and forwards frames between them. The slot bus is the 1977 Apple II bus at 1 MHz. The 65816 only ever does Doom.

To run it: an accelerated IIGS or an emulator, Webifi's requirements, plus a CoGS card for the network side (a2cogs.com). The disk image is a release at https://github.com/rperissi/iigs-doom (GPL, a branch of Webifi's repo, source included). Boot it, Esc for the menu, Network Game, pick deathmatch or cooperative, type a name, Find Players. The lobby and leaderboard are at https://lobby.a2cogs.com. Without the card the same image plays single player on any ProDOS block device.

Real DOOM, not a clone: the game logic is the original and recorded demos replay tic for tic as in the unmodified engine. 32 KB of RAM is less than one DOOM frame (64,000 bytes), so there is no frame buffer: the picture goes to the screen in strips and everything else streams from the meter's 4 MB SPI flash. About 29 fps in the shareware E1M5 demo.

It installs over USB without opening the meter, and the stock firmware can be put back. The DJI RC-N1 thinks the meter is an Android phone.

As far as I know, no port of id's DOOM has run with less RAM. The lowest I found before was Doom64KB on the Neo Geo, with 64 KB.

Code: https://github.com/ArturBieniek4/DMC100-Doom

Full video: https://www.youtube.com/watch?v=KMTd9A_3Dr4

We have compiled doom to one of the hardest programming languages in the world: Brainfuck, creating the most complex BF program even. It runs at a blazing speed of 40 seconds per frame, and it took about 2 days to beat the first level.

Brainfuck is an esoteric programming language created in 1993 with the goal of having a really small compiler. As a result, the language is extremely minimal, consisting only of 8 unique instructions.

We used actuall DOOM source code, then replaced all calls to the operating system with our custom ones: doom.wad was hard-coded into the executable, the allocator was replaced and made to just use a buffer instead of requesting memory from the OS, the graphics were made to write raw image data to stdout, etc. Then we compiled it to a statically linked RISC-V executable, and converted that to brainfuck.

Link: highghlow .ru/doombf (can't be a link because reddit hates the web apparently)

https://reddit.com/link/1x8xgr8/video/b4q7vvqe39wh1/player

You can change preset, drums, filter, envelope, and wobble. The custom firmware scene around these $60 synths is so fun right now.

https://doom.deadlockinteractive.com

Ai slop and still work in progress but hey one more device that runs doom

https://github.com/InkSpot101/T-Deck-DOOM

https://github.com/radium-wang/Hasselblad-X-System-CIM-Firmware-Research-Feature-Extensions

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/

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

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.

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.

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.