Need help removing colour emphasis from roms

Just breed on the famicom turns out to use colour emphasis bits. I'm curious how difficult it is to remove that from the rom and what's involved. Since I'm using a rgb chip the game won't display graphics unless I remove that. Any help is greatly appreciated.

Set a memory write breakpoint on register $2001 (PPU mask). Then find out where the written value originated from (could be an LDA instruction right before the write, or something else). Then make changes to the ROM to ensure that the top 3 bits of that value are always 0 (the top 3 bits control the emphasis).

I'm new to the whole breakpoint thing. Is there some sort of guide out there on how to do something like this in (I assume) fceux? Or if you have the time could you please explain the process to a beginner like myself? If you're too busy that's totally fine I bet it's kind of a pain to explain this to a beginner.

You can do it with FCEUX or Nintendulator.

In FCEUX, press "Add" under Breakpoints, write 2001 as Address (you can leave the other field empty), tick "Write", then OK. Now the debugger will break every time the game writes to $2001. The instruction that writes to $2001 is usually STA, but could be STX or STY too (or in some obscure cases maybe something else). Then it's up to you to find out how that value got loaded to A (or X, or Y) register. Often it's just an LDA/LDX/LDY instruction somewhere before the STA/STX/STY.

In Nintendulator the process is very similar.

This game was easy, look for writes to 2001, and you see that every time it writes to 2001, it will also read address 0001 to see what the color emphasis bytes should be set to, and the game only ever sets the upper 3 bits of 0001 once.

original code:
1F:E0AE:A9 E8 LDA #$E8
1F:E0B0:85 01 STA $0001 = #$18
change to:
1F:E0AE:A9 08 LDA #$08
1F:E0B0:85 01 STA $0001 = #$18

address = E0AF, compare = E8, value = 08
Game genie code: AEXVYEEV
rom file address: 070EBF

You guys are the greatest! Thanks for taking the time to explain all this. Dwedit, I went to that hex address in the rom, what value(s) am I changing? Also how did you figure out the address in the rom file?

Looks like FCEUX's game genie encoder/decoder screwed up here, and 07E0BF is not the correct address.

*edit*

07E0BF, change from E8 to 08

Done, thanks people! Now the famicom version of just breed runs great in rgb.

In the fceux debugger I entered E0AE in PC and hit "seek to pc". The command there matched what dwedit says needs to be changed. Then I checked "rom offsets" and it lists where it is in the rom. I wish I knew before you can get the rom offeset in a debugger.

Also I'm curious, how do you know it only sets the upper 3 bits once?

I don't know if the upper bits will ever be changed, but it wasn't changing them after seeing the title screen and starting the game, so I think they shouldn't change after that. Didn't test battles though. If battles ever use any color-emphasis effects (don't know whether they use them or not), you might need to track down those too.

Also (unrelated), Final Fantasy I uses color emphasis bits for color effects when you enter/exit the menu, and before battles.

Gotcha. So the only way to know for sure is set nestopia to rgb mode and play the game and see if it ever loses picture.

Thanks again people! The english fanslated / rgb compatible roms running on a rgb system:



Looks and sounds excellent.

*bump*

Came across another game that needs this treatment. The megaman 4 minus infinity romhack the brightman stage (lightbulb dude) has colour emphasis on every part of the screen except a horizontal bar where megaman is. I'm looking to disable that if possible.

In the debugger the code I think is this:

"0FC288:99 00 20 STA $2000,Y @ $2001 = #$E8'

Except, I really don't know nes asm well enough to know how to change that e8 to 08.

Here's the link to the hack:

http://www.romhacking.net/hacks/910/

Version I have is probably newer but the fix should be the same if it gets worked out.

Just curious, do we have a database of games that use color emphasis? I've just never known if I am seeing it or not on a game; I don't think I've seen it enough to really know, aside from a time when screwing around with bare fingers on the famicom PCB caused the blue emphasis to kick in for Super Mario Bros...

Haha are you sure that's what happened?

Color emphasis makes everything look dark, like it's night time. The first scene in just breed when you're walking around the town at night time is color emphasis it's a perfect example. Try the megaman 4 minus infinity hack the brightman stage has both regular and colour emphasis modes displaying on the screen at the same time. With a composite ppu the emphasis parts of the screen look darker, with my rgb ppu they turn solid white.

Here's a lazy emulator snapshot demonstration. Composite ppu showing color emphasis:



How it looks on my system using a rgb ppu



Otherwise the game looks fine:

https://www.youtube.com/watch?v=JDPJCJValDs

A few romhacks like to "show off" and use funky ppu effects. If such a list gets made we should include romhacks as well.

RGB emphasis can be set separately for each of the components, so it's possible to end with a blue tint (I think there's a game that uses this to make translucent water).

