The Neo Geo Does Run DOOM After All

July 14, 2026 by Maya Posch 15 Comments

Demonstration of the DoomGeo port of Doom to the Neo Geo. (Credit: Sabino, GitHub)

Perhaps the most ridiculous statement that anyone can make is that a computer system with clearly enough processing power ‘cannot run DOOM‘. This is why we accept the premise that a PDP-11 cannot run this game, but something on the order of a Neo Geo gaming console with its 68000 processor and for the time impressive GPU definitely ought to be able to.

The stated problem here is a lack of RAM for a framebuffer, with the CPU only having 64 kB to play with. This limitation now has seen two different approaches to try and circumvent it, as covered by [Modern Vintage Gamer].

The first project here is Doom64kB, which as the name suggests tries to somehow work with this system RAM limitation. It uses the Doom8088 port for the original IBM PC and similar Intel 8088-based systems. This had to massively reduce the feature list, including the lack of texture mapping for floors and ceiling, no saving or loading, and no music.

The other project is DoomGeo, which doesn’t try to bend the Neo Geo hardware to its will, but accepts the Neo Geo way of doing things: involving sprite strips, pre-baked graphics, fix-layer UI, and a minimum of runtime data. This of course drastically changes how the Doom game engine normally works, with its framebuffer-based rendering.

From this we can thus conclude that it’s not so much the processing power that limits where DOOM can run, but more of how framebuffer-friendly the system architecture is, yet with some ingenuity and a complete rewrite of the game engine even that is no major obstacle.

(Top image: Neo Geo AES console. Credit: Evan-Amos, Wikimedia)

Continue reading “The Neo Geo Does Run DOOM After All” →

Porting DOOM To The Casio Loopy

July 11, 2026 by Maya Posch 8 Comments

Targeted towards refined female gamers unlike the savagery of the mainstream game consoles of the era, 1995’s Casio Loopy was a bit of an oddity of a game console. Despite being standard enough in its design and backed by the might of Casio, it saw only one year of active software development and hardware manufacturing ceased by the end of 1998. With only eleven titles released for the system, with none of them being Doom, this obviously terribly upset [Throaty Mumbo], who set out to right this egregious wrong.

For the two dozen people or so who have one of these systems, you can experience the fruits of his labor yourself via the GitHub repository and something like the FloopyDrive cartridge.. Despite the quite capable Hitachi SH-1 16 MHz CPU and 1 MB of RAM, the main limitation is probably the original 2 MB of ROM space that does not leave a lot of space for DOOM WADs, even after doubling it on the FloopyDrive. Correspondingly you only get a handful of levels out of it.

Overall game performance isn’t too bad, though in the port’s current unoptimized state the resolution is fairly low. That said, even the console’s built-in printer is supported and demonstrated in the video, which is a pretty nice touch. It’s not like Sega or Nintendo consoles allowed you to screenshot those glorious headshots.

Continue reading “Porting DOOM To The Casio Loopy” →

Hacking The Mi Band 10 Smart Band And Its Bestechnic SoC

June 21, 2026 by Maya Posch 11 Comments

In between playing Doom on the most ergonomically challenged devices, [Aaron Christophel] likes to take a relaxing break with reverse-engineering Xiaomi Mi Band fitness trackers and writing custom firmware for them. Also so that he can play more Doom on those, natch. The latest subject comes in the form of the Mi Band 10, which features a BES2700iMP SoC, known internally at the manufacturer Bestechnic as the BEST1503. This is all documented on the GitHub project.

In the accompanying video we get some more details on this project, with the main challenge being that for this Mi Band 10 there’s no public SDK for its SoC. This was a major bummer until [Aaron] realized that the BEST1306 (BES2700IHC) is effectively the same SoC, but with a leaked SDK available via apparently audio-focused development kits. From there a BEST1503-compatible SDK could be assembled.

Naturally, to check that all of this was working correctly Doom was ported to the device courtesy of the GBADoom project. This mostly works aside from the display running in single-bit SPI mode instead of quad-SPI that it should be capable of, along with limited color depth. Despite burning all the tokens on the Claude, this provided little help, probably because the required information hasn’t leaked out of Bestechnic yet and ended up in the training data set.

Since the Mi Band 9 uses the same SoC, it’s expected that this reverse-engineered SDK will also work for that fitness band, though that hasn’t been tested yet.

Continue reading “Hacking The Mi Band 10 Smart Band And Its Bestechnic SoC” →

Hacking A Video Walkie Talkie’s TXW818 MCU And Running DOOM

May 24, 2026 by Maya Posch 10 Comments

Recently cheapo video walkie-talkies popped up on everyone’s favorite online retailers, which naturally lured in the usual gaggle of reverse-engineering enthusiasts of cheap tat to see what’s inside these devices, as well as what more they can be made to do. Cue [Aaron Christophel] doing just that, with the typical DOOM demo as proof of concept.

