MMC5
From NESdev Wiki
Jump to navigationJump to search
The Nintendo MMC5 is a mapper ASIC used in Nintendo's ExROM Game Pak boards. All MMC5 boards are assigned to mapper 5.
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 (RAM support unknown)
- CHR bank size: 1 KB, 2 KB, 4 KB, or 8 KB
- Nametable mirroring: Controlled by mapper
- Subject to bus conflicts: No
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 64KB of WRAM, mappable not only at $6000-$7FFF but also within $8000-$DFFF
- An 8 bit by 8 bit multiplier with a 16 bit result for performing quick calculations
- A scanline based IRQ counter
- The ability to use different CHR banks for background and 8x16 sprites
- 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 quickly getting a blank screen of a particular color/pattern)
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
For details on sound operation, see MMC5_audio
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
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
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 '10'.
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 '01'.
Extended RAM mode ($5104)
7 bit 0
---- ----
xxxx xxXX
||
++- Specify extended RAM usage
- 0 - Use as extra nametable (possibly for split mode)
- 1 - Use as extended attribute data (can also be used as extended nametable)
- 2 - Use as ordinary RAM
- 3 - Use as ordinary RAM, write protected
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 - On-board VRAM page 0
- 1 - On-board VRAM 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,
- 3 - Fill-mode data
Examples:
- $44 (01 00 01 00) - Vertical mirroring
- $50 (01 01 00 00) - Horizontal mirroring
- $14 (00 01 01 00) - Diagonal mirroring
- $00 (00 00 00 00) - 1-screen mirroring, low bank
Fill-mode tile ($5106)
All eight bits specify the tile number to use for fill-mode nametable
Fill-mode color ($5107)
7 bit 0
---- ----
xxxx xxAA
||
++- Specify attribute bits to use for fill-mode nametable
PRG Bankswitching
PRG RAM bank ($5113)
7 bit 0
---- ----
xxxx xCBB
|||
|++- Select 8KB PRG RAM bank at $6000-$7FFF
+--- Select PRG RAM chip
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:
- 0KB: No chips
- 8KB: 1x 8KB chip
- 16KB: 2x 8KB chip
- 32KB: 1x 32KB chip
In the original iNES format, byte 8 of the 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. 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.
PRG bank 0 ($5114)
7 bit 0 ---- ---- RBBB BBBB |||| |||| |+++-++++- Bank number +--------- RAM/ROM toggle (0: RAM; 1: ROM)
- Mode 0 - Ignored
- 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.
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.
PRG bank 1 ($5115)
7 bit 0 ---- ---- RBBB BBBB |||| |||| |+++-++++- Bank number +--------- RAM/ROM toggle (0: RAM; 1: ROM)
- 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 bank 2 ($5116)
7 bit 0 ---- ---- RBBB BBBB |||| |||| |+++-++++- Bank number +--------- RAM/ROM toggle (0: RAM; 1: ROM)
- Mode 0 - Ignored
- 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.
PRG ROM bank 3 ($5117)
7 bit 0 ---- ---- xBBB BBBB ||| |||| +++-++++- PRG ROM bank number
- Mode 0 - Select a 32KB PRG ROM bank at $8000-$FFFF (ignore bottom 2 bits)
- 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
CHR Bankswitching ($5120-$5130)
Registers $5120-$5127 apply to sprite graphics and $5128-$512B for background graphics, but ONLY when 8x16 sprites are enabled.
Otherwise, the last set of registers written to (either $5120-$5127 or $5128-$512B) will be used for all graphics.
CHR selects 0…11
| PPU memory affected for each mode (see #CHR mode ($5101)) | ||||
|---|---|---|---|---|
| Write to CPU address | 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 |
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. 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.
Other Registers
Vertical Split Mode ($5200)
7 bit 0 ---- ---- ESxW WWWW || | |||| || +-++++- Specify vertical split start/stop tile |+-------- Specify vertical split screen side (0:left; 1:right) +--------- 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).
Vertical Split Scroll ($5201)
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 Nes PPU's fine vertical scroll value. In "SL" mode, any values can be used.
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 Counter ($5203)
All eight bits specify the scanline number to generate IRQ at
IRQ Status ($5204, read/write)
Write
7 bit 0 ---- ---- Exxx xxxx | +--------- IRQ Enable flag (1=IRQs enabled)
Read
7 bit 0 ---- ---- SVxx xxxx || |+-------- "In Frame" signal +--------- 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 IRQ Pending flag may be raised even if IRQs are disabled.
Any time this register is read, the IRQ Pending flag is cleared (acknowledging the IRQ).
For details, see IRQ counter operation.
Multiplier ($5205, read/write)
Writes specify the eight-bit multiplicand; reads return the lower eight bits of the product
Multiplier ($5206, read/write)
Writes specify the eight-bit multiplier; reads return the upper eight bits of the product
Expansion RAM ($5C00-$5FFF, read/write)
- 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.
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):
7 bit 0 ---- ---- AACC CCCC |||| |||| ||++-++++- Select 4 KB CHR bank to use with specified tile ++-------- Select palette to use with specified tile
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.
IRQ Counter Operation
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.
The game has no direct access to the internal IRQ counter.
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 [1]. 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.
When the MMC5 detects a scanline, the following events occur:
- if the In Frame signal is clear, set it, reset the IRQ counter to 0, and clear the IRQ Pending flag
- otherwise, increment the IRQ counter. If it now equals the IRQ scanline ($5203), raise IRQ Pending flag
Note the above logic makes it impossible for an IRQ to occur when $5203 is set to $00
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).
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 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.
Hardware
The MMC5 exists in a 100-pin TQFP 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 MMC5B. Their differences are unknown.
Disch's notes
These are no longer Disch's original notes:
========================
= 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: )
'B' Set (BG):
$0000 $0400 $0800 $0C00 $1000 $1400 $1800 $1C00
+-------------------------------+-------------------------------+
C=%00: | $512B |
+-------------------------------+-------------------------------+
C=%01: | $512B | $512B |
+-------------------------------+-------------------------------+
C=%10: | $5129 | $512B | $5129 | $512B |
+---------------+---------------+---------------+---------------+
C=%11: | $5128 | $5129 | $512A | $512B | $5128 | $5129 | $512A | $512B |
+-------+-------+-------+-------+-------+-------+-------+-------+
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
