Running DOOM On A Cheap 104-in-One Handheld

August 11, 2026 by Maya Posch 10 Comments

Taking a break from putting DOOM on devices that absolutely were never conceived for use as gaming devices, [Aaron Christophel] recently got enticed by some cheapo handheld gaming systems at his local Action budget store. One is a controller-shaped ‘mini game console’ with 104 games from the 1980s and 1990s, while the other is simply a Pac-Man handheld in a more typical rectangular form factor. Although this brings to mind basic blob chips and limited hacking potential, as it turns out they’re actually quite nice inside.

As also covered in the demonstration video, rather than said nasty blob chip, both handhelds turned out to use the same unmarked MCU in QFN48 packaging. Some prodding and poking confirmed that it’s a typical ARM core, specifically a Cortex-M33 compatible STAR-MC1 ARMv8-M from an unknown manufacturer. Without a datasheet to go by, its limitations had to be discovered experimentally.

Of those, the biggest were a clock speed of 62 MHz – instead of the typical 194 MHz – as well as a lack of sound. This latter issue might be fixable with a better understanding of what appears to be a quirky DMA-fed DAC. Beyond this you’re also dealing with limited memory and of course just 4 MB of flash, though the chip for this might be upgradable if the MCU can map more. You do get a 320×240 display and a lot of buttons, which is admittedly nice.

As for the price difference of around $8/€7 for the Pac-Man version, this appears to be due to it running an officially licensed Bandai Namco arcade emulator as firmware, while the 104-in-one unit runs FlyThings/ZKSWE with a NES emulator.

Continue reading “Running DOOM On A Cheap 104-in-One Handheld” →

DOOM Using Regular Expressions

July 28, 2026 by Maya Posch 16 Comments

Regular expressions (regexes) are an amazingly powerful way to perform operations on collections of e.g. text. Regexss can also be considered to be a programming language, even a Turing complete one. Ergo it’s perfectly acceptable to thus design a way to use regexes to run and play a game of DOOM, as [Artem Lytkin] recently did.

The GitHub project page can be found here, containing the Python-based code that allows the demonstration to run, as well as the other components, including the C runtime and the 96.6 MB text string that defines a CPU’s registers, RAM, a framebuffer, the DOOM engine compiled to this custom CPU’s instruction set and the WAD file for the game itself.

The C-based driver applies the fixed, ordered list of find-and-replace rules to this string, which after more than ten-thousand of such substitutions later results in a single frame of the game. At about 80,000 substitutions per second on the given test system, that gets you to a sort-of playable framerate, even.

Naturally, the practical value of playing DOOM like this is pretty low, but as a demonstration of why regexes are awesome it’s hard to beat.

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” →