Inside these cheerful little devices is a TXW818 MCU, made by TaiXin Semiconductor. It provides its own CK803 CPU core at 240 MHz with 272 kB of SRAM, as well as BLE and 2.4 GHz Wi-Fi support. For these walkie-talkies an additional 4 MB of PSRAM is provided as well as 2-4 MB of SPI Flash.

The display is a glorious 240×320 LCD, which actually fits rather well with a game like DOOM. As also explained on the GitHub project page, to build the project you simply have to fetch the CDK IDE and build the binary. After that it can be flashed with an STM32F103 ‘Blue Pill’ based board.

According to [Aaron] the SDK is rather convoluted and not that nice to work with, so it’s not a sleeper ESP32 alternative, but these cheap walkie-talkies could be nice to tinker with anyway. Other than playing games, of course, as the side buttons aren’t very conducive to gaming, and the limited Flash space required compressing the WAD game file.

Continue reading “Hacking A Video Walkie Talkie’s TXW818 MCU And Running DOOM“ →

Running DOOM On A Travel Router With Touch Screen

May 1, 2026 by Maya Posch 11 Comments

Continuing his quest to put DOOM on literally everything that has a capable enough processor and a screen, [Aaron Christophel]’s most recent target is a Slate 7 Pro travel router. With a generous 2.8″ touch screen and a lot of onboard processing power to handle all the advertised networking and routing features via its WAN and (W)LAN interfaces, it should be able to run the game really quite well. As usual the main question is how to get the game to run on it first.

The port of choice is fbdoom, with instructions on how to run it on this router provided on the GitHub project page. The reason for the touch screen is so that you can see the status of interfaces and interact with it without having to open the web interface. Boringly, this router has an SSH daemon ready to connect to, giving you full root access to the Linux-based firmware.

It’s just your typical AArch64 ARM-based system, with the gl_screen process running for the touch screen display. From there it was easy enough to deduce the settings to jot into fbdoom so that it too could use the same screen and touch inputs. After copying the compiled binary with SCP over to the router, it can then be started like any application. With touch inputs somewhat awkwardly mapped to certain areas of the touch screen, it’d be nice to see the USB 2.0 port used for USB HID inputs, but it does show how easy things can be when it runs something like Linux and you got full root access.

Incidentally this also heavily blurs the lines between something like a Valve Steamdeck and a router, with the latter just missing some gamepad controls on the side to do some on-the-go gaming when you’re not using it for routing network traffic.

Continue reading “Running DOOM On A Travel Router With Touch Screen” →

DOOM On A Fancy Smart Toaster

April 15, 2026 by Maya Posch 14 Comments

Although toasters should be among the most boring appliances in a household – with perhaps just a focus on making their toasting more deterministic rather than somewhere between ‘still frozen’ and ‘charcoal’ – somehow companies keep churning out toasters that just add very confusing ‘smart’ features. Of course, if a toaster adds a big touch screen and significant processing power, you may as well run DOOM on it, as was [Aaron Christophel]’s reflexive response.

While unboxing the Aeco Toastlab Elite toaster, [Aaron] is positively dumbfounded that they didn’t also add WiFi to the thing. Although on the bright side, that should mean no firmware updates being pushed via the internet. During the disassembly it can be seen that there’s an unpopulated pad for a WiFi chip and an antenna connection, making it clear that the PCB is a general purpose PCB that will see use in other appliances.

The SoC is marked up as a K660L with an external flash chip. Dumping the firmware is very easy, with highly accessible UART that spits out a ‘Welcome to ArtInChip Luban-Lite’ message. After some reverse-engineering the SoC turned out to be a rebranded RISC-V-based ArtInChip D133CxS, with a very usable SDK by the manufacturer. From there it was easy enough to get DOOM to run, with the bonus feature of needing to complete a level before the toaster will give the slice back.

Continue reading “DOOM On A Fancy Smart Toaster” →

The D In DNS Stands For DOOM

March 31, 2026 by Maya Posch 6 Comments

As literally everything ought to be able to play DOOM in some fashion, [Adam Rice] recently set out to make the venerable DNS finally play the game after far too many decades of being DOOM-less. You may be wondering how video games and a boring domain records database relate to each other. This is where DNS TXT records come into play, which are essentially fields for arbitrary data with no requirements or limitations on this payload, other than a 2,000 character limit.

Add to this the concept of DNS zones which can contain thousands of records and the inkling of a plan begins to form. Essentially the entire game (in C#) is fetched from TXT records, loaded into memory and run from there. This is in some ways a benign form of how DNS TXT records can be abused by people with less harmless intentions, though [Adam] admits to using the Claude chatbot to help with the code, so YMMV.

The engine and WAD file with the game’s resources are compressed to fit into 1.7 MB along with a 1.2 MB DLL bundle, requiring 1,966 TXT records in Base64 encoding on a Cloudflare Pro DNS zone. With a free Cloudflare account you’d need to split it across multiple zones. With the TXT records synced across the globe, every caching DNS server in the world now has a copy of DOOM on it, for better or worse.

You can find the project source on GitHub if you want to give this a shake yourself.

Thanks to [MrRTFM] for the tip.