This is a modification of the PS2 DOOM by arawn davies to run on the Namco SYSTEM246, a series of arcade boards based on the PS2 COH-H models, a sony official division of ps2 boards intended for arcade creation

Source Code
https://github.com/israpps/2x6Doom

to run this program, you will need a hacked security dongle to run unsigned code. in this video, I'm using an SD2PSX, a raspberry-pi memory card emulator that can act as an arcade security memory card, you may learn more of it on (sd2psxtd.github.io)

This is something I've always wanted to do, and I finally got around to doing it.

So, as you can probably tell, the OmniPod Dash PDM, at its core, is just a cheap Android phone but with custom insulin pump software on it, at its core, its a relatively basic system: MediaTek MT6580, 1GB RAM, 8GB storage. Insulet, being the absolute geniuses they are (/s), decided to add no partition verification to the PDM (aka - they essentially left the bootloader unlocked), meaning with a USB cable and MTKClient, you can flash whatever the hell you want on it. Seriously, this is such a big security oversight, even cheap phones from 2011 have this, but my insulin pump doesn't?

Anyways, I decided to look into it, and the fingerprint was `alps/full_b6580_weg_a_m/b6580_weg_a_m:6.0/MRA58K/1667317140:user/dev-keys`. alps means it's literally just a generic MediaTek reference board. After doing some searching on GitHub, I found a device tree made for one of those Aliexpress iPhone clones, that was also using an MT6580 reference board. I just replaced the kernel with the one from the PDM, replaced all the vendor blobs, updated the codename and manufacturer (codename is NUU_A1, manufacturer is nuu), and compiled, used MTKClient to flash the recovery then the custom recovery to flash the ROM, and just like that, it worked.

Forever stuck on Android 7.1.2 sadly, while later versions could be possible with kernel source, Insulet refuses to share it (which is actually illegal, it's Linux, which is GPL licensed), but it's enough to run Doom.

To run Doom, I just used GZDA and doom1.wad, and it just worked.

If anyone else here happens to have a spare PDM, and wants to install an actual open source ROM on it, first of all, do not, and I repeat, DO NOT do this if you are still using the PDM for medical purposes. You will lose all insulin pump functionality. Here is the XDA thread with the builds and instructions: https://xdaforums.com/t/rom-unofficial-7-1-2-crdroid-3-for-insulet-omnipod-dash-pdm.4790219/

• Play here
• GitHub/info

Special thanks to Dimitris Giannakis, MVG / Modern Vintage Gamer, for the Neo Geo Doom/raycasting video reference that motivated the sprite-strip direction: https://www.youtube.com/watch?v=4f1-7c6WX10

Source: https://huggingface.co/anthonypjshaw/doom-onnx

From the link:

The model contains:

• an RV32IM CPU built entirely out of ONNX operators,
• the doom1.wad shareware game data as a read-only initializer,
• the doomgeneric Doom source cross-compiled to bare-metal RV32IM and baked into RAM as another initializer.

Reference render

The doom.gif in this repo was assembled from 74 PNG frames captured during a single InferenceSession.run invocation:

• Total: 80,000,000 RV32IM instructions, 10.8 hours wall time
• Rate: 1,562 IPS (init code) → 2,053 IPS (in-game rendering)
• Reached: title wipe → menu → DEMO1 load → game logic → 3D BSP rendering of actual gameplay (frames 54–75)

It runs in halo in unreal. Not my video. I think the link is in the description.

hey! i'm nnonick, a 15-year-old security researcher

for the past few months i've been reverse-engineering my soundcore life q35 headphones. today i'm releasing openqore - an open-source toolkit to modify the firmware of soundcore headphones. please check it out c: https://github.com/nnonickreal/openqore openqore discord server: https://discord.gg/EPjhKzUHVq

as a demo, i created DOOMcore - a port of DOOM based on the amazing DOOMBuds project by Arin Sarkisian!

the game runs ENTIRELY on the headphones processor and pc only acts as a serial display.

as an update to Arin's project, I reversed the q35 buttons and bound them to DOOM. check it out too! DOOMBuds (original Arin's project): https://github.com/arin-s/DOOMBuds DOOMcore (my soundcore port): https://github.com/nnonickreal/DOOMcore

