People on Discord will already have seen a few snippets from this, but I decided to create a thread to aggregate updates on a project I've been working on for the past couple of years:
Trirosmos' Fully-Featured Flash Cart
It's a flash cart in the EverDrive sense, not the " flash a single-game to it at a time " one.
For the longest time, I was convinced that fast, modern microcontrollers ought to be able to emulate parallel ROMs at the speeds required by these old consoles. I selected the Master System as the target to test this concept on since it's a relatively popular console in Brazil, has a cartridge interface that is simpler than that of the NES or other contemporary systems and doesn't require implementing nearly as many mappers as the NES does.
Over time, I fell in love with the SMS and started planning way more features for this cartridge. The current goal is to make the most fully-featured flash cart the SMS has ever received, while keeping it pretty accessible, especially for brazilians, to whom importing electronics is really difficult and expensive.
Instead of expensive and relatively niche programmable logic devices, this cartridge is based on the RP2040 microcontroller and uses fast QSPI flash instead of the usual parallel NOR flash or the more expensive PSRAMs or SDRAMs.
All of the cartridge's components are fed by a regulated 3.3v supply and the entire cartridge bus goes through level shifters.
Current features
- Sega mapper support with proper slot 0 mapping and 32 KiB of SRAM. Battery saves are stored in the SD card.
- ROMs up to 2 MiB in size.
- Relatively fast loading: about 150 KiB/s.
- OPLL and PSG emulation, with a built-in audio output jack.
- In-game quick save states, accessible through button combos on a Mega Drive controller.
- Game soft reset, pause and return to menu through Mega Drive controller button combos.
- Up to 1024 files per directory, with alphabetical sorting.
- Fast menu navigation.
Features planned for next firmware versions
- Codemasters and Korean mapper support, with a games database.
- In-game menu which makes more save state slots available.
- Configurable in-game menu, pause and save button combos.
- Enhanced PSG mode, with configurable wavetables.
- Configurable OPLL and PSG channel volumes.
- Automatic IPS patching.
- PAR-style cheats.
- Per-game in-game hooks and audio settings.
- Costumizable menu color palettes.
- Cycle-accurate VGM player.
Features planned that will require a new hardware revision
- DMA mapper.
- Support for ROMs up to 15 MiB.
- Saving SRAM and save states to the SD card without having to go back to the main menu.
I can't offer any real estimates of when exactly it will be available or what the final asking price will be, but I am at least pretty sure it will be cheaper than the Master EverDrive X7 😛
I will soon record some short feature showcase videos and will post updates here as they happen.
this is great, I just wonder what's the reason behind the limitation of the ROM size at 2 MiB instead of going the full 8-bit SEGA Mapper specs with 4 MiB... ?
this is great, I just wonder what's the reason behind the limitation of the ROM size at 2 MiB instead of going the full 8-bit SEGA Mapper specs with 4 MiB... ?
The current prototype board has 4 MiB of flash, and some of it needs to be reserved for the firmware.
Not to worry, tho, QSPI flash is fairly inexpensive and the next board revision is gonna have 16 MiB of it 😀
Edit: Just to expand on this, I was initially planning on using PSRAM to store the ROMs. In fact, this board does have 8 MiB of QSPI PSRAM. That's why I chose to go with just 4 MiB of flash for this prototype, I didn't think I'd need it for the actual ROMs.
However, in testing how fast flash programming was, I realized it was not nearly as slow as I thought, only about 2x slower than RAM. The main bottleneck really is the SD card access, it turns out.
So, I ultimately decided to ditch the PSRAM, since it increased the BOM cost by, like, 50%, with the only upside being somewhat faster load times.
The current prototype board has 4 MiB of flash, and some of it needs to be reserved for the firmware.
You mean it supports ROMs up to almost 4 MiB?
I mean, SEGA mapper with 8 bits page number?
Yes. Out of the 4 MiB of flash, I have 2 MiB reserved for the firmware, but it's not all being used currently. So, ROMs could be, say, 3.5 MiB in size, I'd just have to change the linker script.
However, none of this matters. It's not a limitation with the mapper implementation, it's just that this specific board doesn't have a larger memory. I could, in fact, desolder the QSPI flash and replace it with a larger chip if I really wanted to.
I'm gonna leave that for the next hardware revision, tho 🙂
Edit: Just to expand on this, I was initially planning on using PSRAM to store the ROMs. In fact, this board does have 8 MiB of QSPI PSRAM. That's why I chose to go with just 4 MiB of flash for this prototype, I didn't think I'd need it for the actual ROMs.
However, in testing how fast flash programming was, I realized it was not nearly as slow as I thought, only about 2x slower than RAM. The main bottleneck really is the SD card access, it turns out.
So, I ultimately decided to ditch the PSRAM, since it increased the BOM cost by, like, 50%, with the only upside being somewhat faster load times.
That's really interesting. I don't think I realised at all that you were using a serial device to host the ROM. It's something I had kind of discounted myself but maybe I should take a look at the timings again. Unfortunately I hardwired the WP pin in my prototype (not to mention I'm super short on I/O) so can't try QSPI mode without a revision.
So at 150 KB/s you can load most games in just 2 or 3 seconds right - seems perfectly reasonable to me! And that's essentially dictated by the maximum speed you can read off the SD?
That's really interesting. I don't think I realised at all that you were using a serial device to host the ROM. It's something I had kind of discounted myself but maybe I should take a look at the timings again.
Turns out the Z80 is pretty slow, fortunately 🙂
Looking at the datasheet for a QSPI flash chip (the W25Q128JV, in this case), you'll see that it takes around 20-ish cycles to read a random byte from it, using quad I/O.
At the max clock speed specified for that chip of 133 MHz, that works out to around 158 ns.
However, a good chunk of that time is just spent on sending the command byte, since it has to be sent using a single data line instead of all four. What's neat tho is that you can append the command to the end of the previous read, so the actual read latency will be of only around 16 cycles, which gets you to the 120 ns ballpark.
The QSPI PSRAM I was using was from Lyontek, but AP Memory also makes some models. They use pretty much the exact same interface, but writes are much faster, of course. They're also significantly more expensive than flash memory.
willbritton wrote
So at 150 KB/s you can load most games in just 2 or 3 seconds right - seems perfectly reasonable to me! And that's essentially dictated by the maximum speed you can read off the SD?
Yeah! Sonic Blast takes around 6.5-ish seconds to load, for instance.
The average read speeds I'm getting from the SD card are actually around twice that, using a 20 MHz clock and SPI mode, but erasing the flash chip takes about as much time as programming it.
Nice, I was just reviewing my datasheet – I'm using the WinBond W25Q80, which interestingly has an optional mode switch on the fast read I/O commands so that you don't need to send the command byte every random access - just the address.
Yes. Out of the 4 MiB of flash, I have 2 MiB reserved for the firmware, but it's not all being used currently. So, ROMs could be, say, 3.5 MiB in size, I'd just have to change the linker script.
However, none of this matters. It's not a limitation with the mapper implementation, it's just that this specific board doesn't have a larger memory.
I suspect it would matter in some way. I expect future homebrews to need as much ROM as possible, still retaining the SEGA Mapper features, so even 3.xx MiB available would be better than 2 MiB...
Yes. Out of the 4 MiB of flash, I have 2 MiB reserved for the firmware, but it's not all being used currently. So, ROMs could be, say, 3.5 MiB in size, I'd just have to change the linker script.
However, none of this matters. It's not a limitation with the mapper implementation, it's just that this specific board doesn't have a larger memory.
I suspect it would matter in some way. I expect future homebrews to need as much ROM as possible, still retaining the SEGA Mapper features, so even 3.xx MiB available would be better than 2 MiB...
I think trirosmos is saying it doesn't matter because this is just a prototype board and the real thing will have more capacity.
Yes. Out of the 4 MiB of flash, I have 2 MiB reserved for the firmware, but it's not all being used currently. So, ROMs could be, say, 3.5 MiB in size, I'd just have to change the linker script.
However, none of this matters. It's not a limitation with the mapper implementation, it's just that this specific board doesn't have a larger memory.
I suspect it would matter in some way. I expect future homebrews to need as much ROM as possible, still retaining the SEGA Mapper features, so even 3.xx MiB available would be better than 2 MiB...
I think trirosmos is saying it doesn't matter because this is just a prototype board and the real thing will have more capacity.
Yeah, exactly. " Features planned that will require a new hardware revision" is not " things I've maybe thought about doing, but who knows ", it's " things that are already included in the design for the next hardware revision ".
I think trirosmos is saying it doesn't matter because this is just a prototype board and the real thing will have more capacity.
oh, so I misunderstood this, my bad. I thought this was the hardware he was going to release 'now', with an improved one 'later'.
sorry everybody :|
Ah, I see why the confusion now.
Yeah, no, this hardware is definitely not final. I anticipate that there will be at least a couple more prototype versions before I release this :)
Speaking of prototypes, here's a short video showcasing most of the features of the current one:
I think trirosmos is saying it doesn't matter because this is just a prototype board and the real thing will have more capacity.
oh, so I misunderstood this, my bad. I thought this was the hardware he was going to release 'now', with an improved one 'later'.
sorry everybody :|
Ah, I see why the confusion now.
Yeah, no, this hardware is definitely not final. I anticipate that there will be at least a couple more prototype versions before I release this :)
Speaking of prototypes, here's a short video showcasing most of the features of the current one:
Now i know your true identity! LOL. You are Marcelo! Fluminense´s soccer player!
