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.
