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