Problem with palette discoloration when PPU is turned off during rendering.

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

User avatar
N·K
Posts: 15
Joined: Mon May 11, 2020 2:45 am
Location: Japan

Problem with palette discoloration when PPU is turned off during rendering.

Post by N·K »

Hello!

The other day, when I was testing a game I was working on with my AV Famicom (HVC-101), I encountered a strange phenomenon.

Specifically, when I was scrolling with the nametable at $2800 or $2C00, if I turned PPU off, changed the XY scroll, and then turned PPU on again, the BG palette changed color by itself.
Just stopping the PPU while scrolling caused the discoloration.

I created a test ROM and tested it several times, and it did not always occur every time, but seemed to occur randomly at a rate of 1 in 10 to 20 times every time the power was turned back on.

I posted this because I was wondering if this glitch occurs on anything other than my AV NES.

I have attached a video recording (link) and a test ROM, and would appreciate it if you could verify it.

-Test ROM operation
Arrow key : Move the start position of the scroll change.(may be easy to discolor if moved left or right?)
B : Reset palette
A : Switch nametable($2800 or $2C00)(It seems to change the way the glitches occur.)

I'm using machine translation, so the sentence may be strange. Sorry.
Thanks in advance.
Attachments
palette_glitch.asm
(4.17 KiB) Downloaded 101 times
palette_glitch.nes
(24.02 KiB) Downloaded 102 times
User avatar
N·K
Posts: 15
Joined: Mon May 11, 2020 2:45 am
Location: Japan

Re: Problem with palette discoloration when PPU is turned off during rendering.

Post by N·K »

I did some additional testing, and to my surprise, simply scrolling the BG and stopping the PPU at the visible scan line caused the discoloration....
(This happened even if the name table was $2000 or $2400.)

I updated the test ROM.
But to be honest, I'm beginning to think that the palette discoloration caused by simply stopping the PPU is simply due to the fact that my AV Famicom is broken...
Attachments
palette_glitch_2.asm
(3.98 KiB) Downloaded 93 times
palette_glitch_2.nes
(24.02 KiB) Downloaded 95 times
User avatar
nesrocks
Posts: 563
Joined: Thu Aug 13, 2015 4:40 pm
Location: Rio de Janeiro - Brazil
Contact:

Re: Problem with palette discoloration when PPU is turned off during rendering.

Post by nesrocks »

Does the discoloration happen in emulators too (if yes, which ones?) or just on real hardware?
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
Fiskbit
Posts: 890
Joined: Sat Nov 18, 2017 9:15 pm

Re: Problem with palette discoloration when PPU is turned off during rendering.

Post by Fiskbit »

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.) [See edit]


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.
User avatar
Controllerhead
Posts: 314
Joined: Tue Nov 13, 2018 4:58 am
Location: $4016
Contact:

Re: Problem with palette discoloration when PPU is turned off during rendering.

Post by Controllerhead »

Fiskbit wrote: Tue Jun 08, 2021 1:20 pm It does sound like it's a previously-unknown
I've actually run across a similar issue, not sure if it's the same, but, when i was cutting off the bottom 16 scanlines with background and sprites off, bits of the palette would sometimes drop and change color slightly and intermittently. They always seemed to get darker, so, i assumed it was the palette DRAM running out of juice and the 1s becoming 0s ...Perhaps it was actually this issue though.

Anyway, rewriting the palette every frame does seem to alleviate the issue i had.
Image
User avatar
N·K
Posts: 15
Joined: Mon May 11, 2020 2:45 am
Location: Japan

Re: Problem with palette discoloration when PPU is turned off during rendering.

Post by N·K »

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.) [See edit]


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...
Attachments
palette_glitch_3.asm
(4.3 KiB) Downloaded 80 times
palette_glitch_3.nes
(24.02 KiB) Downloaded 80 times
Last edited by N·K on Wed Jun 09, 2021 3:26 am, edited 2 times in total.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Problem with palette discoloration when PPU is turned off during rendering.

Post by tokumaru »

