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.
Traditionally, a forum full of technical users trying integrate their own hardware into a game system for the purposes of gaining unfettered access to its entire software library was the kind of thing that would keep engineers at Sony and Nintendo up at night. The development and proliferation of so called “mod chips” were an existential threat to companies that made their money selling video games, and as such, sniffing out these console hackers and keeping their findings from going public for as long as possible was a top priority.
But the Arduboy is no traditional game system. Its games are distributed for free, so a chip that allows users to cram hundreds of them onto the handheld at once isn’t some shady attempt to pull a fast one on the developers, it’s a substantial usability improvement over the stock hardware. So when Arduboy creator Kevin Bates found out about the grassroots effort to expand the system’s internal storage on the official forums, he didn’t try to put a stop to it. Instead, he asked how he could help make it a reality for as many Arduboy owners as possible.
Now, a little less than three years after forum member Mr.Blinky posted his initial concept for hanging an external SPI flash chip on the system’s test pads, the official Arduboy FX Mod-Chip has arrived. Whether you go the DIY route and build your own version or buy the ready-to-go module, one thing is for sure: it’s a must-have upgrade for the Arduboy that will completely change how you use the diminutive handheld.
If you’ve scrolled through the list of boot options offered on any PC’s BIOS, it reads like a history of storage technology. Up top we have the options to boot from disk, often a solid-state drive, then USB disk, optical drive, removable media, and down the bottom there’s usually an option to boot from the network. Practically no BIOS, however, has an option to boot a PC from a vinyl record — at least until now.
Clearly a project from the “Because why not?” school of hacking, [Jozef Bogin] came up with the twist to the normal booting process for an IBM-PC. As in the IBM-PC — a model 5150, with the putty-colored case, dual 5-1/4″ floppies, and one of those amazing monochrome displays with the green slow-decay phosphors. To pull off the trick, [Jozef] leverages the rarely used and little known cassette tape interface that PCs had back in the early days. This required building a new bootloader and burning it to ROM to make the PC listen to audio signals with its 8255 programmable peripheral interface chip.
Once the PC had the right bootloader, a 64k FreeDOS bootable disk image was recorded on vinyl. [Jozef] provides infuriatingly little detail about the process other than to mention that the audio was sent directly to the vinyl lathe; we’d have loved to learn more about that. Nonetheless, the resulting 10″ record, played back at 45 RPM with some equalization tweaks to adapt for the RIAA equalization curve of the preamp, boots the PC into FreeDOS just fine, probably in no more time than it would have taken to boot from floppy.
Any modern computer with an x86 processor, whether it’s Intel or AMD, is a lost cause for software freedom and privacy. We harp on this a lot, but it’s worth repeating that it’s nearly impossible to get free, open-source firmware to run on them thanks to the Intel Management Engine (IME) and the AMD Platform Security Processor (PSP). Without libre firmware there’s no way to trust anything else, even if your operating system is completely open-source.
The IME or PSP have access to memory, storage, and the network stack even if the computer is shut down, and even after the computer boots they run at such a low level that the operating system can’t be aware of what they’re really doing. Luckily, there’s a dark horse in the race in the personal computing world that gives us some hope that one day there will be an x86 competitor that allows their users to have a free firmware that they can trust. ARM processors, which have been steadily increasing their user share for years but are seeing a surge of interest since the recent announcement by Apple, are poised to take over the personal computing world and hopefully allow us some relevant, modern options for those concerned with freedom and privacy. But in the real world of ARM processors the road ahead will decidedly long, windy, and forked.
Even ignoring tedious nitpicks that the distinction between RISC vs CISC is more blurred now than it was “back in the day”, RISC machines like ARM have a natural leg up on the x86 CISC machines built by Intel and AMD. These RISC machines use fewer instructions and perform with much more thermal efficiency than their x86 competitors. They can often be passively cooled, avoiding need to be actively cooled, unlike many AMD/Intel machines that often have noisy or bulky fans. But for me, the most interesting advantage is the ability to run ARM machines without the proprietary firmware present with x86 chips.
We’ve been big fans of the Arduboy since [Kevin Bates] showed off the first prototype back in 2014. It’s a fantastic platform for making and playing simple games, but there’s certainly room for improvement. One of the most obvious usability issues has always been that the hardware can only hold one game at a time. But thanks to the development of an official add-on, the Arduboy will soon have enough onboard storage to hold hundreds of games
The upgrade takes the form of a small flexible PCB that gets soldered to existing test points on the Arduboy. Equipped with a W25Q128 flash chip, the retrofit board provides an additional 16 MB of flash storage to the handheld’s ATmega32u4 microcontroller; enough to hold essentially every game and program ever written for the platform at once.
Of course, wiring an SPI flash chip to the handheld’s MCU is only half the battle. The system also needs to have its bootloader replaced with one that’s aware of this expanded storage. To that end, the upgrade board also contains an ATtiny85 that’s there to handle this process without the need for an external programmer. While this is a luxury the average Hackaday reader could probably do without, it’s a smart move for an upgrade intended for a wider audience.
Historically, booting a Raspberry Pi required an SD card. However, if you follow [tynick’s] instructions, you can get a Pi 4 to boot from the USB port. Combine it with a small solid state disk drive, and you’ll get great performance, according to his post.
The caveat is this depends on a beta bootloader and, of course, you’ll still have to boot from an SD card at least once to load that bootloader. If you were deploying something serious, you’d probably want to make sure the bootloader is suitable for your needs.
A factory is a machine. It takes a fixed set of inputs – circuit boards, plastic enclosures, optimism – and produces a fixed set of outputs in the form of assembled products. Sometimes it is comprised of real machines (see any recent video of a Tesla assembly line) but more often it’s a mixture of mechanical machines and meaty humans working together. Regardless of the exact balance the factory machine is conceived of by a production engineer and goes through the same design, iteration, polish cycle that the rest of the product does (in this sense product development is somewhat fractal). Last year [Michael Ossmann] had a surprise production problem which is both a chilling tale of a nasty hardware bug and a great reminder of how fragile manufacturing can be. It’s a natural fit for this year’s theme of going to production.
The saga begins with [Michael] receiving an urgent message from the factory that an existing product which had been in production for years was failing at such a high rate that they had stopped the production line. There are few worse notes to get from a factory! The issue was apparently “failure to program” and Great Scott Gadgets immediately requested samples from their manufacturer to debug. What follows is a carefully described and very educational debug session from hell, involving reverse engineering ROMs, probing errant voltage rails, and large sample sizes. [Michael] doesn’t give us a sense for how long it took to isolate but given how minute the root cause was we’d bet that it was a long, long time.
The post stands alone as an exemplar for debugging nasty hardware glitches, but we’d like to call attention to the second root cause buried near the end of the post. What stopped the manufacturer wasn’t the hardware problem so much as a process issue which had been exposed. It turned out the bug had always been reproducible in about 3% of units but the factory had never mentioned it. Why? We’d suspect that [Michael]’s guess is correct. The operators who happened to perform the failing step had discovered a workaround years ago and transparently smoothed the failure over. Then there was a staff change and the new operator started flagging the failure instead of fixing it. Arguably this is what should have been happening the entire time, but in this one tiny corner of the process the manufacturing process had been slightly deviated from. For a little more color check out episode #440.2 of the Amp Hour to hear [Chris Gammell] talk about it with [Michael]. It’s a good reminder that a product is only as reliable as the process that builds it, and that process isn’t always as reliable as it seems.