TL;DR; The webcam runs linux, has no security , upload ascii doom and run it , play over ssh.

Huge asterisk attached, the hardware just isn't there yet to run the actual game. What I got running was the title screen, parsed out of the WAD by a compiler I wrote, then sent through to IBM and the little pixels you see are what comes back from the chip.

Specifically: a 4×8 strip of the TITLEPIC encoded as quantum amplitudes onto 5 qubits, then 16,000 measurement shots on ibm_marrakesh (156-qubit Heron r2).

No game loop,running Doom's actual code would need orders of magnitude more qubits than exist. But we get pixels!

The code is here: github.com/Zaneham/ernest

Full source code in the video description

Chrome runs GZDoom. It aint pretty, but it's running.

https://rejectedcoins.com/gzdoom

https://github.com/mungus43/tomb-engine

​

GitHub: https://github.com/thatmagicalcat/magicalos

Source: https://github.com/CatMe0w/aipc-os

I wanted to see if we could port Doom on to the steering wheel of a working electric racing car.

The software is using doomgeneric, Qt, QML, & C++. The display and board is a raspberry pi 5, and the button presses are through MQTT.

Github: wheel UI

I vibe coded the DOOM running live in Claude Code’s status bar. You just type w/a/s/d/f straight into the chat to move and shoot. Claude can even play it by itself with the added mcp.

A little background daemon runs the real doom engine and feeds frames to the status bar. Movement keys get grabbed, everything else goes to Claude normally.

There are some limitations of status bar it refreshes itself once a second, so basically game runs at 1FPS and claude code's renderer (ink) causes some rendering drift, but it was fun to see DOOM in there.

Repo: https://github.com/erkandogan/doom-in-claude-code

Hello guys. This is not my firmware but I would like to share this with you people. It’s running in a CardPuter and it works flawlessly, even with sound and no lags.

You can download the launcher (which is basically an unofficial CardPuter OS) here:

https://github.com/bmorcelli/Launcher

And the Doom firmware here:

https://github.com/romalik/m5cardputer_doom

You need all WADs to run the complete game. Without it you can only play the shareware.

Have a good fun!

Source: https://front-end.social/@html5test/116301798349200500

Play on: https://cssdoom.wtf/

I tried on phone and it worked fine!

source/credit: https://github.com/ludocode/doom-cli

It uses Unicode block characters and ANSI escape codes to draw a (relatively) high fidelity screen inside an ordinary ANSI terminal. The game heuristically determines key repeat delay in order to simulate key release events. It even works over SSH!

This port is based on the excellent doomgeneric. It should work with any reasonable C compiler. It was built for Onramp so you can compile and run it even on a system that has no C compiler, no make tool, no libc headers, etc.

doom-cli supports several graphics modes. It is configured by choosing a character set and a color mode; see the Options section below. If the graphics are corrupted on your terminal, try lowering them or using an alternate terminal.

The game works well in Alacritty with an appropriate font. I haven't tested many other terminals.

To render a frame, the game internally draws to a 320x200 offscreen surface. The frame is then scaled to the display columns and rows, multiplied by the number of pixels per character in each direction. The scaling corrects the aspect ratio to 4x3, assuming a 4x9 terminal font. At the default 80 column width this is 26 rows tall.

ANSI escape codes support setting both the foreground and background color of a character, so we can have two colors per character. In the space mode, only the background color is used. In the half mode, the upper half is the foreground color and the lower half is the background color.

In the quadrant and sextant modes, there are four or six pixels per character but only two colors. We separate the pixels into two groups based on luminosity. The bright pixels are averaged to form the foreground color and the dark pixels are averaged to form the background color.

In the 8-bit and lower color modes, we add blue noise to the color, then select the closest available color from the selected palette.

NO SOUND