Postpone your holiday shopping and spend some quality time with editors Mike Szczys and Elliot Williams as they sift through the week in Hackaday. Which programming language is the greenest? How many trackballs can a mouse possibly have? And can a Bluetooth dongle run DOOM? Join us to find out!
Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!
By now most readers should be used to the phenomenon of taking almost any microcontroller and coaxing it to run a port of the 1990s grand-daddy of all first-person shooters, id Software’s Doom. It’s been done on a wide array of devices, sometimes only having enough power for a demo mode but more often able to offer the full experience. Latest to the slipgate in this festival of pixelated gore is [Nicola Wrachien], who’s achieved the feat using an nRF52840-based USB Bluetooth LE dongle.
Full details can be found on his website, where the process of initial development using an Adafruit CLUE board is detailed. A 16MB FLASH chip is used for WAD storage, and an SPI colour display takes us straight to that cursed base on Phobos. The target board lacks enough I/O brought out for connection to screen and FLASH, so some trickery with 7400 logic is required to free up enough for the task. Controls are implemented via a wireless gamepad using an nRFS1822 board, complete with streamed audio to a PWM output.
The result can be seen in the video below the break, which shows a very playable game of both Doom and Doom 2 that would not have disgraced many machines of the era. This was prototyped on an Adafruit Clue board, and that could be the handheld console you’ve been looking for!
These days we expect even the cheapest of burner smartphones to feature a multi-core processor, at least a gigabyte of RAM, and a Linux-based operating system. But obviously those sort of specs are unnecessary for an old school POTS desktop phone. Well, that’s what we thought. Then [Josh Max] wrote in to tell us about his adventures in hacking the CaptionCall, and now we’re eager to see what the community can do with root access on a surprisingly powerful Linux phone.
As the names implies, the CaptionCall is a desk phone with an LCD above the keypad that shows real-time captions. Anyone in the United States with hearing loss can get one of these phones for free from the government, so naturally they sell for peanuts on the second hand market. Well, at least they did. Then [Josh] had to go ahead and crack the root password for the ARMv7 i.MX6 powered phone, started poking around inside of its 4 GB of onboard NAND, and got the thing running DOOM.
If you’re interested in the technical details, [Josh] has done a great job taking us step by step through his process. It’s a story that will be at least somewhat familiar to anyone who’s played around with embedded Linux devices, and unsurprisingly, starts with locating a serial port header on the PCB.
Finding the environment variables to pretty tightly locked down, he took the slow-route and dumped the phone’s firmware 80 characters at a time with U-Boot’s “memory display” command. Passing the recovered firmware image through binwalk and a password cracker got him the root credentials in short order, and from there, that serial port got a whole lot more useful.
[Josh] kicked the phone’s original UI to the curb, set up an ARM Debian Jessie chroot, and started working his way towards a fully functional Linux environment. With audio, video, and even keypad support secured, he was ready to boot up everyone’s favorite 1993 shooter. He’s been kind enough to share his work in a GitHub repository, and while it might not be a turn-key experience, all the pieces are here to fully bend the hardware to your will.
Historically, running DOOM on a new piece of hardware has been the harbinger of bigger and better things to come. With unfettered access to its Linux operating system up for grabs, we predict the CaptionCall is going to become a popular hacking target going forward, and we can’t wait to see it.
id Software’s iconic 1993 first-person shooter game Doom was the game to play on your 486 (or fast 386) and was for many their first introduction to immersive 3D environments in gaming. Its eventual release as open-source gave it a new life, and now it’s a rite of passage for newly-reverse-engineered devices: Will it run Doom?
To enter the world of a UAC space marine in glorious portrait mode, simply take an installation of Doom 1.9 for DOS, and copy the Toom files from the GitHub repository over the top of it. The minimum spec is a 486 so period hardware will be fine, all you’ll need is a monitor that can be tipped on its side.
Doom consumed far too many hours for gamers of a certain age, and while it may look quaint to modern eyes it can’t be overstated what a giant step it was compared to what had gone before. If any of you install Toom and give it a go, prepare to see its monsters when you close your eyes.
Spec sheets are an important tool in determining the performance of a given part or system, but they’re not the be all and end all when it comes to engineering. However, specs alone don’t prove whether a given system can complete a given task. Sometimes, you need to actually do the work to prove it instead – as [Sylvain] has done, running DOOM on the iCE40 FPGA.
DOOM’s minimum specifications demand a 386 with 4MB RAM minimum, but it’s commonly agreed that a 486 DX2 running at 66MHz with 8MB of RAM is required to play the game smoothly. With an iCEBreaker v1.0b running a RISC V softcore at 25MHz, it may seem like a difficult task, but the RISC V core has the benefit that many instructions run in a single clock cycle that take many on the 486. While the iCEBreaker doesn’t have much RAM onboard, it’s a simple job to piggyback an 8MB SPI device on top of the existing flash storage. Control of the game is via keystrokes sent to the iCEBreaker over serial, while video is handled over a PMOD video interface with an HDMI connector.
[Sylvain] does a great job of explaining all the minute details of the work that was required to get things working, and has provided files on Github for those keen to replicate the feat or expand upon the code. Music is notably absent but MIDI output could likely be achieved without much hassle. “Does it run DOOM?” is still a question asked of many platforms, even the new Nintendo Game & Watch. Video after the break.
It’s a trope among thriller writers; the three-word apocalyptic title. An innocuous item with the power to release unimaginable disaster, which of course our plucky hero must secure to save the day. Happily [Sylvain Lefebvre]’s DOOM chip will not cause the world to end, but it does present a vision of a very 1990s apocalypse. It’s a hardware-only implementation of the first level from id Software’s iconic 1993 first-person-shooter, DOOM. As he puts it: “Algorithm is burned into wires, LUTs and flip-flops on an #FPGA: no CPU, no opcodes, no instruction counter. Running on Altera CycloneV + SDRAM”. It’s the game, or at least the E1M1 map from it sans monsters, solely in silicon. In a very on-theme touch, the rendering engine has 666 lines of code, and the level data is transcribed from the original into hardware tables by a LUA script. It doesn’t appear to be in his GitHub account so far, but we live in hope that one day he’ll put it up.
“Will it run DOOM” is almost a standard for new hardware, but it conceals the immense legacy of this game. It wasn’t the first to adopt a 1st-person 3D gaming environment, but it was the game that defined the genre of realistic and immersive FPS releases that continue to this day. We first played DOOM on a creaking 386, we’ve seen it on all kinds of hardware since, and like very few other games of its age it’s still receiving active development from a large community today. We still mourn slightly that it’s taken the best part of three decades for someone to do a decent Amiga port.
Can you run Doom on the Amiga? No, not really, and arguably that was one of the causes for the computer’s demise in the mid-90s as it failed to catch up on the FPS craze of the PC world. [Krzysztof Kluczek] of the Altair demogroup has managed not exactly to remedy that status with the original article, but to show us how a potential contender could’ve been designed for the unexpanded Amiga hardware back in the day.
Many developers tried to emulate the thrill and ambiance of the id Software shooter, but they all required high-end Amigas with faster processors and expanded memory, limiting their player base on an already diminished demographic. Not only that, but even with fancier hardware, none of them quite managed to match how well Doom ran on your run-of-the-mill 486 at the time. [Krzysztof] isn’t trying to port Doom itself, but instead creating an engine custom-designed to take advantage of, and minding the limitations of the OCS Amiga as it existed in 1987. The result is Dread, a 2.5D engine that resembles the SNES port of Doom and uses assets from the Freedoom project in order to remain copyright-abiding.
It might not be Doom, but it’s a good peek at what the 33-year old hardware could’ve done in the right hands back then. Technically it already surpasses what the Wolfenstein 3D engine could do, so there’s an idea if someone ever aims to make a straight up port instead of their own game. If you like seeing Doom run on machines it wasn’t meant to, boy do we have some posts for you. Otherwise, stick around after the break for two videos of Dread’s engine being demonstrated.