MMC3
The NES power expander
Nintendo's MMC3 mapper chip enabled larger, more sophisticated NES games through bank switching, scanline counting, and expanded capabilities.
The NES’s base hardware had limitations that mapper chips overcame. The MMC3 (Memory Management Controller 3) was Nintendo’s most widely used advanced mapper, enabling bank switching for larger ROMs, scanline IRQs for split-screen effects, and additional RAM. Games like Super Mario Bros. 3 and Kirby’s Adventure used MMC3 to exceed what the base NES could achieve.
The scanline counter that does not count scanlines
The MMC3’s headline feature is a scanline interrupt, which let Super Mario Bros. 3 hold a status bar still while the world scrolled behind it. The mapper has no idea what a scanline is. It watches one wire.
The MMC3 scanline counter is based entirely on PPU A12, triggered on a rising edge after the line has remained low for three falling edges of M2.
A12 is address line 12 of the picture processing unit. The mapper infers the
passage of a scanline from a side effect of how the PPU fetches graphics:
whenever rendering is turned on in the PPU, it fetches nametable and BG pattern tiles from dots 0-255 and 320-340 of a scanline and fetches sprite patterns from dots 256-319, even if no sprites are visible.
So if a game puts its background tiles in the low pattern table and its sprites in the high one, A12 stays low through the background fetches and goes high through the sprite fetches — “causing it to oscillate exactly one time per scanline and 241 times per frame”.
The interrupt is not a timer. It is a cartridge eavesdropping on the video chip’s address bus and counting a pattern that only exists because the PPU fetches sprite data whether or not there are sprites. A game that arranges its pattern tables the other way round breaks its own interrupts.
Two chips, two behaviours
The MMC3 came from more than one manufacturer, and they do not agree:
| Maker | When $C000 is $00 |
Fires when the counter is |
|---|---|---|
| NEC | a single IRQ | decremented to 0 |
| Sharp | an IRQ every scanline | equal to 0 |
The community calls NEC’s the “alternate” or “old” behaviour and Sharp’s the “normal” or “new” one. Three revisions exist — MMC3A, MMC3B and MMC3C — with “no major behavioral differences known, except for the IRQ counter”, and while NEC’s part is “implemented within a 13x56 CMOS gate array”, “the implementation method used by Sharp is not yet known”.
There is also a case nobody has pinned down. Writing $C001 on consecutive
scanlines “can cause pathological behavior”, and the documentation is candid
about where that leaves things: “Because this behavior is not fully understood,
emulators do not yet emulate it.”
Two cartridges bearing the same mapper number, holding the same game, can interrupt at different moments depending on which company etched the chip.
Fast facts
- Manufacturer: Nintendo.
- iNES mapper number: 4 (board family TxROM, including TGROM, TKROM, TLROM, TSROM).
- Purpose: extend NES capabilities beyond the base hardware’s 32 KB PRG / 8 KB CHR ceiling.
- Features: PRG and CHR bank switching, A12-clocked IRQ counter for mid-frame splits, mirroring control, optional 8 KB battery-backed PRG-RAM.
- PRG ROM: up to 512 KB (8 KB granularity).
- CHR ROM/RAM: up to 256 KB (1 KB granularity).
- PRG-RAM: 8 KB at $6000-$7FFF (battery-backed in TKROM/TSROM boards).
- Notable games: Super Mario Bros. 3, Mega Man 3-6, Kirby’s Adventure, Crystalis, Castlevania III.
Bank switching
PRG banking ($8000-$FFFF)
PRG ROM is split into four 8 KB windows. Two are switchable, one is switchable, and one is fixed to the last bank — but the bank-mode bit (bit 6 of the value written to $8000) decides which two are switchable:
| PRG mode (bit 6 of $8000) | $8000-$9FFF | $A000-$BFFF | $C000-$DFFF | $E000-$FFFF |
|---|---|---|---|---|
| 0 | bank R6 | bank R7 | second-to-last | last |
| 1 | second-to-last | bank R7 | bank R6 | last |
The last bank is always fixed at $E000-$FFFF (so reset/IRQ/NMI vectors stay reachable). R6 and R7 are general 8 KB bank registers.
CHR banking ($0000-$1FFF in PPU space)
CHR is split into two 2 KB regions and four 1 KB regions. The CHR-mode bit (bit 7 of $8000) decides which half of pattern-table space gets the 2 KB banks:
| CHR mode (bit 7 of $8000) | $0000-$07FF | $0800-$0FFF | $1000-$13FF | $1400-$17FF | $1800-$1BFF | $1C00-$1FFF |
|---|---|---|---|---|---|---|
| 0 | R0 (2 KB) | R1 (2 KB) | R2 | R3 | R4 | R5 |
| 1 | R2 | R3 | R4 | R5 | R0 (2 KB) | R1 (2 KB) |
R0 and R1 are 2 KB-aligned (their low bit is ignored). R2-R5 are 1 KB banks.
Register map
| Address | Even (A0=0) | Odd (A0=1) |
|---|---|---|
| $8000-$9FFF | Bank select (bits 0-2 = R0-R7 select; bit 6 = PRG mode; bit 7 = CHR mode) | Bank data (writes the selected R-register) |
| $A000-$BFFF | Mirroring (bit 0: 0=vertical, 1=horizontal) | PRG-RAM protect (bit 6 = read-only, bit 7 = enable) |
| $C000-$DFFF | IRQ latch (8-bit reload value) | IRQ reload (writes here force counter reload on next clock) |
| $E000-$FFFF | IRQ disable + acknowledge | IRQ enable |
Each register pair is selected by the address’s low bit — write to even addresses for the first column, odd addresses for the second. Mirroring control via $A000 has no effect on cartridges hard-wired for four-screen mirroring (which use 4 KB of cartridge VRAM instead of CIRAM).
How the IRQ works
MMC3’s IRQ counter is not clocked by a scanline counter. It clocks on each rising edge of PPU address bit A12 — which happens whenever the PPU fetches from $1000-$1FFF after a fetch from $0000-$0FFF.
During normal rendering, the PPU performs background tile fetches in one half of pattern-table space and sprite fetches in the other half. The standard idiom: put background tiles in $0000-$0FFF and sprite tiles in $1000-$1FFF (PPUCTRL bits 3 and 4). On most scanlines this produces exactly one A12 rising edge per scanline (during sprite fetch cycles), so the IRQ counter behaves as a scanline counter — but only if the game arranges its pattern tables that way. Nintendo did not leave that to chance; see below.
Sequence to schedule an IRQ N scanlines into the visible frame:
- Write N to
$C000(IRQ latch). - Write any value to
$C001to flag “reload on next A12 edge”. - Write any value to
$E001to enable IRQs. - Counter reloads on the first A12 edge, then decrements once per A12 edge thereafter; when it reaches zero (and IRQs are enabled), the IRQ line asserts.
- Acknowledge by writing any value to
$E000(this also disables further IRQs until you re-enable).
The A12-edge mechanism means MMC3 IRQs land slightly differently between background-mode and sprite-mode fetches; emulators that model this correctly require a small low-time filter (~10 PPU cycles) to match real-hardware behaviour.
One more trap for implementers: the interval between interrupts is the latch value plus one scanline, not the latch value. In hardware the counter runs upwards from the one’s complement of the value written, and its carry is registered through a flip-flop before it reaches the interrupt line — that extra stage is the extra scanline. Model it as “load, count up to full, fire” and every split lands one line early.
What Nintendo told licensees
Everything above is drawn from the community’s reverse engineering, documented on the NESdev Wiki and verifiable by anyone with a cartridge and a logic analyser. What follows comes from somewhere you cannot check: Nintendo’s own specification for the part, written for licensees and never published.
It is worth reading the two against each other, because they describe the same silicon and agree on none of the vocabulary.
Nintendo’s MMC3 Specification, third edition dated 24 May 1988, describes the interval timer in terms no emulator author would use — and both descriptions are correct.
Nintendo calls it a one-line timer. Its summary of the part gives the timer’s clock as one horizontal line, and its timing diagram measures the period at 63.51 microseconds. There is no mention of A12 at that level, because from a game programmer’s seat the counter is a scanline counter.
It is a scanline counter because Nintendo made it compulsory. Games using the timer were required to fix the PPU’s sprite pattern table high and its background pattern table low, permanently — the exact arrangement that makes A12 rise once per scanline. Where a game used 8×16 sprites, the specification added a further rule: sprite tile numbers must be odd, because in that mode the tile number’s low bit picks the pattern table and an even number would put sprite fetches back in the wrong half. The A12 mechanism is the implementation; the one-line clock is the contract, and the rules exist to keep the two identical.
Blanking the screen stops the counter. The specification states plainly that when both sprites and background are switched off, the timer’s clock is permanently undefined — no rendering means no pattern fetches, so nothing toggles A12 and the counter stops. Nintendo offered two workarounds, both of which turn up in real games: change the apparent brightness using the PPU’s colour controls instead of blanking, or blank only one layer at a time.
And Nintendo’s own worked example confirms the plus-one — while the formula printed beside it does not. The specification works two consecutive timer values through a three-interrupt frame, and both come out as the gap between interrupts minus one, exactly matching the “latch plus one” behaviour described above. The general formula printed alongside those two examples gives a different answer from either of them. Two editions of the document, a year apart, carry the same mismatch. Trust the worked values and the timing diagram, which agree with each other and with the hardware; the printed formula is the odd one out. It is the sort of thing that costs an emulator author an afternoon.
Nintendo’s names for the registers are its own, and nothing like the community’s: the bank-select port is the POINTER, the IRQ latch is JAM, and the three write-only commands are P&SIT (preset and start interval timer), DITIRQ and EITIRQ (disable and enable its interrupt). The specification marks those last three “soft switches” — the value written is irrelevant, the address alone is the command, which is why writing any byte works.
Why it mattered
MMC3 hit the sweet spot of capability versus cost: it gave developers PRG sizes for sprawling games (SMB3 is 384 KB), CHR-bank rotation for tile animation, and a reliable mid-frame IRQ for status bars and parallax — all at a price low enough for first-party use. By the late NES era, MMC3 (and its variants MMC3A/B/C, which differ subtly in IRQ behaviour) was the default choice for any game that needed more than NROM or MMC1 could provide.
Sources
The register map, bank behaviour and IRQ mechanism above follow the NESdev Wiki’s MMC3 page, whose content is public domain and which remains the best place to check any of it.
The section on what Nintendo told licensees draws on the company’s MMC3 Specification, third edition dated 24 May 1988 — an internal document written for cartridge developers, never publicly released. We describe what it says and do not reproduce it; if it were struck from this page entirely, everything above it would still stand.