A mapper related bus conflict typically happens when a game attempts to write to a register that is mapped to the same address as ROM.  From what I understand, unless the mapper disables ROM output for the write (which more modern MMCs did -- but older, simpler mappers did not), the byte from ROM as well as the value being written attempt to be put on the bus at the same time.. so what ends up actually being written is sort of like a 'combination' of the two values.  I've heard that usually this ends up being a logical AND of the two potential values (and at least the game Cybernator seems to rely on bus conflicts to be emulated that way or else the graphics mess up and/or music doesn't play)

From the looks of this code, it looks like the game is not relying on bus conflicts, but is instead making sure to be compliant with them.  It is LDAing and STAing the same address ($8323+Y) for the register write, ensuring that the value written matches what is read from that address.

As for the weird value ($DC instead of the expected $00), this is probably because CNROM boards have CHR-ROM disable bits [presumably] as an anti-piracy measure (at least I don't know why else the game would want to disable CHR-ROM reads).  Exactly which bits need to be set/clear to enable CHR-ROM depends on the specific board configuration.  There's no way to tell from the ROM, really.  Emulators don't emulate it anyway (partially because it's impossible to know which bits to use, partially because no known games rely on it, and partially because nobody cares), so for all practical purposes, yeah only the low bits are significant.  You might run into a little trouble if you try to put the game on a CNROM cartridge though -- but you'd run into that trouble anyway unless the board you're using uses the same bits for the CHR-ROM disable as the original game -- and that can be easily fixed by tweaking the LUT used for bankswapping.



Gawd that was wordy.  Here it is simplified:

0)  The game is not relying on bus conflicts -- even though the swap routine looks weird, all it's doing is swapping to page 0.

1)  If you're putting in your own swap routine, do it how the game is doing it now (put desired page in X or Y, LDA and STA same address using desired page as index)

2)  Only the low bit(s) are significant when determining page number

3)  CHR-ROM disable is unimportant unless you try putting the game on a real CNROM board -- in which case you might have to tweak your swap LUT to get it to work.



I know the CHR-ROM disable stuff isn't in my mapper docs.  That's one of those things I really should get around to updating.  I even think I knew about it when I wrote those -- I don't know why I left it out  =x