Ouch, another hardware quirk? Disabling rendering mid-frame really is something that comes with a lot of warnings!
Drag
Posts: 1615
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: Problem with palette discoloration when PPU is turned off during rendering.

Post by Drag »

I have a front loading NES, and I'm running "palette_glitch_3.nes" on my PowerPak, but I cannot make the glitch happen. No matter how I scroll the screen, or how I adjust the split position, the palette doesn't glitch.
20210609_201546_sm.jpg
User avatar
Dwedit
Posts: 4922
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Problem with palette discoloration when PPU is turned off during rendering.

Post by Dwedit »

Maybe multiple bootups to get the right PPU/CPU sync?
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
User avatar
Quietust
Posts: 1918
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Problem with palette discoloration when PPU is turned off during rendering.

Post by Quietust »

I'd be interested to know what PPU revision is in N·K's AV Famicom - maybe this glitch does not affect the RP2C02G present in most front loading NES units?
Controllerhead wrote: Wed Jun 09, 2021 2:32 am I've actually run across a similar issue, not sure if it's the same, but, when i was cutting off the bottom 16 scanlines with background and sprites off, bits of the palette would sometimes drop and change color slightly and intermittently. They always seemed to get darker, so, i assumed it was the palette DRAM running out of juice and the 1s becoming 0s ...Perhaps it was actually this issue though.
The PPU's palette is stored in 6-transistor static RAM, so DRAM decay is out of the question.
The only thing I can think of is that the I/O controller might be able to enter an invalid state and cause corruption, similar to how Sprite RAM can get corrupted when changing the address at the wrong time.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
User avatar
N·K
Posts: 15
Joined: Mon May 11, 2020 2:45 am
Location: Japan

Re: Problem with palette discoloration when PPU is turned off during rendering.

Post by N·K »

Quietust wrote: Wed Jun 09, 2021 8:26 pm I'd be interested to know what PPU revision is in N·K's AV Famicom - maybe this glitch does not affect the RP2C02G present in most front loading NES units?
I don't have a screwdriver for the special screws used in AV Famicom, so I can't disassemble it ...
However, as far as I can tell from the following site (in Japanese), I think it is 2C02H (HVCN-CPU-02).
http://offgao.blog112.fc2.com/blog-entry-38.html

Edit : Mine was serial number HN10804140.
Last edited by N·K on Thu Jun 10, 2021 2:12 am, edited 1 time in total.
Drag
Posts: 1615
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: Problem with palette discoloration when PPU is turned off during rendering.

Post by Drag »

Dwedit wrote: Wed Jun 09, 2021 7:42 pm Maybe multiple bootups to get the right PPU/CPU sync?
I tried several resets and several power cycles, but I couldn't get the palette to glitch; the palette was stable the entire time no matter what I did on the controller.

Interestingly enough, this demo does a great job showing off the sprite DRAM corruption glitch. :D
Fiskbit
Posts: 890
Joined: Sat Nov 18, 2017 9:15 pm

Re: Problem with palette discoloration when PPU is turned off during rendering.

Post by Fiskbit »

Most AV Famicoms are rev H. Unless the serial number is fairly low, it should be H. What is the serial number?

Vectrex28 reports that he has seen this issue on his square button Famicom (A), frontloader (probably G), and round button Famicom (probably E or G).
Drag
Posts: 1615
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: Problem with palette discoloration when PPU is turned off during rendering.

Post by Drag »

For reference, mine is N29417844.
User avatar
Controllerhead
Posts: 314
Joined: Tue Nov 13, 2018 4:58 am
Location: $4016
Contact:

Re: Problem with palette discoloration when PPU is turned off during rendering.

Post by Controllerhead »

Quietust wrote: Wed Jun 09, 2021 8:26 pm The only thing I can think of is that the I/O controller might be able to enter an invalid state and cause corruption, similar to how Sprite RAM can get corrupted when changing the address at the wrong time.
That was also occurring so that would make sense. I have an NES-08 revision.
Image
Post Reply