Skip to content
Hardware

MMC1

Four registers, one bit at a time

Nintendo's first Multi Memory Controller was the most widely used NES mapper, and the strangest to program: its four control registers loaded serially, a single bit per write.

nintendo-entertainment-systemmappernesnintendoenhancement1986–present

The MMC1 was the first of Nintendo’s Multi Memory Controllers and the most widely used mapper on the NES. It gave cartridges bank-switched program and character ROM, software-controlled mirroring, and 8 KB of optionally battery-backed RAM — the combination that made The Legend of Zelda and Metroid possible on cartridge, saves included.

Nintendo’s own documents never call it “MMC1”. They call the part the MMC, expanded on the first page of its programming specification as Multi Memory Controller. The number only appears once a second controller existed to distinguish it from.

That settles a small, long-standing uncertainty. English-language documentation has generally read MMC as Memory Management Controller, following how Nintendo described the chips to players in the West, while noting that it may have originally meant Multi Memory Controller “at least according to Japanese”. The Japanese specification spells it out on page one, in 1986: Multi Memory Controller. Both names are real — one is what the parts were called when they were designed, the other what they were called when they were explained.

Configured one bit at a time

The MMC1’s defining behaviour is not its banking but how a program talks to it, and the reason is a cost decision:

Unlike almost all other mappers, the MMC1 is configured through a serial port in order to reduce its pin count.

The whole of $8000-$FFFF is wired to a single shift register. To set any internal register the CPU writes five times, each write carrying one bit of the value in bit 0, least significant bit first. On the fifth write the mapper assembles the five bits and files them into one of four internal registers — chosen not by the data but by “bits 14 and 13 of the address”, the only address lines the chip is connected to.

Two consequences follow, and both shaped how NES games are written.

A write with bit 7 set resets the sequence. Any value from $80 to $FF anywhere in that range “clears the shift register to its initial state”, which is how a program recovers if it loses track of where it is in the five.

An interrupt in the middle of the five is a hazard. A sequence half-completed leaves the mapper holding a partial value, and an interrupt handler that touches $8000-$FFFF will corrupt it. This is why MMC1 code disables interrupts around bank switches, and why an emulator that gets the shift-register state wrong produces games that run and then quietly swap the wrong bank.

Five pins’ worth of hardware saved, paid for in software discipline for the life of the platform.

Fast facts

  • Manufacturer: Nintendo.
  • iNES mapper number: 1 (board family SxROM, including SNROM, SKROM and SLROM).
  • Programming specification: dated November 1986, revised March 1987.
  • PRG ROM: up to 256 KB, in 16 KB or 32 KB banks.
  • CHR ROM/RAM: up to 128 KB, in 4 KB or 8 KB banks.
  • PRG-RAM: 8 KB at $6000-$7FFF, battery-backable.
  • No IRQ. Unlike the later MMC3, MMC1 has no scanline counter — mid-frame effects need sprite-zero hits or cycle counting.
  • Notable games: The Legend of Zelda, Metroid, Castlevania II: Simon’s Quest, and several hundred others.

Writing to it: one bit at a time

Most mappers take a bank number as a single write. MMC1 does not. Only two bits of the data bus matter — D0 carries data, D7 resets — and a register is loaded five writes at a time, one bit per write, least-significant bit first.

The sequence to set a register:

  1. Write five times to any address in the target register’s range, each with D7 clear, putting the next bit of the value in D0 (LSB first).
  2. On the fifth write, the assembled 5-bit value lands in the register selected by the address of that write.

A write with D7 set resets the shift register and abandons a part-finished sequence. It also forces the PRG mode that fixes the last bank at $C000 — which is what makes a bare reset routine leave the machine in a sane, known configuration.

Which register receives the finished value depends only on the address:

Address range Register
$8000-$9FFF Control — mirroring, PRG mode, CHR mode
$A000-$BFFF CHR bank 0
$C000-$DFFF CHR bank 1
$E000-$FFFF PRG bank

The practical consequence is that an interrupt landing in the middle of a five-write sequence corrupts it. MMC1 code either disables interrupts across the sequence or keeps a shadow copy to rewrite from.

Writing to ROM space works at all because the MMC gates the ROM’s output enable with the CPU’s read/write line internally: during a write to $8000-$FFFF the ROM is not driving the bus, so there is no conflict to resolve.

What Nintendo told licensees

Three things in Nintendo’s MMC Cassette Programming Specification (November 1986, revised March 1987) explain behaviour that is otherwise just folklore.

The four “magic” addresses are a recommendation, not a rule. The specification names one address per register — $9FFF, $BFFF, $DFFF and $FFFF, the top of each window — and MMC1 game code clusters on them to this day. Any address inside the right window works identically; the chip only decodes enough of the address bus to tell the four windows apart.

Copy protection was a design goal, not a side effect. The specification lists five features of the MMC, and the fifth is that it is effective against copying: being a dedicated IC, it is difficult to replace with ordinary logic gates. Nintendo said so to licensees, in the same feature list as the capacity and convenience arguments.

There is no RESET line on the cartridge connector. The MMC therefore cannot know its own power-on state, and the bank mapped at $C000 when the CPU fetches its reset vector is undefined. Nintendo’s answer was a requirement: program ROM must carry vectors and an initialisation routine in every 16 KB bank. That is why MMC1 cartridge dumps are littered with duplicated stubs — not redundancy, but the only way to guarantee the machine can bootstrap from whichever bank it happens to wake up in.

The MMC1B revision

A Nintendo notice dated 15 June 1989 introduced MMC1B as a replacement for the MMC1A then in use, for a specific reason: to improve RAM data retention. Licensees were asked to program for the new part from that point on, beginning with games that needed battery backup.

One register bit changed meaning. On MMC1B it became an expansion-RAM access control — clear to enable access, set to disable it — and it powers up disabled. The point is to protect a battery-backed save as the machine loses power, when a dying CPU can otherwise scribble on RAM that is still writable.

On MMC1A the same bit did something else entirely, driving an external pin for RAM bank selection. The two revisions are therefore not interchangeable, which is why emulator authors have to decide which part a given game expects instead of implementing “MMC1” as one thing.

Why it mattered

MMC1 arrived when NES cartridges were straining against a 32 KB program ceiling, and it lifted that to 256 KB while adding the two things that changed what a game could be: software-controlled mirroring, so a game could switch scroll axis mid-game, and battery-backed RAM, so it could remember. Zelda’s save slots and Metroid’s passwords belong to the same generational shift.

Its serial interface looks eccentric next to the straightforward parallel writes of later mappers, and it cost every MMC1 game a slightly awkward register-writing routine. But it bought Nintendo a small, cheap package — and by the time the MMC3 arrived with its scanline counter, MMC1 had already carried the console through its most important years.

Sources

The shift-register protocol, register layout and bank behaviour above follow the NESdev Wiki’s MMC1 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 own MMC1 documentation, written for cartridge developers and never publicly released. We describe what it says and do not reproduce it; strike it and everything above it still stands.

See also

Not yet fact-checked. This entry was drafted by an AI and nobody has verified it. The dates, figures and technical details may be wrong. Use it to find your bearings, then confirm anything that matters against a primary source.