Incorrect tint on Dendy

[Drag]

I was interested in seeing what causes that strange green-tint problem that the Dendy Chronicles host mentioned in Lion King and Aladdin. Obviously, I don't have a Dendy, and I only have the rom image for Lion King, but I had a hunch.

On the title screen, the game writes $3E to $2001. Of particular interest is the fact that the red emphasis bit is active...

Apparently, when this bit is active, the Dendy will apply a green tint to the screen, and the amount of tinting depends on the console; for some it's barely noticable, on others it's extremely obnoxious.

I imagine if we looked at Aladdin (from Super Game), we'd see the same thing.

Just what we need, more clone incompatibilities.

[Dwedit]

So between the RGB PPU and Dendy, are the color emphasis bits now at "don't use these"?

At least you can detect a Dendy easily.

[Drag]

So between the RGB PPU and Dendy, are the color emphasis bits now at "don't use these"?

I think you could still use them, it's not your problem if a clone implements a feature incorrectly. It's still better to be aware of the issue though, if your game is intolerable due to it, then you can release a special Dendy version of it.

[3gengames]

I didn't know Nintendos RGB was a clone. lol. Don't use them, subtract 10 and don't be lazy.

[Drag]

I didn't know Nintendos RGB was a clone. lol. Don't use them, subtract 10 and don't be lazy.

Insert a long, drawn out argument as to why one way isn't better than the other here.

The point is, the software is designed for canonical NES hardware. Non-canonical NES hardware is being used. Ergo, compatibility issues that aren't the fault of the designer. I could just as easily say "get a real NES and don't be lazy" right back at you.

[tokumaru]

Don't use them, subtract 10 and don't be lazy.

Not all uses of the emphasis bits can be substituted by "subtracting $10" of each color value. For example, the color emphasis bits are nice for making water of variable depth (such as in Noah's Ark), because these bits can be changed during rendering without problems, while modifying the palette mid-frame is near impossible without severe visual glitches.

[Jeroen]

I didn't know Nintendos RGB was a clone. lol. Don't use them, subtract 10 and don't be lazy.

Insert a long, drawn out argument as to why one way isn't better than the other here.

The point is, the software is designed for canonical NES hardware. Non-canonical NES hardware is being used. Ergo, compatibility issues that aren't the fault of the designer. I could just as easily say "get a real NES and don't be lazy" right back at you.

We might wanna split this if it goes on long enough.

But what about those of us that develop for famicom? There was at least 1 famicom (the famicom titler) that used an rgb ppu.

[tepples]

That and the Sharp TVs with a built-in Famicom. The box of Just Breed apparently has a warning that it won't work on Famicom TVs.

Split as requested.

[rainwarrior]

Ha ha, just looked at the Just Breed box. What it says is:

シャープのC-1ではご使用になれません.

(Don't use with Sharp C-1.)

[ccovell]

Famiclone systems have long been known to have overly-strong colour emphasis behaviour compared to the regular NES/Fami PPU. This means games like Bubble Bobble (FDS), Felix the Cat, Magician, etc. are sometimes a bit unclear and harder to play on clones.

[Shiru]

Felix the Cat suffered a lot on the Famiclones indeed, the brightness was much lower than in other games.

[Drag]

Famiclone systems have long been known to have overly-strong colour emphasis behaviour compared to the regular NES/Fami PPU. This means games like Bubble Bobble (FDS), Felix the Cat, Magician, etc. are sometimes a bit unclear and harder to play on clones.

On the RGB PPU, the games would be completely unplayable due to a completely white screen.

Though, this brings up another point of interest, lots of European-developed games will intentionally leave the palette darkened via the emphasis bits. This isn't just on the NES either, several European-developed SNES games have super dark palettes as well. Why is this? It must have something to do with the PAL standard or something...

[ccovell]

On the RGB PPU, the games would be completely unplayable due to a completely white screen.

Yes, very unfortunate. I can only speculate why Nintendo made PPUs that had features incompatible with each other. My guess, then, is that the original designers of the PPU (at Ricoh?) implemented the emphasis bits and 1) never explained their use in docs for programmers, or 2) told programmers they existed but NOT to use them in regular operation, or 3) told programmers, said "go wild", but then forgot about the emphasis bits when they had to go back and make an RGB version of the PPU. Or, 3) plus 4) since they apparently used a 6-bit DAC for rather lame colour decoding on RGB PPUs, the engineers at Ricoh couldn't be bothered to expend extra die space to implement proper mapping tables for the emphasis bits. (They could have at least had a "halfbrite" function per RGB channel at little additional cost and still keep it totally compatible with the composite PPU...)

Though, this brings up another point of interest, lots of European-developed games will intentionally leave the palette darkened via the emphasis bits. This isn't just on the NES either, several European-developed SNES games have super dark palettes as well. Why is this? It must have something to do with the PAL standard or something...

Again, just speculation, but most likely European programmers never used official Nintendo docs for NES programming. All of their knowledge was based on reverse-engineering (as RARE confirmed doing it this way). Most likely another programming house (probe, Eurocom...) reverse-engineered the PPU and made docs but thought that the emphasis bits were supposed always to be on.

As for the SNES, it probably just comes down to the highly-shaded, glossy European graphics look at the time. (Contrasted with the MS Paint look of US-developed games.)

[Shiru]

Neil Baldwin mentioned that they got a photocopy of original docs in Japanese (it is in the Magician section).

[tokumaru]

I seem to remember, back from the NESDEV mailing list days, Andrew Davie saying that all the knowledge he had when coding for the NES was obtained through reverse engineering.