OAM corruption errata when turning off rendering during active scanline

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

Post Reply
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

OAM corruption errata when turning off rendering during active scanline

Post by rainwarrior »

I am having trouble searching for past threads on this, and I'm trying to collate the data we have. I don't expect there is a complete emulatable solution at this point, but I just want to know what we know.

Basically I want to be able to create a suitable footnote for the last line of Errata: OAM and Sprites on the wiki:
NESDev Wiki wrote:Turning rendering off in PPUMASK ($2001) before the PPU has finished evaluating sprites for that line (x=192 for lines with no sprites, x=240 for lines with at least one sprite) can corrupt OAM, leading to sprite flicker.
So, I believe this issue comes up in StarTropics, where some sort of corrupt sprite is seen every time Mike is coming up through a door on the bottom of the screen. His shadow sprite crossing the render-disable for palette change puts its timing into the "unsafe" window. I noticed that previous PowerPak MMC3 mappers make this problem worse by delaying the IRQ very slightly, causing other sprites (especially the player) to visibly flicker on the map screen and in the dungeon. (Edit: actually StarTropics might have a different, undescribed sprite corruption issue with turning $2001 back on?)

Does anybody have any other examples, more specific notes, or links to past discussions?

Edit: adding past discussions as I find them.
Last edited by rainwarrior on Sat Nov 05, 2022 11:40 pm, edited 14 times in total.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: OAM corruption errata when turning off rendering during active scanline

Post by dougeff »

Is sprite rendering turned off mid screen? Or during pre-rendering / scanline -1?

(edit - I removed the comment about a "new quirk" before the next reply was sent)
Last edited by dougeff on Fri Nov 04, 2022 3:01 pm, edited 1 time in total.
nesdoug.com -- blog/tutorial on programming for the NES
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: OAM corruption errata when turning off rendering during active scanline

Post by rainwarrior »

This is not a new quirk, it has been known for a while. It has never been emulated, AFAIK.

It happens when all rendering is turned off mid-screen (i.e. both BG and sprites disabled via $2001). If the switch-off happens during the sprite-evaluation portion of the scanline, you get sprite corruption when rendering resumes.

If you disable only sprites but keep BG on, the evaluation continues but the result is hidden, so there is no corruption in that case.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: OAM corruption errata when turning off rendering during active scanline

Post by lidnariq »

The window from 192-240-255 is for "only turning off rendering early" - only worrying about corruption of "OAMPTR".

There's stricter constraints for "turning rendering off and turning it back on and expecting sprites to be fully intact below the split", but I fear the specific knowledge is currently bouncing around (other) people's heads and not yet written up on the wiki due to lack of clarity.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: OAM corruption errata when turning off rendering during active scanline

Post by rainwarrior »

Oh... yeah that makes a lot of sense. There's maybe no truly "inactive" part of the scanline for sprite evaluation, so turning it on or off anywhere is going to result in the next active line of sprites being garbage?

Did we determine turning $2001 back on as BG only for 1 line, then BG + sprites would avoid the problem? Is it only 1 corrupt line of sprites after switching on?

If the turn-off timing can cause corruption of the next OAMDMA, presumably it might effect what happens when you turn back on too... but if you're in the "safe zone" past x=240, is the turn-on garbage limited to one line? (Is it limited to one line even if turned off unsafely?)

I vaguely remember another discussion about trying to do this but I can't remember someone saying they successfully tried it. (Wasn't someone making a game with a submarine where they thought 1 line of black could work in the middle...?)

Edit: It was a game idea by FrankenGraphics but was never implemented.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: OAM corruption errata when turning off rendering during active scanline

Post by rainwarrior »

Found a thread about sprite multiplexing. I had always heard "Bigfoot" was the example for this, but apparently it's "Stunt Kids".

Stunt Kids appears to be flawless on my NES. It disables rendering around x=320-337, does an OAM-DMA, re-enables rendering BG only ($10) mid-scanline (x=~122), then 6 scanlines later re-enables the rest ($1E) at x=~280-299.

On Mesen there's a mysterious little grey glitch on the scanline after the BG re-enable, but I don't see the same glitch on my NES?

So, I guess that's a successful example of re-enable but it also has a whole DMA in there, and it hides sprites for several scanlines after the re-enable.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: OAM corruption errata when turning off rendering during active scanline

Post by lidnariq »

My memory is that Fiskbit has said that turning off from X=320-340 should be reliably safe.

Some of this is buried in this post: viewtopic.php?p=249339#p249339
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: OAM corruption errata when turning off rendering during active scanline

Post by rainwarrior »

That OAM flicker test ROM is really nice. Then it got me thinking... how to even try and test the turn-back-on behaviour.... would maybe need several sprite arrangements to test, with the ability to put the splits at arbitrary points above/below/within the sprites...
Post Reply