nesdev.com

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.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi

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.

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.


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

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi

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.

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.

I sometimes wish that emulators would default to open bus until initialized, rather than assuming any default state...

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.

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.

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.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi

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.

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.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi

Perhaps they're initializing MMC3 mirroring from the iNES flag as a halfway method of supporting TEROM/TFROM configured for 206-compatibility mode.

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.

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.