Thanks for the reply!
Fiskbit wrote: ↑
Tue Jun 08, 2021 1:20 pm
This issue was also reported by Vectrex28 on the NESDev Discord about a week ago, though he didn't have a good test ROM yet, so thank you for posting one. It does sound like it's a previously-unknown, unemulated PPU glitch, though the mechanism is definitely not obvious. I've not tried it on real hardware yet, but from what I've seen on emulator and in the video, I suspect that the palette corruption is related to the value of v when rendering is disabled. I had hoped v would be pointing into palette RAM, but it's $7Dxx instead of $3Fxx or $7Fxx, so I don't understand what makes this case special and why we haven't seen this before.
The video shows that the corruption does indeed start mid-screen where the set of writes is done. Unfortunately, the video is at 25 FPS, so it's very hard to figure out the timing of the corruptions. They look like they might be about 8 frames apart, which would support the idea that it's the value of v, since coarse x increments every 8 frames. It also looks like corruption is frequent at the starting location, where v is almost always $7Dxx, but as the disable point moves left and v is more frequently on the left table where it's $79xx, it seems the corruption is less frequent, which may suggest the issue only occurs on the bottom right table.
The new test ROM removes the $2005/2006 writes and moves rendering enable to vblank.
Since I haven't run it yet on hardware or seen a video, I don't know if the actual corruption occurs at disable time or enable time. (As a comparison, the OAM corruption that occurs from disabling rendering mid-screen is caused by the rendering disable, but the corruption doesn't actually happen until rendering begins again.)
Edit: Also in the video, when the palette is reset for the first time, it looks like there are 3 video frames where $3F00 in the palette stripe has been corrupted from #$0F to one of the blue colors (#$11/21/31). During these frames, you can see that the greyscale at rendering disable is also affected by being from one of the brighter rows, so it definitely looks like corruption happens at disable time and that it happens to the same color on multiple consecutive frames.
I was a little hopeful that the color that was being written might be related to the one currently being used when rendering is disabled, but while there are cases that look like they support that, there are also counterexamples, so unless only certain bits are corrupting rather than the whole color, I'm not sure where the color is sourced from.
I'm a little relieved to know that my Famicom is not broken...
I've created and tested a further modified test ROM, and I think your points are generally correct.
Also, it seems that there are alternating scanlines where discoloration occurs and scanlines where it does not.
Checking with Mesen event viewer, it appears that discoloration occurs only on odd scanlines. (This includes H blanks for even-numbered scan lines.)
It seems to depend on the state of Famicom each time it is started and which name table is scrolled through, but it looked like discoloration could occur even on the left side of the screen if it was in the scan line where discoloration tends to occur.
Also, as you mentioned, the discoloration seems to be affected by the color just before disabling the PPU. (The discoloration at the time of the H-blank was black.)
However, there were times when the color changed to a color that was not set in the palette at all.
I have modified the ROM to make it a little easier to test.
Scrolling can now be controlled manually, and the palette after disabling PPU using "lda $2007" is now displayed.
I've also uploaded a new video for you to watch. (link
-Test ROM operations
Arrow key : Move the PPU disable point
A, B : move scroll
Start : Reset palette (on/off)
Select : Switch the name table (switch in order of $2800,$2C00,$2000,$2400)
Edit : There was a mistake in the keystroke processing of rom, so I reuploaded it. Sorry...