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!
[Thanks @arturo182]
Wow, that was fast!
So, does it play^H^H^H^H^H
worth $50?
If it can handle doom it must be a le to handle Gameboy/color games, maybe even GBA (lack of shoulder buttons might be an issue…). This might be an excellent little gb/gbc emu rig.
It only has 1.1MB of flash storage, which is a bit of an issue. Maybe good for adding a few NES games to, but unless there’s a way to mod it to increase the storage, it’s going to be tough to turn it into much of an emulation machine. But if I could add, say, two or three NES games, I’d be pleased enough with it. Stick Mario 3 and maybe Kirby’s Adventure on there (if it can run them), and that’d be cool. Or Zelda and Metroid.
Regardless, I look forward to seeing what they manage to do with the device. I might pick up a second one to keep pristine, and use the one I have now for hacking and modding, when the hacking scene for this thing matures.
It has 1 megabyte of storage. This thing might be able to have a single GB ROM and a super lightweight emulator, or maybe the NES ROM could be replaced (but it might be a source port compiled for this hardware? Idk)
Eh, it’s a 1.8V SOIC-8 MX25. You can replace it with a bigger one. The peripheral can map up to 256MiB.
It seems like a fun dev kit for the cost. The display is parallel RGB, the audio is SAI, and there’s a free battery.
Nintendo DS Lite runs GBA games natively, has shoulder buttons, and can be bought from Craigslist for $20-$30.
IMO this particular platform should rather be used for actual homebrew, applications and games written just for this platform.
If a device can execute code, it will run DOOM eventually.
Really nice effort, props to all involved!
It can run Crysis with a sprite swap.
Now to get it running MS Flight Simulator…
(obviously kidding)
Ugh… I want to hack that thing….
I suggest starting with using STM32cubeMX to view options for the existing device, then use that information to select the options the designers used. This will tell one what is left over one can use.
So a few random thoughts.
You can only upgrade the SOIC device up to 128mbit. I believe the packaging changes at that size because they won’t cram as nicely into cell phones. An optional upgrade path is a carrier board holding say a 512mbit or 1/2gbit device and plonking it on the old pads.
If one uses STM32cubeMX like suggested for said device options like adding external SDRAM become available, SD cards etc. Using mobile SDRAM is desirable in the case of this device. I will note though the SDRAM likely can’t be used x16 but will end up being used x8 because their aren’t enough IO pins available. I believe that processor also supports XIP mode for QSPI devices, so instead of loading the application into RAM it may make more sense to run it from the QSPI, it won’t be as fast but it won’t be running in internal flash either.
Ice Climber uses 18kb, so whit that 1MB you can have a lot of NES games, so could be this could awsome!
Does anyone know if it would be possible to copy the animated “clock” feature from these units and run them on a raspberry pi/screen. To make a stand alone desk clock?