Page 1 of 2

MMC3 at wiki

Posted: Mon Apr 21, 2014 4:31 am
by thefox
NESDev wiki wrote:It was found recently that all banks, in the case of CHR RAM, are set to 0 on power up. More testing will be required to know if the same phenomenon happens for CHR ROM.
Where does this information originate from? I didn't see a "blame" tool on the Wiki, nor a tool to easily find out when a certain part of page was last modified.

Obviously, MMC3 wouldn't care whether CHR ROM or CHR RAM is mapped in, so the behavior should be the same for both. But I'm interested whether the claim about CHR banks booting up in an NROM-compatible way is true.

EDIT: Struck out because the question made no sense, wiki claimed the exact opposite.

Re: MMC3 at wiki

Posted: Mon Apr 21, 2014 5:16 am
by Banshaku
I think I wrote that long time ago, maybe in 2008. I don't remember the details though. That was when I started to experiment with my ff3 dev carts. What can I remember.. hmm.. I had different behavior than the emulator. I was expecting (I think ) banks to be 0 1 2 3 or something like that but I had 0 0 0 0. I think this was this issue.

I was starting nes programming so I didn't know much at the time.

Re: MMC3 at wiki

Posted: Mon Apr 21, 2014 6:06 am
by tepples
thefox wrote:Where does this information originate from? I didn't see a "blame" tool on the Wiki, nor a tool to easily find out when a certain part of page was last modified.
You could bisect the history to do this. Or you could write a tool that uses the MediaWiki API to bisect a page's history to find when a particular phrase was introduced.
But I'm interested whether the claim about CHR banks booting up in an NROM-compatible way is true.
It's unlikely.

Re: MMC3 at wiki

Posted: Mon Apr 21, 2014 9:04 am
by thefox
tepples wrote:
But I'm interested whether the claim about CHR banks booting up in an NROM-compatible way is true.
It's unlikely.
Bleh, I never meant to ask that in fact. I got confuzzled by the ancient doc that FARID posted in another thread (download/file.php?id=1486&mode=view), and somehow read the wiki page as meaning that the CHR banks would boot up in NROM configuration as the ancient doc claimed. I of course discredited the ancient doc right away.

Anyway, I'll edit out the part about CHR-ROM.

EDIT: I took out the whole sentence, I don't think it was that useful (no info at all what tests were used to determine it, or what chip revisions were tested).

Re: MMC3 at wiki

Posted: Mon Apr 21, 2014 11:26 am
by lidnariq
Barring any instance where a given latch has a specific required power-on-reset value, it's extremely likely that any given latch will power up to all 0s or all 1s, because of how CMOS and NMOS logic work.

Re: MMC3 at wiki

Posted: Mon Apr 21, 2014 12:57 pm
by tokumaru
I think it's important to say that the registers MUSt be configured by the program because they aren't neatly initialized to the expected order by the mapper on power up, but we shouldn't assume they'll always be 0.

Re: MMC3 at wiki

Posted: Mon Apr 21, 2014 1:05 pm
by lidnariq
I sometimes wish that emulators would default to open bus until initialized, rather than assuming any default state...

Re: MMC3 at wiki

Posted: Mon Apr 21, 2014 6:56 pm
by tepples
Interesting idea, but it has room for refinement. Requiring a mapper write in order to enable the ROM would break GNROM, Color Dreams, AOROM, BNROM, and UNROM (Crazy Climber configuration) from the moment the CPU tries to read the reset vector.

Re: MMC3 at wiki

Posted: Mon Apr 21, 2014 8:17 pm
by lidnariq
I can't think of a good foolproof way to deal with AxROM-like situations: a game could plausibly want to do something different depending on what bank is swapped in when it reads the reset vector. Picking a random bank on boot is probably as far as we can get and not break things that are valid.

Re: MMC3 at wiki

Posted: Tue Apr 22, 2014 3:03 am
by thefox
tokumaru wrote:I think it's important to say that the registers MUSt be configured by the program because they aren't neatly initialized to the expected order by the mapper on power up, but we shouldn't assume they'll always be 0.
Yeah, but this is just general programming knowledge, not MMC3 specific in any way, so I don't think it should be on the MMC3 page. Otherwise you'd have to put it on every mapper page.

Re: MMC3 at wiki

Posted: Tue Apr 22, 2014 5:15 am
by Banshaku
thefox wrote: EDIT: I took out the whole sentence, I don't think it was that useful (no info at all what tests were used to determine it, or what chip revisions were tested).
I could always retest is someday with the information regarding the chip revision but.. Well, after 6 years, maybe to just set your banks properly is the right answer anyway and this information doesn't have much value. I was contributing when I didn't know squat about nesdev at the time so sometime you document useless details for nothing. As for testing, I would have to dust up what I used for testing and finding the time is another issue.

The only test pattern was that my bank in 0 was shown in all case and I didn't know why since the emulator was showing something else. I was trusting too much the emulatlors, expecting that it should have a default state (which was not the case).

@Tepples

As for the wiki history, since it was moved, that information doesn't exist anymore. I moved it by hand, page by page since I didn't know how to export a wiki and wanted to have a stable one ASAP.

Re: MMC3 at wiki

Posted: Tue Apr 22, 2014 9:13 am
by thefox
Banshaku wrote:The only test pattern was that my bank in 0 was shown in all case and I didn't know why since the emulator was showing something else. I was trusting too much the emulatlors, expecting that it should have a default state (which was not the case).
Yeah it's a pretty common mistake when starting I guess. I have made the same mistake myself (~8 years ago), trying to put SMB1 on an MMC3 devcart. What's funny is that you'd expect it would be far easier for emulators to just initialize everything to zero, but they seem to go out of their way to initialize for compatibility with NROM, or whatever. Maybe some of it has something to do with iNES compatibility issues. One such issue that I can remember is that many emulators initialize MMC3 mirroring based on the flag from the iNES headers, because there are many mapper 206 ROMs out there that are marked as mapper 4. Mapper 206 is mostly compatible with MMC3, but doesn't have mirroring control (among other things).

That's why I plan to add mapper state power-up randomization into NintendulatorDX at some point.

Re: MMC3 at wiki

Posted: Tue Apr 22, 2014 9:22 am
by tepples
Perhaps they're initializing MMC3 mirroring from the iNES flag as a halfway method of supporting TEROM/TFROM configured for 206-compatibility mode.

Re: MMC3 at wiki

Posted: Tue Apr 22, 2014 11:22 am
by lidnariq
tepples wrote:TEROM/TFROM
Possible, but I suspect thefox is right: we've never found a Nintendo-manufactured board that was shipped with the jumpers at any position other than the default.

Re: MMC3 at wiki

Posted: Tue Apr 22, 2014 6:25 pm
by tokumaru
thefox wrote:Yeah, but this is just general programming knowledge, not MMC3 specific in any way, so I don't think it should be on the MMC3 page. Otherwise you'd have to put it on every mapper page.
True, it's general knowledge that all registers must be initialized, but maybe it's worth mentioning somewhere that the CHR banking is still active even if CHR-RAM is used instead of CHR-ROM. Most people who are not familiar with how the hardware works might not immediately understand how or why 8KB of memory banked to an 8KB addressing space would be chopped up and shuffled around. Before Banshaku confirmed this, I'm pretty sure I assumed that the 8KB of CHR-RAM in MMC3 boards were always mapped linearly, that the mapper-controlled CHR lines weren't even connected or something like that.