MMC3: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
(→‎MMC3: IRQ counter on MMC3 and MMC3_alt. I hope it's clear.)
m (→‎MMC3 IRQ: small fixes.)
Line 126: Line 126:
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).
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).


The counter is based on the following trick:
The counter is based on the following trick: 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.
* 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.
Because of this, if BG uses the left pattern table ($0000), and if sprites always use the right pattern table ($1000), A12 will remain low during all nametable and BG pattern fetches, and high during all sprite pattern fetches, causing it to oscillate exactly one time per scanline and 241 times per frame. It may oscillate more if the program uses registers $2006 and $2007 to access PPU $1000-$1FFF during vblank, but this is rare because very few games have MMC3 and CHR RAM (two on TQROM and three on TGROM among NES games, and a couple more Famicom-only games). The scanline counter will also work when the BG uses the right pattern table ($1000) and the sprites use the left pattern table ($0000), but this is less common.
Because of this, if BG uses the left ($0000) pattern table, and if sprites always use the right ($1000) pattern tables, A12 will remain low during all nametable and BG pattern fetches, and high during all sprite pattern fetches, causing it to oscillate exactly one time per scanline and 241 times per frame.
* It may oscillate more if the program uses registers $2006 and $2007 to access PPU $1000-$1FFF during vblank, but this is rare because very few games have MMC3 and CHR RAM (two on TQROM and three on TGROM among NES games, and a couple more Famicom-only games). The scanline counter will also work when the BG uses the right ($1000) pattern table and the sprites use the left ($0000) pattern table, but this is less common.


