nesdev.org

I think the idea is "make it break so emulators gets fixed". Especially true since as soon as something capable of detecting emulators is found there will be people who will exploit it just to prevent their stuff from working on them (as an attempt to force you to use cartridges instead - yeah, that kind of people exist).

The kind of people who will patch out your anti-emulator mechanism also exist, though.

Sik wrote:I think the idea is "make it break so emulators gets fixed".

Which is inconvenient for users if the (hobbyist) developers of emulators for a particular platform have a habit of blowing off compatibility fix requests, or saying "fixed in the next version" when the latest stable release is years old *cough*Nestopia*cough*FCEUX*cough*, rather than implementing and publishing them. It's also inconvenient for game developers if none of the emulators gets fixed until after the hype for a particular game has blown over.

"clearly" the correct thing to do is explicitly elicit a DPCM bit deletion and refuse to run in emulators that don't implement it.

lidnariq wrote:"clearly" the correct thing to do is explicitly elicit a DPCM bit deletion and refuse to run in emulators that don't implement it.

Sarcasm noted But the problem is, unless you have player cooperation or one of the (uncommon) cases where there's a signature afterward, you can't guarantee detection of a bit deletion.

Myask wrote:But the problem is, unless you have player cooperation or one of the (uncommon) cases where there's a signature afterward, you can't guarantee detection of a bit deletion.

You can make two quick reads in succession, one uncorrupted, one intentionally corrupted, and just test if they're equal.

A true fail is going to fail this test every time you do it. A human playing on hardware accidentally making a press in the middle of this process probably isn't going to be able to do it two frames in a row. Pretty easy to weed out the false positives just by requiring several failed frames in succession. You don't need to be able to fail all the time, you can just wait until they need to press RIGHT or something and catch it then.

Not that I'd recommend it, anyway, just I don't think this in particular is the problem.

Myask wrote:unless you have player cooperation or one of the (uncommon) cases where there's a signature afterward, you can't guarantee detection of a bit deletion.

Bit deletions work on reads from $2007, too ... it's just more than a single byte per glitch there.

If you want to detect failure through controller reads, you'll have to autodetect the type of controller in port 1. It could be an authentic NES controller, a Super NES controller with its 16-bit report (especially if played on an FC Twin or if the player also owns a Super NES Mouse-compatible game), the left half of a Four Score with its 24-bit report, or an unlicensed NES controller that returns 0 bits after the 8-bit report instead of 1 bits. It might be easier to test whether $2007 readback skips a byte, though I imagine a broken emulator might implement double reads for $2007 but not $4016 or vice versa.

tepples wrote: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

Is Dendy afflicted by the DMC/controller conflict? If not, then treating Dendy like PAL in this case would make the conditionals a simple pair of lda with beq/bne (In the usual setup of NTSC = 0, PAL = 1, and Dendy = 2).

To be safe, I'd just spend the 4 cycles (2 before, 2 after) on testing bit 0.

Rahsennor wrote:The expected output is that the screen should remain black until right is pressed on either controller. If it fails, it should do so almost instantly, producing a white screen.

Never noticed this test existed until now (saw a link in another thread). Mesen keeps a black screen the whole time and goes white if I press right - so I guess it passes? I do have the DMC glitch emulated. Just wanted to double-check before I add it to the list of tests it passes.

Offtopic:
Being an emulator author I might be biased, but wouldn't it be helpful if the wiki had a page containing all known test roms? I have a collection of ~300ish of them, but I keep finding test roms posted here and there in both new and old forum threads (and sometimes the download links are not even working anymore). There is a test rom page already, but it is outdated and missing literally hundreds of them.

Sour wrote:wouldn't it be helpful if the wiki had a page containing all known test roms? [...] There is a test rom page already, but it is outdated and missing literally hundreds of them.

If there are others you know about, feel free to join and add them to Emulator tests.

Sour wrote:Never noticed this test existed until now (saw a link in another thread). Mesen keeps a black screen the whole time and goes white if I press right - so I guess it passes? I do have the DMC glitch emulated. Just wanted to double-check before I add it to the list of tests it passes.

Grab the old version from page 1 and see if the odd test fails instantly. If it doesn't, you either have no DMC glitches or your controller reports aren't padded with 1s.

If it does, congrats, Mesen is the first emulator to pass.

tepples wrote:If there are others you know about, feel free to join and add them to Emulator tests.

I just tried to create a wiki account and get a 500 error with both FF & Chrome.

Rahsennor wrote:Grab the old version from page 1 and see if the odd test fails instantly.

Yup, the odd test gives me a white screen instantly. Always nice to pass new tests without having to waste a whole day trying to figure out what's wrong :)

Mail from the wiki is broken right now. Try not providing an email address when signing up. Because mail is broken, you'll need to autoconfirm (2 talk edits and 4 days) or wait for me or another administrator to wake back up and confirm your account.