GitHub link

The port running in ScummVM is called glkdoom, which is a Doom port that was compiled to Glulx bytecode and renders using the Glk API. To try out glkdoom, check out the latest release.

The idea for glkdoom was born when I found the glulx-llvm toolchain by Daniel Fremont while searching for obscure architectures to port Doom to. glulx-llvm doesn't actually implement enough of the C standard library for Doom to compile, so I had to first implement some missing functions, like strcasecmp and strrchr. There wasn't really anything stopping those functions from coming with glulx-llvm. They just weren't needed to compile Inform.

Once everything with the stdlib was done, it was time to set up most of the I/O, excluding audio. Doom's framebuffer is drawn to a graphics window pixel by pixel using glk_window_fill_rect, which just so happens to use the same pixel color format as Doom, which sped up rendering a bit (but not that much, see above). Basic timekeeping is done with glk_current_time, and input is done with char events. Because char events are meant for typing and not real-time shooting, held inputs can accumulate across frames. If you want to hold an input down, spam the key instead. Sadly, because Glk wasn't designed with Doom in mind, it runs at about 2 FPS on Glulxe and about 4 FPS with Git.

Now that basic gameplay was done, it was time to add audio. Sadly, the ways Doom and Glk handle audio are completely incompatible. Doom plays sequenced MIDI music and raw PCM audio that it can load from the WAD, and Glk plays audio from hardcoded container formats stored with the work of fiction itself. As a result, I decided to compromise and bundle every single audio track and sound effect from Doom 1 and 2 into the blorb files. And with that final change, glkdoom was complete.

Glulx is fully supported by ScummVM, which of course means that Doom now runs in ScummVM, as shown in the video.

I will post a video later, I'm a 15y/o guy just having fun doing this stuff and self teaching myself programming using AI! :)

Although the amount of people hating on AI, I think it's an incredible tool and can really be helpful if you want to learn stuff, also, the project is available on GitHub if you want to try it!

https://www.github.com/Davitekk/unifi-UDR-doom/

Probably worst graphics of all time, but it runs!

I've had this phone rotting in the drawer for the last decade, I recently flashed Bada back on it and got the idea of making it run Doom since nobody has done it before.

The porting was pretty straightforward, mostly just hooking up doomgeneric and compiling with badaIDE that I found on archive.org.

The original firmware doesn't support sideloading random stuff, so I had to install TurkoCFW which disables the signature checks and exposes the internal partitions over MTP. I couldn't figure out a way to install a new app, so I hijacked one of the built-in ones.

Sources: https://github.com/UDPSendToFailed/BadaDoom

Hey !

I'm a 13y/o self taught programmer/hardware hacker, i recently posted on r/embedded about me creating a C library to manipulate most huawei routers screen, and someone told me "see you on r/itrunsdoom". Well here we are.

Using my library, i quickly patched the program, and also added correct minimal button support (only two buttons beng present, one for pressing enter / shooting and 1 for moving forward).

It was a bit of a challenge, between trying to understand the unhinged nature of 90s C cryptic code, but at the end i made it, and its pretty smooth !!

The source code is right here, and the library is here.
Go check out my profile, ive got other stuff, like my own distr, or serious research and rooting projects for bluray players, and why not follow to show some support ^^ !

Feel free to ask any questions, i'll be happy to answer them !

More info about the process here: https://robco-industries.org/log/entry028

TL;DR: It's a mashup of PicoDoom and stm32doom with some aggressive memory management to squeeze it into 192k RAM

This is a WIP port of Doom for NEC PC-FX: https://youtu.be/EYmpnZv95lM

Here are some of the non exhaustive changes made for it

