It is currently Sun May 26, 2019 7:56 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 12 posts ] 
Author Message
 Post subject: MMC1 banks at power
PostPosted: Fri Aug 06, 2010 9:39 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Aug 06, 2010 12:43 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21402
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Aug 06, 2010 12:52 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Aug 08, 2010 12:59 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7711
Location: Chexbres, VD, Switzerland
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Aug 08, 2010 1:09 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21402
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Aug 08, 2010 2:04 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Aug 08, 2010 2:23 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21402
Location: NE Indiana, USA (NTSC)
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.

Quote:
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?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Aug 08, 2010 3:21 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
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).

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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 07, 2011 2:19 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3141
Location: Tampere, Finland
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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 07, 2011 6:30 am 
Offline
User avatar

Joined: Sun Sep 07, 2008 7:27 am
Posts: 497
Location: Seatlle, WA, USA
http://www.retrousb.com/product_info.ph ... ucts_id=43

Where does Retrozone get their MMC1?

How does it behave?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 07, 2011 7:18 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21402
Location: NE Indiana, USA (NTSC)
clueless wrote:
Where does Retrozone get their MMC1?

RetroZone makes its own MMC1 out of a CPLD.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 07, 2011 8:09 am 
Offline
User avatar

Joined: Sun Sep 07, 2008 7:27 am
Posts: 497
Location: Seatlle, WA, USA
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)?"


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 10 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group