Somewhere along the way, I broke Punch-Out!

Well crap.. This regression happened at some point and I'm not sure what caused it, but I just noticed it. Glass Joe looks kind of scary now. Any clue what could have done this? This may help... Interestingly, if I do not fetch the 34th BG tile then the fighters look perfect but of course breaks the ring tileset. So I can get one or the other looking right by changing whether or not I fetch it.

I thought magic tile fetches for pattern table 1 weren't supposed to affect the bank for pattern table 0 or vice versa.

Yeah, it shouldn't be. This is my swap code. "patbank" is in 1K blocks, so the "> 3" of course means if its the upper 4 KB in the banks.



The second parameter to CHRswap is the block to be swapped, based on size given in last parameter. So, this looks right to me.

Do you update the mappings when $Bxxx/Cxxx/Dxxx/Exxx are written to? Remember that the magic tiles only select which registers select the low/high CHR page. Writing those registers will also update the mapping.

I was only doing it on reads, I guess I misunderstood the docs on it! That fixed the fighter tile glitches. Thanks!

One more little glitch remains. Some small patches of sprite(?) glitches remain like on the title screen and Doc's face between some rounds:

Here's my setup, which works for Punch-Out!! at least (not sure if it's accurate in all situations when different kinds of magic tiles appear next to each other):

I have two booleans low_bank_uses_0FDx_reg and high_bank_uses_1FDx_reg. I keep track of the previous value on the PPU's address bus each tick, and whenever the address transitions from a magic address to a non-magic address, I update those booleans according to what the last magic value on the address bus was. I then call a routine make_effective() (other emulators seem to call this routine sync()) that sets up the CHR mappings by looking at the booleans and the register values. make_effective() is also called whenever the regs are updated.

The above mirrors that magic tiles only take effect after the magic tile itself has been fetched.

The mapper itself probably uses two multiplexers. The first one selects between the 0FDx and 0FEx regs based on a low_bank_uses_0FDx_reg flip-flop, and the second one between the 1FDx and 1FEx regs based on a high_bank_uses_1FDx_reg flip-flop. Magic tiles only update those flip-flops.

Thanks! I'll see what I can do here... this mapper is so quirky.

Are you applying the FD/FE magic when sprites use those tiles too?

Yep, I'm doing it anywhere a tile can be accessed.