• Textures have been downgraded to 32x64 for RAM consumption reasons, as well as fitting neatly into a 2 KiB DRAM pages.
• Sky uses the RAINBOW layer (as MJPEG), helping recover some performance (currently it doesn't scroll horizontally, that can be fixed later. RAINBOW does support endless mode)
• VDC sprites are used for Gun/Shotgun/Chaingun/Chainsaw etc... This was done because they would be otherwise drawn half-width and waste further performance.
• VDC is also used for the bottom HUD and sharing its palette with KING (Doom only uses 256 colors at most)
• Sound samples are currently stored as ADPCM on the second KRAM page. Problem is that they have a few issues / small. This is difficult because there is no effective strategy to combat this and we need to test for worst case (including when player progresses forward with all of the weapons).
• Some optimizations from optiDoom, d32r, GBADoom... however its clear that these are not enough at all and d32r showed that it needs to be specific to hardware to be fast.
• Internal resolution is 128x208 and always running in Low details. This is because KING I/O ports are 16 bits wide and KING framebuffer is not memory mapped. Page flipping is done in real hardware and the drawing functions have been modified to take advantage of autoincrementing, among other things.
• No music (CD-DA will be added later)
• Memory usage was a big concern so a similar format to PSXDoom was adopted : A single level binary file contains all of the floors, ceiling, monster sprites etc.. needed for the level. (the only exception are the weapons, LZ4 compressed, always in memory and bundled with executable) This also addresses loading times as they can be loaded into one go into a single shared memory block.
• Lots of v810 inline assembly...

Rendering times are roughly as follows:

• 31.1 ms walls
• 28.7 ms planes
• 7.3 ms sprites

It turns out that Doom is in fact very difficult to run smoothly on that kind of low end hardware (Low end compared to a 486 that is). It's no surprise why 3DO Doom ended up the way it is : the game needs a good CPU. PC-FX is a bit less catastrophic but also has clear disadvantages.

No public release yet as i want to get it running smoothly before i do. I'm confident a 20 FPS is doable and that has been my objective.

The site is very thorough, so I'll refer you all there for full information. Essentially, just click next until you see DOOM, then click it, build the .css file, and play. And, expect 1-2fps in Doom at maximum - but it does run. Honestly, I'll take 2fps: it's a miracle it works at all.

Possibly more impressively, it boots Windows 1.0 too.

All credit to Doom8088 and Lyra Rebane for the original x86 css implementation that proved this is possible, please take a look at the site's credits section for more on both of those.

Github repo link

My team and I recently graduated and wanted to share our Bachelor's thesis turned hobby OS: ALKOS (named after the initials of our 3-person team).

We wrote this with very little prior OS dev experience, so it’s been a massive learning journey for us, and the codebase definitely reflects a fresh perspective and the path we went! We are really passionate about this project and plan to continue working on it now that we've graduated. You can grab an iso/code from here: https://github.com/AlkOS-Dev/AlkOS

We got DOOM running on Neo Geo, and now Genesis.

GitHub: https://github.com/akiyan/genesis-DOOM64KB

Based on the Linux doom port on Id software’s GitHub, it runs at full speed on a 480x320 touchscreen, the specs are a dual core 240MHz CPU and 8MB ram, 16MB flash, runs at native resolution with virtual controls and dpad

Doom64KB is a port of Doom for computers with only 64 KB of RAM but with lots of room for ROM. This is the Neo Geo edition. It now has texture mapped walls:

• GitHub
• Gameplay

It started as a half-joking aside on Discord — "someone should get Doom running on a Prusa" — and I couldn't let it go.

This isn't a browser tab or a Pi taped to the back. It's a standalone firmware running on the printer's own xBuddy board (STM32F427), rendering E1M1 on the printer's display, controlled with the front knob: turn to look, hold to walk forward, tap to shoot and open doors.

The tricky parts were squeezing it into 256 KB of RAM (used GBADoom, the Game Boy Advance port) and trimming the WAD down to a single level so it fits in the 2 MB of flash next to the engine. It packs into a normal .bbf and installs from a USB stick like any firmware update — and it's fully reversible, the stock Prusa firmware flashes right back on with Old Configuration.

Runs at ~7 fps. Not exactly a speedrun machine, but it runs Doom.

Code and a short write-up: https://github.com/NilsN3DP/Prusa-Core-One._But-Can-it-run-Doom

https://www.instagram.com/reel/DZzaHAFOK4G/

Disclaimer:
Yes AI Was Part Of This Project because because I reached a point where I couldn't proceed further with my own knowledge

Source Code in the description of the video/Github

Can XenevaOS run Doom? YES!

Here's a short video of our Custom Hybrid Kernel OS running Doom!
But not just that - we're running it on bare metal on ARM64 architecture (Raspberry Pi 3B+).

Also yes, we're Open Source! Repository & Website in the comments.

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