Dreamcast Homebrew Gets Boost From SD Card Cache

While it might have been a commercial failure compared to contemporary consoles, the Sega Dreamcast still enjoys an active homebrew scene more than twenty years after its release. Partly it’s due to the fact that you can burn playable Dreamcast discs on standard CD-Rs, but fans of the system will also point out that the machine was clearly ahead of its time in many respects, affording it a bit of extra goodwill in the community.

That same community happens to be buzzing right now with news that well-known Dreamcast hacker [Ian Micheal] has figured out how to cache data to an SD card via the console’s serial port. At roughly 600 KB/s the interface is too slow to use it as swap space for expanding the system’s paltry 16 MB of memory, but it’s more than fast enough to load game assets which otherwise would have had to be loaded into RAM.

A third-party Dreamcast SD adapter.

In the video below, [Ian] shows off his new technique with a port of DOOM running at 640×480. He’s already seeing an improvement to framerates, and thinks further optimizations should allow for a solid 30 FPS, but that’s not really the most exciting part. With the ability to load an essentially unlimited amount of data from the SD card while the game is running, this opens the possibility of running mods which wouldn’t have been possible otherwise. It should also allow for niceties like saving screenshots or game progress to the SD card for easy retrieval.

[Ian] says he’ll be bringing the same technique to his Dreamcast ports of Quake and Hexen in the near future, and plans on posting some code to GitHub that demonstrates reading and writing to FAT32 cards so other developers can get in on the fun. The downside is that you obviously need to have an SD card adapter plugged into your console to make use of this technique, which not everyone will have. Luckily they’re fairly cheap right now, but we wouldn’t be surprised if the prices start climbing. If you don’t have one already, now’s probably the time to get one.

To be clear, this technique is completely separate from replacing the Dreamcast’s optical drive with an SD card, which itself is a very popular modification that’s helped keep Sega’s last home console kicking far longer than anyone could have imagined.

Continue reading “Dreamcast Homebrew Gets Boost From SD Card Cache”

Kitchen Bump Bar Plays Doom Between Orders

For as much as we love reverse engineering projects, we have to admit that we almost passed up on this “kitchen bump bar” hack. Having never had the privilege of working in the food-service industry — well, there was that time working at Chuck E. Cheese’s, but that only lasted for one shift — we were unaware of what a bump bar is, and the whys and hows of hacking one to the point where it can play Doom.

We’re glad we stuck with it, though, because [Kiwa]’s hack is pretty cool, and we got to learn a little about the technology of the modern commercial kitchen. Most fast food and family casual restaurants have what’s known as a “kitchen display system”, which relays orders from the wait staff to the kitchen. You’ve probably seen parts of the KDS, like the touch screens used by the wait staff to enter orders, or the screens dangling in the kitchen that display the pending orders. A bump bar is a small terminal used by the kitchen crew to review orders and move them around in the queue, or “bump” them, as needs dictate.

The bump bar [Kiwa] dug into appears to be a model from the early 2000s and very sturdily built, as anything used in a kitchen would need to be. Hooked up to a monitor and a keyboard, [Kiwa] discovered that it booted right into an OS with all the familiar trappings of DOS. After a detour for a teardown and dumping the flash contents, [Kiwa] was able to boot it up and run Doom, albeit somewhat slowly. It also looks like he’s got a couple of different Windows versions running, and even played some Solitaire.

It’s always fun to see what will run Doom — an NES, an oscilloscope, a thermostat, or even a bag of potatoes.

Thanks to [Fritnando] for the tip.

DOOM On A Bootloader Is The Ultimate Cheat Code

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

Ice40 Runs DOOM

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”

DOOM Running On The Nintendo Game & Watch

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”

The Potatoes Of DOOM

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”

The DOOM Chip

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.