INES Mapper 004: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
(Link to PPU Rendering instead of directly to the frame timing diagram)
(Redirect: everything here is now covered by MMC3)
 
(11 intermediate revisions by 4 users not shown)
Line 1: Line 1:
[[iNES Mapper 004]] is a wide abstraction that can represent boards using the Nintendo [[MMC3]], Nintendo [[MMC6]], or functional clones of any of the above. Most games utilizing [[TxROM]], [[DxROM]], and [[HKROM]] boards use this designation.
#REDIRECT [[MMC3]]
 
{{DEFAULTSORT:004}}[[Category:iNES Mappers]][[Category:MMC3-like mappers]][[Category:in NesCartDB]][[Category:Nintendo licensed mappers]][[Category:NES 2.0 mappers with submappers]][[Category:Mappers with scanline IRQs]]
A few specific TxROM boards handle the PPU bus differently and thus have separate mapper numbers:
*[[iNES Mapper 118]] covers TKSROM and TLSROM, which use CHR bank bits to control nametable [[mirroring]]
*[[iNES Mapper 119]] covers TQROM, which has both CHR RAM and CHR ROM
 
Some [[:Category:MMC3-like mappers|MMC3-like mappers]] have different behaviors and thus their own mapper numbers.
 
HKROM does not have its own mapper number.
It can be identified in [[NES 2.0]] images by having 1024 bytes of battery-backed PRG RAM or in traditional iNES images by comparing the hash of the PRG ROM to the PRG hashes of the [http://bootgod.dyndns.org:7777/search.php?keywords=HKROM&kwtype=pcb two distinct licensed games that use this board]].
 
As with any iNES mapper, there is no exact "strict" interpretation of a hardware reality to be had. This is significant for example with the case of roms that exceed normal 512KB PRG limits, such as this significant rom hack: http://www.romhacking.net/translations/1590/ ; where you may have to consider mapper 4 as defining a fake MMC3 chip that contains full 8 bit registers capable of fully addressing the expanded PRG.
 
Consulting [[PPU rendering]], which includes a frame timing diagram and details on PPU address bus contents, might help in understanding the IRQ scanline counting logic.
 
  Here are Disch's original notes:
  ========================
  =  Mapper 004          =
  ========================
 
  aka
  --------------------------
  MMC3
  TxROM
  (MMC6)
  (HxROM)
 
 
  Example Games:
  --------------------------
  Mega Man 3, 4, 5, 6
  Kirby's Adventure
  Gauntlet
  Rad Racer 2
  Startropics 1, 2 (MMC6)
  Super Mario Bros. 2, 3
  ... a zillion other games (most common mapper)
 
 
  4-Screen Notes:
  ---------------------------
  TR1ROM and TVROM are two of the *very few* boards to use 4-screen mirroring.  The only mapper 004 games which
  use 4-screen mirroring I know of are Rad Racer 2 and Gauntlet.  Several other games are incorrectly labelled
  as being 4-screen when they are in fact, not (ex: Gauntlet 2).
 
  TR1ROM and TVROM are both configured in a way which uses on-cart WRAM as VRAM for the nametables.  However
  this means the WRAM is not tied to the CPU, therefore they do not have any SRAM/WRAM!
 
  So to be "safe":
  - when homebrewing:  choose either 4-screen or WRAM.  You can't have both
  - when emudeving:  permanently disable WRAM when 4-screen.  This does not break any games.
 
  4-screen mirroring for these boards is hardwired!  When in 4-screen mode, your emu must ignore writes to the
  mirroring reg.
 
  Also note that many Rad Racer 2 dumps are floating around which do not indicate it is 4-screen.  So if you
  try that game in your emu and the graphics are screwed, that's the first thing to check.
 
 
  IRQ Notes:
  ---------------------------
  IRQ Operation on this mapper is simple at first glance, however its precise operation gets very complex.
  This mapper is infamously one of the hardest (if not the very hardest) mapper to emulate accurately -- a
  double-whammy since it's also hands down the most common mapper around.
 
  Be sure to read 'Basic IRQ operation' below, and I recommend you seriously consider skimming 'Detailed IRQ
  operation' as well -- especially if you're emudeving.
 
 
 
  Other notes:
  ---------------------------
  Low G Man will actually confirm that WRAM disabling works properly, and will break if it isn't.  So if your
  emu ignores WRAM disabling and always has it enabled, Low G Man will break (specifically, during the
  level 1 boss fight)
 
 
 
  Registers:
  ---------------------------
 
  Range,Mask:  $8000-FFFF, $E001
 
 
    $8000:  [CP.. .AAA]
      C = CHR mode select (see CHR setup)
      P = PRG mode select (see PRG setup)
      A = Address for use with $8001
 
 
    $8001:  [DDDD DDDD] --  data port
        R:0 ->  CHR reg 0
        R:1 ->  CHR reg 1
        R:2 ->  CHR reg 2
        R:3 ->  CHR reg 3
        R:4 ->  CHR reg 4
        R:5 ->  CHR reg 5
        R:6 ->  PRG reg 0
        R:7 ->  PRG reg 1
 
 
    $A000:  [.... ...M]
      Mirroring:  0=Vert
                  1=Horz
 
      Ignore when 4-screen
 
 
    $A001:  [EW.. ....]
      E = Enable WRAM (0=disabled, 1=enabled)
      W = WRAM write protect (0=writable, 1=not writable)
 
 
    $C000: [IIII IIII]   IRQ Reload value
    $C001:  [.... ....]   IRQ Clear
    $E000:  [.... ....]    IRQ Acknowledge / Disable
    $E001:  [.... ....]    IRQ Enable
 
 
  CHR Setup:
  ---------------------------
 
                $0000  $0400  $0800  $0C00  $1000  $1400  $1800  $1C00
              +---------------+---------------+-------+-------+-------+-------+
  CHR Mode 0:  |    <R:0>    |    <R:1>    |  R:2  |  R:3  |  R:4  |  R:5  |
              +---------------+---------------+---------------+---------------+
  CHR Mode 1:  |  R:2  |  R:3  |  R:4  |  R:5  |    <R:0>    |    <R:1>    |
              +-------+-------+-------+-------+---------------+---------------+
 
  PRG Setup:
  ---------------------------
 
                $8000  $A000  $C000  $E000 
              +-------+-------+-------+-------+
  PRG Mode 0:  |  R:6  |  R:7  | { -2} | { -1} |
              +-------+-------+-------+-------+
  PRG Mode 1:  | { -2} |  R:7  |  R:6  | { -1} |
              +-------+-------+-------+-------+
 
 
  Basic IRQ Operation
  ---------------------------
 
  MMC3 IRQs utilize a scanline counter.  The basic steps to making it work are as follows:
 
  1)  Set the desired number of scanlines you want to wait by writing N to $C000
  2)  Reset the internal IRQ counter by writing any value to $C001
  3)  Enable IRQs by writing any value to $E001
 
  An IRQ will then fire after N+1 rendered scanlines, at which point, you would write any value to $E000 to
  acknowledge the IRQ, and disable further IRQs (and possibly repeat the above 3 steps if you want to fire
  another IRQ this frame).
 
  The MMC3 counts scanlines by watching the CHR accesses the NES makes.  Therefore in order for this IRQ
  counter to work properly, the NES must be making the accesses that the MMC3 is expecting.  If you have
  abnormal settings, you will confuse the MMC3 and IRQs will not work properly.  Therefore, you must follow
  these rules:
 
  1)  The IRQ counter will only count when the PPU is on (sprites and/or BG enabled).
  2)  Do not manipulate $2006 or $2007 while using IRQ counter
  3)  Do not set $C000 to $00
  4)  BG and Sprites must use opposing pattern tables for CHR.  EG:
    a)  if 8x16 sprites, BG must use $0xxx, *ALL* sprites must use $1xxx
    b)  if 8x8 sprites, if BG is using $0xxx, sprites must use $1xxx
    c)  if 8x8 sprites, if BG is using $1xxx, sprites must use $0xxx  (slightly abnormal)
 
  With settings 'a' and 'b', the IRQ will occur after dot 260. With setting 'c', it will occur after dot 324
  of the *previous* scanline.
 
 
  The IRQ Counter consists of several parts:
  1)  Actual 8-bit IRQ counter (not directly accessable)
  2)  8-bit latch, or reload value (reg $C000)
  3)  IRQ Enable flag
  4)  IRQ Pending flag
 
  IRQ Registers interact with the above parts as follows:
    reg $C000 - sets IRQ Reload value
    reg $C001 - sets the actual IRQ counter to 0 (regardless of what value is written)
    reg $E000 - clears both IRQ Enable flag and IRQ Pending flag
    reg $E001 - sets IRQ Enable flag
 
  Every time the MMC3 detects a scanline, the following IRQ Counter logic is executed.  Note this occurs EVEN
  IF IRQs are disabled (the IRQ counter is always counting):
 
  - If IRQ Counter is 0...
      a)  reload IRQ counter with IRQ Reload value
 
  - Otherwise...
      a)  Decrement IRQ counter by 1
      b)  If IRQ counter is now 0 and IRQs are enabled, trigger IRQ
 
  Note that 241 scanlines are counted per frame (the 240 rendered scanlines, and the "prerender" scanline).
 
 
 
 
 
  Detailed IRQ Operation
  ---------------------------
 
  MMC3 detects scanlines by watching A12 ($1000) on the PPU bus.  Every time a rising edge occurs (transitions
  from 0->1), and it hasn't been too close to the previous rising edge, the IRQ counter gets clocked.
 
  Under *normal* conditions (BG using $0xxx, sprites using $1xxx), A12 will rise exactly 8 times every scanline
  (once for each sprite CHR fetch).  However the 8 rises are so close together that only the first is 'seen'.
 
  During rendering and pre-render scanlines the PPU is fetching NT and CHR data from the cart through a series
  of reads.  Each read updates the PPU Address lines (including A12), and each read takes 2 PPU cycles (2
  dots).  There are 4 reads per tile, and 42 tiles per scanline:
 
  - 32 BG tiles
  - 8 Sprite tiles (for the next scanline)
  - 2 BG tiles (for the next scanline)
 
 
  Each tile requires 4 reads, each read is 2 dots:
  dot 0:  Name table fetch ($2xxx -- A12 is low)
  dot 2:  Attribute fetch  ($2xxx -- A12 is low)
  dot 4:  Low CHR fetch    ($0xxx or $1xxx -- A12 is low or high)
  dot 6:  High CHR fetch  ($0xxx or $1xxx -- A12 is low or high)
 
  If the tile being fetched is using the right-hand pattern table ($1xxx), then A12 goes high on dot 4 of that
  8-dot sequence.  Otherwise, A12 stays low throughout.
 
  This 8-dot sequence is repeated for each tile.. meaning there are 42 opportunities for A12 to rise.  These
  opportunities occur on the following dots:
 
  4, 12, 20, ..., 244, 252                (32 BG tiles)
  260, 268, 276, 284, 292, 300, 308, 316  (8 Spr tiles)
  324, 332                                (2 BG tiles)
 
  (You might be able to see now how I came up with those 260, 324 numbers I threw at you earlier)
 
  MMC3 seems to ignore rises that are too close together.  This is why the 8 sprite fetches will only clock
  the counter once.  Exactly how far apart the rising edges have to be is unknown, but it is somewhere between
  14 and 16 dots.  So any two consecutive opportunities are too close together (including the most distant
  332->4), but any two non-consecutive opportunities will both be acknowledged.
 
  Figuring whether the tile is being fetched from $0xxx or $1xxx is usually easy.  BG and 8x8 sprites are
  always fetched from an assigned pattern table (configurable by PPU reg $2000).  However, 8x16 sprites can
  come from either pattern table.  So which tile is begin fetched depends on which sprite is being fetched....
  which depends on what scanline you're on, and what sprites are found to be in-range on that scanline.  For
  scanlines which contain less than 8 sprites, tile $FF is fetched as a dummy (in 8x16 sprites, this would be
  from the $1xxx pattern table).
 
  This is why, when you have 8x16 sprites, ALL sprites must use the right-hand pattern table.  If you have
  sprites using the left and the right, you'll probably end up having some scanlines where the IRQ counter
  counts the same scanline multiple times!  All depending on which sprites are in-range and when.  For example,
  if there are 4 sprites on the scanline using $0xxx, and 4 using $1xxx, the IRQ counter might count the
  scanline anywhere from 1 to 4 times!
 
  0,0,0,0,1,1,1,1  <---  all 4 rises consecutive, will only clock once
  0,1,0,1,0,1,0,1  <---- all 4 rises nonconsecutive, counter clocked each time!
 
  This is also why the IRQ counter isn't clocked when both BG and sprites use the left pattern table (since
  there is never any rising edge, the MMC3 never detects any scanlines).
 
 
 
  $2006 and $2007
  ---------------------------
  A game can manually clock the IRQ counter (either on accident, or by design) by manipulating $2006 and $2007.
  A12 is updated (potentially triggering a rising edge) when the PPU address is updated by these registers.
  On $2007 reads/writes, and on the second $2006 write.  This is why messing with $2006 and $2007 after you
  prep your IRQ stuff may screw up your IRQs unless you're careful.
 
 
 
 
  IRQ Counter priming
  ---------------------------
  Some games seem to prime the IRQ counter by repeatedly writing $0000 and $1010 to $2006.  This toggles A12,
  clocking the IRQ counter.  It is unknown whether or not this is actually required.
 
 
 
  Reload value of $00
  ---------------------------
  Different MMC3 versions behave differently when you set $C000 to $00.  There are at least two (possibly more)
  behaviors.  These behaviors are mentioned in the readme accompanied with blargg's MMC3 test ROMs, which, if
  you're emudeving, I highly recommend you pick up.  Otherwise, the behavior of having a reload value of $00
  is unreliable and/or undesirable, and should be avoided at all costs when homebrewing/hacking.
 
 
 
 
  Special Variant -- MMC6:
  --------------------------
 
  Startropics 1 and 2 are both MMC6 games (not MMC3).  However, they are unfortunately assigned the same mapper
  number, despite being slightly incompatible.  There is no simple way to determine MMC3 from MMC6.  You'll
  probably have to use a CRC or hash check or something.
 
  For the most part they are the same -- but the big difference is the WRAM.  MMC6 has only 1k of WRAM,
  whereas MMC3 games have 8k.  It is also mapped a bit differently, and is enabled/disabled differently from
  MMC3.
 
  MMC6 registers are as follows.  All other registers behave just as they do on MMC3:
 
 
    $8000:  [CPW. .AAA]
      C,P,A = Same as on MMC3
      W = WRAM Enable (0=disabled, 1=enabled)
 
    $A001:  [HhLl ....]
      H,L = Enable WRAM block (0=disabled, 1=enabled)
      h,l = WRAM block write protect (0=writes disabled, 1=writes enabled)
 
 
  The 1k of WRAM is split into 2 512 byte blocks... one at $7000-71FF and another at $7200-73FF.  Each block
  can be controlled independently through $A001.  H,h bits deal with the high block ($7200), and L,l bits deal
  with the low block ($7000).
 
  If only one block is enabled, the disabled block will read back as $00.  However if BOTH blocks are disabled,
  reading either will return open bus.
 
  $7000-73FF is mirrored throughout $7400-7FFF.  However, $6000-6FFF is always open bus (unmapped).
 
  $8000.5, when clear (to disable WRAM), simply sets $A001 to $00 and keeps it there.  Writing to $A001 when
  $8000.5 is clear will have no effect.
 
== See also ==
*[[iNES Mapper 064]]: Tengen RAMBO-1, successor to MIMIC-1
*[[iNES Mapper 076]]: Strange MMC3 variant
*[[iNES Mapper 206]] covers Tengen MIMIC-1 or Namco 109 chip, the MMC3's predecessor with no mirroring control or IRQ
 
[[Category:iNES Mappers|004]][[Category:MMC3-like mappers|004]][[Category:in NesCartDB|004]]

Latest revision as of 18:53, 30 May 2015

Redirect to: