DRW wrote: ↑Tue Jul 12, 2022 1:43 pm
So, I can be sure that those glitch issues only appear on the old Famicoms whose controllers don't even look like the later, more famous model?
Other models don't have different behavior? Can I be definitely sure that, for example, the first batch of American NES consoles that were sold in winter of 1985 will not produce any strange behavior that differs from the behavior of, let's say, a 1989 NES?
Is this an officially supported operation, though, or just some chance discovery? I've never heard of the address $3E01 in regards to NES programming and I'd rather not use stuff that's
too obscure.
The $2001 write glitches I'm describing occur
only on the RP2C02A and presumably RP2C02 letterless. These PPUs exist
onlyin the first couple hundred thousand RF Famicoms, which were sold with square button controllers. You will not find them in any other console. The North American market only got E, G, and H PPUs, and the vast majority of these are G (only around 1 million E's and probably a very small number of H's).
The $2001 write workaround where you use PPU register mirrors that correspond with your data to avoid glitches will work on official hardware with no negative side effects, and probably on most clones and most (all?) reasonable emulators. It was just discovered in this thread, but as lidnariq says, other PPU register bits have the same bug and the workaround for them has been known for years. As far as we know, this is new knowledge that Nintendo and contemporary developers did not know about and thus did not intentionally use.
Glitches from turning rendering off at approximately dots 1-64 or 257-320 occur only on E, G, and H PPUs. Glitches from urning rendering off at approximately dots 65-256 and back on mid-screen on some alignments occur on all NTSC PPUs (and probably RGB PPUs, as well). PAL is untested.
Dwedit wrote: ↑Tue Jul 12, 2022 11:14 am
Final Fantasy 1 is known to use timed PPUMASK writes to do the light beam effect when you get a crystal. What would the failure condition look like on a square button Famicom? Is there no failure condition because there is no forced blanking?
I'm going to guess here because I don't like this game and am not going to play far enough to trigger this effect, but assuming it's doing normal $2001 writes, then the greyscale part will work fine, but rendering will turn off briefly after both edges, messing up the background afterward on each scanline. Sprites on the next scanline will presumably be disrupted, and it may cause sprite issues on the remainder of the screen depending on the CPU/PPU alignment because at least some of the writes occur in the approximately 65-256ish dot range where rendering disable can cause poorly-understood sprite issues. I'm not sure exactly how wide the rendering disable region is; that's something that would need to be tested. However, it doesn't have to be wide to meaningfully disrupt a whole sliver.
CutterCross' CrossPaint demo has $2001 writes all down the edge of the canvas in hblank, and on revision A, those cause flickering bad slivers all along that edge unless changed to $3E01. I think he had a report of this happening on a revision B console, as well (which would bring the affected number of PPUs up to about 1.2 million), but I don't think I ever saw evidence of this issue on my B's. I still need to test CrossPaint on one. I don't have B, C, D, or D-0 PPUs in consoles with composite output, which makes testing them pretty annoying.