DPCM/Controller Glitch emulation

Sorry if this was answered somewhere else already, but I looked and couldn't find it.
Is there an emulator that correctly emulates the DPCM/Controller glitch? It seems that most people on here think highly of Mesen. Does that one? I normally test on FCEUX, and then on Everdrive periodically to make sure things work on real hardware. it seems to be glitching on the real NES, but not FCEUX. It just got me thinking. Thanks.

Rahsennor came up with the method of aligning the even/odd cpu cycles to the apu (after OAM DMA) to avoid sample playback mangling the controller input just the other year, so i believe at least that particular technique is best to test on ntsc hardware for now.

I am currently reading the controller in a loop until I get two identical reads in a row. I'm happy with that. It required the least modification to my existing code, and it works fast enough for my needs. I just wanted to make sure I wasn't going to encounter any more surprises. I think I am going to start using Mesen for testing from now on. it seems better.

Personally I think the "best" technique is the traditional one that hundreds of NES games used. (repeated reads)

The OAM DMA alignment trick has very severe constraints about when you can poll the controller, and has had problems with several recent versions of emulators that implemented DPCM corruption before the alignment property was known.

So... it's advantages are IMO pretty minor (saving ~2 scanlines of time per frame? DPCM support for uncommon peripherals?) and the drawbacks you trade for that are significant. It's a cool technique if it solves your specific set of needs, but it's a far cry from "best", IMO. This is not a problem that needs a new/novel solution, the 35 years old method still works perfectly well.

That's a good comparison. I didn't mean that there was a "best" method tough; i just meant that it'd be best to test it on hardware if that particular method was used.

On the topic of when to use it.. well, i think they could've been slightly better off if they knew the technique for metroid, for example. When samus is falling down a shaft (that one condition in the game where scrolling can get pretty fast), you get a race condition where NT attributes occasionally aren't correctly loaded. The resulting artifacts stick until you've cleared the nametable scrubbing the scroll back and forth. But then again, they could've had a more robust update routine, too.

I think Mesen's current development build is your best bet.

Emulator support for DPCM glitch will always be poor. No games rely on it happening. The main need for emulating it is to support homebrew that needs to avoid causing it to happen, and that's a niche only a few emulators address.

If you really want to know which emulators support it or not, you should run some test ROMs to check. You can test some of the known behaviours with these:

• (blargg) read_joy3, count_errors.nes: will measure the effect of DPCM glitches. If it counts 0, the emulator doesn't do it.
• (rahsennor) dma_sync_test_v2: will display a white screen if an emulator implements DPCM glitches but with the wrong alignment timing (or if you manually press right on the d-pad), otherwise black.
• (blargg) dmc_dma_during_read4: tests $2007 and $4016 for read corruption, though the output of these tests is a little bit obtuse to understand (check the source).
• (fiskbit) dma_sync_test_loop: not quite sure what this tests, but it seems to fail in Mesen?

There's probably other properties of it that need testing too, but you'll have to go looking for tests for that, or write your own.

Edit: added a few more tests, and links to the ROMs.

Oh! I apologize for misreading that, sorry.

On the other hand, for some specialized controllers, there is a best method. Rereading a Four Score is time-consuming. It's also impossible for an Arkanoid controller or Super NES Mouse, as strobing those have side effects: the Arkanoid controller restarts the ADC when strobed, and the Mouse clears accumulated horizontal and vertical mickeys to 0 when strobed.

I was also aware of reads from $2007 being corrupted as well, but I never read from $2007 in my current project, so it's not an issue.

Thanks for the info about the other controllers. I'll have to remember that if I ever use them in the future.

Yes, this one fails in Mesen, there was some discussion about this in the Mesen thread, too, but essentially I haven't been able to make the Disch's DMA-related timing results from Visual 2C02 with existing test roms. I can easily make the test rom pass (while keeping all other tests as a pass, too), but I'm fairly certain that fix is incorrect (at least, based on my understand of how the DMAs work internally), so I haven't changed anything as of yet.

If you're hoping to get your games to run on as many emulators as possible, the best bet really is to just read the controllers multiple times, imo. I'm not sure that any existing emulator actually implements the DMC DMA cycle stealing 100% correctly.

I seemed to have missed some of these findings.

I tried dma_sync_test_loop and dma_sync_test_v2 in BizHawk and both pass as far as I can tell.

@Sour: I see in the Mesen thread that you tested BizHawk and it failed one of the tests. which one was it? I'm not aware of Bizhawk failing any DMA related tests.

Odds are that the version of Bizhawk I was running wasn't anywhere near up-to-date with the code on Github. If it passes all the tests, I'll have to take a look at the code again then. Unfortunately lost the local git branch that I had with my tests on this, so might be a little while (esp. since my time is currently all being spent on trying to build a SNES emulator)

Woah really? That's awesome! Good luck on that.

@sour

Already working on a snes emulator? That's interesting. If it's as user friendly as mesen then I will be more than happy to test it

It's nothing special at the moment, started a week ago, but some games are booting and from time to time something displays properly :p

I'm reusing a lot of stuff from Mesen which has really been helping speed this up. The idea is to eventually add similar debug tools as much as possible (currently only ported the trace logger and hex editors with some functionality stripped out).

Also in the process of gathering all SNES-related documentation into a wiki as I go, because the current state of SNES documentation is not great when you compare it to the Nesdev wiki.

I'd love to get into SNES development at some point, and you're right about the lack of documentation. Something like that would be a great tool.

As far as I can tell, BizHawk 2.3.1 doesn't support this glitch at all; none of the tests I've tried that are expected to fail are doing so on this emulator. [Edit: Alyosha_TAS pointed out that the NesHawk core, which is not the default, does support this glitch and passes/fails tests as expected]

As of my testing in January, Nintendulator seems to be the best one for testing this, as it correctly passes/fails related input corruption tests I've tried or written. However, last I saw from Quietust on this topic, he wasn't confident that the timing was 100% right in all cases. Mesen and puNES also support this and appear to be good enough for testing anything but long synced-read functions. Nestopia and Nintaco have some level of support, but seem to be inaccurate enough at this time that their results aren't reliable.

And yeah, I agree that multiple reads is the way to go for now.


@rainwarrior: dma_sync_test_loop attempts to sync once and then perform joypad reads indefinitely without corruption. The initial discussion around synced input reading was that the joypad read cycles needed to be timed to land on even cycles, which works fine for a short input reading function, but if your input reading takes longer than your DMC rate, then you also need your sequences of writes to end on even cycles. Otherwise, DMA landing on a misaligned write will take an odd number of cycles and change cycle parity, causing your joypad reads to land on odd cycles.


@Sour: I'm really excited to see what you can pull off for SNES emulation. If the tools are anywhere near as good as what you've made for NES, I suspect I'll finally start tinkering around with SNES.

For BizHawk you need to change to the NESHawk core. Do this by going to Config -> Cores -> NES -> NESHawk.

The default core is QuickNES, which is fast but not very accurate.

NESHawk is the slow but accuracy focused core.

Ah, thanks. Yeah, you're right that it passes/fails as it should. Looks like it might be as good as Nintendulator, then.

I'm surprised QuickNES is the default in this emulator, given its accuracy problems. I've already had to work around QuickNES bugs in my projects, such as by incrementing a non-FF negative value to reset MMC1 because QuickNES wasn't ignoring the second write.

Cool! Looking forward to hearing more about that later!