The MMC3 IRQ has two revisions that work slightly different [http://nesdev.parodius.com/bbs/viewtopic.php?p=62546#62546].
The MMC3 IRQ has two revisions that work slightly different [http://nesdev.parodius.com/bbs/viewtopic.php?p=62546#62546].
Line 135: Line 133:
* When the scanline counter is clocked, the value will first be checked. If it is zero '''or''' the ''reload flag'' is set to true, it will be reloaded from the IRQ latch ($C000); otherwise, it will decrement. If the scanline counter is zero, an IRQ will be fired if IRQ generation is enabled (by writing to $E001); also, the alternate version checks if the scanline counter is zero and the previous value is non-zero, whether from decrementing or reloading.
* When the scanline counter is clocked, the value will first be checked. If it is zero '''or''' the ''reload flag'' is set to true, it will be reloaded from the IRQ latch ($C000); otherwise, it will decrement. If the scanline counter is zero, an IRQ will be fired if IRQ generation is enabled (by writing to $E001); also, the alternate version checks if the scanline counter is zero and the previous value is non-zero, whether from decrementing or reloading.


Regarding PPU A12 rises:
* If the BG uses $0000, and the sprites use $1000, then the IRQ will occur after PPU cycle 260 (as in, a little after the visible part of the target scanline has ended).
* If the BG uses $0000, and the sprites use $1000, then the IRQ will occur after PPU cycle 260 (as in, a little after the visible part of the target scanline has ended).
* If the BG uses $1000, and the sprites use $0000, then the IRQ will occur after PPU cycle 324 of the ''previous'' scanline (as in, ''right before'' the target scanline is about to be drawn).
* If the BG uses $1000, and the sprites use $0000, then the IRQ will occur after PPU cycle 324 of the ''previous'' scanline (as in, ''right before'' the target scanline is about to be drawn).

Revision as of 02:49, 8 April 2012

The Nintendo MMC3 is a mapper ASIC used in Nintendo's TxROM Game Pak boards. Most common TxROM boards, along with HxROM boards (which use the Nintendo MMC6) are assigned to iNES Mapper 004; the TKSROM and TLSROM boards are assigned to iNES Mapper 118, and TQROM is assigned to iNES Mapper 119. This chip first appeared in the fourth quarter of 1988.

Overview

  • PRG ROM size: Up to 512 KB
  • PRG ROM bank size: 8 KB
  • PRG RAM: Up to 8 KB
  • CHR capacity: Up to 256 KB ROM or 8 KB RAM
  • CHR bank size: 1 KB and 2 KB
  • Nametable mirroring: Controlled by mapper
  • Subject to bus conflicts: No

Banks

  • CPU $6000-$7FFF: 8 KB PRG RAM bank
  • CPU $8000-$9FFF (or $C000-$DFFF): 8 KB switchable PRG ROM bank
  • CPU $A000-$BFFF: 8 KB switchable PRG ROM bank
  • CPU $C000-$DFFF (or $8000-$9FFF): 8 KB PRG ROM bank, fixed to the second-last bank
  • CPU $E000-$FFFF: 8 KB PRG ROM bank, fixed to the last bank
  • PPU $0000-$07FF (or $1000-$17FF): 2 KB switchable CHR bank
  • PPU $0800-$0FFF (or $1800-$1FFF): 2 KB switchable CHR bank
  • PPU $1000-$13FF (or $0000-$03FF): 1 KB switchable CHR bank
  • PPU $1400-$17FF (or $0400-$07FF): 1 KB switchable CHR bank
  • PPU $1800-$1BFF (or $0800-$0BFF): 1 KB switchable CHR bank
  • PPU $1C00-$1FFF (or $0C00-$0FFF): 1 KB switchable CHR bank

Registers

The MMC3 has 4 pairs of registers at $8000-$9FFF, $A000-$BFFF, $C000-$DFFF, and $E000-$FFFF - even addresses ($8000, $8002, etc.) select the low register and odd addresses ($8001, $8003, etc.) select the high register in each pair.

Bank select ($8000-$9FFE, even)

7  bit  0
---- ----
CPxx xRRR
||    |||
||    +++- Specify which bank register to update on next write to Bank Data register
||         0: Select 2 KB CHR bank at PPU $0000-$07FF (or $1000-$17FF);
||         1: Select 2 KB CHR bank at PPU $0800-$0FFF (or $1800-$1FFF);
||         2: Select 1 KB CHR bank at PPU $1000-$13FF (or $0000-$03FF);
||         3: Select 1 KB CHR bank at PPU $1400-$17FF (or $0400-$07FF);
||         4: Select 1 KB CHR bank at PPU $1800-$1BFF (or $0800-$0BFF);
||         5: Select 1 KB CHR bank at PPU $1C00-$1FFF (or $0C00-$0FFF);
||         6: Select 8 KB PRG bank at $8000-$9FFF (or $C000-$DFFF);
||         7: Select 8 KB PRG bank at $A000-$BFFF
|+-------- PRG ROM bank configuration (0: $8000-$9FFF swappable,
|                                         $C000-$DFFF fixed to second-last bank;
|                                      1: $C000-$DFFF swappable,
|                                         $8000-$9FFF fixed to second-last bank)
+--------- CHR ROM bank configuration (0: two 2 KB banks at $0000-$0FFF,
                                          four 1 KB banks at $1000-$1FFF;
                                       1: two 2 KB banks at $1000-$1FFF,
                                          four 1 KB banks at $0000-$0FFF)

Bank data ($8001-$9FFF, odd)

7  bit  0
---- ----
DDDD DDDD
|||| ||||
++++-++++- New bank value, based on last value written to Bank select register (mentioned above)

The PRG banks are 8192 bytes in size, half the size of an iNES PRG bank. If your emulator or copier handles PRG data in 16384 byte chunks, you can think of the lower bit as selecting the first or second half of the bank:[1]

7  bit  0  When $8000 AND #$06 == #$06
---- ----
xxBB BBBH
  || ||||
  || |||+- 0: Select first half of this bank;
  || |||   1: Select second half of this bank
  ++-+++-- Select 16 KB PRG bank at $8000-$9FFF, $A000-$BFFF, or $C000-$DFFF

Mirroring ($A000-$BFFE, even)

7  bit  0
---- ----
xxxx xxxM
        |
        +- Mirroring (0: vertical; 1: horizontal)

PRG RAM protect ($A001-$BFFF, odd)

7  bit  0
---- ----
RWxx xxxx
||
|+-------- Write protection (0: allow writes; 1: deny writes)
+--------- Chip enable (0: disable chip; 1: enable chip)

These bits work on the MMC3 that blargg tried, even if some emulators do not implement them.

IRQ latch ($C000-$DFFE, even)

7  bit  0
---- ----
DDDD DDDD
|||| ||||
++++-++++- IRQ latch value

This register specifies the IRQ counter reload value. When the IRQ counter is zero (or a reload is requested through $C001), this value will be copied into the MMC3 IRQ counter at the end of the current scanline.

IRQ reload ($C001-$DFFF, odd)

7  bit  0
---- ----
xxxx xxxx

Writing any value to this register reloads the MMC3 IRQ counter at the NEXT rising edge of the PPU address, presumably at the end of the current scanline.

IRQ disable ($E000-$FFFE, even)

7  bit  0
---- ----
xxxx xxxx

Writing any value to this register will disable MMC3 interrupts AND acknowledge any pending interrupts.

IRQ enable ($E001-$FFFF, odd)

7  bit  0
---- ----
xxxx xxxx

Writing any value to this register will enable MMC3 interrupts.

Hardware

The MMC3 most commonly exists in a 44-pin TQFP package. Three revisions are known to exist - MMC3A, MMC3B, and MMC3C. No major behavioral differences are known, except for the IRQ counter.

Acclaim's MC-ACC chip is their own variant of the MMC3, that they used for their own boards (for industrial money-saving purposes). It comes in a standard 600 mil 40-pin DIP package. It is not known if it has SRAM support, and no difference is known between this chip and the real MMC3.

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

The counter is based on the following trick: 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. Because of this, if BG uses the left pattern table ($0000), and if sprites always use the right pattern table ($1000), A12 will remain low during all nametable and BG pattern fetches, and high during all sprite pattern fetches, causing it to oscillate exactly one time per scanline and 241 times per frame. It may oscillate more if the program uses registers $2006 and $2007 to access PPU $1000-$1FFF during vblank, but this is rare because very few games have MMC3 and CHR RAM (two on TQROM and three on TGROM among NES games, and a couple more Famicom-only games). The scanline counter will also work when the BG uses the right pattern table ($1000) and the sprites use the left pattern table ($0000), but this is less common.

The MMC3 IRQ has two revisions that work slightly different [2].

  • For the alternate version, the reload flag is set to true when writing to $C001.
  • When the scanline counter is clocked, the value will first be checked. If it is zero or the reload flag is set to true, it will be reloaded from the IRQ latch ($C000); otherwise, it will decrement. If the scanline counter is zero, an IRQ will be fired if IRQ generation is enabled (by writing to $E001); also, the alternate version checks if the scanline counter is zero and the previous value is non-zero, whether from decrementing or reloading.

Regarding PPU A12 rises:

  • If the BG uses $0000, and the sprites use $1000, then the IRQ will occur after PPU cycle 260 (as in, a little after the visible part of the target scanline has ended).
  • If the BG uses $1000, and the sprites use $0000, then the IRQ will occur after PPU cycle 324 of the previous scanline (as in, right before the target scanline is about to be drawn).

Important points:

  • The scanline counter cannot be stopped. It will continue to decrement and reload as long as PPU A12 on the PPU bus toggles.
  • There is no direct access to the counter! The best you can do is update the reload value and immediately request a reload.
  • Writing to $E000 will only prevent the MMC3 from generating IRQs - the counter will continue to run.
  • Writing to $E001 will simply allow the MMC3 to generate IRQs - the counter remains unaffected.
  • Writing to $C001 will cause the counter to be cleared, and set reload flag to true. It will be reloaded on the NEXT rising edge of the PPU A12.
  • Writing to $C000 does not immediately affect the value within the counter - this value is only used when the counter is reloaded, whether from reaching 0 or from writing to $C001.
  • The exact number of scanlines between IRQs is N+1, where N is the value written to $C000. 1 (Sharp MMC3B, MMC3C) or 2 (MMC3A, Non-Sharp MMC3B) to 256 scanlines are supported.
  • The counter will not work properly unless you use different pattern tables for background and sprite data. The standard configuration is to use PPU $0000-$0FFF for background tiles and $1000-$1FFF for sprite tiles, whether 8x8 or 8x16.
  • The counter is clocked on each rising edge of PPU A12, no matter what caused it, so it is possible to (intentionally or not) clock the counter by writing to $2006.

There's a slight discrepancy with what happens when you set $C000 to $00, and so far, two behaviors are known to exist:

  • All MMC3A's and non-Sharp MMC3B's will generate only a single IRQ when $C000 is $00. This is because this version of the MMC3 generates IRQs when the scanline counter is decremented to 0. In addition, writing to $C001 with $C000 still at $00 will result in another single IRQ being generated. In the community, this is known as the "alternate" behavior.
  • All MMC3C's and Sharp MMC3B's will generate an IRQ on each scanline while $C000 is $00. This is because this version of the MMC3 generates IRQs when the scanline counter is equal to 0. In the community, this is known as the "normal" behavior.

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.

Variants

The TKSROM and TLSROM boards, assigned to INES Mapper 118, connect the upper bank select line directly to VRAM A10, allowing more flexible control over nametable mirroring.

The TQROM board, assigned to INES Mapper 119, uses both CHR ROM and CHR RAM simultaneously, using the 2nd-highest CHR bank select line to choose between them (on a per-bank basis).

DxROM carts have a custom mapper developed by Namco before the MMC3 existed. Tengen used it for some of their games under the name MIMIC-1. It exists both in a 400 mil 28-pin Shrink-DIP (found in licensed DxROM boards) and in a larger 600 mil 28-pin DIP (found in unlicensed Tengen cartridges).

This chip does the basic PRG ROM switching exactly like the MMC3, but it only implement the low 3 bits of $8000 and the low 5 bits of $8001. Compared to the MMC3, it lacks mirroring control, SRAM support and an IRQ counter. The TEROM and TFROM boards have been developed with backward compability with DxROM in mind, featuring solder pads to have hardwired H/V mirroring instead of MMC3 controlled mirroring, and allow to disable IRQs by hardware.

IRQ behavior when reload is set to 0 differs among different MMC3 chips. For MMC3B chips bearing a bold S before the date code, this results in an IRQ every scanline. For MMC3B chips lacking the S and having a date code of the form nnnnPKnnn, this results in IRQs ceasing to be generated. An MMC3A 8940EP chip tested also displays the latter behavior. Some games have used both versions, so it's unlikely that commercial NES games even depend on this difference. In fact, it might be one of the things that caused Nintendo lot check to reject a program.

Pirate variants

Mapper 245 uses bit 2 of CHR Register 0 to select which 512KB bank of PRG ROM is seen. This increases the maximum PRG size up to 1024K. CHR RAM is not bankable, but the top bit of $8000 will still switch the left and right pattern tables.

Mapper 74 replaces CHR pages 08 and 09 with CHR RAM.