Talk:MMC3

The hardware section of this page needs to be tidied up a bit, because right now, it's just a giant infodump with little organization. :P --Drag 13:09, 4 June 2012 (PDT)

There's some documentation about the differences between MMC3 revisions here: [1] I'll add them in at some point, if nobody else does. --Drag 18:00, 19 April 2011 (UTC)

PRG RAM bank behavior

When PRG RAM is accessed via $6000-$7FFF, what does the MMC3 put on the upper PRG ROM address lines? --Tepples 23:24, 20 April 2011 (UTC)

Ideally, the MMC3 wouldn't put anything on the ROM address lines. :P Either way, if the CPU is accessing $6000-7FFF, I'd imagine whatever chip is selected would see %011xxxxx xxxxxxxx on its address lines. RAM would just see the x part, and whatever mapper-supplemented upper address lines if the RAM is bankswitched. --Drag 04:05, 21 April 2011 (UTC)

When I hear "wouldn't put anything", I think "high impedance". It appears you claim that if $6000-$7FFF is accessed, the PRG A13 through PRG A18 outputs from the mapper are high-Z, not the value in either PRG bank register. Do I misunderstand? --Tepples 22:42, 21 April 2011 (UTC)

The simplest thing electrically is to never disable the address drivers. Given how MMC3 works I'd guess it drives the upper address lines high. Lidnariq 18:08, 22 April 2011 (UTC)

Actually, I'm not entirely sure I understand what you're saying. When you say PRG ROM address lines, I thought you meant the address lines on the actual ROM. Yes, even if the CPU is accessing $6000-7FFF, the ROM would still see the address bus, but it won't do anything with it, because the mapper won't select the chip. That's what I meant by "wouldn't put anything on the ROM address lines". Even though it's physically putting something there, the ROM is disabled so it never does anything with it.

If you're talking about what happens with WRAM, I imagine the chip wouldn't have the upper three address lines, unless the RAM is bankswitched. --Drag 07:33, 25 April 2011 (UTC)

I was asking whether or not it's feasible to build PRG RAM bankswitching by running the same upper address lines out of the mapper to both PRG ROM and PRG RAM. When PRG RAM is being accessed, what is the voltage on each of the upper address lines PRG A18-A13 (pins 23, 25, 21, 18, 22, 19) coming out of the MMC3? Does it depend on either of the PRG ROM bank values, or is it a constant value? --Tepples 13:25, 25 April 2011 (UTC)

Ahh, ok, that makes more sense. The MMC3 outputs different things to the most significant rom bits depending on what address is being accessed, so it's entirely possible that the circuitry involved selects between a couple different latches, depending on bits 14 and 13 of the PRG address. If it uses an ordinary decoder, then it's possible that bit 15 goes to the /OE of whatever multiplexer it uses.

TL;DR: The "banks" for $0000-$7FFF may mirror the bank configuration of $8000-$FFFF, or it may not. Either way, accessing $6000-7FFF is like accessing $E000-FFFF (which is fixed to the last bank), so whether it looks at A15 or not, you'll probably end up with all 1's across A13+. This is just my speculation though. --Drag 19:56, 25 April 2011 (UTC)

I can't say for sure, because very complex equipment would be needed to verify this, but it's extremely likely that the MMC3's PRG-banking ciruitery completely ignores the state of A15. That is, acessing any adress with A15 low will have the higher adress lines pointed to the same latch as if the corresponding adress with A15 high was used. In particular, when acessing $6000-$7fff, the MMC3 will act like when acessing $e000-$ffff (which means all adress lines will go high, pointing to the "last-hardwired" bank).

This hypothesis is especially robust when you consider there is no A15 on the cart edge, so you have to invert PRG /CE to get the state of A15. Also, when the PPU fetches nametable area ($2000-$2fff), the MMC3 does bank the CHR-ROM exactly like when acessing the corresponding area with A13 low, that is $0000-$1fff, and the TLSROM and TKSROM boards makes a good use of this.

This is valid not only for the MMC3 but for 99% of mappers in fact : Anyone would be crazy to add extra circuitry in their chips so that it acts differently when the CPU is adressing space where the ROM will never respond anyways. (Probably only mappers such as the MMC5 or FME7, which can map ROM and RAM anywhere regardless of the state of A15, will not follow this rule). So, no, sorry but no PRG-RAM switching would be possible on MMC3. But any mapper that was not designed to switch PRG-RAM, but that was designed to switch PRG-ROM at $e000-$ffff could be abused to also switch RAM. Bregalad 11:39, 1 May 2011 (UTC)

MMC3 scanline counter

What happens when both background and sprites are fetched from $1xxx? --Zepper 02:28, 8 November 2011 (UTC)

I think that should disable IRQs, because A12 will never be 0 for longer than 4 pixels —Lidnariq (talk) 14:12, 25 January 2015 (MST)

Even during the dummy fetches at the end of a line (337-340)? --Tepples (talk) 16:03, 25 January 2015 (MST)

Depends on what the idle cycle's address is. If A12 is 0 during it, then A12 could be low for 9 pixels. And then that gets into the question below… —Lidnariq (talk) 17:40, 25 January 2015 (MST)

The MMC3 scanline counter is based entirely on PPU A12, triggered on rising edges (after the line remains low for a sufficiently long period of time) Which period of time exactly? —anonymous contributer from 94.254.14.226

Without clocking it manually, it's hard to say, but certainly not more than 64 pixels (because it still works if the pattern tables are swapped). See also https://github.com/christopherpow/nes-test-roms/tree/master/mmc3_irq_tests ; test 3.4 there also requires that it be no longer than ≈22cy, but that's about the same as 64 pixels. —Lidnariq (talk) 14:01, 25 January 2015 (MST)

I performed some tests using my own dumper and real cartridge. Seems like IRQ counter working when there are 2 rising edges of M2 between falling and rising of A12. It's the only one necessary condition. —83.149.9.144 07:25, 31 January 2015 (MST)

Oversize "non-compliance"?

I could use a clarification about this edit by Lidnariq. If the ROM size is <= 512K the top two data bits have to be ignored when writing the bank register. What possible incompatibility could result from implementing an 8-bit register? Why would an emulator choose to present an error to the user instead of simply supporting the oversize ROM? - Rainwarrior (talk) 13:59, 30 May 2015 (MDT)

For the same reason that NES emulators shouldn't implement a plugin that takes in arbitrary video and quantizes it to the NES output: the hardware that does that doesn't exist. Same problem with ROM hacks that only work in Nesticle. Emulators must implement the restrictions of the hardware, because otherwise you end up with crap like the aforementioned ROM hack where because they don't understand why they're not allowed to do that, they include patches to hack FCEUXDSP and Nintendulator to support their BS oversize ROM, and no-one can ever make a reproduction that uses an MMC3. —Lidnariq (talk) 14:55, 30 May 2015 (MDT)

Ahh, the extension seems extremely logical and straightforward to me, but after checking FCEUX, Nestopia, and Nintendulator, I can see that all of them prevent oversized MMC3. I don't really understand the motivation for this (does it create other software incompatibility?), but the lack of emulator support is good reason to remove oversize support from the infobox. Hadn't read the description of that romhack either (was just part of a merge), but it's kind of interesting that not much supports it. I'll revise. - Rainwarrior (talk) 15:15, 30 May 2015 (MDT)