Porting DOOM to run on hardware never meant to run it is a tradition as old as time. Getting it to run on embedded devices, ancient computers, virtual computers, and antique video game consoles are all classic hacks, but what DOOM ports have been waiting for is something with universal applicability that don’t need a bespoke solution for each piece of hardware. Something like DOOM running within a bootloader.
The bootloader that [Ahmad] works with is called Barebox and is focused on embedded systems, often those running Linux. This is the perfect environment for direct hardware access, since the bootloader doubles as a bare metal hardware bring-up toolkit. Now that DOOM runs on this bootloader, it effectively can run anywhere from embedded devices to laptops with minimal work, and although running it in a bootloader takes away a lot of the hard work that would normally need to be done during a port, it may still need some tweaking for specific hardware not otherwise supported.
For those already running Barebox, the bareDOOM code can be found on [Ahmad]’s GitHub page. For those not running Barebox, it does have a number of benefits compared to other bootloaders, even apart from its new ability to play classic FPS games. For those who prefer a more custom DOOM setup, though, we are always fans of DOOM running within an NES cartridge.
Photo: AntonioMDA, CC BY-SA 4.0 via Wikimedia Commons
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.
Continue reading “Ice40 Runs DOOM”
Today the newly-released Nintendo Game & Watch can play DOOM. Sure, there are caveats…this is a watered down version due to the restraints of the hardware itself. But the important thing is that this shows the hardware has been fully owned. This is code written to replace the firmware that ships on the STM32 within, and that makes this a gorgeous little hardware platform that is completely open to homebrew hacking.
Honestly, you had to assume this was going to happen pretty quickly considering the effort being thrown into it. We first reported on Tuesday that the EEPROM memory which stores the ROMs on the Game and Watch had been decoded. Shortly after that was published, [stacksmashing] and [Konrad Beckmann] were showing test patterns on the display and mentioning the audio was working as well. Turns out they were able to dump the stock firmware despite the chip being security locked.
We’ll have to wait for more details on exactly how to dump firmware, but [stacksmashing] drops enough of a mention in the video below to confirm the obvious. A common approach to dumping code from a locked microcontroller is to find a vulnerability that grants execution of custom code. Being able to run just a few lines of your own code is enough set up something as simple as looping through all internal flash memory addresses and dumping them over a few GPIO pins. In this case our two heroes discovered some ARM code was being loaded from the EEPROM onto the STM32, and managed to inject their own directives to perform the dump. They have promised full details soon.
What we have today is a pretty tricky hack not just to load code, but to get DOOM to run on meager hardware specs. Notably, 128 k of SRAM and 1.3 MB of external RAM. There’s also a bottleneck with the 1.1 MB of FLASH for storing game files. The textures were stripped down, and memory allocation was rewritten, but the proof of concept is there and the game runs. Homebrew, here we come!
Continue reading “DOOM Running On The Nintendo Game & Watch”
Over the years, the 1993 classic Doom has gained an almost meme-like status where it can seemingly run on anything. Everything from printers to smartwatches has been shown off running the now-iconic first level of Doom. Looking to up the bar, [Equalo] set out to run Doom on potatoes. However until we develop full biological computers, he had to settle for running Doom on a device powered by potatoes. (Video, embedded below.)
As we’ve seen with other hacks before, potatoes are a decent power source that just requires potato, zinc, and copper. Some have attempted to make it easier to scale potato power and others have focused on making the individual potatoes more powerful. The biggest obstacle when working with potatoes as a battery is that even though each potato can put out almost a volt, the current is laughably small.
The lack of current is what drove [Equalo] to dramatically scale up the typical potato battery. With a target device of a Raspberry Pi Zero requiring around 100 mA at 4.5V, this means he needed over 700 potato slices. After boiling hundreds of potatoes and with a bit of help from friends and family, the giant potato battery was constructed, and we can’t help but marvel at the sheer scale and audacity. The challenge of scaling up a potato battery is that by the time you’re wiring up the 400th potato, your first potato has already started to corrode.
Next time you’re looking for some inspiration for a monumental task, perhaps watch the tale of [Equalo’s] giant potato battery and remember what can be accomplished with some determination and a hundred pounds of spuds.
Continue reading “The Potatoes Of DOOM”
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.
Continue reading “Doom Clone Shows What An Alternate-Reality Amiga Could’ve Had”
Google Photos is handy. You take pictures and videos on your cell phone, and they automatically upload to the cloud. If you’re anything like me, however, every snap comes with a self-reminder that “the cloud” is a fancy name for someone else’s server. What could possibly go wrong? How about some of your videos randomly included in another user’s downloads?
Confirmed by Google themselves, this bug hit those using Google Takeout, the service that allows you to download all your data from a Google application, as a single archive. Google Photos archives downloaded between November 21 and November 25 may contain videos from other users, according to a notice sent to the users who downloaded said archives. It’s notable that those notices haven’t been sent to users who’s videos were exposed.
Continue reading “This Week In Security: Google Photos, Whatsapp, And Doom On Deskphones”