I've been having trouble implimenting this. what happens is the game works fine until the boxing ring comes up, then the very first frame looks perfect, then the background goes to shit. I was wondering if anyone else has had a problem like this.
just a couple of questions,
1) does the latch change on reads from sprite data, it seems logical. I've tried both ways and still no dice.
2) is there any other from of mirroring that this uses(other then vert horiz).

Most likely it's a problem with your latch. Did you try here:
http://oldnes.sourceforge.net/doc/mmc2.txt
It seems they have a problem with not knowing if reading from sprites does anything or not either.
I pretty sure no other mirroring is used.

I haven't had any problems with MMC2, I run it just like MMC4, but with 8k PRG switch instead. That is, I have:
$Axxx - 8k PRG select at $8000
$Fxxx - Mirroring (0 = V, 1 = H)

$Bxxx - 4k CHR at $0000 when $0000-latch = $FD
$Cxxx - 4k CHR at $0000 when $0000-latch = $FE
$Dxxx - 4k CHR at $1000 when $1000-latch = $FD
$Exxx - 4k CHR at $1000 when $1000-latch = $FE
There are two 'latches', one for $0000-$0FFF and one for $1000-$1FFF.
Firebug's doc says something else.

I hope I got this right now... Anyway, I don't know if it helps, your problem sounds more severe. :-)

/Hugin

Hi, I'm also having some problems with this mapper. When you implemented it, did you include the automatic VROM bank switching on reads from ($0FD0-$0FDF or $1FD0-$1FDF) or ($0FE0-$0FEF or $1FE0-$1FEF), as indicated in the MMC2.txt file by Jim Geffre? My mapper code seems to follow what you have outlined, but when I emulate the game roughly half the screen always looks like garbage. I would appreciate any help you might be able to give me.

I fixed the problem. basically there are some accesses to ppu memory that are made on the real nes, that are not required for drawing the screen. note in the ppu tec guide. the ppu fetches the first 3 tiles to draw on a given scanline durring the previous scanline, then on the current scanline it fetches 32 tiles from memory. so you can think of this as fetching 2 to 3 more tiles then it needs to. if the x scroll is zero, it takes 32 tiles to draw a scanline, if x scroll is nonzero it takes 33 tiles. so to fix the problem, I added a few extra bs memory accesses at the end of each scanline. if x offset is zero I fetch 3 extra tiles, if it is zero, I fetch 2 extra tiles.
as an example

1)
if x offs is zero
fetch 32 tiles from nt1(this is all that's necessary to draw the screen)
fetch the remaining 3 tiles from nt 2(these are not necessary to draw the screen)

2) if x offset is nonzero,
fetch x tiles from nt1, fetch y tiles from nt2
so x+y = 33, these tiles are necessary to draw the screen. make 2 more fetches from nt2 for a total of 35.


this could be wrong though, but it gets puntchout working well, also I check the latches durring sprite memory accesses aswell, but it doesn't seem to be required for punchout.

hugin, thanks that's how I implimented it in the first place, but the problem came from two few accesses to ppu mem, at least it seems

big pastey, I had just the same problem you described as half the screen is messed up

Were you able to fix the problem? I'm pretty sure my latches are screwed up. I've been messing around with them, trying every permutation of saving any writes to $C000-$EFFF in 4 different registers and then automatically loading them on PPU reads from the "latch" areas, but the best I've been able to do is get the bottom half of the screen + the sprites to look right.

there should be a bankswap after the first scanline, then another midway in screen. you're emu probably is only swaping midscreen. mine was doing the same thing. the top ie the ring was all garbage, but the bottom, ie mac, and the enmimy and the ring mat(all blue) looked fine. are you implimenting the exrta ppu mem reads I posted about yesterday?

also note there are two latches one for data [0000-1000) and another for [1000-2000) someone posted about this earlier, as far as I can see, this is correct

How do you know what bank to swap at scanline 1 and at midframe? I'm guessing that you swap in the bank last specified through a write to $B000-$CFFF at scanline 0 and swap in the bank last specified through a write to $D000-$EFFF at mid frame?

it depends on the latches, I don't remember exactly what latch selector is in use. if you really want, I'll test the game and tell you exactly what banks get swaped and when.

void _fastcall mapper9Write(BYTE bVal, WORD wAddress) {

switch(wAddress>>12) {
case 0xA:
swapPrg8(0x8000, bVal);
break;
case 0xB:
if(mmc2Regs.iLatchSelector1 == 0xFD)
if(mmc2Regs.iLatch1 != bVal)
swapChar4(0, bVal);

mmc2Regs.iLatch1 = bVal;
break;
case 0xC:
if(mmc2Regs.iLatchSelector1 == 0xFE)
if(mmc2Regs.iLatch2 != bVal)
swapChar4(0, bVal);

mmc2Regs.iLatch2 = bVal;
break;
case 0xD:

if(mmc2Regs.iLatchSelector2 == 0xFD)
if(mmc2Regs.iLatch3 != bVal)
swapChar4(0x1000, bVal);

mmc2Regs.iLatch3 = bVal;
break;
case 0xE:

if(mmc2Regs.iLatchSelector2 == 0xFE)
if(mmc2Regs.iLatch4 != bVal)
swapChar4(0x1000, bVal);

mmc2Regs.iLatch4 = bVal;
break;
case 0xF:
setMirroring((bVal&1) ? HORIZONTAL : VERTICAL);
break;
default: MessageBox(0, "def", 0, 0);
}
}

//this is called on ppu mem reads at addresses below 0x2000
void latchCheck(int ippuAddress) {

if(ippuAddress>=0x1000) {

if((ippuAddress&0xFF0) == 0xFE0) {
if(mmc2Regs.iLatchSelector2 != 0xFE)
swapChar4(0x1000, mmc2Regs.iLatch4);

mmc2Regs.iLatchSelector2 = 0xFE;
}
else if((ippuAddress&0xFF0) == 0xFD0) {
if(mmc2Regs.iLatchSelector2 != 0xFD)
swapChar4(0x1000, mmc2Regs.iLatch3);

mmc2Regs.iLatchSelector2 = 0xFD;

}
}
else {

if((ippuAddress&0xFF0) == 0xFE0) {
if(mmc2Regs.iLatchSelector1 != 0xFE)
swapChar4(0, mmc2Regs.iLatch2);

mmc2Regs.iLatchSelector1 = 0xFE;
}
else if((ippuAddress&0xFF0) == 0xFD0) {
if(mmc2Regs.iLatchSelector1 != 0xFD)
swapChar4(0, mmc2Regs.iLatch1);

mmc2Regs.iLatchSelector1 = 0xFD;
}
}
}

Thanks a lot for your help. It turns out that my problem was that I was not emulating the 2 or 3 extra PPU fetches per scanline, as you deatiled earlier in the thread.

I thought so, you're problem sounded to much like mine. =) I'm glad it works for you, I remember how frustrating that was. I thought the whole emu was jacked