MMC1 banks at power
Moderator: Moderators
MMC1 banks at power
In preparation for the MMC1-based devcart, I tested the power-up state of the PRG and CHR bank selection bits of all 21 MMC1 games I have. I found that the four PRG bank bits powered up all set. The five CHR bank bits powered up all clear for Sharp-manufactured MMC1 chips, or all set for NEC-manufactured chips.
Sharp:
MMC1 Metroid
MMC1 Zelda
MMC1A Bionic Commando
MMC1A Blaster Master
MMC1B2 Battle of Olympus
MMC1B2 Blaster Master
MMC1B2 Castlevania 2
MMC1B2 Clash at Demonhead
MMC1B2 Faxanadu
MMC1B2 Faxanadu
MMC1B2 Fester's Quest
MMC1B2 Lolo 3
MMC1B2 Magic of Scheherazade
MMC1B2 Snake's Revenge
MMC1B2 Strider
MMC1B2 Ultima: Quest of the Avatar
MMC1B2 Zelda 2
NEC:
MMC1B2 Dragon Quest
MMC1B2 Flying Warriors
MMC1B2 Tombs and Treasure
MMC1B2 Willow
I partly did this because of mention that one must have the reset vector in every 16K bank. Based on the above, it only seems necessary to have a proper reset vector in the last bank and any bank that is selected for the $C000-$FFFF region during exectution, at least for these revisions.
Sharp:
MMC1 Metroid
MMC1 Zelda
MMC1A Bionic Commando
MMC1A Blaster Master
MMC1B2 Battle of Olympus
MMC1B2 Blaster Master
MMC1B2 Castlevania 2
MMC1B2 Clash at Demonhead
MMC1B2 Faxanadu
MMC1B2 Faxanadu
MMC1B2 Fester's Quest
MMC1B2 Lolo 3
MMC1B2 Magic of Scheherazade
MMC1B2 Snake's Revenge
MMC1B2 Strider
MMC1B2 Ultima: Quest of the Avatar
MMC1B2 Zelda 2
NEC:
MMC1B2 Dragon Quest
MMC1B2 Flying Warriors
MMC1B2 Tombs and Treasure
MMC1B2 Willow
I partly did this because of mention that one must have the reset vector in every 16K bank. Based on the above, it only seems necessary to have a proper reset vector in the last bank and any bank that is selected for the $C000-$FFFF region during exectution, at least for these revisions.
That might be true of the PRG bank bits, but what about the PRG bank mode bits (bits 2 and 3 of register $8000)? A Sharp might power up with banks 0 and 0 loaded if the mode is fixed low (bank 0 at $8000), or with banks 0 and 1 loaded if the mode is 32K. So you'll probably still want to use what I've been calling a "Barbie stub" in all banks.
For this test I had the CPU stuck driving the upper address lines high, so that it was finding what PRG bank was selected for the reset vector. In my tests of the MMC1, when you soft-reset it (write byte with high bit set), it sets bits 2 and 3 of the $8000 register, putting the last PRG bank in $C000-$FFFF. I'm assuming this is what's going on, rather than the PRG bank bits at $E000 being set to all ones. The cause isn't as important as it consistently using the last bank, because if I can rely on this, the design is simplified.
Do we have any evidence that this isn't the case? It'd be really useful to have that documented. Note that the question here is only what bank it gets the reset vector from when powering up, not when the reset button is pressed. In the latter case, the reset vector gets fetched from whatever bank happens to be selected for $C000-$FFFF, which is entirely due to the running program, rather than the MMC1. If the program could have any bank in that region, then clearly it must have the reset vector and handler in every bank as well.
Do we have any evidence that this isn't the case? It'd be really useful to have that documented. Note that the question here is only what bank it gets the reset vector from when powering up, not when the reset button is pressed. In the latter case, the reset vector gets fetched from whatever bank happens to be selected for $C000-$FFFF, which is entirely due to the running program, rather than the MMC1. If the program could have any bank in that region, then clearly it must have the reset vector and handler in every bank as well.
From what Blargg said, all PRG banks are set - so 3 cases can happen :
1) 16k low switching mode, with banks 15 and 15 switched
2) 16k high switching mode, with banks 0 and 15 switched
3) 32k switchig mode, banks 14 and 15 switched.
In all cases bank 15 is switched at $c000-$ffff so it's safe to put your reset code here.
I think only some very old MMC1 games have a reset vector in all banks. Probably because Nintendo didn't know their own hardware very well or because those games use 16k high or 32k switching mode.
1) 16k low switching mode, with banks 15 and 15 switched
2) 16k high switching mode, with banks 0 and 15 switched
3) 32k switchig mode, banks 14 and 15 switched.
In all cases bank 15 is switched at $c000-$ffff so it's safe to put your reset code here.
I think only some very old MMC1 games have a reset vector in all banks. Probably because Nintendo didn't know their own hardware very well or because those games use 16k high or 32k switching mode.
Useless, lumbering half-wits don't scare us.
Only the CHR bank bits differed on the NEC Chip; the PRG bits were all set for both manufacturers. I just re-tested one of each in a different setup, with my own edge connector wired with A14 high, /PRG low, and RD asserted, and powered up the boards many times in a row to be really sure.
The reason I wanted to confirm this behavior is that the Flash chip (put in place of the original PRG ROM) must contain some code which is always guaranteed to run before anything else, and must never be erased, since the design has no separate cartridge programmer or removable memory. If this code gets corrupt, then the cartridge is bricked and must be mailed back for reprogramming. The Flash allows using an EPROM programmer to protect any of the 64K-sized segments, but this wouldn't be any help if the MMC1 could power up to any segment, and would require significant extra circuitry to always power up in the last segment (in comparison to what we're doing, which is just a few cut traces and jumpers). Unfortunately the CHR bank difference on NEC means that boards containing an NEC MMC1 must have it swapped with a Sharp MMC1, but it seems that Sharp is at least twice as common, so it shouldn't be that often.
...as long as you don't ever switch any other banks there, or don't mind the reset button not always working.Bregalad wrote:In all cases bank 15 is switched at $c000-$ffff so it's safe to put your reset code here.
The reason I wanted to confirm this behavior is that the Flash chip (put in place of the original PRG ROM) must contain some code which is always guaranteed to run before anything else, and must never be erased, since the design has no separate cartridge programmer or removable memory. If this code gets corrupt, then the cartridge is bricked and must be mailed back for reprogramming. The Flash allows using an EPROM programmer to protect any of the 64K-sized segments, but this wouldn't be any help if the MMC1 could power up to any segment, and would require significant extra circuitry to always power up in the last segment (in comparison to what we're doing, which is just a few cut traces and jumpers). Unfortunately the CHR bank difference on NEC means that boards containing an NEC MMC1 must have it swapped with a Sharp MMC1, but it seems that Sharp is at least twice as common, so it shouldn't be that often.
Sorry, I must have either misread something or had that SUROM tech demo idea from #nesdev on my mind. In SUROM, which uses one of the CHR bank bits to switch between two PRG ROM superbanks, banks 15 and 31 would definitely both need a reset stub.blargg wrote:Only the CHR bank bits differed on the NEC Chip; the PRG bits were all set for both manufacturers.
Does this code need to run after a reset, or can it run only after a power cycle? Would using two flash chips with separate enables help, or would the glue logic to decode them be prohibitive?The reason I wanted to confirm this behavior is that the Flash chip (put in place of the original PRG ROM) must contain some code which is always guaranteed to run before anything else, and must never be erased
Well, actually I will be using one of the CHR bank lines to select between the two 256K halves of the Flash, which is why the NEC chips aren't desired (I'll also be using a couple of the other ones as a Flash write enable, and MMC1 disable, so they all need to have definite states at power).
Glue logic would be very undesired; if this design using just a couple of resistors and diodes will work, then I want to avoid extra chips. The basic idea is the cheapest cart that's reprogrammable by the end user, can't be bricked, and is easy to construct with minimal modification of an existing cart.
Picture from when I was testing all the MMC1 carts I have:
It could run after any reset, though I'm not sure how that would help. If it powers and executes unknown code, then there's no simple way you're going to get into a known state after a reset.Does this code need to run after a reset, or can it run only after a power cycle? Would using two flash chips with separate enables help, or would the glue logic to decode them be prohibitive?
Glue logic would be very undesired; if this design using just a couple of resistors and diodes will work, then I want to avoid extra chips. The basic idea is the cheapest cart that's reprogrammable by the end user, can't be bricked, and is easy to construct with minimal modification of an existing cart.
Picture from when I was testing all the MMC1 carts I have:
This info should be added to the wiki. I think we can be fairly certain that all revisions start up in mode where last bank is at $C000-$FFFF.
So blargg tested four revisions of MMC1. What other revisions are there?
So blargg tested four revisions of MMC1. What other revisions are there?
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
http://www.retrousb.com/product_info.ph ... ucts_id=43
Where does Retrozone get their MMC1?
How does it behave?
Where does Retrozone get their MMC1?
How does it behave?