MMC1 banks at power

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

Post Reply
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

MMC1 banks at power

Post by blargg » Fri Aug 06, 2010 9:39 am

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.

tepples
Posts: 21748
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Fri Aug 06, 2010 12:43 pm

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.

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Fri Aug 06, 2010 12:52 pm

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.

User avatar
Bregalad
Posts: 7766
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Sun Aug 08, 2010 12:59 pm

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.
Life is complex: it has both real and imaginary components.

tepples
Posts: 21748
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Sun Aug 08, 2010 1:09 pm

Bregalad wrote:From what Blargg said, all PRG banks are set
On an NEC chip. On a Sharp chip, it could be 0/15, 0/0, or 0/1 until the code soft-resets the chip.

I looked at Bomberman 2, and it also had something in every bank.

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Sun Aug 08, 2010 2:04 pm

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.
Bregalad wrote:In all cases bank 15 is switched at $c000-$ffff so it's safe to put your reset code here.
...as long as you don't ever switch any other banks there, or don't mind the reset button not always working.

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.

tepples
Posts: 21748
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Sun Aug 08, 2010 2:23 pm

blargg wrote:Only the CHR bank bits differed on the NEC Chip; the PRG bits were all set for both manufacturers.
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.
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
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?

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Sun Aug 08, 2010 3:21 pm

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).
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?
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.

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:
Image

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Post by thefox » Fri Jan 07, 2011 2:19 am

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?
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

User avatar
clueless
Posts: 498
Joined: Sun Sep 07, 2008 7:27 am
Location: Seatlle, WA, USA

Post by clueless » Fri Jan 07, 2011 6:30 am

http://www.retrousb.com/product_info.ph ... ucts_id=43

Where does Retrozone get their MMC1?

How does it behave?

tepples
Posts: 21748
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Fri Jan 07, 2011 7:18 am

clueless wrote:Where does Retrozone get their MMC1?
RetroZone makes its own MMC1 out of a CPLD.

User avatar
clueless
Posts: 498
Joined: Sun Sep 07, 2008 7:27 am
Location: Seatlle, WA, USA

Post by clueless » Fri Jan 07, 2011 8:09 am

tepples wrote:
clueless wrote:Where does Retrozone get their MMC1?
RetroZone makes its own MMC1 out of a CPLD.
That is what I thought. The bigger question is, "how does it behave (per the tests that Blarrg is doing)?"

Post Reply