DOOM Played On Series Of 555 Timers

August 28, 2026 by Bryan Cockfield 18 Comments

It’s technically true that any piece of software can be reproduced in hardware, although modern software’s size and complexity generally makes this a non-starter. But if we go far enough back in time, older software becomes easier and easier to implement in hardware. The original DOOM from 1993 might one day be recreated in full this way, but that day is not today. Instead, [Nick] has recreated the original music from that game, playing the opening track in nothing but 555 timers.

The circuit starts with a 555 timer that acts as a system clock with a rate of just over 7 Hz. These pulses feed a binary counter which in turn feeds a decoder, giving the circuit 15 positions. Each output of the decoder feeds to a diode matrix which stores information about what pitch the circuit should play. The circuit only needs to play six pitches so the diodes effectively connect each moment in time to one of these six notes. From there the circuit feeds into a set of switches which select different resistor networks of another 555 which is actually responsible for producing sound. The resistor networks have different values to adjust the timing of the 555 to produce different pitches.

Of course this entire exercise is largely academic as almost any microcontroller would be able to be programmed to play this chiptune quite easily, but it’s not a bad idea to get down into the weeds of digital logic from time to time in order to refine one’s skills and knowledge about what’s really going on in the inner workings of circuits. Or, go even deeper than that and build the logic gates themselves from first principles.

Continue reading “DOOM Played On Series Of 555 Timers” →

Claude Plays DOOM

August 26, 2026 by Zoe Skyforest 31 Comments

Large language models (LLMs) are generally thought of as machines that accept textual prompts and spit out textual content. However, if you’re creative in the way you interface with them, you can get them to do a wider range of tasks. For example, [Andrea Ricci] figured out how to get one to play DOOM.

For this project, [Andrea] began by porting the game to the SCINTIX P4. It’s a rather interesting device, being a single board designed in the Raspberry Pi CM4/CM5 form factor, but carrying an ESP32-P4 and an ESP32-C6 instead. The game runs on the P4 and is displayed on a 1024×600 MIPI DSI panel, but it’s only stepped through a few frames at a time. These frames are then passed to Claude Sonnet via a WebSockets setup. With only the same information as a human player would get, the LLM has to figure out what it’s looking at, and then respond with movement and fire commands to play the game.

It’s quite interesting to watch the system play—the LLM mostly accurately describes the game world, navigates down corridors, opens doors, and shoots at enemies. There is a bit of work behind the scenes to enable it to see and understand the game world—namely, using a depth fan across the field of view so it can figure out where walls are and how not to bang into them. There’s also an ASCII automap used to allow the system to keep track of where it has already been. But fundamentally, the LLM is playing the game without any other sort of additional assistance.

We’ve seen some other great ways in which AIs have been whipped up to play various games, like Trackmania.

Continue reading “Claude Plays DOOM“ →

Running DOOM On A Cheap 104-in-One Handheld

August 11, 2026 by Maya Posch 9 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” →

Running DOOM On A Custom CPU Built From Scratch

July 23, 2026 by Zoe Skyforest 10 Comments

Running DOOM on weird obscure hardware is a fun hacker pastime that’s been around for a long time now. It’s always enjoyable to see someone port it to an egg timer, or a hat, or whatever else. But what about running the iconic shooter on a CPU of your very own? [Armaan] and [Liam] have done just that.

The CPU in question was designed at the logic gate level, deployed on to an FPGA, and hooked up with the necessary peripherals to run as a going concern. Early testing of the CPU involved running straightforward code to generate Mandelbrot sets and to play a simple game of Pong. But [Armaan] and [Liam] had bigger goals: to port the game that everybody ports to everything. Doing that took some work.

To get DOOM running, the CPU had to get faster, and it needed many tweaks to how memory was handled. There was also work to be done to create a keyboard interface, an HDMI video output, and a hardware timer. From there, the game itself had to then be ported to the custom CPU’s architecture. Eventually, the duo had the game running… at a glacial 0.7 FPS. A success, but not the magical end result that was desired. A bump to clock speed and further optimizations and compiler tweaks eventually got the game up to an impressive 15-20 FPS. The goal for future work is to push it to an entirely-playable figure of 30 FPS or better.

It’s worth checking out the (apparently unembeddable) videos on Instagram to see the CPU in action. We’ve also featured plenty of fun DOOM ports before, too. If you’re brewing up custom CPUs or DOOM ports of your own, keep them coming to the tipsline. The latter in particular is often a wonderful milk run for the writer that happens across it. Happy hacking out there!

A RayCast FPS In COBOL

June 6, 2026 by Tyler August 2 Comments

COBOL is not the first language anyone would ever think of when writing a First Person Shooter– after all , it’s the Common Business Oriented Language, not the Common Game Oriented Language. For Youtube-based hacker [icitry] though, that’s the point. The only way to determine if COBOL would be enough to write an FPS game was to do it.

Sure, you could rest on your laurels knowing that the language is Turing complete and therefore capable by definition, but what’s the fun in that? Now the pipeline for this game is as hacky as anything– COBOL doesn’t exactly have a robust graphics stack or a lot of libraries for pushing pixles, so he’s outputting each frame of the game as raw bitmap to STDOUT, and letting ffplay assemble the images. Control enters the same way, with the terminal set to raw input and the COBOL program reading STDIN.

As for what the images consist of, he’s going for a standard Wolfenstien-inspired raycasting shooter. [icitr] provides a decent explanation of the raycasting algorithm, along with why implementing in COBOL is a silly thing to try. That’s a theme here; he’s able to implement sprites and the logic to move and attack enemies, while constantly complaining about COBOL. If that wasn’t enough, he adds variable-height sectors to bring this much closer to a true DOOM clone. By the end, there’s a full game. It’s all up on GitHub on an Apache license.

While this video is not the most gentle introduction to COBOL, it does show you can hack the business-specific language to do whatever you’d like.

Hackaday Links: May 24, 2026

May 24, 2026 by Tom Nardi 5 Comments

If your first-generation Chromecast was acting a little wonky this week, don’t worry. Contrary to fears online, the 2014 device hasn’t been excommunicated by Google. In a statement to Ars Technica, a rep for the search giant explained that the issue, which was keeping the devices from being able to stream video from services like Netflix, was temporary and should now be resolved. That said, the OG Chromecast hasn’t officially been supported since 2023, so it’s not clear how much longer they will remain operational. Google be Google, after all.

After resisting for years, this week, Mozilla finally relented and brought Web Serial to Firefox. While there’s been some debate about the wisdom of letting the Internet directly talk to hardware gadgets, anyone who’s flashed Meshtastic or configured their Betaflight-powered drone from the browser can attest to how convenient it is. In the announcement, Mozilla acknowledges that “most folks won’t use this API”, but points out that the “community of builders and tinkerers” (that’s us!) is sure to be excited about the news. They’ve even teamed up with Adafruit to ensure their web-based microcontroller workflows are compatible in Firefox 151 and beyond. If you give it a shot, let us know how it goes.

Speaking of hardware support, the Linux Vendor Firmware Service (LVFS) recently picked up a couple of big-name sponsors. As reported by It’s FOSS, this week, Lenovo, Dell, and HP have signed on as Premier-level sponsors to the tune of $100,000 per year. For those unfamiliar, LVFS offers a central repository where hardware vendors can upload firmware updates. On the client side, fwupd can be used to pull these updates down automatically without having to hunt around on each vendor’s website. The experienced players don’t need a service like LVFS, but it’s certainly one of those quality-of-life improvements that make the desktop experience a bit more accessible.

Continue reading “Hackaday Links: May 24, 2026” →

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.