nesdev.org

mikejmoffitt wrote:I am pretty sure that this is what I caused to happen, though. Here is a video of it happening by briefly touching a capacitor to a CPU pin

Yeah, I see no reason that most games would need to write to $2001 regularly, unless they're explicitly enabling/disabling rendering late/early, or using the tint bits.

mikejmoffitt wrote:If I find it, I have a video of a Famicom starting to act strange if I mash my palm on the underside of the PCB. It starts with the tint changing, the sync starting to waver, the jailbars becoming more pronounced, followed by usually a game crash, but occasionally just weird mis-writes that don't break it completely.

I'm still kind of awed that circuit bending ever works instead of just completely blowing up. Complex systems fail in complex ways, blah blah blah.

lidnariq wrote:

mikejmoffitt wrote:I am pretty sure that this is what I caused to happen, though. Here is a video of it happening by briefly touching a capacitor to a CPU pin

Yeah, I see no reason that most games would need to write to $2001 regularly, unless they're explicitly enabling/disabling rendering late/early, or using the tint bits.

mikejmoffitt wrote:If I find it, I have a video of a Famicom starting to act strange if I mash my palm on the underside of the PCB. It starts with the tint changing, the sync starting to waver, the jailbars becoming more pronounced, followed by usually a game crash, but occasionally just weird mis-writes that don't break it completely.

I'm still kind of awed that circuit bending ever works instead of just completely blowing up. Complex systems fail in complex ways, blah blah blah.

Isn't it incredible that at a singular point in time, the unplanned, uncoordinated haphazard mis-connection of data lines can cause such a specific action without ruining other things? I was already surprised that Mario got put behind the backdrop layer but the engine kept running without major complaints.

Not surprised about Mario being put behind the background actually, it seems like somehow the game is in its "finished level" state, and indeed Mario gets put behind the background when he goes inside the castle (while he keeps moving forwards - a solid block in the castle prevents him from advancing). Further proof of that is that the time is stopped.

lidnariq wrote:Yeah, I see no reason that most games would need to write to $2001 regularly, unless they're explicitly enabling/disabling rendering late/early, or using the tint bits.

You'd think that, but most games I've personally debugged write to $2001 every frame at least once. Sometimes games disable sprites in the area where the status bar is, which requires a $2001 write. But even if there's no apparent reason, a lot of games reconfigure the PPU every frame (i.e. they write to $2005, $2000 and $2001), maybe out of fear that using $2006/$2007 might screw things up (like is the case with scrolling), or maybe simply because their NMI handler is able to reconfigure the PPU every frame (i.e. it dumps values from RAM into the PPU registers, so that the program can just modify these variables if it wants to modify rendering parameters for the next frame).

tokumaru wrote:or maybe simply because their NMI handler is able to reconfigure the PPU every frame (i.e. it dumps values from RAM into the PPU registers, so that the program can just modify these variables if it wants to modify rendering parameters for the next frame).

I'd bet this is the most common reason for it, i.e. it's easier to just dump the "shadow" register to the PPU on NMI since writing to $2001 doesn't have any side effects. Writing to $2000 is (can be, depending on implementation) a different deal because it has side effects such as messing up the PPU address and generating an extra NMI if it's toggled without clearing the NMI flag by reading $2002 (and blindly reading $2002 in the NMI handler can be problematic on its own right if the main thread may be processing some PPU writes, because the $2002 read may happen to clear the address latch in the middle of two $2006 (PPU_ADDR) writes). But I digress...

Sik wrote:Not surprised about Mario being put behind the background actually, it seems like somehow the game is in its "finished level" state, and indeed Mario gets put behind the background when he goes inside the castle (while he keeps moving forwards - a solid block in the castle prevents him from advancing). Further proof of that is that the time is stopped.

Ah, that explains the controls not responding as well. That's less fun

I'm sorry, this might be the wrong place to ask this question, but I was wondering if anyone knew of a way to patch NES games to correct the colors for RGB modded systems. My personal opinion is that 90% of the time the colors look fine; Some may be different, but to my eyes look fine. The game that really bugs me is Zelda: The dirt in the background looks terrible to me. Also, Mario 1 and 3 look weird...it's not terrible, but it would be nice to set it back the way it was.

It would be cool if these patches already existed, but if not where's a good place for me to start looking? Thanks for your help.

Yes, you can modify a game's palettes. However, depending on the game and how those colors are determined it may be as simple as a single value change and as complicated as the disassembly and reassembly of some code that generates palette choices.

It is possible that the "correct colors" you want may not be available on the PC10 PPU, though you may find suitable replacements.