nesdev.org

Drag wrote:The only caveat is that this gives you less time for PPU updates since sprite DMA should ideally be done first thing, followed by all the PPU bus accessing code.

On NTSC NES, where avoiding this glitch actually matters, whether you do OAM DMA before or after VRAM updates doesn't matter so long as it's all done before reenabling rendering.

Drag wrote:On the other hand, wow, you don't need to reread and compare the controller bytes!

That's especially useful if you're using the SNES Mouse, since you can't reread (it accumulates movement info over the course of a frame, and reading it resets its counters). Similar code could probably be written for the Arkanoid controller (which uses D3/D4 and also does not allow rereading).

Drag wrote:The only caveat is that this gives you less time for PPU updates since sprite DMA should ideally be done first thing, followed by all the PPU bus accessing code.

Not really. DMA first or VRAM updates first doesn't matter, added up they'd still take the same amount of time either way. And by doing the DMA last you can let the controller code itself spill into the visible frame, no need to deduce that part from the vblank budget.

You do lose a bit of time on PAL, where the DMA must come first, but is that really a problem with a vblank period that long? That would only be a problem in PAL-only games (that can't possibly be converted to NTSC), something I don't think people should be making.

No, you guys are right. Sprite DMA being first is only important on PAL machines, where the DMA glitch is fixed. On NTSC machines, sprite DMA can happen after the PPU update routine, and then controller reading can happen immediately afterwards since all the vblank critical stuff is done.

Though I'm going to pout just a little because I came up with that bit-merging method of doing DMA-corrected joypad reading and felt really clever about it, and now it's obsolete.

tokumaru wrote:You do lose a bit of time on PAL, where the DMA must come first, but is that really a problem with a vblank period that long? That would only be a problem in PAL-only games (that can't possibly be converted to NTSC), something I don't think people should be making.

PAL-only games wouldn't even be doing this in the first place anyway.

So the only problem is one that can be fixed - incompability with current versions of some emulators?

Maybe we could try quickly modifying an existing game to use this technique to see how feasible it is in practice?

Sik wrote:PAL-only games wouldn't even be doing this in the first place anyway.

True, you lose no vblank time on PAL either.

This is a really awesome find. Can't wait to use this in future projects!

Tested on a Powerpak. At first, neither *_even nor *_odd would turn white without pressing right, until I realized I had my Four Score enabled. Disabled it and then *_odd started turning white immediately. Which makes sense.

Question: is it possible from within the ROM to detect whether the host emulator is doing the wrong thing, by reading the controller on odd cycles while turning DMC on and off? If that were the case, the ROM could switch to using a routine compatible with that host's behavior.

Drag wrote:The only caveat is that this gives you less time for PPU updates since sprite DMA should ideally be done first thing, followed by all the PPU bus accessing code. On the other hand, wow, you don't need to reread and compare the controller bytes! That's really spiffy, especially if you need to read more than 8 bits from each port. Nice finding!

So…forgive me if this is obvious, but why not just put the DMA after the PPU updates? Or is that only in PAL?

OAM DMA should be done first in PAL because OAM is not writable in lines 261-310.

Recommended pseudocode:
If PAL NES then OAM DMA
Update palettes, nametables, and CHR RAM as needed
If NTSC or Dendy then OAM DMA
Read controller

dustmop wrote:Tested on a Powerpak. At first, neither *_even nor *_odd would turn white without pressing right, until I realized I had my Four Score enabled. Disabled it and then *_odd started turning white immediately. Which makes sense.

I was going to add a test to make sure you have the right kind of controller hooked up, but I figured simpler code with clear instructions would be better for this.

If I were to write a test ROM for emulator devs, though, I would definitely trick it out with every possible failure mode. I'll probably get on that when I have time.

dustmop wrote:Question: is it possible from within the ROM to detect whether the host emulator is doing the wrong thing, by reading the controller on odd cycles while turning DMC on and off? If that were the case, the ROM could switch to using a routine compatible with that host's behavior.

You could, but breaking incorrect emulators is a feature in my book.

It only breaks emulators that are already trying to be accurate hard enough to bother implementing the DMC interference in the first place. Most "inaccurate" emulators are already giving you glitch free reads.

What I find amusing is that the broken emulators seem to be actually doing the correct thing, just with the wrong cycle alignment.

Rahsennor wrote:breaking incorrect emulators is a feature in my book.

It could be, at least until you hear complaints from a user of your game on a platform for which there is no accurate emulator to recommend. For example, which accurate emulator should I recommend to a user of Android?