i just wrote a little table-driven test which uses DMC interrupts to produce raster splits at mostly-eight-line intervals. For purposes of this demo, the raster IRQ simply changes the RGB emphasis bits (as as to make the effects visible in the screen borders) and all stores occur the same amount of time after the IRQ. A practical game should adjust the amount of time before each store to compensate for the fact that the IRQs aren't triggered at quite the same time every scan line, but compatibility testing is probably better served by letting some of the stores be barely visible.
I'd like to know if this works with NTSC Famiclones the same way as it does on my vintage NES.
The worst spots on my NES are on the white bar just beyond the midpoint. That bar is long enough that even though the transition from blue to white sometimes happens early (reaching back one dot on my set) the transition from white to red happens late (reaching the fourth dot). If the code were tuned and optimized, the overhead could probably be reduced to under 100 cycles per split point, suggesting that this approach could be used to let Ruby Runner show 512 tiles on screen, but it would only be worth pursuing that if the raster timings end up being consistent on a wide enough range of machines.
The present version of the code wouldn't have a chance of working on PAL. PAL looks like it could be supported with somewhat more overhead per split; if alternate splits are timed for 900 cycles and 922, the splits following the 922-cycle splits would need to do their last APU store a minimum of ~98 cycles after the IRQ is triggered (vs 84 for NTSC) but it might still be reasonable.
I'd like to know if this works with NTSC Famiclones the same way as it does on my vintage NES.
The worst spots on my NES are on the white bar just beyond the midpoint. That bar is long enough that even though the transition from blue to white sometimes happens early (reaching back one dot on my set) the transition from white to red happens late (reaching the fourth dot). If the code were tuned and optimized, the overhead could probably be reduced to under 100 cycles per split point, suggesting that this approach could be used to let Ruby Runner show 512 tiles on screen, but it would only be worth pursuing that if the raster timings end up being consistent on a wide enough range of machines.
The present version of the code wouldn't have a chance of working on PAL. PAL looks like it could be supported with somewhat more overhead per split; if alternate splits are timed for 900 cycles and 922, the splits following the 922-cycle splits would need to do their last APU store a minimum of ~98 cycles after the IRQ is triggered (vs 84 for NTSC) but it might still be reasonable.