infiniteneslives wrote:
James wrote:
'clock the counter if A12 went high after being low for x cpu cycles'.
Yes that's the key. CHR A12 must be low for ~X CPU cycles before the next rising edge is allowed to clock the counter. I use 5 cycles in hardware and it seems to work. I've heard of emus using 4-6, but I suppose that is due to subtle timing inaccuracies.
When the PPU is rendering the BG, it makes two nametable accesses ($2xxx), and then two pattern table accesses ($0xxx ideally), for each tile, so A12 stays low for the whole time.
When the PPU is fetching the sprite patterns, it makes two garbage nametable accesses ($2xxx again), and then two pattern table accesses ($1xxx ideally). This means, A12 is constantly toggling high and low!
Each of the PPU's memory fetches take two pixels to complete, so the MMC3 must be able to ignore the 4 pixels of A12 being low while it makes the garbage nametable accesses. I'd say the MMC3 must be able to ignore a
minimum of 5 pixels (or 1.667 CPU cycles) before the next rising edge of A12 can clock the scanline counter.
That's the absolute bare minimum; the MMC3 probably waits a lot longer than just that. An easy way to test this with an authentic MMC3 is to set up a scenario using 8x16 sprite mode, with the BG using pattern table $0000. Put sprites 0-7 on the same Y-position together, give sprites 0 and 7 a pattern from $1000, with the others using a pattern from $0000. If the counter still functions normally, then the MMC3 is ignoring at least 53 pixels (17.667 CPU cycles).
If this disrupts the scanline counter, then the effect will be the counter being clocked twice per scanline. Try having sprites 1 and 7 use the pattern from $1000 (MMC3 ignoring 45 pixels?), then sprites 2 and 7 (ignoring 37 pixels?), then 3 and 7 (ignoring 29 pixels?), and so on until the scanline counter starts behaving normally again.