MMC5: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
(→‎Overview: no technical reason why MMC5 couldn't support CHR-RAM, also "Rockman 4: Minus Infinity" ROM hack requires CHR-RAM and has been confirmed to work on real h/w (see http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=82338))
(→‎Scanline IRQ Status ($5204, read/write): Clarified that the scanline does not reset from a scanline interrupt.)
 
(186 intermediate revisions by 13 users not shown)
Line 1: Line 1:
[[Category:ASIC mappers]]
{{Infobox iNES mapper
The '''Nintendo MMC5''' is a [[MMC|mapper]] [[:Category:ASIC mappers|ASIC]] used in Nintendo's [[ExROM]] Game Pak boards. All MMC5 boards are assigned to '''mapper 5'''.
|name=MMC5
|name2=ExROM
|company=Nintendo, Koei, others
|mapper=5
|nescartdbgames=15
|complexity=ASIC
|boards=EKROM, ELROM,<br/>ETROM, EWROM
|pinout=MMC5 pinout
|prgmax=1024K
|prgpage=8K, 16K, or 32K
|wrammax=128K
|wrampage=8K ($6000-$DFFF),<br/>16K (only $8000-$BFFF<br />at PRG mode 1/2)
|chrmax=1024K
|chrpage=1K, 2K, 4K, or 8K
|mirroring=arbitrary, up to 3 source<br />nametables (plus fill mode)
|busconflicts=No
|irq=Yes
|audio=[[MMC5_audio|Yes]]
}}
{{nesdbbox
|ines|5|iNES 005
|unif_wild|-E%ROM|ExROM
|unif_wild|EKROM|EKROM
|unif_wild|ELROM|ELROM
|unif_wild|ETROM|ETROM
|unif_wild|EWROM|EWROM
}}
[[Category:Nintendo licensed mappers]][[Category:Mappers using $4020-$5FFF]][[Category:Mappers with large PRG RAM]][[Category:Mappers with scanline IRQs]][[Category:Mappers with single-screen mirroring]][[Category:Mappers with cycle IRQs]]
The '''Nintendo MMC5''' is a [[mapper]] [[:Category:ASIC mappers|ASIC]] used in Nintendo's [[ExROM]] Game Pak boards. All MMC5 boards are assigned to '''mapper 5'''.
 
Example games:
* ''Castlevania 3''
* ''Just Breed''
* ''Uncharted Waters''
* ''Romance of the Three Kingdoms II''
* ''Laser Invasion''
* ''Metal Slader Glory''
* ''Uchuu Keibitai SDF''
* ''Shin 4 Nin Uchi Mahjong - Yakuman Tengoku''
* ''Bandit Kings of Ancient China''
 
The first game to use this chip (''Nobunaga's Ambition II'') was released in February 1990. The [http://bootgod.dyndns.org:7777/profile.php?id=3169 date codes on components on early released cartridges] show that manufacturing had started at the end of 1989.
 
A later '''[[#MMC5A|MMC5A]]''' revision was introduced with a few extra features, but all released games do not rely on these features and are compatible with the original MMC5.


== Overview ==
== Overview ==
* PRG ROM size: Up to 1024 KB
* PRG ROM bank size: 8 KB, 16 KB, or 32 KB
* PRG RAM: Up to 64 KB
* CHR capacity: Up to 1024 KB ROM or RAM
* CHR bank size: 1 KB, 2 KB, 4 KB, or 8 KB
* Nametable [[mirroring]]: Controlled by mapper
* Subject to [[bus conflict]]s: No
The MMC5 is the most powerful mapper ASIC Nintendo made for the NES and Famicom.
The MMC5 is the most powerful mapper ASIC Nintendo made for the NES and Famicom.


Line 16: Line 51:
* 4 PRG ROM switching modes
* 4 PRG ROM switching modes
* 4 CHR ROM switching modes
* 4 CHR ROM switching modes
* Up to 64KB of WRAM, mappable not only at $6000-$7FFF but also within $8000-$DFFF
* Up to 128KB of WRAM, mappable not only at $6000-$7FFF but also within $8000-$DFFF
** Supports either one chip (up to 128KB) or two chips (up to 32KB each)
* An 8 bit by 8 bit multiplier with a 16 bit result for performing quick calculations
* An 8 bit by 8 bit multiplier with a 16 bit result for performing quick calculations
* A scanline based IRQ counter
* Scanline detection with counter and configurable IRQ
* The ability to use different CHR banks for background and 8x16 sprites
* Frame detection with status bit
* The ability to use different CHR banks for background and 8x16 sprites (allowing 256 unique 8x16 sprite tiles, independent of the background).
* 1024 bytes of on-chip memory, which can be used for 4 different purposes:
* 1024 bytes of on-chip memory, which can be used for 4 different purposes:
** An extra general-use nametable
** An extra general-use nametable
Line 28: Line 65:
** Two pulse channels, identical to those in the NES APU (except lacking pitch sweeps).
** Two pulse channels, identical to those in the NES APU (except lacking pitch sweeps).
** An 8-bit RAW PCM channel
** An 8-bit RAW PCM channel
* A 'fill mode' nametable, which can be instantly set to contain a specific tile in a specific color (useful for quickly getting a blank screen of a particular color/pattern)
* A 'fill mode' nametable, which can be instantly set to contain a specific tile in a specific color (useful for screen transitions)
* System reset detection
** Triggered by a positive or negative gap in M2 of at least 11.2 usec.
** Also triggered and latched by absence of AVcc.
** After reapplying AVcc, another gap in M2 is sometimes necessary to clear the latch.
** This feature resets some, but not all, states of the MMC5.
** The PRG RAM +CE pin is a direct reflection of system reset detection state.


== Banks ==
== Banks ==
Line 80: Line 123:
== Registers ==
== Registers ==


=== Sound ===
=== Sound ($5000-$5015) ===
 
For details on sound operation, see [[MMC5 audio]]
 
=== NES internal state monitoring ===
All of these registers overlay various registers that are already used inside the NES, and are fully decoded. A game could write to a mirror of a PPU register to get the MMC5 out of sync, but it's not clear how that could be useful.
==== 8x16 mode enable ($2000 = [[PPUCTRL]]) ====
7  bit  0
---- ----
xxZx xxxx
  |
  +------- Sprite size (0: 8x8 pixels; 1: 8x16 pixels)
 
Only when Z is set and at least one E bit is set does the MMC5 [[#CHR_Bankswitching_.28.245120-.245130.29|draw 8x16 sprites from eight independent banks]].<ref>[https://forums.nesdev.org/viewtopic.php?p=229375#p229375 krzysiobal's RE notes]</ref>
 
==== PPU Data Substitution Enable ($2001 = [[PPUMASK]]) ====
7  bit  0
---------
xxxE Exxx
    | |
    +-+--- 1,2,3: Substitutions enabled; 0: substitutions disabled
 
The MMC5 listens to writes to PPUMASK ($2001). When it sees that both E bits are cleared, it disables its ability to make substitutions on the PPU data bus.  This includes disabling:
* Independent bank 8x16 sprite mode
* Extended attribute mode
* Vertical split mode
 
The MMC5 only listens to the fully decoded address $2001, so this can be tested by using the PPU’s mirrors of this register.  For example, writing to register $2009 will be heard by the PPU but not the MMC5.  It is not clear if that could have a practical use beyond test purposes.
 
When the MMC5 sees $00 written to $2001, and then the PPU’s rendering gets enabled via a mirror of $2001, the MMC5 still counts scanlines and can generate scanline interrupts even though it thinks $2001 is still disabled.  The transition from disabled to enabled resets the scanline counter.
 
Driving pin 92 low similarly disables substitutions.  Because no scanline interrupts occur with pin 92 held low, it seems to hold the scanline counter in reset.


For details on sound operation, see [[MMC5_audio]]
==== Unknown ($2002 = [[PPUSTATUS]], read only) ====
Power analysis has detected that both revisions of the MMC5 monitor reads here, purpose unknown.
 
==== Unknown ($2005 = [[PPUSCROLL]]) ====
Power analysis has detected that both revisions of the MMC5 monitor writes here, purpose unknown.
 
==== Unknown ($2006 = [[PPUADDR]], MMC5A only) ====
Power analysis has detected that the MMC5A monitors writes here, purpose unknown.
 
==== Unknown ($4014 = [[OAMDMA]]) ====
Power analysis has detected that both revisions of the MMC5 monitor writes here, purpose unknown.


=== Configuration ===
=== Configuration ===
Line 96: Line 180:
* 2 - One 16KB bank ($8000-$BFFF) and two 8KB banks ($C000-$DFFF and $E000-$FFFF)
* 2 - One 16KB bank ($8000-$BFFF) and two 8KB banks ($C000-$DFFF and $E000-$FFFF)
* 3 - Four 8KB banks
* 3 - Four 8KB banks
''Castlevania III'' uses mode 2, which is similar to [[VRC6]] PRG banking. All other games use mode 3. The Koei games never write to this register, apparently relying on the MMC5 defaulting to mode 3 at power on.


==== CHR mode ($5101) ====
==== CHR mode ($5101) ====
Line 107: Line 193:
* 2 - 2KB CHR pages
* 2 - 2KB CHR pages
* 3 - 1KB CHR pages
* 3 - 1KB CHR pages
''Metal Slader Glory'' uses 4KB CHR pages. All other games use 1KB pages.


==== PRG RAM Protect 1 ($5102) ====
==== PRG RAM Protect 1 ($5102) ====
Line 115: Line 203:
         ++- RAM protect 1
         ++- RAM protect 1


In order to enable writing to PRG RAM, this must be set to '10'.
In order to enable writing to PRG RAM, this must be set to binary '10' (e.g. $02).


==== PRG RAM Protect 2 ($5103) ====
==== PRG RAM Protect 2 ($5103) ====
Line 124: Line 212:
         ++- RAM protect 2
         ++- RAM protect 2


In order to enable writing to PRG RAM, this must be set to '01'.
In order to enable writing to PRG RAM, this must be set to binary '01' (e.g. $01).


==== Extended RAM mode ($5104) ====
==== Internal extended RAM mode ($5104) ====
  7  bit  0
  7  bit  0
  ---- ----
  ---- ----
Line 132: Line 220:
         ||
         ||
         ++- Specify extended RAM usage
         ++- Specify extended RAM usage
* 0 - Use as extra nametable (possibly for split mode)
{| class=wikitable
* 1 - Use as extended attribute data (can also be used as extended nametable)
! $5104 !! CPU Access ($5C00-$5FFF) <br/> during blanking !! CPU Access ($5C00-$5FFF) <br/> during rendering !! PPUDATA Access ($2000-$2FFF){{sup|(1)}} <br/> during blanking !! Available as <br/> Nametable !! Enable Extended <br/> Attribute Mode
* 2 - Use as ordinary RAM
|-
* 3 - Use as ordinary RAM, write protected
! %00
| {{no}}{{sup|(3)}} || <center>{{yes|Write Only}}{{sup|(4)}}</center> || {{yes|Read/Write}} || {{yes}} || {{no}}
|-
! %01
| {{no}}{{sup|(3)}} || <center>{{yes|Write Only}}{{sup|(4)}}</center> || {{yes|Read/Write}} || {{yes}}{{sup|2}} || {{yes}}
|-
! %10
| {{yes|Read/Write}} || {{yes|Read/Write}} || {{no}} || {{no}} || {{no}}
|-
! %11
| <center>Read Only</center> || <center>Read Only</center> || {{no}} || {{no}} || {{no}}
|-
|}
 
{{sup|(1)}}When configured as a nametable in register $5105, read and write access is possible through the PPU via registers $2006/$2007 when the PPU is not rendering.  Based on register $5105, any nametables mapped to extended RAM will support the corresponding PPU address ranges for reads and writes.  For example, if NT4 is mapped to extended RAM, reads/writes to PPU $2C00 will correspond with extended RAM $5C00.
 
{{sup|(2)}}Though it is possible to still assign the extended RAM as a nametable in the mode %01, you are going to have the same data used twice, once as extended attribute data, and once as nametable data, this does not seem to be a useful combination. In the other modes, the nametable will read as if it contains all $00s.
 
{{sup|(3)}}Counterintuitively, writes in these modes are only allowed when the PPU is rendering. If writes are attempted during V-blank, they may be ignored or cause a corruption at that memory address. In practice, temporarily switch to mode %10 if you wish to write during V-blank.
 
{{sup|(4)}}Attempting to read extended RAM in those modes returns open bus.
 
===== Extended attributes =====
 
In mode %01, "Extended Attribute Mode", each byte of the MMC5's internal extended RAM is used to enhance the background tile at the corresponding nametable address. The extended attributes are 1-screen mirrored; in other words, they apply the same for all nametables.
 
Format of each extended attribute byte:
 
7  bit  0
---- ----
AACC CCCC
|||| ||||
||++-++++- Select 4 KB CHR bank to use with specified tile
++-------- Select palette to use with specified tile
 
In extended attribute mode, CHR banking behaves differently than normal when fetching background tiles from pattern tables:
* CHR mode (register $5101) is ignored.  CHR banks are always 4KB in this mode.
* The values of the CHR banking registers $5120-$512B are also ignored.
* Bits 0-5 specified here are used for selecting a 4KB CHR bank on a per-tile basis.
* The two bits in $5130 are used globally as CHR bank bits 6 and 7.
* Driving pin 92 low disables extended attribute mode. Extended attribute mode is also automatically disabled based on PPUMASK monitoring. (See section on $2001 monitoring.) In these cases, the non-extended attribute table is used instead.
 
In other words, this works as if the nametable was extended from 8-bit to 14-bit tile offsets, with the ExRAM holding the upper 6-bits and the 2-bit palette value, while the nametable selected through $5105 contains the lower 8 bits.
 
''Just Breed'', ''Yakuman Tengoku'', and the Koei games use extended attributes continuously.


==== Nametable mapping ($5105) ====
==== Nametable mapping ($5105) ====
Line 147: Line 279:
  ++-------- Select nametable at PPU $2C00-$2FFF
  ++-------- Select nametable at PPU $2C00-$2FFF
Nametable values:
Nametable values:
* 0 - On-board VRAM page 0
* 0 - CIRAM page 0
* 1 - On-board VRAM page 1
* 1 - CIRAM page 1
* 2 - Internal Expansion RAM, only if the Extended RAM mode allows it ($5104 is 00/01); otherwise, the nametable will read as all zeros,
* 2 - Internal extended RAM
**When $5104 is set to mode %10 or %11, the nametable will read as all zeros.  This does not share functionality with fill mode.
* 3 - Fill-mode data
* 3 - Fill-mode data
**See registers $5106 and $5017
[[Mirroring]] examples:


Examples:
{| class="wikitable"
* $44 (01 00 01 00) - Vertical [[mirroring]]
! Mode !! Value !! NTD !! NTC !! NTB !! NTA
* $50 (01 01 00 00) - Horizontal mirroring
|-
* $14 (00 01 01 00) - Diagonal mirroring
| Horizontal || $50 || %01 || %01 || %00 || %00
* $00 (00 00 00 00) - 1-screen mirroring, low bank
|-
| Vertical  || $44 || %01 || %00 || %01 || %00
|-
| Single-screen CIRAM 0 || $00 || %00 || %00 || %00 || %00
|-
| Single-screen CIRAM 1 || $55 || %01 || %01 || %01 || %01
|-
| Single-screen ExRAM || $AA || %10 || %10 || %10 || %10
|-
| Single-Screen Fill-mode || $FF || %11 || %11 || %11 || %11
|-
| Diagonal  || $14 || %00 || %01 || %01 || %00
|-
|}


==== Fill-mode tile ($5106) ====
==== Fill-mode tile ($5106) ====
  All eight bits specify the tile number to use for fill-mode nametable
When a nametable is mapped to fill-mode in register $5105, all nametable fetches get replaced by the value of this register. Only the nametable is affected by fill mode.  When the PPU later uses this information to fetch the corresponding tile from the pattern table, CHR banking is unaffected and continues to work normally.
 
§
==== Fill-mode color ($5107) ====
==== Fill-mode color ($5107) ====
  7  bit  0
  7  bit  0
Line 166: Line 315:
  xxxx xxAA
  xxxx xxAA
         ||
         ||
         ++- Specify attribute bits to use for fill-mode nametable
         ++- Specify background palette index to use for fill-mode nametable
When a nametable is mapped to fill-mode in register $5105, and $5104 is not in mode %01, all attribute table fetches get replaced by the value of this register.  Each byte of the attribute table normally contains four 2-bit palette indexes.  The two bits in this register are copied for all four indexes.
 
When $5104 is in mode %01, extended attribute mode does apply for fill mode, and this register is ignored. However, if pin 92 is driven low in this mode, extended attribute mode becomes disabled and this register comes back into effect.


=== PRG Bankswitching ===
=== PRG Bankswitching ($5113-$5117)===
In general, when the CPU accesses an address that corresponds to the range of a PRG bank designated by the present PRG mode, the bits of that PRG bank register are applied to the appropriate PRG address buses as follows:


==== PRG RAM bank ($5113) ====
  7  bit  0
  7  bit  0
  ---- ----
  ---- ----
  xxxx xCBB
  RAAA AaAA
      |||
|||| ||||
      |++- Select 8KB PRG RAM bank at $6000-$7FFF
|||| |||+- PRG ROM/RAM A13
      +--- Select PRG RAM chip
|||| ||+-- PRG ROM/RAM A14
|||| |+--- PRG ROM/RAM A15, also selecting between PRG RAM /CE 0 and 1
|||| +---- PRG ROM/RAM A16
|||+------ PRG ROM A17
||+------- PRG ROM A18
|+-------- PRG ROM A19
+--------- RAM/ROM toggle (0: RAM; 1: ROM) (registers $5114-$5116 only)
 
Bank register effective areas versus PRG mode:
{| class="wikitable"
! !! colspan=4|CPU memory affected for each mode (see [[#PRG mode ($5100)]])
|-
!CPU Address
!scope="col" style="width: 125px;"|Mode 3 Registers
!scope="col" style="width: 125px;"|Mode 2 Registers
!scope="col" style="width: 125px;"|Mode 1 Registers
!scope="col" style="width: 125px;"|Mode 0 Registers
|-
||'''$6000-7FFF'''|| $5113 (RAM only) || $5113 (RAM only)    || $5113 (RAM only)    || $5113 (RAM only)
|-
||'''$8000-9FFF'''|| $5114            || rowspan=2|$5115      || rowspan=2|$5115      || rowspan=4|$5117 (ROM only)
|-
||'''$A000-BFFF'''|| $5115
|-
||'''$C000-DFFF'''|| $5116            || $5116                || rowspan=2|$5117 (ROM only)
|-
||'''$E000-FFFF'''|| $5117 (ROM only) || $5117 (ROM only)
|-
|}
 
Register bits $5113.7 and $5117.7 are always ignored.  $5113 always maps RAM, and $5117 always maps ROM.  Because of this, it is not possible to map the interrupt vectors to RAM in any mode. All known games have their reset vector in the last bank of PRG ROM, and the vector points to an address greater than or equal to $E000. This tells us that $5117 must have a reliable power-on value of $FF.
 
When a bankswitch register controls an 8kByte CPU address range, register bits 6..0 correspond to PRG A19..A13.
 
In PRG modes where a register controls a 16kByte CPU address range, register bits 6..1 correspond to PRG A19..A14. Register bit 0 is ignored and instead CPU A13 directly controls PRG A13.  For example, comparing mode 3 to mode 2 for CPU address range $8000-BFFF.  These are equivalent:
*In mode 3, write value $90 to $5114 and value $91 to $5115.
*In mode 2, write value $90 to $5115.


The MMC5 supports 2 PRG RAM chips, each up to 32KB in length. The following configurations of WRAM are known to exist in ExROM games:
However, these are not equivalent:
* 0KB: No chips
*In mode 3, write value $91 to $5114 and value $92 to $5115.
* 8KB: 1x 8KB chip
*In mode 2, write value $91 to $5115.
* 16KB: 2x 8KB chip
* 32KB: 1x 32KB chip


In the original iNES format, byte 8 of the [[iNES#.NES format|file's header]] should indicate how many pages are present, but ROM images in the wild that use this mapper may not have byte 8 set correctly, nor do emulators necessarily honor this number.
The MMC5 ignores register bit 0 in the 16kByte bank.
Byte 10 of the [[NES 2.0]] header should be reliable.


No ExROM game is known to write PRG RAM with one bank value and then attempt to read back the same data with a different bank value. So lacking better information, mirroring can be ignored, 64KB of WRAM could be emulated at all times, and $5113 can be treated as a simple page offset into that 64KB. Emulating 32KB won't work, even if no games used more than that; because 16KB games will expect to see their two distinct pages by toggling bit 2, not bit 0.
Similarly, when register $5117 controls a 32kByte CPU address range in mode 0, register bits 6..2 correspond to PRG A19..A15, register bits 1..0 are ignored, and CPU A14..A13 directly control PRG A14..A13


==== PRG bank 0 ($5114) ====
====Separate PRG-ROM and PRG-RAM Address Busses====
7  bit  0
---- ----
RBBB BBBB
|||| ||||
|+++-++++- Bank number
+--------- RAM/ROM toggle (0: RAM; 1: ROM)


* Mode 0 - Ignored
The MMC5 has separate sets of address pins for PRG-ROM and PRG-RAM.  This is a concept that has proven difficult to understand and explain.  It all stems from the fact that CPU A15 is not directly routed to the cartridge; the signal /ROMSEL is supplied instead.  Though it is possible to figure out CPU A15 from /ROMSEL, it is not possible to use it to select the correct PRG address.  The PRG address needs to be set sooner than this in order to have an adequate setup time for the RAM or ROM chips. So basically, the starting point is that the MMC5 has to ''ignore'' /ROMSEL (and therefore CPU A15) when it comes to the PRG address, for the purpose of timings.  This effectively creates a mirror on the PRG address bus for CPU address range $0000-7FFF and $8000-FFFF.  Specifically, this makes range $6000-7FFF indistinguishable from $E000-FFFF.  Because the MMC5 wanted to have separately controllable mapping for those ranges, its solution was to make two separate PRG address busses.
* Mode 1 - Ignored
* Mode 2 - Ignored
* Mode 3 - Select an 8KB PRG bank at $8000-$9FFF


When selecting a RAM bank, treat bank bits as indicated for the PRG RAM bank register at $5113.
The MMC5's PRG-ROM address pins follow this logic.  Though the PRG-ROM address bus is decoded at ''all'' CPU addresses, the gray areas always have PRG ROM /CE disabled:


Bandit Kings of Ancient China maps PRG-RAM to the CPU $8000+ area and expects to be able to write to it through there. Failure to emulate this causes corruption when the background is restored on the world map.
{| class="wikitable"
!CPU Address
!scope="col" style="width: 125px;"|Mode 3 PRG-ROM<br/>Address Source
!scope="col" style="width: 125px;"|Mode 2 PRG-ROM<br/>Address Source
!scope="col" style="width: 125px;"|Mode 1 PRG-ROM<br/>Address Source
!scope="col" style="width: 125px;"|Mode 0 PRG-ROM<br/>Address Source
|-
||'''$0000-1FFF'''|| style="background: #cccccc;"|$5114 || style="background: #cccccc;" rowspan=2|$5115 || style="background: #cccccc;" rowspan=2|$5115 || style="background: #cccccc;" rowspan=4|$5117
|-
||'''$2000-3FFF'''|| style="background: #cccccc;"|$5115
|-
||'''$4000-5FFF'''|| style="background: #cccccc;"|$5116 || style="background: #cccccc;"|$5116          || style="background: #cccccc;" rowspan=2|$5117
|-
||'''$6000-7FFF'''|| style="background: #cccccc;"|$5117 || style="background: #cccccc;"|$5117
|-
||'''$8000-9FFF'''|| style="background: #80C0FF;"|$5114 || style="background: #80C0FF;"rowspan=2|$5115 || style="background: #80C0FF;"rowspan=2|$5115 || style="background: #80C0FF;"rowspan=4|$5117
|-
||'''$A000-BFFF'''|| style="background: #80C0FF;"|$5115
|-
||'''$C000-DFFF'''|| style="background: #80C0FF;"|$5116 || style="background: #80C0FF;"|$5116          || style="background: #80C0FF;"rowspan=2|$5117
|-
||'''$E000-FFFF'''|| style="background: #80C0FF;"|$5117 || style="background: #80C0FF;"|$5117
|-
|}


==== PRG bank 1 ($5115) ====
The MMC5's PRG-RAM address pins follow this logic, again with PRG-RAM /CE always disabled in the gray areas:
  7 bit  0
{| class="wikitable"
---- ----
!CPU Address
  RBBB BBBB
!scope="col" style="width: 125px;"|Mode 3 PRG-RAM<br/>Address Source
|||| ||||
!scope="col" style="width: 125px;"|Mode 2 PRG-RAM<br/>Address Source
|+++-++++- Bank number
!scope="col" style="width: 125px;"|Mode 1 PRG-RAM<br/>Address Source
+--------- RAM/ROM toggle (0: RAM; 1: ROM)
!scope="col" style="width: 125px;"|Mode 0 PRG-RAM<br/>Address Source
|-
||'''$0000-1FFF'''|| style="background: #cccccc;"|$5114 || style="background: #cccccc;" rowspan=2|$5115 || style="background: #cccccc;" rowspan=2|$5115 || style="background: #cccccc;" rowspan=3|$5113
|-
||'''$2000-3FFF'''|| style="background: #cccccc;"|$5115
|-
||'''$4000-5FFF'''|| style="background: #cccccc;"|$5116 || style="background: #cccccc;"|$5116          || style="background: #cccccc;"|$5113
|-
||'''$6000-7FFF'''|| style="background: #FFC0C0;"|$5113 || style="background: #FFC0C0;"|$5113          || style="background: #FFC0C0;"|$5113          || style="background: #FFC0C0;"|$5113
|-
||'''$8000-9FFF'''|| style="background: #FFC0C0;"|$5114 || style="background: #FFC0C0;"rowspan=2|$5115 || style="background: #FFC0C0;"rowspan=2|$5115 || style="background: #cccccc;" rowspan=4|$5113
|-
||'''$A000-BFFF'''|| style="background: #FFC0C0;"|$5115
|-
||'''$C000-DFFF'''|| style="background: #FFC0C0;"|$5116 || style="background: #FFC0C0;"|$5116          || style="background: #cccccc;" rowspan=2|$5113
|-
||'''$E000-FFFF'''|| style="background: #cccccc;"|$5113 || style="background: #cccccc;"|$5113
|-
|}
 
If we overlap these two tables, the original table reemerges. Pink always has /CE enabled for RAM (using $5113), Blue always has /CE enabled for ROM (using $5117), and Purple chooses which /CE using the register bit 7.  Gray always has RAM /CE and ROM /CE disabled at all times.
{| class="wikitable"
!CPU Address
!scope="col" style="width: 125px;"|Mode 3 PRG<br/>Address Source
!scope="col" style="width: 125px;"|Mode 2 PRG<br/>Address Source
!scope="col" style="width: 125px;"|Mode 1 PRG<br/>Address Source
!scope="col" style="width: 125px;"|Mode 0 PRG<br/>Address Source
|-
||'''$0000-1FFF'''|| style="background: #cccccc;"|$5114 || style="background: #cccccc;" rowspan=2|$5115  || style="background: #cccccc;" rowspan=2|$5115 || style="background: #cccccc;" rowspan=3|$5113/$5117
|-
||'''$2000-3FFF'''|| style="background: #cccccc;"|$5115
|-
||'''$4000-5FFF'''|| style="background: #cccccc;"|$5116 || style="background: #cccccc;"|$5116            || style="background: #cccccc;"|$5113/$5117
|-
||'''$6000-7FFF'''|| style="background: #FFC0C0;"|$5113/$5117 || style="background: #FFC0C0;"|$5113/$5117 || style="background: #FFC0C0;"|$5113/$5117    || style="background: #FFC0C0;"|$5113/$5117
|-
||'''$8000-9FFF'''|| style="background: #D0C0E0;"|$5114 || style="background: #D0C0E0;"rowspan=2|$5115    || style="background: #D0C0E0;"rowspan=2|$5115  || style="background: #80C0FF;" rowspan=4|$5113/$5117
|-
||'''$A000-BFFF'''|| style="background: #D0C0E0;"|$5115
|-
||'''$C000-DFFF'''|| style="background: #D0C0E0;"|$5116 || style="background: #D0C0E0;"|$5116            || style="background: #80C0FF;" rowspan=2|$5113/$5117
|-
||'''$E000-FFFF'''|| style="background: #80C0FF;"|$5113/$5117 || style="background: #80C0FF;"|$5113/$5117
|-
|}


* Mode 0 - Ignored
* Mode 1 - Select a 16KB PRG bank at $8000-$BFFF (ignore bottom bit)
* Mode 2 - Select a 16KB PRG bank at $8000-$BFFF (ignore bottom bit)
* Mode 3 - Select an 8KB PRG bank at $A000-$BFFF


When selecting a RAM bank, treat bank bits as indicated for the PRG RAM bank register at $5113.
==== PRG-RAM configurations ====


==== PRG bank 2 ($5116) ====
In [[ExROM|commercial configurations]], bits 0 and 1 select pages ''within'' an SRAM chip, and bit 2 selects between two separate SRAMs. 8K and 32K games have a single SRAM chip that will only be active when bit 2 is clear. 16K games instead have two chips, but only the first is battery backed.
7  bit  0
{| class="wikitable"
---- ----
! rowspan=2 | Configuration
RBBB BBBB
! colspan=8 | bank value & 7
|||| ||||
|-
|+++-++++- Bank number
! 0 !! 1 !! 2 !! 3 !! 4 !! 5 !! 6 !! 7
+--------- RAM/ROM toggle (0: RAM; 1: ROM)
|-
! ELROM 0K
| [[open bus]] || open bus || open bus || open bus || open bus || open bus || open bus || open bus
|-
! EKROM 8K (1 x 8K)
| 0:$0000 || 0:$0000 || 0:$0000 || 0:$0000 || open bus || open bus || open bus || open bus
|-
! ETROM 16K (2 x 8K)
| '''0''':$0000 || '''0''':$0000 || '''0''':$0000 || '''0''':$0000 || '''1''':$0000 || '''1''':$0000 || '''1''':$0000 || '''1''':$0000
|-
! EWROM 32K (1 x 32K)
| 0:$'''0000''' || 0:$'''2000''' || 0:$'''4000''' || 0:$'''6000''' || open bus || open bus || open bus || open bus
|-
! Superset 64K (2 x 32K)
| '''0''':$'''0000''' || '''0''':$'''2000''' || '''0''':$'''4000''' || '''0''':$'''6000''' || '''1''':$'''0000''' || '''1''':$'''2000''' || '''1''':$'''4000''' || '''1''':$'''6000'''
|}


* Mode 0 - Ignored
Since [[iNES]] headers were lacking reliable PRG-RAM size information before [[NES 2.0]], some emulators may have selected these behaviours through ROM CRC checks.
* Mode 1 - Ignored
* Mode 2 - Select an 8KB PRG bank at $C000-$DFFF
* Mode 3 - Select an 8KB PRG bank at $C000-$DFFF


When selecting a RAM bank, treat bank bits as indicated for the PRG RAM bank register at $5113.
Because no ExROM game is known to write PRG-RAM with one bank value and then attempt to read back the same data with a different bank value, emulating the PRG-RAM as 64K at all times can be used as a compatible superset for all games.


==== PRG ROM bank 3 ($5117) ====
Investigation of the [[MMC5 pinout]] in 2018 revealed that bits 2 and 3 also control additional PRG-RAM address pins, which could theoretically have been used to select 32 banks of a single 128K SRAM, with bit 2 controlling PRG A15 directly rather than using the two chip select /CE outputs.
7  bit 0
---- ----
xBBB BBBB
  ||| ||||
  +++-++++- PRG ROM bank number


* Mode 0 - Select a 32KB PRG ROM bank at $8000-$FFFF (ignore bottom 2 bits)
==== Other PRG-RAM notes ====
* Mode 1 - Select a 16KB PRG ROM bank at $C000-$FFFF (ignore bottom bit)
* Mode 2 - Select an 8KB PRG ROM bank at $E000-$FFFF
* Mode 3 - Select an 8KB PRG ROM bank at $E000-$FFFF


* ''Bandit Kings of Ancient China'' maps PRG-RAM to the CPU $8000+ area and expects to be able to write to it through there.  Failure to emulate this causes corruption when the background is restored on the world map.
* ''Uncharted Waters'' requires emulating bankswitching of PRG-RAM: it writes to PRG-RAM at one CPU address and expects to be able to read the same data back via a different CPU address.
* Games with 16K PRG-RAM only battery-save the first 8K.
* [http://bootgod.dyndns.org:7777/search.php?ines=5&battery=Yes&group=groupid List of MMC5 games which include a battery].


=== CHR Bankswitching ($5120-$5130) ===
=== CHR Bankswitching ($5120-$5130) ===
Registers $5120-$5127 apply to sprite graphics and $5128-$512B for background graphics, but ONLY when 8x16 sprites are enabled.
When using 8x8 sprites, only registers $5120-$5127 are used. Registers $5128-$512B are completely ignored.
 
When using 8x16 sprites, the PPU ignores the [[PPUCTRL|sprite pattern table address]] and can select tiles from the entire 8 KiB of pattern tables, which on other mappers overlaps with the background pattern table. The MMC5 keeps track of whether the PPU is fetching background tiles or sprite tiles, and has new registers to specify independent banks for the background tiles even if they appear to be the same address from the PPU. This effectively creates a CHR window of 12 KiB, with up to eight 1 KiB banks of sprites available simultaneously. Registers $5120-$5127 specify banks for sprites, registers $5128-$512B apply to background tiles, and the last set of registers written to (either $5120-$5127 or $5128-$512B) will be used for I/O via [[PPUDATA]] ($2007). [https://forums.nesdev.org/viewtopic.php?p=193069#p193069] [http://forums.nesdev.org/viewtopic.php?p=194120#p194120] The MMC5 knows that sprite data is being fetched by counting the number of fetches since the last detected scanline start, similar to how it detects the position for the vertical split.
 
''Bandit Kings of Ancient China'' and ''Uchuu Keibitai SDF'' have non-pattern data stored in CHR ROM, read out via $2007.


Otherwise, the last set of registers written to (either $5120-$5127 or $5128-$512B) will be used for all graphics.
The MMC5 is known to listen to the same address as the PPU to find out when to enable the 8x16 sprite mode; see [[#8x16_mode_enable_1_.28.242000_.3D_PPUCTRL.29|above]].


==== CHR selects 0…11====
==== CHR select $5120-$512B ====
{| class="wikitable"
{| class="wikitable"
! !! colspan=4|PPU memory affected for each mode (see [[#CHR mode ($5101)]])
! !! colspan=4|PPU memory affected for each mode (see [[#CHR mode ($5101)]])
|-
|-
! Write to CPU address !! 1 KiB !! 2 KiB !! 4 KiB !! 8 KiB
! Register !! 1 KiB !! 2 KiB !! 4 KiB !! 8 KiB
|-
|-
| $5120 || $0000-$03FF || none || none || none
| '''$5120''' || $0000-$03FF || none || none || none
|-
|-
| $5121 || $0400-$07FF || $0000-$07FF || none || none
| '''$5121''' || $0400-$07FF || $0000-$07FF || none || none
|-
|-
| $5122 || $0800-$0BFF || none || none || none
| '''$5122''' || $0800-$0BFF || none || none || none
|-
|-
| $5123 || $0C00-$0FFF || $0800-$0FFF || $0000-$0FFF || none
| '''$5123''' || $0C00-$0FFF || $0800-$0FFF || $0000-$0FFF || none
|-
|-
| $5124 || $1000-$13FF || none || none || none
| '''$5124''' || $1000-$13FF || none || none || none
|-
|-
| $5125 || $1400-$17FF || $1000-$17FF || none || none
| '''$5125''' || $1400-$17FF || $1000-$17FF || none || none
|-
|-
| $5126 || $1800-$1BFF || none || none || none
| '''$5126''' || $1800-$1BFF || none || none || none
|-
|-
| $5127 || $1C00-$1FFF || $1800-$1FFF || $1000-$1FFF || $0000-$1FFF
| '''$5127''' || $1C00-$1FFF || $1800-$1FFF || $1000-$1FFF || $0000-$1FFF
|-
|-
| $5128 || $0000-$03FF and $1000-$13FF || none || none || none
| '''$5128''' || $0000-$03FF and $1000-$13FF || none || none || none
|-
|-
| $5129 || $0400-$07FF and $1400-$17FF || $0000-$07FF and $1000-$17FF || none || none
| '''$5129''' || $0400-$07FF and $1400-$17FF || $0000-$07FF and $1000-$17FF || none || none
|-
|-
| $512A || $0800-$0BFF and $1800-$1BFF || none || none || none
| '''$512A''' || $0800-$0BFF and $1800-$1BFF || none || none || none
|-
|-
| $512B || $0C00-$0FFF and $1C00-$1FFF || $0800-$0FFF and $1800-$1FFF || $0000-$0FFF and $1000-$1FFF || $0000-$1FFF
| '''$512B''' || $0C00-$0FFF and $1C00-$1FFF || $0800-$0FFF and $1800-$1FFF || $0000-$0FFF and $1000-$1FFF || $0000-$1FFF
|}
|}
'''Caution:''' Unlike the MMC1 and unlike PRG banking on the MMC5, the banks are always indexed by the ''currently selected size''. When using 2kb, 4kb or 8kb bank sizes, the registers hold bank index of that larger size, and lower bits are *not* ignored.


==== Upper CHR Bank bits ($5130) ====
==== Upper CHR Bank bits ($5130) ====
Line 293: Line 546:


When the MMC5 is using 2KB/1KB CHR banks, only 512KB/256KB of CHR ROM can be selected using the previous registers. To access all 1024KB in those modes, first write the upper bit(s) to register $5130 and then write the lower bits to $5120-$512B.
When the MMC5 is using 2KB/1KB CHR banks, only 512KB/256KB of CHR ROM can be selected using the previous registers. To access all 1024KB in those modes, first write the upper bit(s) to register $5130 and then write the lower bits to $5120-$512B.
When the Extended RAM mode is set to 1, this selects which 256KB of CHR ROM is to be used for all background tiles on the screen.
 
The only ExROM game with CHR ROM larger than 256KB is ''Metal Slader Glory'', which uses 4KB CHR banks and does not use extended attributes. In other words, no official game relies on this register, and most don't even initialize it.
 
In extended attribute mode ($5104 = 1), this register likely acts as a global, instantaneous bank selection that gets appended as the most significant 2 bits of ''all'' of the tile-specific CHR banks, selecting which 256KB of CHR ROM is to be used for all background tiles on the screen.  It is unlikely that the extended RAM stores all 10 bits per write, like registers $5120-$512B.


=== Other Registers ===
=== Other Registers ===
Line 302: Line 558:
  ESxW WWWW
  ESxW WWWW
  || | ||||
  || | ||||
  || +-++++- Specify vertical split start/stop tile
  || +-++++- Specify vertical split threshold tile count
  |+-------- Specify vertical split screen side (0:left; 1:right)
  |+-------- Specify vertical split region screen side (0:left; 1:right)
  +--------- Enable vertical split mode
  +--------- Enable vertical split mode


When vertical split mode is enabled, all VRAM fetches corresponding to the appropriate screen region will be redirected to Extended RAM (as long as its mode is set to 0 or 1).
''Uchuu Keibitai SDF'' uses split screen mode during the intro, where it shows ship stats.  ''Bandit Kings of Ancient China'' uses split screen mode during the ending sequence<ref>https://forums.nesdev.org/viewtopic.php?f=2&t=12764</ref>.
 
MMC5 internal extended RAM is always used as the nametable in split screen mode. Extended RAM mode ($5104) should be set to %00 or %01. RAM modes %10 or %11 disable split mode. Driving pin 92 low also disables split mode.  Split mode is automatically disabled based on PPUMASK monitoring. (See section on $2001 monitoring)
 
When using mode %01 with vertical split mode, the non-split region gains extended attributes, and the split region does not use extended attributes. As long as the non-split region remains horizontally scrolled to align with the left edge of a nametable, it is possible to share the extended RAM for both purposes.  For example, a split region on the right side of the screen will read its nametable data and non-extended attribute data from the “right side” of the extended RAM, and the left side of the screen will read its nametable data from wherever it is assigned in $5105, and get its extended attributes from the “left side” of the extended RAM.  The two separate functions of extended RAM data would not overlap this way.
 
===== Method of Operation =====
 
Based on nametable fetch count (horizontally) and scanline count (vertically), the MMC5 makes substitutions to the nametable data, attribute table data, and the lowest 3 address bits of the pattern data.
 
===== Horizontal Behavior =====
 
For each visible scanline, the PPU fetches nametable data for 34 background tiles.  The MMC5 locates the split threshold by counting these fetches and comparing the count to the count value stored in register $5200. When the PPU is rendering in the split region, the MMC5 replaces the normal nametable data with the split region nametable data.  Because the split threshold is located based on nametable fetch count and not based on the actual nametable address requested by the PPU, the location of the split is more of an absolute position on the screen, always positioned the same number of tiles from the left side of the screen.  The PPU’s fine horizontal scrolling can cause the first tile rendered to be of fractional width, however the vertical split threshold will always occur at a full tile boundary, so the exact location of the split threshold is affected by fine horizontal scrolling, potentially deviating by up to 7 pixels this way.
Left Split:
* Tiles 0 to T-1 are the split region.
* Tiles T and on are rendered normally.
Right Split:
* Tiles 0 to T-1 are rendered normally.
* Tiles T and on are the split region.
 
There is no intended horizontal scrolling of any kind for the split region.  Right-side split regions will always remain right-aligned with the right-hand side of the nametable, and left-side split regions will always remain left-aligned with the left-hand side of the nametable. Coarse horizontal scrolling can still be used for the non-split region.
 
===== Vertical Behavior =====
The MMC5 is able to have its own vertical origin in the split region because the nametable data that it substitutes is based on scanline count, which is always aligned to the top of the screen.
 
The MMC5 keeps track of the scanline count and adds this to the vertical scrolling value in $5201 in order to know what nametable data to substitute in the split region on each scanline.  Though the PPU continues requesting nametable data corresponding to its normal vertical scrolling in the split region, the MMC5 is ignoring the nametable address requested in this case and directly substituting its own nametable data.
 
One additional caveat is fine vertical scrolling of the split region.  For each tile on each scanline, the PPU reads from a nametable, and uses that information to fetch the pattern data for 1 row of pixels for that tile.  The PPU normally keeps track of which row to fetch using PPU A0..3.  However, if the MMC5’s fine vertical scrolling doesn’t match the PPU’s fine vertical scrolling, it won’t be fetching the correct row of pixels from the tile.  This is why the MMC5 provides CHR A0..3.  By default, Nintendo PCBs are wired in “CL Mode”, which prevents the correct fine vertical scrolling of the split region.  (See [[MMC5 pinout]]).
 
Vertical scrolling for the split region operates like normal vertical scrolling.  0-239 are valid scroll values, whereas 240-255 will display attribute table data as nametable data for the first few scanlines.  The MMC5 does proper vertical mirroring of the split region nametable so that scrolling down properly rolls over to the top of the nametable, skipping the attribute table data that would naturally be located there.


==== Vertical Split Scroll ($5201) ====
==== Vertical Split Scroll ($5201) ====
   All eight bits specify the vertical scroll value to use in split region
   All eight bits specify the vertical scroll value to use in split region


MMC5 boards wired in "CL" mode may only use vertical scroll values whose bottom 3 bits match the [[PPU|Nes PPU]]'s fine vertical scroll value. In "SL" mode, any values can be used.
MMC5 boards wired in "CL" mode should only use vertical scroll values whose bottom 3 bits match the [[PPU]]'s fine vertical scroll value. Using a mismatched value will cause tiles to seem to "roll" within themselves. In "SL" mode, any values can be used. (No existing games used the SL board configuration.)


Horizontal scrolling is not allowed within the split region.
Horizontal scrolling is not allowed within the split region.
Line 318: Line 606:
   All eight bits select a 4 KB CHR bank at $0000-$0FFF and $1000-$1FFF while rendering the split region.
   All eight bits select a 4 KB CHR bank at $0000-$0FFF and $1000-$1FFF while rendering the split region.


==== IRQ Counter ($5203) ====
==== IRQ Scanline Compare Value ($5203) ====
  All eight bits specify the scanline number to generate IRQ at
All eight bits specify the target scanline number at which to generate a scanline IRQ.  Value $00 is a special case that will not produce IRQ pending conditions, though it is possible to get an IRQ while this is set to $00 (due to the pending flag being set already.) You will need to take additional measures to fully suppress the IRQ. See the detailed discussion.


==== IRQ Status ($5204, read/write) ====
==== Scanline IRQ Status ($5204, read/write) ====
===== Write =====
===== Write =====
  7  bit  0
  7  bit  0
Line 327: Line 615:
  Exxx xxxx
  Exxx xxxx
  |
  |
  +--------- IRQ Enable flag (1=IRQs enabled)
  +--------- Scanline IRQ Enable flag (1=enabled)


===== Read =====
===== Read =====
  7  bit  0
  7  bit  0
  ---- ----
  ---- ----
  SVxx xxxx
  SVxx xxxx MMC5A default power-on value = $00
  ||
  ||
  |+-------- "In Frame" signal
  |+-------- "In Frame" flag
  +--------- IRQ Pending flag
  +--------- Scanline IRQ Pending flag


When set, the "In Frame" signal specifies that the PPU is currently rendering a scanline.  It also plays a role in how IRQs are generated.
The Scanline IRQ Pending flag becomes set at any time that the internal scanline counter matches the value written to register $5203.  If the scanline IRQ is enabled, it will also generate /IRQ to the system.


The IRQ Pending flag may be raised even if IRQs are disabled.
The "In Frame" flag is set when the PPU is actively rendering visible scanlines and cleared when not rendering; for example, vertical blank scanlines.  This flag does not clear for the short H-Blank period between visible scanlines.  When pin 92 is driven low, this flag remains low at all times. Additionally, scanline IRQs no longer occur when pin 92 is driven low.


Any time this register is read, the IRQ Pending flag is cleared (acknowledging the IRQ).
Any time this register is read, the Scanline IRQ Pending flag is automatically cleared (acknowledging the IRQ).  Acknowledging the IRQ does not clear the scanline counter, and you may write a larger value to $5203 within a scanline ISR in order to generate another IRQ on an additional scanline within the same frame.


For details, see [[MMC5#IRQ_Counter_Operation|IRQ counter operation]].
For details, see [[MMC5#IRQ_Counter_Operation|IRQ counter operation]].


==== Multiplier ($5205, read/write) ====
==== Unsigned 8x8 to 16 Multiplier ($5205, $5206 read/write) ====
  Writes specify the eight-bit multiplicand; reads return the lower eight bits of the product
The unsigned 16-bit product is available to be read from these registers immediately after writing.  All 65536 combinations of multiplicand and multiplier were tested and verified correct on MMC5A here[https://forums.nesdev.org/viewtopic.php?p=226537#p226537].
===== Write =====
*$5205 8-bit Unsigned Multiplicand
*$5206 8-bit Unsigned Multiplier
*MMC5A default power-on write value = $FF for both of these registers.
 
===== Read =====
*$5205 Unsigned 16-bit Product (low byte)
*$5206 Unsigned 16-bit Product (high byte)
*MMC5A default power-on read value = $FE01, i.e. $FF * $FF.
 
=== Internal extended RAM ($5C00-$5FFF, read/write) ===
Refer to register $5104 for special behaviors of the MMC5's 1KB internal extended RAM.
 


==== Multiplier ($5206, read/write) ====
== MMC5A ==
  Writes specify the eight-bit multiplier; reads return the upper eight bits of the product


=== Expansion RAM ($5C00-$5FFF, read/write) ===
The MMC5A was a later revision of MMC5 that included some extra features. Other than Just Breed mysteriously writing to $5800, no game is known that uses these features. Therefore, these will probably tend to have poor support from emulators.
* Mode 0/1 - Not readable (returns [[open bus]]), can only be written while the PPU is rendering (otherwise, 0 is written)
* Mode 2 - Readable and writable
* Mode 3 - Read-only


In Mode 1, nametable fetches are processed normally, and can come from CIRAM nametables, fill mode, or even Expansion RAM, but attribute fetches are replaced by data from Expansion RAM.
=== MMC5A Registers ===
Registers $5207, $5208, $5209, $520A, and range $5800-$5BFF are present only in MMC5A.
==== CL3 / SL3 Data Direction and Output Data Source (MMC5A: $5207 write only) ====
7  bit  0
---- ----
ABxx xxCD  MMC5A default power-on write value = 11xx xx00
||    ||
||    |+- MMC5.97 (CL3) Function (0 = I/O Control, 1 = $5800 read control
||    +-- MMC5.98 (SL3) Function (0 = I/O Control, 1 = $5800 write control
|+-------- MMC5.97 (CL3) I/O Data Direction (0 = output, 1 = input)
+--------- MMC5.98 (SL3) I/O Data Direction (0 = output, 1 = input)


Each byte of Expansion RAM is used to enhance the tile at the corresponding address in every nametable (so the extended attributes are 1-screen mirrored):
When a function bit is set to 1, the pin becomes controlled by the applicable CPU writes or reads in the range $5800-$5BFF. The pin is normally driven high, and when the read or write occurs, it has a low pulse corresponding to !(M2). The intended purpose is unknown. It is theorized that it may attach a peripheral or additional RAM. When in this mode, none of the I/O configuration bits have any effect.


==== CL3 / SL3 Status (MMC5A: $5208 read/write) ====
===== Write =====
  7  bit  0
  7  bit  0
  ---- ----
  ---- ----
  AACC CCCC
  ABxx xxxx  MMC5A default power-on write value = 00xx xxxx
||
|+-------- Value to be output on MMC5.97 pin (CL3) if it is set as an I/O output in $5207.
+--------- Value to be output on MMC5.98 pin (SL3) if it is set as an I/O output in $5207.
 
Warning: The PCB may connect pins 97 and 98 directly to GND.  Though not totally confirmed, setting them as output high while connected like this has appeared to break the output drivers of these pins. Also note that enabling the $5800 function will have these pins driving high most of the time as well.
 
===== Read =====
7  bit  0
---- ----
ABxx xxxx
||
|+-------- Input value of MMC5.97 pin (CL3)
+--------- Input value of MMC5.98 pin (SL3)
 
==== 16-bit Hardware Timer with IRQ (MMC5A: $5209 read/write, $520A write) ====
===== Read =====
*$5209
7  bit  0
---- ----
Vxxx xxxx  MMC5A default power-on read value = $00
|
+--------- Hardware Timer IRQ Flag
 
===== Write =====
*$5209
7  bit  0
---- ----
TTTT TTTT  MMC5A default power-on write value = $00
|||| ||||
++++-++++- Timer count LSB
 
*$520A
7  bit  0
---- ----
TTTT TTTT  MMC5A default power-on write value = $00
  |||| ||||
  |||| ||||
  ||++-++++- Select 4 KB CHR bank to use with specified tile
  ++++-++++- Timer count MSB
  ++-------- Select palette to use with specified tile
 
Based on findings from krzysiobal:
The timer automatically starts when writing any value to register $5209, if the 16-bit timer value does not equal $0000.  For example, to write value $0100, you would first write $01 (MSB) to register $520A, which does not start the timer. Then write $00 (LSB) to register $5209, which at that point will start the timer from value $0100.


The pattern fetches ignore the standard CHR banking bits, and instead use the top two bits of $5130 and the bottom 6 bits from Expansion RAM to choose a 4KB bank to select the tile from.
Each 8-bit value is written directly to an internal 16-bit counter that decrements each CPU cycle, specifically on the rising edge of M2.  Additional writes while the timer is running will directly overwrite that portion of the counter.  Reading register $5209 while the timer is running reports $00.  The transition from counter value $0001 to $0000 generates an IRQ and sets the hardware timer IRQ flag.  The timer stops at this point.  Reading this register reports the IRQ flag, then automatically clears the IRQ and IRQ flag.


== IRQ Counter Operation ==
If the MMC5 detects a reset, it clears the timer if active, and it clears the IRQ and IRQ flag if set.  Reset detection works by looking for a gap larger than about 11 usec on M2.


The MMC5 has an 8-bit incrementing IRQ counter that watches the PPU as it renders, and counts each passing scanline.  When the counter reaches the desired IRQ scanline (specified by the $5203 register), it signals an IRQ.  It also uses an In Frame signal which can be read from $5204.6 in conjunction with the 8-bit counter.  Games can use this signal as an indication of whether or not the PPU is currently in rendering time.
This register's IRQ operation is completely independent from register $5204.  Disabling interrupts through $5204 has no effect on, and reading $5204 does not report on, IRQs generated these registers.


The game has no direct access to the internal IRQ counter.
==== Unknown Address Range (MMC5A: $5800-$5BFF, write only) ====
Reads and writes in this address range are reflected on the CL3 and SL3 pins when register $5207 = $03.  The purpose of this function is unknown.  Minute VCC current spikes shortly after rising edge of M2 during writes in this range exhibit the same characteristics as writes in internal extended RAM range $5C00-$5FFF, suggesting possible existence of RAM in this range, though experimentally reading from this range is always met with open CPU bus.


How the MMC5 actually detects scanlines is still unknown.  The best evidence now is that it watches for the two dummy nametable reads which occur at the end of each scanline, see [http://forums.nesdev.org/viewtopic.php?t=7653].  It appears that all 240 rendered scanlines as well as the pre-render scanline are all detected by the MMC5.  It also appears that scanlines are detected near their end (or near the start of the next scanline).  When a game sets the desired IRQ scanline to $04, the IRQ will occur near the start of the 5th rendered scanline.
Address $5800 is written to by Just Breed.  During each V-Blank, it writes value $03, then $01 to this address, reads and writes to PPU registers, then writes value $00 to this address once complete.  It is theorized that this was used as a debug signal to measure CPU usage / idle time during development.


When the MMC5 detects a scanline, the following events occur:
== Scanline Detection and Scanline IRQ ==
* if the In Frame signal is clear, set it, reset the IRQ counter to 0, and clear the IRQ Pending flag
[[File:mmc5_in_frame_status_bit.png|thumb|right|MMC5 'in frame' status bit state diagram]]
* otherwise, increment the IRQ counter.  If it now equals the IRQ scanline ($5203), raise IRQ Pending flag
The MMC5 detects scanlines by first looking for three consecutive PPU reads from the same nametable address in the range $2xxx. Once this has been seen, the next PPU read, regardless of address, is the point at which the scanline is detected.  This works because the PPU does two matching dummy nametable byte reads at the end of each scanline, followed by a third matching nametable byte read at the beginning of the next scanline, followed by an attribute table byte read.  So, the scanline gets detected when the PPU does the attribute table byte read, which is at PPU cycle 4.


Note the above logic makes it impossible for an IRQ to occur when $5203 is set to $00
Once that occurs, if the "in-frame" flag (register $5204) was clear, it becomes set, and the internal 8-bit scanline counter is reset to zero; but if it was already set, the scanline counter is incremented, then compared against the value written to $5203. If they match, the "irq pending" flag is set.


The In Frame signal is cleared as soon as the MMC5 no longer detects PPU rendering. This happens at the end of the last rendered scanline, and whenever the PPU is switched off (Sprite and BG rendering disabled).
The IRQ pending flag is raised when the desired scanline is reached ''regardless'' of whether or not the scanline IRQ is enabled, i.e. even after a 0 was written to the scanline IRQ enable flag. However, an actual IRQ is only sent to the CPU if both the scanline IRQ enable flag and IRQ pending flag are set. A $5203 value of $00 is a special case where the comparison is never true. The MMC5's scanline IRQ occurs at PPU cycle 4, unlike the simpler scanline counter of the MMC3, which usually generates an IRQ around PPU cycle 260. See also [http://forums.nesdev.org/viewtopic.php?t=7653].


Note that there are side-effects to switching off the PPU mid frame.  Clearing the In Frame signal effectively resets the IRQ counter as can be seen in the logic given above.  Therefore, if the PPU is switched back on in the frame, the IRQ counter will begin counting from $00 again.
The "in-frame" flag is cleared  when the PPU is no longer rendering.  This is detected when 3 CPU cycles pass without a PPU read having occurred (PPU /RD has not been low during the last 3 M2 rises).  The PPU does this in these conditions:
* the PPU begins the post-render scanline 240
* the PPU stops rendering because the user program wrote to CPU address $2001 with bits 3 and 4 clear.
* note: the MMC5 may not listen directly to writes to $2001 for this behavior, or it may be monitoring for particular transitions of $2001 that have not yet been fully tested.


The IRQ Pending flag is raised when the desired scanline is reached ''regardless'' of whether or not IRQs are enabled.  $5204.7 can still be read as set even when IRQ Enable flag is clear.  However, an actual IRQ is only sent to the CPU if both the IRQ Enable flag and IRQ Pending flag are raised.
The "in frame" flag is cleared, scanline IRQ is automatically acknowledged, and the internal scanline counter is reset in any of these conditions:
* the V-blank NMI occurs, i.e. CPU reads the interrupt vector from addresses $FFFA and $FFFB
* the user program intentionally reads from CPU addresses $FFFA or $FFFB
* the 241st scanline is detected.
* when the MMC5 believes that $2001 bits 3 and 4 are both clear and then either one of them gets set.


== Hardware ==
The scanline IRQ is acknowledged, but the "in frame" flag is not cleared and the scanline counter is not reset in any of these conditions:
* the user program reads register $5204
* scanline 0 is detected


The MMC5 exists in a 100-pin TQFP package, see [[MMC5 pinout]] for details.
When system reset detection occurs, the only thing that happens is scanline IRQ becomes disabled. All other operation continues unaffected.  These things happen any time that scanline IRQ becomes disabled:
* if /IRQ was low due to scanline IRQ pending flag, /IRQ returns high
* the scanline IRQ pending flag remains unaffected
* register $5203 value remains unaffected
* scanline counter remains unaffected
* enabling the scanline IRQ will cause immediate /IRQ low if IRQ pending flag is set, but will not affect anything else


MMC5 cartridge PCBs can be configured to different modes, see [[ExROM]] for details.
This means in pseudo-code:
(On every PPU read -- PPU /RD falling edge)
if address >= $2000 and address <= $2FFF and address == lastAddress
    matchCount := matchCount +1
    if matchCount == 2
      if inFrame == false
        inFrame := true
        scanline := 0
      else
        scanline := scanline +1
        if scanline == [$5203]
            irqPending := true
else
    matchCount := 0
lastAddress := address
ppuIsReading := true
(On every CPU cycle -- M2 rising edge)
if ppuIsReading
    idleCount := 0
else
    idleCount := idleCount +1     
    if idleCount == 3
      inFrame := false
      lastAddress := undefined
ppuIsReading := false
(On every CPU write)
if address == $2001 and (value & $18) == 0
    inFrame := false
    lastAddress := undefined
(On every CPU read)
if address == $FFFA or address == $FFFB
    inFrame := false
    lastAddress := undefined
Please refer to the state diagrams on the right for a more formal description of the scanline and in-frame detection counters.


At least two different versions of the MMC5 are known to exist: MMC5, and MMC5B. Their differences are unknown.
== Hardware ==


== Disch's notes ==
The MMC5 exists in a 100-pin rectangular QFP package, see [[MMC5 pinout]] for details.


  These are no longer Disch's original notes:
MMC5 cartridge PCBs can be configured to different modes, see [[ExROM]] for details.
  ========================
  =  Mapper 005          =
  ========================
 
  aka
  --------------------------
  MMC5
  ExROM
 
 
 
  Example Games:
  --------------------------
  Castlevania 3
  Just Breed
  Uncharted Waters
  Romance of the 3 Kingdoms 2
  Laser Invasion
  Metal Slader Glory
  Uchuu Keibitai SDF
  Shin 4 Nin Uchi Mahjong - Yakuman Tengoku
  Bandit Kings of Ancient China
 
  Test ROM Notes:
  ---------------------------
  - Bandit Kings of Ancient China writes PRG-RAM through the $8000+ ROM area. Failure to emulate this causes
    corruption when the background is restored on the world map.
  - Uchuu Keibitai SDF is the only known game to use split screen mode (during the intro, where it shows ship
    stats)
  - Shin 4 Nin Uchi Mahjong uses the extra PCM channel ($5011) as well as the other extra sound
  - Uncharted Waters does PRG-RAM swapping
  - Just Breed uses ExAttribute mode everywhere, as well as the extra sound.
 
 
  General Notes:
  ---------------------------
  MMC5 is the infamous juggernaut mapper.  It does a whole slew of neat tricks, making it far more powerful
  than any other mapper around.  Though despite its apparent complexity, it's suprisingly straightforward to
  emulate (that doesn't mean it's easy, though).
 
  It's a shame that the only real games to use this mapper were a ton of really, really terrible Koei strategy
  games.  Such a waste.
 
 
  RAM Notes:
  ----------------------------
  MMC5 can address up to 64k PRG-RAM!  This is significantly more than the usual 8k.  When emulating, it's
  easiest just to give MMC5 games a full 64k, since the header doesn't really provide a decent way to indicate
  how much PRG-RAM actually exists.
 
  In addition to PRG-RAM, the MMC5 itself has a full 1k of 'ExRAM' which can be accessed by both the CPU and
  PPU.  This ExRAM can be used for many things... from plain vanilla WRAM, to an extra nametable, to a seperate
  split screen, to extending normal attribute tables.
 
 
  This document's organization:
  ---------------------------
  Since there are so many registers for this mapper, and it has so many features, registers will be listed and
  outlined as the features are explained... and the overall registers section will be extremely brief --
  serving primarily as a very quick reference or checklist.
 
  Misc Modes and Setup:
  ---------------------------
 
    $5102:  [.... ..AA]    PRG-RAM Protect A
    $5103:  [.... ..BB]   PRG-RAM Protect B
        To allow writing to PRG-RAM you must set these regs to the following values:
          A=%10
          B=%01
        Any other values will prevent PRG-RAM writing.
 
    $5104:  [.... ..XX]    ExRAM mode
        %00 = Extra Nametable mode    ("Ex0")
        %01 = Extended Attribute mode ("Ex1")
        %10 = CPU access mode        ("Ex2")
        %11 = CPU read-only mode      ("Ex3")
 
 
  CHR Setup:
  ---------------------------
  The MMC5 has two sets of CHR regs.  One set is used for sprites, the other is used for BG.  The MMC5
  carefully watches what tiles are being fetched and when (or has some other way of syncing with the NES
  somehow), which allows it to tell when the NES is fetching BG tiles, and when it's fetching sprite tiles.
  As such, it can use different regs accordingly, allowing games to basically have 12k of CHR "active" at once
  instead of the usual 8k!  This means you can have a full 512 tiles exclusively for sprites, and have an
  additional 256 tiles for the BG!
 
  CHR Mode Select Reg:
  $5101:  [.... ..CC]
        %00 = 8k Mode
        %01 = 4k Mode
        %10 = 2k Mode
        %11 = 1k Mode
 
  'High' CHR Reg:
    $5130  [.... ..HH] (see below)
 
  'A' Regs:
    $5120 - $5127
  'B' Regs:
    $5128 - $512B
 
  When in 8x16 sprite mode, both sets of registers are used.  The 'A' set is used for sprite tiles, and the
  'B' set is used for BG.  This makes it so that sprites can have a full 8k of CHR available, without having
  to share any of the tiles with the BG (since the BG uses its own 4k of CHR, designated by the 'B' set).  It
  is unsure what you will get when reading CHR via $2007.
 
  When in 8x8 sprite mode, only one set is used for both BG and sprites.  Either 'A' or 'B', depending on which
  set is written to last.  If 'B' is used, $1000-1FFF always mirrors $0000-0FFF (making the 'B' set pretty
  worthless with 8x8 sprites)
 
 
  'A' Set (sprites):
                $0000  $0400  $0800  $0C00  $1000  $1400  $1800  $1C00
              +---------------------------------------------------------------+
    C=%00:    |                            $5127                            |
              +---------------------------------------------------------------+
    C=%01:    |            $5123            |            $5127            |
              +-------------------------------+-------------------------------+
    C=%10:    |    $5121    |    $5123    |    $5125    |    $5127    |
              +---------------+---------------+---------------+---------------+
    C=%11:    | $5120 | $5121 | $5122 | $5123 | $5124 | $5125 | $5126 | $5127 |
              +-------+-------+-------+-------+-------+-------+-------+-------+
 
  'B' Set (BG):
                $0000  $0400  $0800  $0C00  $1000  $1400  $1800  $1C00
              +-------------------------------+
    C=%00:    |            $512B*            |
              +-------------------------------+
    C=%01:    |            $512B            |
              +-------------------------------+  $1xxx always mirrors $0xxx
    C=%10:    |    $5129    |    $512B    |
              +---------------+---------------+
    C=%11:    | $5128 | $5129 | $512A | $512B |
              +-------+-------+-------+-------+
 
  * $512B in 8k mode is an 8k page number, but only the first half of the 8k page is used.


(It is not clear that the above is always true. It seems that neither nintendulator nor fceux actually obey this, and some demos fail if this behavior is emulated. A proposed revision would be as follows: )
At least two different versions of the MMC5 are known to exist: MMC5, and MMC5A. MMC5A has the addition of registers $5207, $5208, $5209, and $520A: SL3/CL3 control and hardware timer.


  'B' Set (BG):
== References ==
                $0000  $0400  $0800  $0C00  $1000  $1400  $1800  $1C00
<references />
              +-------------------------------+-------------------------------+
    C=%00:    |                            $512B                            |
              +-------------------------------+-------------------------------+
    C=%01:    |            $512B            |            $512B            |
              +-------------------------------+-------------------------------+
    C=%10:    |    $5129    |    $512B    |    $5129    |    $512B    |
              +---------------+---------------+---------------+---------------+
    C=%11:    | $5128 | $5129 | $512A | $512B | $5128 | $5129 | $512A | $512B |
              +-------+-------+-------+-------+-------+-------+-------+-------+
&nbsp;
  Note that unlike most other mappers, these CHR pages are in *actual* sizes.  IE:  when in 4k mode, registers
  contain 4k page numbers.  But when in 2k mode, register contain 2k page numbers.
 
  CHR Regs are actually 10 bits wide, not just 8.  When you write to the regs, the value written is the low 8
  bits, and the high 2 bits are copied from $5130.  Example:
 
    LDA #$00
    STA $5130  ; high bits = 0
    LDA #$20
    STA $5127  ; $5127 now = $020
 
    LDA #$02
    STA $5130
    LDA #$41
    STA $5123  ; $5123 now = $241
              ; and $5127 still = $020 (not $220)
 
  $5130 has an additional role in ExAttribute mode.
 
 
 
  PRG/RAM Setup:
  ---------------------------
 
 
  $5100:  [.... ..PP]    PRG Mode Select:
      %00 = 32k
      %01 = 16k
      %10 = 16k+8k
      %11 = 8k
 
  $5113:  [.... .PPP]        (simplified, but technically inaccurate -- see below)
    8k PRG-RAM page @ $6000
 
  $5114-5117:  [RPPP PPPP]
    R = ROM select (0=select RAM, 1=select ROM)  **unused in $5117**
    P = PRG page
 
  The high bit allows the game to select between ROM and RAM.  This allows the game to put PRG-RAM anywhere
  between $6000-DFFF (but no higher, since $5117 always selects ROM)
 
  Only RAM can be swapped to $6000-7FFF.
  $5117 always selects ROM, never RAM (ROM always at $E000-FFFF).
 
                  $6000  $8000  $A000  $C000  $E000 
                +-------+-------------------------------+
    P=%00:    | $5113 |          <<$5117>>          |
                +-------+-------------------------------+
    P=%01:    | $5113 |    <$5115>    |    <$5117>    |
                +-------+---------------+-------+-------+
    P=%10:    | $5113 |    <$5115>    | $5116 | $5117 |
                +-------+---------------+-------+-------+
    P=%11:    | $5113 | $5114 | $5115 | $5116 | $5117 |
                +-------+-------+-------+-------+-------+
 
 
  Technically, $5113 should look something like:
    [.... .CPP]
      C = Chip select
      P = 8k PRG-RAM page on selected chip
 
  MMC5 can address two seperate RAM chips, each up to 32k in size.
 
  This detail can impact how RAM is mirrored across pages if the chip sizes are less than 32k.  For example,
  Uncharted Waters has two 8k chips (only 16k total -- but on two seperate chips), so it uses selects pages
  $00 and $04, rather than $00 and $01 like you may expect.  This is because bit 2 is the chip select, and
  the 8k on each chip is mirrored to every page on that chip... that is... $00-$03 would all select the first
  8k.
 
  Note that no commercial games rely on this mirroring -- therefore you can take the easy way out and simply give
  all MMC5 games 64k PRG-RAM.
 
 
  Mirroring:
  ---------------------------
    $5105:  [DDCC BBAA]
 
 
  MMC5 allows each NT slot to be configured:
    [  A  ][  B  ]
    [  C  ][  D  ]
 
  Values can be the following:
    %00 = NES internal NTA
    %01 = NES internal NTB
    %10 = use ExRAM as NT
    %11 = Fill Mode
 
 
  For example... some typical mirroring setups would be:
                (  D  C  B  A)
    Horz:  $50  (%01 01 00 00)
    Vert:  $44  (%01 00 01 00)
    1ScA:  $00  (%00 00 00 00)
    1ScB:  $55  (%01 01 01 01)
 
 
  ExRAM can act as a 3rd nametable here... but only in Ex0 or Ex1 (see $5104 above).  If in Ex2 or Ex3, the PPU
  will get $00 when it attempts to read from the nametable.  Note that while ExRAM can be used as a nametable
  in Ex1, it's probably a bad idea, since ExRAM is also used for Extended attributes in that mode.  Therefore,
  when using ExRAM as a nametable, you should stick to Ex0.
 
  Fill Mode is a virtual nametable.  It is not a full nametable, but rather, as the PPU attempts to read it,
  the MMC5 will feed it a specific tile -- thus appearing as though there's a full nametable filled with a
  single tile.  The tile can be configured by the game with the following regs:
 
    $5106:  [TTTT TTTT]    Fill Tile
    $5107:  [.... ..AA]    Fill Attribute bits
 
 
 
  Extended Attribute Mode:
  ---------------------------
  When in Ex1 mode (see $5104 above), ordinary attribute tables and BG CHR regs are ignored, and instead, each
  byte in ExRAM coresponds with an onscreen tile, and assigns that tile a 4k CHR page (allowing you to choose
  from 16k tiles instead of 256) and its own attribute bits (allowing each 8x8 tile to have its own palette,
  rather than having the normal 16x16 blocks).
 
  Bytes in ExRAM:
    [AACC CCCC]
      A = Attribute bits
      C = 4k CHR Page
 
  Additionally... $5130 is used directly as the high 2 bits of CHR for every on-screen BG tile when in this
  mode.  It effectively selects a 256k block for BG to use (in addition to its normal use with CHR swapping).
  $5130's runtime value affects all BG tiles, therefore changing $5130 will immediately swap all on-screen BG
  when in this mode.  Therefore, if/when you change $5130 to swap CHR for sprites, you must write to $5130
  again with the desired value for the BG.
 
  Sprites are unaffected by this mode and still use the normal CHR regs.
 
  Which tile uses which byte in ExRAM depends on its position in the nametable.  Scrolling is irrelevent.  The
  tile at $2000 always uses the first byte in ExRAM, $2001 uses the second, etc.  $2400, $2800, and $2C00 also
  use the first byte of ExRAM.
 
 
  CPU Accessing ExRAM:
  ---------------------------
  ExRAM can be accessed by the CPU via $5C00-$5FFF.  Whether or not you can read or write depends on the
  current mode (see $5104):
 
    Mode  Readable  Writable
    -------------------------
    Ex0      no        *
    Ex1      no        *
    Ex2      yes      yes
    Ex3      yes        no
 
  In Ex0 and Ex1, ExRAM can only be written DURING RENDERING (insane, I know).  If a game attempts to write
  outside of rendering, $00 is written instead of the desired value.  Writes have absolutely no effect in Ex3.
 
  Attempting to read when not readable will return open bus.
 
 
 
 
  8 * 8 -> 16 Multiplier:
  ---------------------------
  MMC5 has a nifty multiplier, similar to the SNES's.
 
  on write:
    $5205:  multiplicand
    $5206:  multiplier
 
  on read:
    $5205:  low 8 bits of product
    $5206:  high 8 bits of product
 
  Basic functionality is, you write two values you want multiplied to $5205 and $5206, then read the product
  back.  Multiplication is unsigned.  There is no noticable delay -- that is, the product can be read back
  right after writing.
 
 
 
 
  Split Screen:
  ---------------------------
  A unique feature to MMC5 is its ability to split the screen vertically down the middle.  However due to some
  limitations that couldn't be avoided, it ended up not being that useful of a feature.
 
  Note:  Split screen mode is only allowed in Ex0 or Ex1.  When in Ex2 and Ex3, it is always disabled.  I do
  not know whether or not the split is affected by Extended Attributes when in Ex1.  Judging by the $5202, I
  would assume it isn't, but that's a total guess.
 
    $5200:  [ER.T TTTT]    Split control
      E = Enable  (0=split mode disabled, 1=split mode enabled)
      R = Right side  (0=split will be on left side, 1=split will be on right)
      T = tile number to split at
 
    $5201:  [YYYY YYYY]    Split Y scroll
 
    $5202:  [CCCC CCCC]    4k CHR Page for split
 
 
  34 BG tiles are fetched per scanline.  MMC5 performs the split by watching which BG tile is being fetched,
  and if it is within the split region, replacing the normal NT data with the split screen data according to
  the absolute screen position of the tile (i.e., ignoring the coarse horizontal and vertical scroll output
  as part of the VRAM address for the fetch).  Since it operates on a per-tile basis... fine horizontal
  scrolling "carries into" the split region.  Setting the horizontal scroll to 1-7 will result in the split
  being moved to the left 1-7 pixels, however when you scroll to 8, the split will "snap" back to its normal
  position.
 
 
  Left Split:
    Tiles 0 to T-1 are the split.
    Tiles T and on are rendered normally.
 
  Right Split:
    Tiles 0 to T-1 are rendered normally.
    Tiles T and on are the split.
 
 
  There is no coarse horizontal scrolling of any kind for the split.  Right-side splits will always show the
  right-hand side of the nametable, and left-hand splits will always show the left-hand side of the nametable.
  Coarse horizontal scrolling can still be used for the non-split region.
 
  ExRAM is always used as the nametable in split screen mode.
 
  Vertical scrolling for the split operates like normal vertical scrolling.  0-239 are valid scroll values,
  whereas 240-255 will display Attribute table data as NT data for the first few scanlines.  The split nametable
  will wrap so that the top of the nametable will appear below as you scroll (just as if vertical mirroring
  were employed).
 
  $5202 selects (yet another) CHR page to use for the BG.  This page is used for the split region only.
 
 
 
 
  IRQ Operation:
  ---------------------------
  MMC5 has a scanline counter for IRQs, however it is significantly more sophisticated than MMC3's, and doesn't
  suffer from the same restrictions.  It is also a bit easier to use.
 
  Write:
    $5203:  [IIII IIII]    IRQ Target
    $5204:  [E... ....]    IRQ Enable (0=disabled, 1=enabled)
 
  Read:
    $5204:  [PI.. ....]
      P = IRQ currently pending
      I = "In Frame" signal
 
    Reading $5204 will clear the pending flag (acknowledging the IRQ).
 
 
 
  Basic operation:
  1)  Write the desired scanline number to $5203
  2)  Enable IRQs by setting $5204.7
 
    IRQ will then trip on the given scanline number (provided PPU rendering is enabled).  The only thing to
  note here is that this behavior changes drastically if you turn the PPU off mid-frame... and that an IRQ will
  never occur when the target scanline number is 0 or greater than (?or equal to?) $F0.
 
    The "In Frame" signal will read back as set when the PPU is rendering (during scanlines 0-239).  Though
  its actual behavior and how it interacts with the IRQ counter is a bit more complex.
 
 
 
  Detailed Operation:
 
    The IRQ counter is an up counter, rather than a down counter (like MMC3).  Every time the MMC5 detects a
  scanline, it does the following:
 
  - If In Frame Signal is clear...
    a) Set In Frame signal
    b) Reset IRQ counter to 0
    c) Clear IRQ pending flag (automatically acknowledging IRQ)
 
  - otherwise...
    a) Increment IRQ counter
    b) If IRQ counter now equals the trigger value, raise IRQ pending flag
 
  Note that the IRQ pending flag is raised *regardless* of whether or not IRQs are enabled.  However, this will
  only trigger an IRQ on the 6502 if both this flag *and* the IRQ enable flag is set.  Therefore IRQs must
  still be enabled for this to have an effect, however the pending flag can still be read back as set via $5204
  even when IRQs are disabled.
 
  Also note that the IRQ counter is compared after it is incremented.  This is why a trigger value of 0 will
  never trigger an IRQ.
 
  At any time when the MMC5 detects that the PPU is inactive, the In Frame signal is automatically cleared.
  The MMC5 will detect this after rendering for the frame is complete, and as soon as the PPU is turned off via
  $2001.  This is why turning off the PPU mid-frame will disrupt IRQs -- since the In Frame signal being
  cleared will reset the IRQ counter next scanline.
 
  HOW the MMC5 detects scanlines is still unknown.  One theory is that it looks for the two dummy nametable
  fetches at the end of the scanline.  Or perhaps it counts the number of fetches the PPU performs.  Nobody
  knows for sure.
 
  The IRQ will trip at the *start* of the desired scanline.  Or, more precisely, near the very end of the
  previous scanline (closest I can figure is dot 336).  That is... if the trigger line is set to 1, the IRQ
  will trip on dot 336 of scanline 0.
 
  I am unsure whether or not the last rendered scanline (239) is detected by the MMC5.  I would assume it is,
  which would mean a trigger value of $F0 would trip an IRQ at the end of rendering.  Trigger values above $F0
  will never be reached, since rendering stops before then, and the in-frame signal would automatically clear.
 
 
 
 
  Sound:
  ---------------------------
  The MMC5 also has 3 additional sound channels!  (Will the list of features ever stop?!?!).  Unfortunately,
  due to the NES being dumbed down, these can only be heard on a Famicom (or a modified NES).
 
  There are 2 additional Pulse channels, and 1 additional PCM channel.
 
  Registers for them are as follows:
 
  Write:
    $5000-5003:  Regs for Pulse 1
    $5004-5007:  Regs for Pulse 2
    $5010:      PCM Unknown (no games use this part of the PCM)
    $5011:      PCM output
    $5015:  [.... ..BA]  Enable flags for Pulse 1 (A), 2 (B)  (0=disable, 1=enable)
 
  Read:
    $5015  [.... ..BA]  Length status for Pulse 1 (A), 2 (B)
 
 
  Pulse channels behave identically to the native NES pulse channels, only they lack a sweep unit.  Rather than
  going into details on their function, I recommend you pick up blargg's apu reference.
 
  $5000-5007 operate just as $4000-4007 do
  $5015 operates just as $4015 does (for reads and writes)
 
 
  Nobody knows exactly how the PCM channel of the MMC5 works.  The patent documentation is unclear, and no
  games seem to use it apart from $5011.  $5010 likely does *something*... but nobody knows what.
 
  $5011 operates exactly like $4011, only it is 8 bits wide instead of 7.  Games *do* use this register to
  output sound.
 
 
  Powerup:
  ---------------------------
  Games seem to expect $5117 to be $FF on powerup (last PRG page swapped in).  Additionally, Romance of the 3
  Kingdoms 2 seems to expect it to be in 8k PRG mode ($5100 = $03).
 
 
 
  Register Overview:
  ---------------------------
  Due to the massive number of registers on this mapper, this section will be brief.  Registers were all
  covered in detail in the sections above -- this is just to recap them all:
 
 
  Writable Regs:
    $5000-5003:  Sound, Pulse 1
    $5004-5007:  Sound, Pulse 2
    $5010-5011:  Sound, PCM
    $5015:      Sound, General
    $5100:      PRG Mode Select
    $5101:      CHR Mode Select
    $5102-5103:  PRG-RAM Write protect
    $5104:      ExRAM Mode
    $5105:      Mirroring Mode
    $5106:      Fill Tile
    $5107:      Fill Attribute
    $5113:      PRG-RAM reg
    $5114-5117:  PRG regs
    $5120-5127:  CHR regs 'A'
    $5128-512B:  CHR regs 'B'
    $5130:      CHR high bits
    $5200:      Split Screen control
    $5201:      Split Screen V Scroll
    $5202:      Split Screen CHR Page
    $5203:      IRQ Trigger
    $5204:      IRQ Control
    $5205-5206:  8*8->16 Multiplier
    $5C00-5FFF:  ExRAM CPU Access
 
 
  Readable Regs:
    $5015:      Sound Status
    $5204:      IRQ Status
    $5205-5206:  8*8->16 Multiplier Product
    $5C00-5FFF:  ExRAM CPU Access


[[Category:Mappers using $4020-$5FFF]]
== External links ==
[[Category:Mappers with large PRG RAM]]
* NES Mapper list by Disch [http://www.romhacking.net/documents/362/]
* Nintendo MMC5 by goroh, translated by Sgt. Bowhack [//nesdev.org/mmc5-e.txt]
* Nintendo MMC5 Bankswitching by Kevin Horton [//nesdev.org/mmc5_bank_switch.txt]

Latest revision as of 14:48, 2 April 2024


MMC5
ExROM
Company Nintendo, Koei, others
Games 15 in NesCartDB
Complexity ASIC
Boards EKROM, ELROM,
ETROM, EWROM
Pinout MMC5 pinout
PRG ROM capacity 1024K
PRG ROM window 8K, 16K, or 32K
PRG RAM capacity 128K
PRG RAM window 8K ($6000-$DFFF),
16K (only $8000-$BFFF
at PRG mode 1/2)
CHR capacity 1024K
CHR window 1K, 2K, 4K, or 8K
Nametable mirroring arbitrary, up to 3 source
nametables (plus fill mode)
Bus conflicts No
IRQ Yes
Audio Yes
iNES mappers 005
NESCartDB
iNES 005
ExROM
EKROM
ELROM
ETROM
EWROM

The Nintendo MMC5 is a mapper ASIC used in Nintendo's ExROM Game Pak boards. All MMC5 boards are assigned to mapper 5.

Example games:

  • Castlevania 3
  • Just Breed
  • Uncharted Waters
  • Romance of the Three Kingdoms II
  • Laser Invasion
  • Metal Slader Glory
  • Uchuu Keibitai SDF
  • Shin 4 Nin Uchi Mahjong - Yakuman Tengoku
  • Bandit Kings of Ancient China

The first game to use this chip (Nobunaga's Ambition II) was released in February 1990. The date codes on components on early released cartridges show that manufacturing had started at the end of 1989.

A later MMC5A revision was introduced with a few extra features, but all released games do not rely on these features and are compatible with the original MMC5.

Overview

The MMC5 is the most powerful mapper ASIC Nintendo made for the NES and Famicom.

It supports many advanced features, including:

  • 4 PRG ROM switching modes
  • 4 CHR ROM switching modes
  • Up to 128KB of WRAM, mappable not only at $6000-$7FFF but also within $8000-$DFFF
    • Supports either one chip (up to 128KB) or two chips (up to 32KB each)
  • An 8 bit by 8 bit multiplier with a 16 bit result for performing quick calculations
  • Scanline detection with counter and configurable IRQ
  • Frame detection with status bit
  • The ability to use different CHR banks for background and 8x16 sprites (allowing 256 unique 8x16 sprite tiles, independent of the background).
  • 1024 bytes of on-chip memory, which can be used for 4 different purposes:
    • An extra general-use nametable
    • Attribute and tile index expansion - address 16384 background tiles at once, and allow each individual 8x8 tile to have its own palette setting
    • Vertical split-screen
    • Extra RAM for storing program variables
  • Three extra sound channels
    • Two pulse channels, identical to those in the NES APU (except lacking pitch sweeps).
    • An 8-bit RAW PCM channel
  • A 'fill mode' nametable, which can be instantly set to contain a specific tile in a specific color (useful for screen transitions)
  • System reset detection
    • Triggered by a positive or negative gap in M2 of at least 11.2 usec.
    • Also triggered and latched by absence of AVcc.
    • After reapplying AVcc, another gap in M2 is sometimes necessary to clear the latch.
    • This feature resets some, but not all, states of the MMC5.
    • The PRG RAM +CE pin is a direct reflection of system reset detection state.

Banks

The MMC5 provides 4 distinct banking modes for both PRG ROM and CHR ROM.

PRG mode 0

  • CPU $6000-$7FFF: 8 KB switchable PRG RAM bank
  • CPU $8000-$FFFF: 32 KB switchable PRG ROM bank

PRG mode 1

  • CPU $6000-$7FFF: 8 KB switchable PRG RAM bank
  • CPU $8000-$BFFF: 16 KB switchable PRG ROM/RAM bank
  • CPU $C000-$FFFF: 16 KB switchable PRG ROM bank

PRG mode 2

  • CPU $6000-$7FFF: 8 KB switchable PRG RAM bank
  • CPU $8000-$BFFF: 16 KB switchable PRG ROM/RAM bank
  • CPU $C000-$DFFF: 8 KB switchable PRG ROM/RAM bank
  • CPU $E000-$FFFF: 8 KB switchable PRG ROM bank

PRG mode 3

  • CPU $6000-$7FFF: 8 KB switchable PRG RAM bank
  • CPU $8000-$9FFF: 8 KB switchable PRG ROM/RAM bank
  • CPU $A000-$BFFF: 8 KB switchable PRG ROM/RAM bank
  • CPU $C000-$DFFF: 8 KB switchable PRG ROM/RAM bank
  • CPU $E000-$FFFF: 8 KB switchable PRG ROM bank

CHR mode 0

  • PPU $0000-$1FFF: 8 KB switchable CHR bank

CHR mode 1

  • PPU $0000-$0FFF: 4 KB switchable CHR bank
  • PPU $1000-$1FFF: 4 KB switchable CHR bank

CHR mode 2

  • PPU $0000-$07FF: 2 KB switchable CHR bank
  • PPU $0800-$0FFF: 2 KB switchable CHR bank
  • PPU $1000-$17FF: 2 KB switchable CHR bank
  • PPU $1800-$1FFF: 2 KB switchable CHR bank

CHR mode 3

  • PPU $0000-$03FF: 1 KB switchable CHR bank
  • PPU $0400-$07FF: 1 KB switchable CHR bank
  • PPU $0800-$0BFF: 1 KB switchable CHR bank
  • PPU $0C00-$0FFF: 1 KB switchable CHR bank
  • PPU $1000-$13FF: 1 KB switchable CHR bank
  • PPU $1400-$17FF: 1 KB switchable CHR bank
  • PPU $1800-$1BFF: 1 KB switchable CHR bank
  • PPU $1C00-$1FFF: 1 KB switchable CHR bank

Registers

Sound ($5000-$5015)

For details on sound operation, see MMC5 audio

NES internal state monitoring

All of these registers overlay various registers that are already used inside the NES, and are fully decoded. A game could write to a mirror of a PPU register to get the MMC5 out of sync, but it's not clear how that could be useful.

8x16 mode enable ($2000 = PPUCTRL)

7  bit  0
---- ----
xxZx xxxx
  |
  +------- Sprite size (0: 8x8 pixels; 1: 8x16 pixels)

Only when Z is set and at least one E bit is set does the MMC5 draw 8x16 sprites from eight independent banks.[1]

PPU Data Substitution Enable ($2001 = PPUMASK)

7  bit  0
---------
xxxE Exxx
   | |
   +-+--- 1,2,3: Substitutions enabled; 0: substitutions disabled

The MMC5 listens to writes to PPUMASK ($2001). When it sees that both E bits are cleared, it disables its ability to make substitutions on the PPU data bus. This includes disabling:

  • Independent bank 8x16 sprite mode
  • Extended attribute mode
  • Vertical split mode

The MMC5 only listens to the fully decoded address $2001, so this can be tested by using the PPU’s mirrors of this register. For example, writing to register $2009 will be heard by the PPU but not the MMC5. It is not clear if that could have a practical use beyond test purposes.

When the MMC5 sees $00 written to $2001, and then the PPU’s rendering gets enabled via a mirror of $2001, the MMC5 still counts scanlines and can generate scanline interrupts even though it thinks $2001 is still disabled. The transition from disabled to enabled resets the scanline counter.

Driving pin 92 low similarly disables substitutions. Because no scanline interrupts occur with pin 92 held low, it seems to hold the scanline counter in reset.

Unknown ($2002 = PPUSTATUS, read only)

Power analysis has detected that both revisions of the MMC5 monitor reads here, purpose unknown.

Unknown ($2005 = PPUSCROLL)

Power analysis has detected that both revisions of the MMC5 monitor writes here, purpose unknown.

Unknown ($2006 = PPUADDR, MMC5A only)

Power analysis has detected that the MMC5A monitors writes here, purpose unknown.

Unknown ($4014 = OAMDMA)

Power analysis has detected that both revisions of the MMC5 monitor writes here, purpose unknown.

Configuration

PRG mode ($5100)

7  bit  0
---- ----
xxxx xxPP
       ||
       ++- Select PRG banking mode
  • 0 - One 32KB bank
  • 1 - Two 16KB banks
  • 2 - One 16KB bank ($8000-$BFFF) and two 8KB banks ($C000-$DFFF and $E000-$FFFF)
  • 3 - Four 8KB banks

Castlevania III uses mode 2, which is similar to VRC6 PRG banking. All other games use mode 3. The Koei games never write to this register, apparently relying on the MMC5 defaulting to mode 3 at power on.

CHR mode ($5101)

7  bit  0
---- ----
xxxx xxCC
       ||
       ++- Select CHR banking mode
  • 0 - 8KB CHR pages
  • 1 - 4KB CHR pages
  • 2 - 2KB CHR pages
  • 3 - 1KB CHR pages

Metal Slader Glory uses 4KB CHR pages. All other games use 1KB pages.

PRG RAM Protect 1 ($5102)

7  bit  0
---- ----
xxxx xxWW
       ||
       ++- RAM protect 1

In order to enable writing to PRG RAM, this must be set to binary '10' (e.g. $02).

PRG RAM Protect 2 ($5103)

7  bit  0
---- ----
xxxx xxWW
       ||
       ++- RAM protect 2

In order to enable writing to PRG RAM, this must be set to binary '01' (e.g. $01).

Internal extended RAM mode ($5104)

7  bit  0
---- ----
xxxx xxXX
       ||
       ++- Specify extended RAM usage
$5104 CPU Access ($5C00-$5FFF)
during blanking		 CPU Access ($5C00-$5FFF)
during rendering		 PPUDATA Access ($2000-$2FFF)(1)
during blanking		 Available as
Nametable		 Enable Extended
Attribute Mode
%00 No(3) Write Only(4) Read/Write Yes No
%01 No(3) Write Only(4) Read/Write Yes2 Yes
%10 Read/Write Read/Write No No No
%11
Read Only
Read Only
 No No No

(1)When configured as a nametable in register $5105, read and write access is possible through the PPU via registers $2006/$2007 when the PPU is not rendering. Based on register $5105, any nametables mapped to extended RAM will support the corresponding PPU address ranges for reads and writes. For example, if NT4 is mapped to extended RAM, reads/writes to PPU $2C00 will correspond with extended RAM $5C00.

(2)Though it is possible to still assign the extended RAM as a nametable in the mode %01, you are going to have the same data used twice, once as extended attribute data, and once as nametable data, this does not seem to be a useful combination. In the other modes, the nametable will read as if it contains all $00s.

(3)Counterintuitively, writes in these modes are only allowed when the PPU is rendering. If writes are attempted during V-blank, they may be ignored or cause a corruption at that memory address. In practice, temporarily switch to mode %10 if you wish to write during V-blank.

(4)Attempting to read extended RAM in those modes returns open bus.

Extended attributes

In mode %01, "Extended Attribute Mode", each byte of the MMC5's internal extended RAM is used to enhance the background tile at the corresponding nametable address. The extended attributes are 1-screen mirrored; in other words, they apply the same for all nametables.

Format of each extended attribute byte: 

7  bit  0
---- ----
AACC CCCC
|||| ||||
||++-++++- Select 4 KB CHR bank to use with specified tile
++-------- Select palette to use with specified tile

In extended attribute mode, CHR banking behaves differently than normal when fetching background tiles from pattern tables:

  • CHR mode (register $5101) is ignored. CHR banks are always 4KB in this mode.
  • The values of the CHR banking registers $5120-$512B are also ignored.
  • Bits 0-5 specified here are used for selecting a 4KB CHR bank on a per-tile basis.
  • The two bits in $5130 are used globally as CHR bank bits 6 and 7.
  • Driving pin 92 low disables extended attribute mode. Extended attribute mode is also automatically disabled based on PPUMASK monitoring. (See section on $2001 monitoring.) In these cases, the non-extended attribute table is used instead.

In other words, this works as if the nametable was extended from 8-bit to 14-bit tile offsets, with the ExRAM holding the upper 6-bits and the 2-bit palette value, while the nametable selected through $5105 contains the lower 8 bits.

Just Breed, Yakuman Tengoku, and the Koei games use extended attributes continuously.

Nametable mapping ($5105)

7  bit  0
---- ----
DDCC BBAA
|||| ||||
|||| ||++- Select nametable at PPU $2000-$23FF
|||| ++--- Select nametable at PPU $2400-$27FF
||++------ Select nametable at PPU $2800-$2BFF
++-------- Select nametable at PPU $2C00-$2FFF

Nametable values:

  • 0 - CIRAM page 0
  • 1 - CIRAM page 1
  • 2 - Internal extended RAM
    • When $5104 is set to mode %10 or %11, the nametable will read as all zeros. This does not share functionality with fill mode.
  • 3 - Fill-mode data
    • See registers $5106 and $5017

Mirroring examples:

Mode Value NTD NTC NTB NTA
Horizontal $50 %01 %01 %00 %00
Vertical $44 %01 %00 %01 %00
Single-screen CIRAM 0 $00 %00 %00 %00 %00
Single-screen CIRAM 1 $55 %01 %01 %01 %01
Single-screen ExRAM $AA %10 %10 %10 %10
Single-Screen Fill-mode $FF %11 %11 %11 %11
Diagonal $14 %00 %01 %01 %00

Fill-mode tile ($5106)

When a nametable is mapped to fill-mode in register $5105, all nametable fetches get replaced by the value of this register. Only the nametable is affected by fill mode. When the PPU later uses this information to fetch the corresponding tile from the pattern table, CHR banking is unaffected and continues to work normally. §

Fill-mode color ($5107)

7  bit  0
---- ----
xxxx xxAA
       ||
       ++- Specify background palette index to use for fill-mode nametable

When a nametable is mapped to fill-mode in register $5105, and $5104 is not in mode %01, all attribute table fetches get replaced by the value of this register. Each byte of the attribute table normally contains four 2-bit palette indexes. The two bits in this register are copied for all four indexes.

When $5104 is in mode %01, extended attribute mode does apply for fill mode, and this register is ignored. However, if pin 92 is driven low in this mode, extended attribute mode becomes disabled and this register comes back into effect.

PRG Bankswitching ($5113-$5117)

In general, when the CPU accesses an address that corresponds to the range of a PRG bank designated by the present PRG mode, the bits of that PRG bank register are applied to the appropriate PRG address buses as follows: 

7  bit  0
---- ----
RAAA AaAA
|||| ||||
|||| |||+- PRG ROM/RAM A13
|||| ||+-- PRG ROM/RAM A14
|||| |+--- PRG ROM/RAM A15, also selecting between PRG RAM /CE 0 and 1
|||| +---- PRG ROM/RAM A16
|||+------ PRG ROM A17
||+------- PRG ROM A18
|+-------- PRG ROM A19
+--------- RAM/ROM toggle (0: RAM; 1: ROM) (registers $5114-$5116 only)

Bank register effective areas versus PRG mode:

CPU memory affected for each mode (see #PRG mode ($5100))
CPU Address Mode 3 Registers Mode 2 Registers Mode 1 Registers Mode 0 Registers
$6000-7FFF $5113 (RAM only) $5113 (RAM only) $5113 (RAM only) $5113 (RAM only)
$8000-9FFF $5114 $5115 $5115 $5117 (ROM only)
$A000-BFFF $5115
$C000-DFFF $5116 $5116 $5117 (ROM only)
$E000-FFFF $5117 (ROM only) $5117 (ROM only)

Register bits $5113.7 and $5117.7 are always ignored. $5113 always maps RAM, and $5117 always maps ROM. Because of this, it is not possible to map the interrupt vectors to RAM in any mode. All known games have their reset vector in the last bank of PRG ROM, and the vector points to an address greater than or equal to $E000. This tells us that $5117 must have a reliable power-on value of $FF.

When a bankswitch register controls an 8kByte CPU address range, register bits 6..0 correspond to PRG A19..A13.

In PRG modes where a register controls a 16kByte CPU address range, register bits 6..1 correspond to PRG A19..A14. Register bit 0 is ignored and instead CPU A13 directly controls PRG A13. For example, comparing mode 3 to mode 2 for CPU address range $8000-BFFF. These are equivalent:

  • In mode 3, write value $90 to $5114 and value $91 to $5115.
  • In mode 2, write value $90 to $5115.

However, these are not equivalent:

  • In mode 3, write value $91 to $5114 and value $92 to $5115.
  • In mode 2, write value $91 to $5115.

The MMC5 ignores register bit 0 in the 16kByte bank.

Similarly, when register $5117 controls a 32kByte CPU address range in mode 0, register bits 6..2 correspond to PRG A19..A15, register bits 1..0 are ignored, and CPU A14..A13 directly control PRG A14..A13

Separate PRG-ROM and PRG-RAM Address Busses

The MMC5 has separate sets of address pins for PRG-ROM and PRG-RAM. This is a concept that has proven difficult to understand and explain. It all stems from the fact that CPU A15 is not directly routed to the cartridge; the signal /ROMSEL is supplied instead. Though it is possible to figure out CPU A15 from /ROMSEL, it is not possible to use it to select the correct PRG address. The PRG address needs to be set sooner than this in order to have an adequate setup time for the RAM or ROM chips. So basically, the starting point is that the MMC5 has to ignore /ROMSEL (and therefore CPU A15) when it comes to the PRG address, for the purpose of timings. This effectively creates a mirror on the PRG address bus for CPU address range $0000-7FFF and $8000-FFFF. Specifically, this makes range $6000-7FFF indistinguishable from $E000-FFFF. Because the MMC5 wanted to have separately controllable mapping for those ranges, its solution was to make two separate PRG address busses.

The MMC5's PRG-ROM address pins follow this logic. Though the PRG-ROM address bus is decoded at all CPU addresses, the gray areas always have PRG ROM /CE disabled:

CPU Address Mode 3 PRG-ROM
Address Source 		Mode 2 PRG-ROM
Address Source 		Mode 1 PRG-ROM
Address Source 		Mode 0 PRG-ROM
Address Source
$0000-1FFF $5114 $5115 $5115 $5117
$2000-3FFF $5115
$4000-5FFF $5116 $5116 $5117
$6000-7FFF $5117 $5117
$8000-9FFF $5114 $5115 $5115 $5117
$A000-BFFF $5115
$C000-DFFF $5116 $5116 $5117
$E000-FFFF $5117 $5117

The MMC5's PRG-RAM address pins follow this logic, again with PRG-RAM /CE always disabled in the gray areas:

CPU Address Mode 3 PRG-RAM
Address Source 		Mode 2 PRG-RAM
Address Source 		Mode 1 PRG-RAM
Address Source 		Mode 0 PRG-RAM
Address Source
$0000-1FFF $5114 $5115 $5115 $5113
$2000-3FFF $5115
$4000-5FFF $5116 $5116 $5113
$6000-7FFF $5113 $5113 $5113 $5113
$8000-9FFF $5114 $5115 $5115 $5113
$A000-BFFF $5115
$C000-DFFF $5116 $5116 $5113
$E000-FFFF $5113 $5113

If we overlap these two tables, the original table reemerges. Pink always has /CE enabled for RAM (using $5113), Blue always has /CE enabled for ROM (using $5117), and Purple chooses which /CE using the register bit 7. Gray always has RAM /CE and ROM /CE disabled at all times.

CPU Address Mode 3 PRG
Address Source 		Mode 2 PRG
Address Source 		Mode 1 PRG
Address Source 		Mode 0 PRG
Address Source
$0000-1FFF $5114 $5115 $5115 $5113/$5117
$2000-3FFF $5115
$4000-5FFF $5116 $5116 $5113/$5117
$6000-7FFF $5113/$5117 $5113/$5117 $5113/$5117 $5113/$5117
$8000-9FFF $5114 $5115 $5115 $5113/$5117
$A000-BFFF $5115
$C000-DFFF $5116 $5116 $5113/$5117
$E000-FFFF $5113/$5117 $5113/$5117


PRG-RAM configurations

In commercial configurations, bits 0 and 1 select pages within an SRAM chip, and bit 2 selects between two separate SRAMs. 8K and 32K games have a single SRAM chip that will only be active when bit 2 is clear. 16K games instead have two chips, but only the first is battery backed.

Configuration bank value & 7
0 1 2 3 4 5 6 7
ELROM 0K open bus open bus open bus open bus open bus open bus open bus open bus
EKROM 8K (1 x 8K) 0:$0000 0:$0000 0:$0000 0:$0000 open bus open bus open bus open bus
ETROM 16K (2 x 8K) 0:$0000 0:$0000 0:$0000 0:$0000 1:$0000 1:$0000 1:$0000 1:$0000
EWROM 32K (1 x 32K) 0:$0000 0:$2000 0:$4000 0:$6000 open bus open bus open bus open bus
Superset 64K (2 x 32K) 0:$0000 0:$2000 0:$4000 0:$6000 1:$0000 1:$2000 1:$4000 1:$6000

Since iNES headers were lacking reliable PRG-RAM size information before NES 2.0, some emulators may have selected these behaviours through ROM CRC checks.

Because no ExROM game is known to write PRG-RAM with one bank value and then attempt to read back the same data with a different bank value, emulating the PRG-RAM as 64K at all times can be used as a compatible superset for all games.

Investigation of the MMC5 pinout in 2018 revealed that bits 2 and 3 also control additional PRG-RAM address pins, which could theoretically have been used to select 32 banks of a single 128K SRAM, with bit 2 controlling PRG A15 directly rather than using the two chip select /CE outputs.

Other PRG-RAM notes

  • Bandit Kings of Ancient China maps PRG-RAM to the CPU $8000+ area and expects to be able to write to it through there. Failure to emulate this causes corruption when the background is restored on the world map.
  • Uncharted Waters requires emulating bankswitching of PRG-RAM: it writes to PRG-RAM at one CPU address and expects to be able to read the same data back via a different CPU address.
  • Games with 16K PRG-RAM only battery-save the first 8K.
  • List of MMC5 games which include a battery.

CHR Bankswitching ($5120-$5130)

When using 8x8 sprites, only registers $5120-$5127 are used. Registers $5128-$512B are completely ignored.

When using 8x16 sprites, the PPU ignores the sprite pattern table address and can select tiles from the entire 8 KiB of pattern tables, which on other mappers overlaps with the background pattern table. The MMC5 keeps track of whether the PPU is fetching background tiles or sprite tiles, and has new registers to specify independent banks for the background tiles even if they appear to be the same address from the PPU. This effectively creates a CHR window of 12 KiB, with up to eight 1 KiB banks of sprites available simultaneously. Registers $5120-$5127 specify banks for sprites, registers $5128-$512B apply to background tiles, and the last set of registers written to (either $5120-$5127 or $5128-$512B) will be used for I/O via PPUDATA ($2007). [1] [2] The MMC5 knows that sprite data is being fetched by counting the number of fetches since the last detected scanline start, similar to how it detects the position for the vertical split.

Bandit Kings of Ancient China and Uchuu Keibitai SDF have non-pattern data stored in CHR ROM, read out via $2007.

The MMC5 is known to listen to the same address as the PPU to find out when to enable the 8x16 sprite mode; see above.

CHR select $5120-$512B

PPU memory affected for each mode (see #CHR mode ($5101))
Register 1 KiB 2 KiB 4 KiB 8 KiB
$5120 $0000-$03FF none none none
$5121 $0400-$07FF $0000-$07FF none none
$5122 $0800-$0BFF none none none
$5123 $0C00-$0FFF $0800-$0FFF $0000-$0FFF none
$5124 $1000-$13FF none none none
$5125 $1400-$17FF $1000-$17FF none none
$5126 $1800-$1BFF none none none
$5127 $1C00-$1FFF $1800-$1FFF $1000-$1FFF $0000-$1FFF
$5128 $0000-$03FF and $1000-$13FF none none none
$5129 $0400-$07FF and $1400-$17FF $0000-$07FF and $1000-$17FF none none
$512A $0800-$0BFF and $1800-$1BFF none none none
$512B $0C00-$0FFF and $1C00-$1FFF $0800-$0FFF and $1800-$1FFF $0000-$0FFF and $1000-$1FFF $0000-$1FFF

Caution: Unlike the MMC1 and unlike PRG banking on the MMC5, the banks are always indexed by the currently selected size. When using 2kb, 4kb or 8kb bank sizes, the registers hold bank index of that larger size, and lower bits are *not* ignored.

Upper CHR Bank bits ($5130)

7  bit  0
---- ----
xxxx xxBB
       ||
       ++- Upper bits for subsequent CHR bank writes

When the MMC5 is using 2KB/1KB CHR banks, only 512KB/256KB of CHR ROM can be selected using the previous registers. To access all 1024KB in those modes, first write the upper bit(s) to register $5130 and then write the lower bits to $5120-$512B.

The only ExROM game with CHR ROM larger than 256KB is Metal Slader Glory, which uses 4KB CHR banks and does not use extended attributes. In other words, no official game relies on this register, and most don't even initialize it.

In extended attribute mode ($5104 = 1), this register likely acts as a global, instantaneous bank selection that gets appended as the most significant 2 bits of all of the tile-specific CHR banks, selecting which 256KB of CHR ROM is to be used for all background tiles on the screen. It is unlikely that the extended RAM stores all 10 bits per write, like registers $5120-$512B.

Other Registers

Vertical Split Mode ($5200)

7  bit  0
---- ----
ESxW WWWW
|| | ||||
|| +-++++- Specify vertical split threshold tile count
|+-------- Specify vertical split region screen side (0:left; 1:right)
+--------- Enable vertical split mode

Uchuu Keibitai SDF uses split screen mode during the intro, where it shows ship stats. Bandit Kings of Ancient China uses split screen mode during the ending sequence[2].

MMC5 internal extended RAM is always used as the nametable in split screen mode. Extended RAM mode ($5104) should be set to %00 or %01. RAM modes %10 or %11 disable split mode. Driving pin 92 low also disables split mode. Split mode is automatically disabled based on PPUMASK monitoring. (See section on $2001 monitoring)

When using mode %01 with vertical split mode, the non-split region gains extended attributes, and the split region does not use extended attributes. As long as the non-split region remains horizontally scrolled to align with the left edge of a nametable, it is possible to share the extended RAM for both purposes. For example, a split region on the right side of the screen will read its nametable data and non-extended attribute data from the “right side” of the extended RAM, and the left side of the screen will read its nametable data from wherever it is assigned in $5105, and get its extended attributes from the “left side” of the extended RAM. The two separate functions of extended RAM data would not overlap this way.

Method of Operation

Based on nametable fetch count (horizontally) and scanline count (vertically), the MMC5 makes substitutions to the nametable data, attribute table data, and the lowest 3 address bits of the pattern data.

Horizontal Behavior

For each visible scanline, the PPU fetches nametable data for 34 background tiles. The MMC5 locates the split threshold by counting these fetches and comparing the count to the count value stored in register $5200. When the PPU is rendering in the split region, the MMC5 replaces the normal nametable data with the split region nametable data. Because the split threshold is located based on nametable fetch count and not based on the actual nametable address requested by the PPU, the location of the split is more of an absolute position on the screen, always positioned the same number of tiles from the left side of the screen. The PPU’s fine horizontal scrolling can cause the first tile rendered to be of fractional width, however the vertical split threshold will always occur at a full tile boundary, so the exact location of the split threshold is affected by fine horizontal scrolling, potentially deviating by up to 7 pixels this way.

Left Split:

  • Tiles 0 to T-1 are the split region.
  • Tiles T and on are rendered normally.

Right Split:

  • Tiles 0 to T-1 are rendered normally.
  • Tiles T and on are the split region.

There is no intended horizontal scrolling of any kind for the split region. Right-side split regions will always remain right-aligned with the right-hand side of the nametable, and left-side split regions will always remain left-aligned with the left-hand side of the nametable. Coarse horizontal scrolling can still be used for the non-split region.

Vertical Behavior

The MMC5 is able to have its own vertical origin in the split region because the nametable data that it substitutes is based on scanline count, which is always aligned to the top of the screen.

The MMC5 keeps track of the scanline count and adds this to the vertical scrolling value in $5201 in order to know what nametable data to substitute in the split region on each scanline. Though the PPU continues requesting nametable data corresponding to its normal vertical scrolling in the split region, the MMC5 is ignoring the nametable address requested in this case and directly substituting its own nametable data.

One additional caveat is fine vertical scrolling of the split region. For each tile on each scanline, the PPU reads from a nametable, and uses that information to fetch the pattern data for 1 row of pixels for that tile. The PPU normally keeps track of which row to fetch using PPU A0..3. However, if the MMC5’s fine vertical scrolling doesn’t match the PPU’s fine vertical scrolling, it won’t be fetching the correct row of pixels from the tile. This is why the MMC5 provides CHR A0..3. By default, Nintendo PCBs are wired in “CL Mode”, which prevents the correct fine vertical scrolling of the split region. (See MMC5 pinout).

Vertical scrolling for the split region operates like normal vertical scrolling. 0-239 are valid scroll values, whereas 240-255 will display attribute table data as nametable data for the first few scanlines. The MMC5 does proper vertical mirroring of the split region nametable so that scrolling down properly rolls over to the top of the nametable, skipping the attribute table data that would naturally be located there.

Vertical Split Scroll ($5201)

 All eight bits specify the vertical scroll value to use in split region

MMC5 boards wired in "CL" mode should only use vertical scroll values whose bottom 3 bits match the PPU's fine vertical scroll value. Using a mismatched value will cause tiles to seem to "roll" within themselves. In "SL" mode, any values can be used. (No existing games used the SL board configuration.)

Horizontal scrolling is not allowed within the split region.

Vertical Split Bank ($5202)

 All eight bits select a 4 KB CHR bank at $0000-$0FFF and $1000-$1FFF while rendering the split region.

IRQ Scanline Compare Value ($5203)

All eight bits specify the target scanline number at which to generate a scanline IRQ. Value $00 is a special case that will not produce IRQ pending conditions, though it is possible to get an IRQ while this is set to $00 (due to the pending flag being set already.) You will need to take additional measures to fully suppress the IRQ. See the detailed discussion.

Scanline IRQ Status ($5204, read/write)

Write
7  bit  0
---- ----
Exxx xxxx
|
+--------- Scanline IRQ Enable flag (1=enabled)
Read
7  bit  0
---- ----
SVxx xxxx  MMC5A default power-on value = $00
||
|+-------- "In Frame" flag
+--------- Scanline IRQ Pending flag

The Scanline IRQ Pending flag becomes set at any time that the internal scanline counter matches the value written to register $5203. If the scanline IRQ is enabled, it will also generate /IRQ to the system.

The "In Frame" flag is set when the PPU is actively rendering visible scanlines and cleared when not rendering; for example, vertical blank scanlines. This flag does not clear for the short H-Blank period between visible scanlines. When pin 92 is driven low, this flag remains low at all times. Additionally, scanline IRQs no longer occur when pin 92 is driven low.

Any time this register is read, the Scanline IRQ Pending flag is automatically cleared (acknowledging the IRQ). Acknowledging the IRQ does not clear the scanline counter, and you may write a larger value to $5203 within a scanline ISR in order to generate another IRQ on an additional scanline within the same frame.

For details, see IRQ counter operation.

Unsigned 8x8 to 16 Multiplier ($5205, $5206 read/write)

The unsigned 16-bit product is available to be read from these registers immediately after writing. All 65536 combinations of multiplicand and multiplier were tested and verified correct on MMC5A here[3].

Write
  • $5205 8-bit Unsigned Multiplicand
  • $5206 8-bit Unsigned Multiplier
  • MMC5A default power-on write value = $FF for both of these registers.
Read
  • $5205 Unsigned 16-bit Product (low byte)
  • $5206 Unsigned 16-bit Product (high byte)
  • MMC5A default power-on read value = $FE01, i.e. $FF * $FF.

Internal extended RAM ($5C00-$5FFF, read/write)

Refer to register $5104 for special behaviors of the MMC5's 1KB internal extended RAM.


MMC5A

The MMC5A was a later revision of MMC5 that included some extra features. Other than Just Breed mysteriously writing to $5800, no game is known that uses these features. Therefore, these will probably tend to have poor support from emulators.

MMC5A Registers

Registers $5207, $5208, $5209, $520A, and range $5800-$5BFF are present only in MMC5A.

CL3 / SL3 Data Direction and Output Data Source (MMC5A: $5207 write only)

7  bit  0
---- ----
ABxx xxCD  MMC5A default power-on write value = 11xx xx00
||     ||
||     |+- MMC5.97 (CL3) Function (0 = I/O Control, 1 = $5800 read control
||     +-- MMC5.98 (SL3) Function (0 = I/O Control, 1 = $5800 write control
|+-------- MMC5.97 (CL3) I/O Data Direction (0 = output, 1 = input)
+--------- MMC5.98 (SL3) I/O Data Direction (0 = output, 1 = input)

When a function bit is set to 1, the pin becomes controlled by the applicable CPU writes or reads in the range $5800-$5BFF. The pin is normally driven high, and when the read or write occurs, it has a low pulse corresponding to !(M2). The intended purpose is unknown. It is theorized that it may attach a peripheral or additional RAM. When in this mode, none of the I/O configuration bits have any effect.

CL3 / SL3 Status (MMC5A: $5208 read/write)

Write
7  bit  0
---- ----
ABxx xxxx  MMC5A default power-on write value = 00xx xxxx
||
|+-------- Value to be output on MMC5.97 pin (CL3) if it is set as an I/O output in $5207.
+--------- Value to be output on MMC5.98 pin (SL3) if it is set as an I/O output in $5207.

Warning: The PCB may connect pins 97 and 98 directly to GND. Though not totally confirmed, setting them as output high while connected like this has appeared to break the output drivers of these pins. Also note that enabling the $5800 function will have these pins driving high most of the time as well.

Read
7  bit  0
---- ----
ABxx xxxx
||
|+-------- Input value of MMC5.97 pin (CL3)
+--------- Input value of MMC5.98 pin (SL3)

16-bit Hardware Timer with IRQ (MMC5A: $5209 read/write, $520A write)

Read
  • $5209
7  bit  0
---- ----
Vxxx xxxx  MMC5A default power-on read value = $00
|
+--------- Hardware Timer IRQ Flag
Write
  • $5209
7  bit  0
---- ----
TTTT TTTT  MMC5A default power-on write value = $00
|||| ||||
++++-++++- Timer count LSB
  • $520A
7  bit  0
---- ----
TTTT TTTT  MMC5A default power-on write value = $00
|||| ||||
++++-++++- Timer count MSB

Based on findings from krzysiobal: The timer automatically starts when writing any value to register $5209, if the 16-bit timer value does not equal $0000. For example, to write value $0100, you would first write $01 (MSB) to register $520A, which does not start the timer. Then write $00 (LSB) to register $5209, which at that point will start the timer from value $0100.

Each 8-bit value is written directly to an internal 16-bit counter that decrements each CPU cycle, specifically on the rising edge of M2. Additional writes while the timer is running will directly overwrite that portion of the counter. Reading register $5209 while the timer is running reports $00. The transition from counter value $0001 to $0000 generates an IRQ and sets the hardware timer IRQ flag. The timer stops at this point. Reading this register reports the IRQ flag, then automatically clears the IRQ and IRQ flag.

If the MMC5 detects a reset, it clears the timer if active, and it clears the IRQ and IRQ flag if set. Reset detection works by looking for a gap larger than about 11 usec on M2.

This register's IRQ operation is completely independent from register $5204. Disabling interrupts through $5204 has no effect on, and reading $5204 does not report on, IRQs generated these registers.

Unknown Address Range (MMC5A: $5800-$5BFF, write only)

Reads and writes in this address range are reflected on the CL3 and SL3 pins when register $5207 = $03. The purpose of this function is unknown. Minute VCC current spikes shortly after rising edge of M2 during writes in this range exhibit the same characteristics as writes in internal extended RAM range $5C00-$5FFF, suggesting possible existence of RAM in this range, though experimentally reading from this range is always met with open CPU bus.

Address $5800 is written to by Just Breed. During each V-Blank, it writes value $03, then $01 to this address, reads and writes to PPU registers, then writes value $00 to this address once complete. It is theorized that this was used as a debug signal to measure CPU usage / idle time during development.

Scanline Detection and Scanline IRQ

MMC5 'in frame' status bit state diagram

The MMC5 detects scanlines by first looking for three consecutive PPU reads from the same nametable address in the range $2xxx. Once this has been seen, the next PPU read, regardless of address, is the point at which the scanline is detected. This works because the PPU does two matching dummy nametable byte reads at the end of each scanline, followed by a third matching nametable byte read at the beginning of the next scanline, followed by an attribute table byte read. So, the scanline gets detected when the PPU does the attribute table byte read, which is at PPU cycle 4.

Once that occurs, if the "in-frame" flag (register $5204) was clear, it becomes set, and the internal 8-bit scanline counter is reset to zero; but if it was already set, the scanline counter is incremented, then compared against the value written to $5203. If they match, the "irq pending" flag is set.

The IRQ pending flag is raised when the desired scanline is reached regardless of whether or not the scanline IRQ is enabled, i.e. even after a 0 was written to the scanline IRQ enable flag. However, an actual IRQ is only sent to the CPU if both the scanline IRQ enable flag and IRQ pending flag are set. A $5203 value of $00 is a special case where the comparison is never true. The MMC5's scanline IRQ occurs at PPU cycle 4, unlike the simpler scanline counter of the MMC3, which usually generates an IRQ around PPU cycle 260. See also [4].

The "in-frame" flag is cleared when the PPU is no longer rendering. This is detected when 3 CPU cycles pass without a PPU read having occurred (PPU /RD has not been low during the last 3 M2 rises). The PPU does this in these conditions:

  • the PPU begins the post-render scanline 240
  • the PPU stops rendering because the user program wrote to CPU address $2001 with bits 3 and 4 clear.
  • note: the MMC5 may not listen directly to writes to $2001 for this behavior, or it may be monitoring for particular transitions of $2001 that have not yet been fully tested.

The "in frame" flag is cleared, scanline IRQ is automatically acknowledged, and the internal scanline counter is reset in any of these conditions:

  • the V-blank NMI occurs, i.e. CPU reads the interrupt vector from addresses $FFFA and $FFFB
  • the user program intentionally reads from CPU addresses $FFFA or $FFFB
  • the 241st scanline is detected.
  • when the MMC5 believes that $2001 bits 3 and 4 are both clear and then either one of them gets set.

The scanline IRQ is acknowledged, but the "in frame" flag is not cleared and the scanline counter is not reset in any of these conditions:

  • the user program reads register $5204
  • scanline 0 is detected

When system reset detection occurs, the only thing that happens is scanline IRQ becomes disabled. All other operation continues unaffected. These things happen any time that scanline IRQ becomes disabled:

  • if /IRQ was low due to scanline IRQ pending flag, /IRQ returns high
  • the scanline IRQ pending flag remains unaffected
  • register $5203 value remains unaffected
  • scanline counter remains unaffected
  • enabling the scanline IRQ will cause immediate /IRQ low if IRQ pending flag is set, but will not affect anything else

This means in pseudo-code: 

(On every PPU read -- PPU /RD falling edge)
if address >= $2000 and address <= $2FFF and address == lastAddress
   matchCount := matchCount +1
   if matchCount == 2
     if inFrame == false
        inFrame := true
        scanline := 0
     else
        scanline := scanline +1
        if scanline == [$5203]
           irqPending := true
else
   matchCount := 0
lastAddress := address
ppuIsReading := true

(On every CPU cycle -- M2 rising edge)
if ppuIsReading
   idleCount := 0
else
   idleCount := idleCount +1      
   if idleCount == 3
      inFrame := false
      lastAddress := undefined
ppuIsReading := false

(On every CPU write)
if address == $2001 and (value & $18) == 0
   inFrame := false
   lastAddress := undefined

(On every CPU read)
if address == $FFFA or address == $FFFB
   inFrame := false
   lastAddress := undefined

Please refer to the state diagrams on the right for a more formal description of the scanline and in-frame detection counters.

Hardware

The MMC5 exists in a 100-pin rectangular QFP package, see MMC5 pinout for details.

MMC5 cartridge PCBs can be configured to different modes, see ExROM for details.

At least two different versions of the MMC5 are known to exist: MMC5, and MMC5A. MMC5A has the addition of registers $5207, $5208, $5209, and $520A: SL3/CL3 control and hardware timer.

References

  1. ↑ krzysiobal's RE notes
  2. ↑ https://forums.nesdev.org/viewtopic.php?f=2&t=12764

External links

  • NES Mapper list by Disch [5]
  • Nintendo MMC5 by goroh, translated by Sgt. Bowhack [6]
  • Nintendo MMC5 Bankswitching by Kevin Horton [7]
Retrieved from "https://www.nesdev.org/w/index.php?title=MMC5&oldid=21737"