Nine sprites overflow doesn't work in the beginning

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Drag
Posts: 1615
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: Nine sprites overflow doesn't work in the beginning

Post by Drag »

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. :P

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.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Nine sprites overflow doesn't work in the beginning

Post by rainwarrior »

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.
Drag
Posts: 1615
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: Nine sprites overflow doesn't work in the beginning

Post by Drag »

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. :P
Ti_
Posts: 61
Joined: Sat Aug 03, 2013 3:08 pm
Location: Russia
Contact:

Re: Nine sprites overflow doesn't work in the beginning

Post by Ti_ »

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
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Nine sprites overflow doesn't work in the beginning

Post by rainwarrior »

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.
Ti_
Posts: 61
Joined: Sat Aug 03, 2013 3:08 pm
Location: Russia
Contact:

Re: Nine sprites overflow doesn't work in the beginning

Post by Ti_ »

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.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Nine sprites overflow doesn't work in the beginning

Post by lidnariq »

What's the specific PPU version in your videos?
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Nine sprites overflow doesn't work in the beginning

Post by rainwarrior »

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.
Ti_
Posts: 61
Joined: Sat Aug 03, 2013 3:08 pm
Location: Russia
Contact:

Re: Nine sprites overflow doesn't work in the beginning

Post by Ti_ »

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
Last edited by Ti_ on Mon May 01, 2017 10:35 pm, edited 1 time in total.
Ti_
Posts: 61
Joined: Sat Aug 03, 2013 3:08 pm
Location: Russia
Contact:

Re: Nine sprites overflow doesn't work in the beginning

Post by Ti_ »

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
Ti_
Posts: 61
Joined: Sat Aug 03, 2013 3:08 pm
Location: Russia
Contact:

Re: Nine sprites overflow doesn't work in the beginning

Post by Ti_ »

Here's a rom that shows pseudo-temperature:

works on my famicom (ppu RP2C02E-0), video:

doesn't work on my other ntsc-clone (which also has sprites flickering), but shows fixed value '25'.

rom uses sprites overflow and dma with oam adr #$80. if overflow happens on first line it counts as '2' , and if on second as '1'. counts average 'hits' every 25 frames. oam with adr #$80 is sensitive to temperature. for overflow on first line I use 8 sprites, instead of 9 (otherwise I lose overflow on second line, one of those bugs?)

unfortanely you need to wait about 5 minutes from cold-cold boot.
Attachments
RP2C02E-0.7z
(695.17 KiB) Downloaded 39 times
test_temperature.7z
(1.99 KiB) Downloaded 35 times
Post Reply