For the last month or so I've been spending my free time on the weekends writing a NES emulator. So far I have just been figuring things out as I go, making one thing work at a time. The current incarnation of my emulator can handle a few mappers (NROM, MMC1, UNROM) and appears to do a good job of running the games that I've tested.
I've decided to use what I have learned in this process to refactor my emulator, but I am not sure that I entirely understand how memory is physically and logically distributed between the CPU, PPU, and MMC.
Here is my current understanding of the situation:
---------------------------------------------------------
"CPU"
0x0000 - 0x1FFF - RAM (0x0800 mirrored four times)
0x2000 - 0x3FFF - CPU <-> PPU communication registers (0x2000 - 0x2008 mirrored many times)
0x4000 - 0x4017 - APU and I/O registers
0x4018 - 0x5FFF - Expansion RAM ***MMC
0x6000 - 0x7FFF - Cartridge SRAM ***MMC
0x8000 - 0xFFFF - Cartridge PrgROM ***MMC
The cpu does not actually have its own physical memory for anything in expansion ROM and onward, this is all routed through the MMC. Any of this that is not present on the cartridge (expansion ROM, SRAM) is ignored when written to, and returns open bus when read.
"PPU"
0x0000 - 0x1FFF - Cartridge VROM/VRAM ***MMC
0x2000 - 0x2FFF - Nametables ( two actual ) + mirrors
0x3000 - 0x3EFF - Mirror of 0x2000 - 0x2EFF ?
0x3F00 - 0x3F1F - Palettes (mirrored through 0x3FFF?)
0x4000 - 0xFFFF - Mirrors of entire PPU address space
The ppu does not have its own physical memory for VROM/VRAM, and reads/writes will be routed through the MMC. There *should* be no situation were a cart does not have either VRAM or VROM for this. (Ignore/open bus if it didnt?)
---------------------------------------------------------
Is my above description basically correct?
Is it possible for an MMC to take over reads/writes to other locations in CPU or PPU memory? Are there any mappers that actually do this?
( Just writing this out clarified a lot for me, assuming it is all correct. Maybe my biggest problem is bad notetaking. )
I've decided to use what I have learned in this process to refactor my emulator, but I am not sure that I entirely understand how memory is physically and logically distributed between the CPU, PPU, and MMC.
Here is my current understanding of the situation:
---------------------------------------------------------
"CPU"
0x0000 - 0x1FFF - RAM (0x0800 mirrored four times)
0x2000 - 0x3FFF - CPU <-> PPU communication registers (0x2000 - 0x2008 mirrored many times)
0x4000 - 0x4017 - APU and I/O registers
0x4018 - 0x5FFF - Expansion RAM ***MMC
0x6000 - 0x7FFF - Cartridge SRAM ***MMC
0x8000 - 0xFFFF - Cartridge PrgROM ***MMC
The cpu does not actually have its own physical memory for anything in expansion ROM and onward, this is all routed through the MMC. Any of this that is not present on the cartridge (expansion ROM, SRAM) is ignored when written to, and returns open bus when read.
"PPU"
0x0000 - 0x1FFF - Cartridge VROM/VRAM ***MMC
0x2000 - 0x2FFF - Nametables ( two actual ) + mirrors
0x3000 - 0x3EFF - Mirror of 0x2000 - 0x2EFF ?
0x3F00 - 0x3F1F - Palettes (mirrored through 0x3FFF?)
0x4000 - 0xFFFF - Mirrors of entire PPU address space
The ppu does not have its own physical memory for VROM/VRAM, and reads/writes will be routed through the MMC. There *should* be no situation were a cart does not have either VRAM or VROM for this. (Ignore/open bus if it didnt?)
---------------------------------------------------------
Is my above description basically correct?
Is it possible for an MMC to take over reads/writes to other locations in CPU or PPU memory? Are there any mappers that actually do this?
( Just writing this out clarified a lot for me, assuming it is all correct. Maybe my biggest problem is bad notetaking. )