Telling LYs tracking bug

[pinobatch]

This is a meta-issue for issues filed against emulators for failing the "Telling LYs?" test ROM.

---

Input changes on same scanline every time

A program can tell that it's running on $emulator because the buttons always change right at vblank.

To reproduce:

1. Install $emulator
2. Start the attached test ROM "Telling LYs?" $download_link
3. Press all $buttoncount buttons in any order
4. Watch the arrow sprite at the right side

Expect: Arrow moves after each press, followed by "Pass", as on my $console

Actual: Arrow stays at $side of the screen, followed by an "Incorrect behavior" message that clearly isn't "Pass"

The Game Boy emulator BGB by beware passes this test. Normally it changes the input on the first scanline of vertical blanking to reduce input latency. But if a program reads input multiple times during a frame, the emulator starts to randomize on which scanline the input changes. This way, the program can't discern that it's being emulated and freeze on a copy protection screen, but it adds one frame of lag. Once the program returns to polling once a frame, BGB returns to the low-latency behavior.

Related forum topic: $NESdev_BBS_link

---

When filing a Telling LYs bug, fill in the above template with the appropriate console name, button count, emulator name, BBS topic, download link, and failure side. BBS topics are listed below:

• Telling LYs? (input timing test ROM) for Game Boy
• Telling LYs? (input timing test ROM) for NES
• Telling LYs? (input timing test ROM) for Super NES

[pinobatch]

Bugs filed so far:

• Input change always happens at the same Y position SourMesen/Mesen#688
• Input change always happens at the same Y position SourMesen/Mesen-S#63
• Key IRQ always happens at the same LY mgba-emu/mgba#1232
• Joypad interrupt does not fire deltabeard/Peanut-GB#34
• Input change always happens at the same Y position snes9xgit/snes9x#593
• Joypad interrupt does not fire binji/binjgb#25

[MineRobber9000]

I filed Baekalfen/PyBoy#116.

[pinobatch]

Not everyone is interested in investigating further, for whatever reason:

• byuu/bsnes#212 - Run ahead breaks Telling LYs (WONTFIX)

[endrift]

"For whatever reason" is because "they shouldn't fire all on the same scanline" is a purely statistical take. It's not a bug in the strict sense that it's statistically impossible to press all the buttons on the same scanline, that's just the reality of a human playing the game. But a TAS machine could be rigged up to present this input on a real GB, thus reproducing your "bug" on hardware. And while there may be games that are "affected" by this, in general...no one really cares.

[pinobatch]

Mostly I see it as a matter of reliability of button press timing as a source of entropy.

I filed two issues against Mesen-SX
NovaSquirrel/Mesen-SX#113
NovaSquirrel/Mesen-SX#114