CHR corruption

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
CHR corruption
by on (#54687)
Just wanted to check something before I start investigating the reason I'm getting the odd bit of CHR corruption. I'm pretty sure it's because I'm sometimes doing too much writing of VRAM in a single frame but weirdly it never occurs in Nestopia, only on actual hardware (Famicom AV + PowerPak).

It manifests itself by corrupting a few CHR tiles. Reducing the amount of writes to $2006/$2007 during vblank stops it from happening but I want to be sure that it's simply a case of me writing too much or there's something else going on too, a possible side effect maybe.

I'm just confused how the CHR ROM appears to get corrupted which would seem to suggest it's peculiar to PowerPak somehow? That may very well be a pretty dumb thing to suggest, I don't know much about hardware intricacies.

by on (#54688)
Sounds less like "CHR ROM corruption" and more like the PPU doing something "unexpected" as a result of doing too much in a single frame (single NMI/interrupt). You might have to resort to cycle counting to see how much time your NMI routine takes up...

by on (#54691)
The strange thing is, it's not constantly corrupting stuff, it just seems to affect a couple-or-three characters on screen (but the actual CHR definitions for them so, say, all the letter "C"s will have a line through the middle for example). Resetting the NES doesn't seem to cure it either - I have to switch it off and back on again.

The other problem is that I can't replicate it in Nestopia so it's not something that is easily traceable. Yes, I can force my screen updating routines to do too much and that will be visible in Nestopia but the glitch manifests itself differently so I don't even know if it's the same problem on hardware Vs Nestopia.

by on (#54693)
Do you see the same problem in Nintendulator? I've found that the PPU accuracy of Nintendulator is significantly improved compared to Nestopia.

by on (#54694)
This happens all the time to me and is due to the crappy connector not making good connexion on some of the CHR adress lines I think. Re-insert your cart in the NES and reset until it gets cured (it usually takes a LOT of tries to get proper image, and sometimes even corrupt while playing - which is why I mostly play NES games emulated).

by on (#54714)
Is the CHR-ROM write-protected on the PowerPak? If it's not, that would cause the effect you're seeing. But at the same time, the bad writes can end up in the nametables, attributes, and possibly the palette.

Yeah could be a bad cart connection too, but that's less likely on a Famicom and easy to rule out.

by on (#54721)
Memblers wrote:
Yeah could be a bad cart connection too, but that's less likely on a Famicom and easy to rule out.

Couldn't the fact that the PowerPak has to go through an adapter in order to work on a Famicom make things worse?

I know I very often get corrupt tiles with the PowerPak on my NES. It usually takes a few tries to get it working right.

by on (#54731)
tokumaru wrote:
Memblers wrote:
Yeah could be a bad cart connection too, but that's less likely on a Famicom and easy to rule out.

Couldn't the fact that the PowerPak has to go through an adapter in order to work on a Famicom make things worse?


If the adapter works, it shouldn't. At least in my experience with a Game Genie, my friends and I used one all the time because it made the games work better. But that was a bad connector issue. But if the PowerPak has some kind of bus control issue, I have no idea. I heard it doesn't work on some Famiclones, and no one knows why.

by on (#54741)
I'm pretty sure it's not a bad connection issue. Most of the time it works fine - as I say: "cured" by not trying to print so much in one frame.

I've optimised my two big buffer updating routines as combined they were taking up about 7/8ths of the screen! I'll do some more testing.