So I've been trying to figure out a way to make a mapper disable feature so I can program a UNROM devcart with my Kazzo
The obvious "easy" choice is a hardware mapper disable by making use of the EXP0 pin. But I need to do some work with the hardware and software to get all that to work. Then I wondered if possible solution would be to emulate the '161 counter with a mcu and have a software disable.
The main concern is timing obviously, ensuring the mcu is fast enough to bankswitch for the NES. I broke out the oscope and checked my frontloader and FC mobile II both, and found I had about 0.37 uSec worth of time while PRG R/W and PRG /CE were low. And figured out I should be able to make it work running at 20Mhz on my mcu.
So I wrote up some code quick and flashed up a Attiny44 and replaced the 161 on a UNROM cart with it. I kept the '32 OR gates, expecting I wouldn't be able to be quick enough to emulate it as well. I didn't have too high of hopes that it would work but I figured it was worth a try. Turned out it DID work. With some testing I quickly became critical of every minor glitch expecting it was a product of me emulating the counter. I made a mental list of about 6 minor glitches and soldered the 161 back in to see if they went away. To my further amazement all the glitches were still there, as far as I could tell I was emulating it "perfectly" as far as the NES and my FCmobile were concerned.
So my plan is to come up with some sort of software mapper defeat so I can write to the SRAM (and potentially Flash memory) I'm using with my discrete mapper dev cart. Basically I'll recognize a specific pattern of writing bits to the "counter." I could even use a larger mcu like a ATmega88 and gain access to the whole PRG DATA bus to create a more obscure pattern if needed.
My first question is do you guys have any recommendations as to what pattern I could use? I was imagining something like switching to 3 banks in a row, potentially not allowing time for reading from those banks. It would seem this kind of behavior wouldn't be non-sensible in a game. I haven't tested this out yet but if you guys can recommend something simple I'll do some tests.
Once I got this working I started realizing there may be more potential than I realized. First off with a bigger mcu I'll be able to easily emulate the counter for UxROM, AxROM, CNROM, and BNROM without requiring a TON of jumpers. I could just use a selector switch or two and add some extra hardware to enable/disable the '32 on the UxROM.
But I had another thought and wondered what you guys thought about it. Something like this could be used to add WRAM or other features to a UxROM style mapper. I know MMC1 is great for this capability, but if you don't want to use donors this would be simple and around half the cost or less. Now I realize this wouldn't run in emulators, but that's moot in my opinion. My greater concern would be compatibility with hardware and games. On that note I'll have to verify it works with my top loader since its sitting here next to me.
Anyways, just some food for thought there. Not sure if anyone's done this before or not, but figured I would share what I spent the afternoon playing around with. I seem to remember the question coming up at one point about using a mcu for a mapper and the quick answer was it was too slow. I thought it might be as well, but turns out it can be done.
The obvious "easy" choice is a hardware mapper disable by making use of the EXP0 pin. But I need to do some work with the hardware and software to get all that to work. Then I wondered if possible solution would be to emulate the '161 counter with a mcu and have a software disable.
The main concern is timing obviously, ensuring the mcu is fast enough to bankswitch for the NES. I broke out the oscope and checked my frontloader and FC mobile II both, and found I had about 0.37 uSec worth of time while PRG R/W and PRG /CE were low. And figured out I should be able to make it work running at 20Mhz on my mcu.
So I wrote up some code quick and flashed up a Attiny44 and replaced the 161 on a UNROM cart with it. I kept the '32 OR gates, expecting I wouldn't be able to be quick enough to emulate it as well. I didn't have too high of hopes that it would work but I figured it was worth a try. Turned out it DID work. With some testing I quickly became critical of every minor glitch expecting it was a product of me emulating the counter. I made a mental list of about 6 minor glitches and soldered the 161 back in to see if they went away. To my further amazement all the glitches were still there, as far as I could tell I was emulating it "perfectly" as far as the NES and my FCmobile were concerned.
So my plan is to come up with some sort of software mapper defeat so I can write to the SRAM (and potentially Flash memory) I'm using with my discrete mapper dev cart. Basically I'll recognize a specific pattern of writing bits to the "counter." I could even use a larger mcu like a ATmega88 and gain access to the whole PRG DATA bus to create a more obscure pattern if needed.
My first question is do you guys have any recommendations as to what pattern I could use? I was imagining something like switching to 3 banks in a row, potentially not allowing time for reading from those banks. It would seem this kind of behavior wouldn't be non-sensible in a game. I haven't tested this out yet but if you guys can recommend something simple I'll do some tests.
Once I got this working I started realizing there may be more potential than I realized. First off with a bigger mcu I'll be able to easily emulate the counter for UxROM, AxROM, CNROM, and BNROM without requiring a TON of jumpers. I could just use a selector switch or two and add some extra hardware to enable/disable the '32 on the UxROM.
But I had another thought and wondered what you guys thought about it. Something like this could be used to add WRAM or other features to a UxROM style mapper. I know MMC1 is great for this capability, but if you don't want to use donors this would be simple and around half the cost or less. Now I realize this wouldn't run in emulators, but that's moot in my opinion. My greater concern would be compatibility with hardware and games. On that note I'll have to verify it works with my top loader since its sitting here next to me.
Anyways, just some food for thought there. Not sure if anyone's done this before or not, but figured I would share what I spent the afternoon playing around with. I seem to remember the question coming up at one point about using a mcu for a mapper and the quick answer was it was too slow. I thought it might be as well, but turns out it can be done.