But yeah, as far as I know that's a PPU register and not something that can be modified from outside (it should affect the signal the PPU itself generates), so messing with the PCB shouldn't cause emphasis to kick in. Probably something else screwed up.

Noah's Ark (E) is one game that does this.


Yeah it's unlikely, because even if a bit got corrupted during one PPU_MASK write, most games rewrite this register every frame so the setting wouldn't stay enabled for long.

When all 3 bits are used, yes. What happens is that on the composite PPU, these bits actually de-emphasize the other colors (i.e. blue emphasis actually darkens red and green to make the blue stand out), so when you set all 3 bits, all 3 colors are de-emphasized equally, making the image darker. On the RGB PPU however, the emphasis bits increase the color components all the way up (i.e. blue emphasis puts blue at the maximum value and doesn't affect the other components), so when you blow all of them up you get white.


From the top of my head, I can only think of Noah's Ark, which uses blue emphasis in combination with the grayscale bit to create the water effect. They could have used some sprites on the surface (like in the Sonic games - even the ones on the Master system & Game Gear, which have the same sprite limitations as the NES - but I'm sure you know that ) to make it look better though, that black line doesn't look anything like water.

The Game Gear also has a much narrower screen, for 40% overdraw instead of 25%.

Doesn't Chemical Plant Zone act 2 in Sonic 2 rewrite the palette for the parts under polluted water? The NES can't really do that.

Sure, but the same games are on the Master System (OK, not Triple Trouble - officially at least), which has a display as wide as the NES.


The great majority of water levels in Sonic games rewrite the palette. The one exception I can think of is the beginning of Hydrocity Act 1 in Sonic 3, because of the "water filling up the tunnel" gimmick. As for the 8-bit games, I'm fairly sure Sonic 1 and 2 on the SMS/GG also didn't rewrite palettes, but Chaos, Triple Trouble and Blast did.

Anyway, I was only questioning what Noah's Ark does for the surface of the water (black line?), what it does for the actual water is fine IMO (the grayscale bit makes the things look pretty bright though, but I understand that the blue emphasis alone without any sort of effect on the surface would have been too subtle), it doesn't need to rewrite the palette.

A very good question and point. No, we do not have such a "database" -- and I hate the use of that word in this context (would prefer "a list of games that use it") -- so I have created exactly that:

http://wiki.nesdev.com/w/index.php/Colo ... asis_games

I urge folks to update this with games they know use the bits, and to please add short descriptions where in-game they're used; if you aren't sure what to say/how to say it, use the Tricky-to-emulate games page as a guide.

I also added a link to this in the NES reference guide section, as appropriate.

You're missing at least Magician, Jungle Book and Lion King (I think both the official and pirate versions).

Didn't James Bond Jr. use all 3 bits like, the whole time just to darken the entire screen?

I'm not missing anything -- it's a wiki, which is why I urged folks to update it. :D

Didn't realize that account creation was enabled again on the wiki.

No way these $2001 writes could be filtered with some added hardware so that the top 3 bits were never set? D7 to PPU = D7 from CPU AND (address lines to PPU aren't 001)?

A device similar to a Game Genie? I guess it could work...

That would be a cool device if it's not a pain to make. For now I'm content with romhacking. Yesterday I mentioned this to spikeman and handed him my progress. Spikeman went into turbo spikeman mode and fixed the brightman stage. According to the original author of this hack dr cossack stage 3 lower route also has color emphasis which it does in a playthrough video I found. I'm unsure if our current fix also fixed cossack stage 3 I'm waiting for someone to play to that stage in fceux and make a savestate we can use for debugging.

If you're willing to rely on bus conflicts, sure!

Use a 74'238 (active high one-of-eight selector) and 74'03 (open collector quad NAND) to make this:

M2 → 238.+G1
A15 → 238./G2A
A14 → 238./G2B
A2 → 238.C
A1 → 238.B
A13 NAND A0 → 238.A (use pull-up resistor)
238./Y0 NAND self → D7
238./Y0 NAND self → D6
238./Y0 NAND self → D5

After using spikeman romhacking + game genie codes I got to the spot in cossack stage 3 with color emphasis. I sent spikeman the savestate, he found the data, and it's changed. I wound up changing the rising / falling water from emphasis to grayscale. In the brightman stage the areas that you can't see are also changed from emphasis to grayscale. I burned the rom, plugged it into my mmc5 devcart, runs great on my rgb twin. I think this is done unless we find another part of the game that uses color emphasis. The author of this romhack only mentioned these two stages.

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(You can see it kick in at 0:33 right before the game crashes). 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.

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.

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.

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).

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...

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.