With the Pi Pico standing in for the original ROM, updating firmware takes a fraction of the time and doesn’t require you to actually disconnect any of the hardware. [Nick] had done something similar with FPGAs in the past, but the far cheaper and easier to work with Pi Pico makes this version particularly appealing. The secret to getting it to work is the overclocking potential of the Pico, which he says has been pushed to 400 MHz for this particular application.
The downside is that you can’t access the Pico’s onboard flash when the chip is running that fast. To get around that limitation, all of the code is loaded into the microcontroller’s RAM. With a healthy 264 KB of memory this isn’t really a problem when emulating 32 KB chips, but [Nick] says his method would quickly fall apart for larger ROMs.
Beyond the Pi Pico itself, [Nick] is using a trio of 74LVC245AN 8-bit logic level shifters so the chip can talk to the 5 V logic of his homebrew 6502 computer. With everything wired up on a simple breadboard, PicoROM has no trouble serving up the operating system as it hums along at 2 MHz.
Have you ever heard of a Centurion minicomputer? If not, don’t feel bad — we hadn’t either, until [David Lovett] stumbled upon a semi-complete version of the 1980-ish mini in all its wood-trimmed, dust-encased glory. And what does a hacker do with such an acquisition but attempt to get it going again?
Of course, getting a machine from the Reagan administration running is not without its risks, including the chance of losing whatever is on the machine’s many ROM chips forever. When finding a commercial ROM reader supporting the various chips proved difficult, [David] decided to build his own. The work was eased considerably by the fact that he had managed to read one chip in a commercial reader, giving him a baseline to compare his circuit against. The hardware is straightforward — a 12-bit counter built from a trio of cascaded 74LS161s to step through addresses, plus an Arduino Nano to provide clock pulses and to read the data out to the serial port.
The circuit gave the same results as the known good read, meaning results would be valid for the rest of the chips. The breadboard setup made supporting multiple ROM pinouts easy, even for the chips that take -9 volts. What exactly the data on the ROMs mean, if anything, remains a mystery, but at least it’s backed up now.
Before anyone notes the obvious, yes, [David] could have used a 555 to clock the reader — perhaps even this one. We’d actually have loved that, but we get it — sometimes you just need to throw an Arduino at a job and be done with it.
The story for this one starts a few months ago, when [John Green] released his PICO-GB project. His code allowed the Raspberry Pi Pico to stand in for a Game Boy cartridge, complete with a simple text menu that let the user select between ROMs that had been baked into the microcontroller’s firmware. The project was particularly notable for the fact that it was entirely a software solution; while a custom breakout cartridge made for a handy temporary solution, you could have permanently wired the Pico’s pins directly to the Game Boy’s cartridge connector if you wanted to.
The RP2040 is joined by a trio of Texas Instruments TXB0108 level shifters, and there’s a spot for adding a SPI flash chip. The RP2040 supports a maximum of 16 MB of external flash, but given the size of Game Boy games were generally measured in kilobytes, that shouldn’t pose much of a problem.
Looking ahead, the original PICO-GB documentation mentions enhancements like loading ROMs from SD card, as well as hardware additions like a real-time-clock for the more advanced games that supported it. We assume those concepts will become part of [Martin]’s PCB eventually, but these are still early days.
If there is one thing that Sir Clive SInclair was famous for, it was producing electronic devices that somehow managed to squeeze near-impossible performance out of relatively meagre components. This gave us some impressive products, but it’s fair to say that sometimes this philosophy pushed the envelope a little too far. Thus even some of the most fondly remembered Sinclair products concealed significant flaws, and this extended to both their hardware and their software.
The SInclair ZX spectrum’s ROM for example had more than its fair share of bugs, and its BASIC programming experience with single keypress was unique but also slow to run. It’s something [Jonathan Cauldwell] has addressed with his Arcade Game Designer ROM, a complete and ready to run replacement for the original Spectrum ROM that contains a scripting language, a compiler, editors for in-game assets, and a game engine upon which to run your games. It’s the ROM you wanted back in 1983, when you were struggling to fit a bit of Z80 code in a Sinclair Basic REM statement.
If you’re a Spectrum enthusiast and think this sounds a little familiar then you are of course correct. It builds upon his past work with his Arcade Game Designer, with the distribution by ROM allowing the developer to use the full 48k available on all but a very few early 16k machines. You’ll need your own EPROM on which to burn it, but we suspect that if you’re the kind of person who has a Spectrum and has writing these games in mind, you already have access to the relevant equipment.
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.
It will come as no surprise to the average Hackaday reader that what we’re looking at here is a pocket-sized NES emulator, but until [stacksmashing] cracked his open, nobody was quite sure what kind of hardware is was running on. Thankfully there wasn’t an epoxy blob in sight, and all of the chips were easily identifiable. Armed with the knowledge that the Game & Watch is running on a STM32H7B0 microcontroller with a nearby SPI flash chip holding the firmware, it was just a matter of figuring out how the software worked.
But he was able to dump the RAM through SWD, which allowed him to identify where the Super Mario Bros NES ROM lived. By connecting the SPI flash chip to a reader and comparing its contents with what the system had in RAM, [stacksmashing] was able to figure out the XOR encryption scheme and come up with a tool that will allow you to insert a modified ROM into an image that can be successfully flashed to the chip.
So does that mean you can put whatever NES ROM you want on the new Game & Watch? Unfortunately, we’re not quite there yet. The emulator running on the device has a few odd quirks, and it will take some additional coaxing before its ready to run Contra. But we’ve seen enough of these devices get hacked to know that it’s just a matter of time.
We know what you’re thinking: this is yet another one of those “Gut the retro gear for its cool old case and then fill it up with IoT junk” projects. Well, rest assured that extending and enhancing this 1970s computer trainer is very much an exercise in respecting the original design, and while there’s a Pi inside, it doesn’t come close to spoiling the retro goodness.
Like many of a similar vintage as [Scott M. Baker], the Heathkit catalog was perhaps only leafed through marginally less than the annual Radio Shack catalog. One particularly desirable Heathkit item was the ET-3400 microcomputer learning system, which was basically a 6800-based computer surrounded by a breadboarding area for experimentation. [Scott] got a hold of one of these, but without the optional expansion accessory that would allow it to do interesting things such as running BASIC or even supporting a serial port. So [Scott] decided to roll his own expansion board.
The expansion card that [Scott] designed is not strictly a faithful reproduction, at least in terms of the original BOM. He turned to more modern — and more readily available — components, but still managed to provide the serial port, cassette interface, and RAM/ROM expansion of the original unit. The Raspberry Pi is an optional add-on, which just allows him to connect wirelessly if he wants. The card fits into a 3D-printed case that sits below the ET-3400 and maintains the original trainer’s look and feel. The longish video below shows the build and gives a tour of the ET-3400, both before and after the mods.
It looks as though trainers like these and other artifacts from the early days of the PC revolution are getting quite collectible. Makes us wish we hadn’t thrown some things out.