Hey Guys,
I know, we can't turn the popular microcontroller into a famicom mapper due to the limitation of process speed.
All the famicom mapper solution are using cpld/fpga.
But i still wanna know, if the microcontroller is fast enough, can we use it as alternative solution for famicom mapper?
Such as: Rasp Pico..etc. I don't know .
The motivation of this question is thE Core of new Nintendo game and watch .It is using ARM uC from ST for 6502 system and buy the home brew of the hacking result, it can play so many game with difference mapper.
Alternative Solution for Famicom mapper?
Moderator: Moderators
Alternative Solution for Famicom mapper?
Last edited by Ten1hc on Sat Mar 04, 2023 9:32 pm, edited 1 time in total.
- jeffythedragonslayer
- Posts: 344
- Joined: Thu Dec 09, 2021 12:29 pm
Re: Alternatice Solution for Famicom mapper?
Ya, ARM or any platform
Re: Alternatice Solution for Famicom mapper?
Oddly enough, it's not only processor speed. It's that stupidly fast systems aren't engineered to deal with low latency low jitter systems. So you're right that you can't use an AVR as a mapper, because it's too slow, but you also can't use most STM32s because they have too much state and aren't designed for low-latency GPIO.
One: There are basically no microcontrollers that can deal with the Famicom's entirely separate CPU and PPU buses. You should just assume that's completely out of scope, and if you want CHR bankswitching you're going to have to farm it out to some kind of programmable logic or multiple microcontrollers.But i still wanna know, if the microcontroller is fast enough, can we use it as alternative solution for famicom mapper?
Such as: Rasp Pico..etc.
Two: There are very few and very specific microcontrollers that are actually suitable for emulating a mapper. The RP2040 looks like it should be one of them - but note that it has very few pins. Only the simpler mappers will fit.
Three: Once you have the RP2040, which can address 16 MiB of serial flash on its own, there's no reason to even bother with external parallel memory. Both the timing will end up being more predictable and also the cost will be lower if one makes a ROMulator with integrated banking, vs relying on external serial NOR to boot the RP2040 and external parallel NOR for the Famicom CPU.
Re: Alternatice Solution for Famicom mapper?
Thank you very much.lidnariq wrote: ↑Sat Mar 04, 2023 12:41 pmOddly enough, it's not only processor speed. It's that stupidly fast systems aren't engineered to deal with low latency low jitter systems. So you're right that you can't use an AVR as a mapper, because it's too slow, but you also can't use most STM32s because they have too much state and aren't designed for low-latency GPIO.
One: There are basically no microcontrollers that can deal with the Famicom's entirely separate CPU and PPU buses. You should just assume that's completely out of scope, and if you want CHR bankswitching you're going to have to farm it out to some kind of programmable logic or multiple microcontrollers.But i still wanna know, if the microcontroller is fast enough, can we use it as alternative solution for famicom mapper?
Such as: Rasp Pico..etc.
Two: There are very few and very specific microcontrollers that are actually suitable for emulating a mapper. The RP2040 looks like it should be one of them - but note that it has very few pins. Only the simpler mappers will fit.
Three: Once you have the RP2040, which can address 16 MiB of serial flash on its own, there's no reason to even bother with external parallel memory. Both the timing will end up being more predictable and also the cost will be lower if one makes a ROMulator with integrated banking, vs relying on external serial NOR to boot the RP2040 and external parallel NOR for the Famicom CPU.
Seem there is no perfect solution can replace the cpld/fpga solution