This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Safe time to turn off the screen?

Safe time to turn off the screen?
by on (#58172)
Fantastic Adventures of Dizzy turns off the screen at PPU clock 299 to 318.
Back to the future turns off the screen at clock 6-26.
RC Pro Am turns off the screen at 259-277.
Micro Machines turns off the screen at 315-316. (very precise!)
Super Off Road turns off sprites at 259-279, then turns off the screen 48 clocks later.
Wizards and Warriors 3 turns off the screen at 276-295.
So when is the safe time, and safe conditions for turning off the screen? Is it always okay as long as you overwrite the OAM every time?
Re: Safe time to turn off the screen?
by on (#58174)
Dwedit wrote:
Is it always okay as long as you overwrite the OAM every time?

No, even if you do a sprite DMA after having turned the screen off the OAM can (and usually is, from my tests) corrupted. I have no idea why that is, but a new DMA transfer doesn't fix the corruption (it seems some entries don't get updated or something).

According to tepples you can avoid glitches if there are no sprites being displayed on the scanline where rendering is turned off, but since I couldn't garantee that, I gave up on disabling rendering early.

by on (#58182)
Here's my hypothesis that appears to match up with observation:

OAM is DRAM. Whenever the PPU reads OAM, it has to write identical data back to OAM. When you interrupt this OAM refresh process, sometimes a half-completed refresh gets stuck in the PPU registers, and this data gets copied over some other part of OAM. So if you turn rendering off early with a half-completed refresh in the buffer, you have to wait for a rendered scanline for this refresh to complete.

The last topic about this seems to indicate that a safe time that doesn't interfere with OAM evaluation should be about X=64 to X=255 of any line with no sprites.

by on (#58185)
So what happens is that we interrupt the DRAM refresh process, then we perform a sprite DMA and the new data is safe in place, but once rendering starts again the DRAM refresh process doesn't have a clean start so it ends up corrupting some of the data, is that it?

This is an evil detail, because many people consider turning rendering off early when they are short of VBlank time. I grew fond of the opposite, enabling rendering late, because it's easier to do without IRQs or sprite 0 hits (even if it requires timed NMI code).