nesdev.org

Apologies if this information has been mentioned before, but the last time I remember hearing anything regarding the OAM DRAM refresh bug, this information was how the bug worked.

TL;DR: When rendering is disabled in the middle of a scanline (between pixels 64-255) that has any of sprites 0-5 on it, the DRAM refresh bug occurs.

It's really interesting to hear that pressing the reset button interrupts the sprite evaluation logic in the same way that disabling rendering does, to where the DRAM refresh bug occurs the first time the game switches rendering back on, but it makes sense and I suppose it should've been a logical conclusion.

A workaround to fix the title screen would be very easy, just display one blank frame as part as your reset routine. A full vblank-to-vblank frame, to be sure that the relevant sprite logic has run and is terminating safely before rendering is turned back off.

Drag wrote:When rendering is disabled in the middle of a scanline (between pixels 64-255) that has any of sprites 0-5 on it, the DRAM refresh bug occurs.

What do you mean by sprites 0-5?

By the frequency of errors during the reset test on oam_reset2.nes, I'd say it corrupts something like 30-50% of the time. I don't think this would be possible if it was limited only to scanlines with sprites 0-5. It seems more or less the probability I'd expect if any interruption on the active half of a scanline counts.

This is the original thread where this glitch was discussed. Here is where I got the "only sprites 0-5 trigger the glitch" figure, unless I've misinterpreted Blargg, which is always possible.

I worded the 64-255 pixel range thing clumsily in my old thread, so the correct information is that pixels 64-255 of a scanline are the "safe" region to disable rendering and not cause the DRAM refresh bug, but it's only safe when no sprites intersect the scanline, or when intersecting sprites intersect on their bottom-most row. Disabling rendering outside of the 64-255 "safe" region will always cause the bug.

Math time! Assuming NTSC NES.
There are 341 dots in a scanline. Dots 64-255 are safe for disabling sprites, subject to the condition of there not being any sprites intersecting the scanline underneath the one where you disable rendering. Therefore, there are 151 "bad" dots on each scanline, dots where you should not disable rendering under any circumstance.

Disabling rendering outside of the visible scanlines does not trigger the bug, so only the visible 240 scanlines can trigger the bug. 240 dangerous scanlines * 151 bad dots = 36240 bad dots that will trigger the bug. There are 89341.5 dots in a frame (.5 because one dot is skipped during odd frames).

Assuming a screen with no sprites, using the above figures, this bug has a 40.56% chance of occuring when you disable rendering at a random point in the frame (such as by pressing the reset button).

Assuming only sprites 0-5 trigger the glitch, the probability is 42.26% at best (all 6 sprites have the same Y position), and 50.77% at worst (all 6 sprites are spread out and do not intersect each other on the Y axis).

If all sprites trigger the glitch, the probability is 42.26% at best (all visible sprites have the same Y position), and 91.60% at worst (every single visible scanline has a sprite on it)

Never the less, these percentages seem to match what you experienced, so good catch on my blunder.

DRW wrote: If the game is already playing for some seconds and you only check for the sprite overflow then, it never freezes.

Some things depends on chip temperature:
If set spr adr to $80 instead of $00 before doing sprites dma. bugs happens, but disappears after some time (on famicom model hvc-102): https://youtu.be/QgJMzyEbko8
If change spr addr to $80 after dma: bugs changes to other bugs after some time (until power off) -> https://youtu.be/Y-v0STBK_Co OR bugs also fully disappers after some time - https://youtu.be/XrvyQM43QhI

Ti_ wrote:

DRW wrote: If the game is already playing for some seconds and you only check for the sprite overflow then, it never freezes.

Some things depends on chip temperature:
If set spr adr to $80 instead of $00 before doing sprites dma. bugs happens, but disappears after some time (on famicom model hvc-102): https://youtu.be/QgJMzyEbko8
If change spr addr to $80 after dma: bugs changes to other bugs after some time (until power off) -> https://youtu.be/Y-v0STBK_Co OR bugs also fully disappers after some time - https://youtu.be/XrvyQM43QhI

OAM Decay is definitely affected by temperature.

DRW's problem wasn't OAM decay, though. It is some uninitialized sprite evaluation flag, which I don't think really does have to do with temperature.

rainwarrior wrote: OAM Decay is definitely affected by temperature.

I gave links for same thing as "oamaddr bug" option in mesen emulator, not oam decay.

What's the specific PPU version in your videos?

Ti_ wrote:

rainwarrior wrote: OAM Decay is definitely affected by temperature.

I gave links for same thing as "oamaddr bug" option in mesen emulator, not oam decay.

Oh, I misunderstood what those ROMs are supposed to test. (Where are those ROMs available?)

So you're saying the effect of sprite evaluation copying one tile over another is subject to temperature variation?

The related effect on reset from my tests above did not seem to change over time, or go away after warming up... They appeared to have a pretty consistent rate of occurrence.

roms:
https://yadi.sk/d/p1_zFOK43HXiZH
(if you turn on after 1 hour been off, you may need to wait about 3-5 minutes to see changes).
you need to turn off power at least for 1minute to see effects goes back.
(roms oam_addr_80 and oam_dma_80)

lidnariq wrote:What's the specific PPU version in your videos?

RP2C02E-0

Some other glithces (on this ppu version?):
If a new frame starts while rendering been off somewhere in previous frame, some of sprites flashes:
https://yadi.sk/i/ic0hpjsT3J8A8J
Which of sprites depends on time where it has been off, when sprdma starts, and slightly by a chip temperature.

Games where it is seen, Somari:
https://yadi.sk/i/NQgOpc603J8Akf