Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.
I'll check it tomorrow, frankly I was too tired to read through the whole thread right now
I am very happy to report that v23 of the PowerMappers fixed my issue! All the splits I had for all bosses and this parallax double split mentioned in the OP all work FLAWLESSLY on the AVS (as well as the original NES). Thank you!thefox wrote:I'll check it tomorrow, frankly I was too tired to read through the whole thread right now
This tells me though I probably need to get an INL mmc3 dev cart ASAP so I can make sure that mmc3 implementation works well on everything for the remainder of the project.
Still interested in further thoughts on this even though it is kind of a moot point at this point since everything is working. Heck, I still even have a coarse hblank nudging timer in there! (dex/bne instead of a long list of nops)
Glad that solved the issue!
The 2005/6 writes shouldn't affect the operation of MMC3. It's only looking at PPU A12, which toggles the same way regardless of scroll. If you look at https://wiki.nesdev.com/w/index.php/Fil ... timing.png, A12 would stay low for the first ~260 pixels of the scanline as the PPU is fetching background tiles (from $0000), then goes high as it starts fetching sprite tiles (from $1000). Also, the reload also only takes effect on the rising edge of A12. Personally, I would avoid writing around pixel 260 (right around the beginning of hblank) because if your writes are not perfectly timed (as they rarely are) the write could sometimes land before and sometimes after the rising edge of A12. But other than that you should be safe doing the writes anywhere.GradualGames wrote:Since you're familiar with how this mapper works, is my theory above at all conceivable? Like, do I need to ensure a fair distance between the split x/y 2005/2006 writes and the reset of the mmc3 scanline counter? I have these operations right next to each other; I'm wondering if it would be "safer" and admit a variance in mmc3 implementations to spread the two operations apart with a few nops or something, or if that's all speculation and not reflective of what may actually be happening with this 1 scanline jitter?
In New PPU mode it syncs PPU and CPU every 8 pixels. It's not the best, but it's really nowhere near the worst at this point.tokumaru wrote:FCEUX rounds some things to the nearest scanline, it's probably one of the worst emulators to test raster effects.
The best right now seems to be Mesen, which has a really lovely "event viewer" that's perfect for this kind of work.
(IMO anything at all involving hblank needs hardware testing, though.)