Precision about MMC5

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
johnmph
Posts: 13
Joined: Fri Feb 28, 2020 8:17 am

Precision about MMC5

Post by johnmph » Thu Apr 23, 2020 10:01 am

Hello all, I am trying to implement MMC5 mapper but I have questions about some details not covered in https://wiki.nesdev.com/w/index.php/MMC5 :

  1. $5102 and $5103 are two PRG RAM Protect, why two ? Is it in case of two PRG-RAM chips with PRG RAM Protect 1 for chip 1 and Protect 2 for chip 2 ?
    Or is it Protect 1 and 2 for the whole PRG-RAM ? In this case, does we need the two protects to be enabled to write to PRG RAM or one protect enabled is sufficient ?
  2. $5105 is for nametable mapping, in the case of address > $2FFF, does it mirror to $2XXX like no mapper behaviour ?
  3. MMC5 counts the PPU fetch to know what is currently fetched like sprite or background tile in case of 8x16 sprite mode or for vertical split.
    But how does he count the fetch ? Simply by counting the PPU access to memory ? In this case, if the CPU performs a $2007 read (during rendering), will the counter be out of sync for counting PPU fetch ?
  4. For scanline detection, it is says in the wiki that when a scanline is detected :
    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.
    And later :
    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
    But when scanline 0 is detected, the in-frame flag is clear and it is says above that the scanline counter is reset to 0 but here it is says that the scanline counter is not reset !?
Thanks

Post Reply