Here’s something fun from our hacker [Piers]: Software Defined ROMs.
In this series of three videos, [Piers] runs us through what a software defined ROM is, how to make them, and then how to use them.
As [Piers] explains, one frustration a retro technician will face is a failed ROM chip. In the era he’s interested in, there are basically three relevant kinds of ROM chip, all 24-pin Dual Inline Package (DIP):
- 2364 ROM chip: 8KB; 1x chip-select line
- 2332 ROM chip: 4KB; 2x chip-select lines
- 2316 ROM chip: 2KB; 3x chip-select lines
The chip-select line is how the processor indicates to a particular ROM chip that it should be active. When active, a ROM chip will read the value on the address lines and output the data at that address on the data lines.
With his software defined ROMs [Piers] implements the ROM behavior (converting requests on the address lines to results on the data lines) by using a microcontroller. As his ROM boards are software defined, they are eminently configurable, which means he can support all configurations of all three types of ROM.
[Piers] looks at some old ROM datasheets to get details about timing requirements. His functional requirements are that all three types of ROM can be emulated with a single hardware variant (the same microcontroller) with the same footprint (24-pin DIP), that they be hand-solderable, and cheap. Further technical requirements were that the solutions can all be implemented in software (no FPGA), requiring as few onboard components as possible, that the GPIOs be 5V tolerant, that a fast clock speed be available using the on-chip oscillator, that no more than two PCB layers are required, and that all SMD components are 0603 or larger.
He considered various microcontrollers, including PICO/RP2040/RP2350, ESP32, ATMEGA, PIC, STM32F1, and STM32F4. He really wanted the PICO because they are fast and powerful, but they don’t have 5V tolerant GPIOs, so he settled on the STM32F4 instead. He talks in detail about pin selection, PCB routing, and ROM preprocessing (mangling) for optimal performance. The chip loads its data from flash storage into RAM so it has reliable and deterministic performance characteristics. Provision is made for programming pins so the ROMs can be reprogrammed in-circuit.
When it comes to programming, [Piers] has implemented most things in hand-rolled assembly code. The reason, he says, is that he didn’t want variable implementations depending on the version of compiler used.
Now that you have a universal software defined ROM, all you need is a reliable ROM dumper.
Pretty sure Tyler already got to this one before you did, John: https://hackaday.com/2025/07/05/software-defined-retro-rom-makes-8-bit-easy/
Oh, whoops! Not sure how I missed that. Still, this post has two follow-up videos that were added since Tyler’s initial write-up.
True, true! Piers seems to really be on a roll. Looking forward to making use of his work when bit-rot inevitably sets in on my C64 or C128. :)
Thanks for pointing out this dupe, by the way. Nice catch. I have let the editors know, it’s up to them whether this post gets deleted or reworded or what. Thanks again. And yes, I definitely have this project bookmarked for when I one day need it! I really like this software defined approach to ROMs.