The mooneye test lcdon_write_timing tries to write the value 0x81 to the OAM address 0xfe00 with different delays after enabling the PPU. When it uses 131 or 245 NOPs between enabling the PPU and writing the value, the write is successful. But in those cases we see in the wave diagram that the write operation gets really butchered: The write signal that is applied to the OAM is very short, like it's just a glitch. During testing I managed with some timing values to only write some bits of 0xfe00 including bit 0 and 7, but not all. In that case the mooneye test succeeded, because it actually clears the OAM with zeros before the test, so the resulting value is still 0x81 as it expects.
I would like to test the following things on real hardware with NOP counts of 131 and 245:
- Try different values than 0x81 to see if we can flip all bits to 1.
- Try the same with OAM memory initialized to 0xff, so we can see if all bits can be flipped to 0.
- Is the behavior the same for both OAM blocks? Address 0xfe00 points to OAM block B. Try 0xfe01 (OAM block A) or maybe even more addresses.
The mooneye test lcdon_write_timing tries to write the value 0x81 to the OAM address 0xfe00 with different delays after enabling the PPU. When it uses 131 or 245 NOPs between enabling the PPU and writing the value, the write is successful. But in those cases we see in the wave diagram that the write operation gets really butchered: The write signal that is applied to the OAM is very short, like it's just a glitch. During testing I managed with some timing values to only write some bits of 0xfe00 including bit 0 and 7, but not all. In that case the mooneye test succeeded, because it actually clears the OAM with zeros before the test, so the resulting value is still 0x81 as it expects.
I would like to test the following things on real hardware with NOP counts of 131 and 245: