nesdev.com

EDIT: I found out Indiana Jones and the Last Crusade (Ubisoft version) uses #$0D too. However, I think the developers found out about the particularity of that colour with Jimmy Connors Tennis, which uses $0F and therefore runs fine on my TV

I wanted to play some Bee 52 the other day, and it turns out the picture gets distorted on my new TV... Then I popped in some other Camerica games and they have the same problem. Dizzy even screws up the scrolling.

Having done some research, I came to the conclusion that Dizzy uses the evil, evil $0D colour that can screw things up and that some Camerica games read the $2004 register, which makes those games not work on some older NES revisions. My older TV ran the Camerica games fine though. Any idea why Camerica games don't work well with my TV? Do other Camerica games use $0D? Do you have the same problems?

Do you have a flash cart, such as PowerPak or EverDrive-N8? If so, can you make the PLUGE test in 240p test suite 0.03 cause a similar loss of sync on this TV?

I wonder if playing with the "brightness" control might help it see the sync better.

I don't have a flashcart, even though I always think of getting one :/
Maybe there are other folks with trinitrons that could help.

I have a Sony KV-13FS100 (13" Trinitron) that I use solely for consoles. I also have a PowerPak, and a top-loader NES as well as front-loader NES.

I'm willing to try out some of the Camerica games to confirm/deny aforementioned claims, but is there any chance of this being something that only happens with an actual legit cart vs. being run via a PowerPak? (Rephrased: OP has carts, I do not, thus I am not sure if the test would be valid)

Also: I'm making a blind assumption that the OP is in Switzerland (PAL), so could this be some PAL vs. NTSC oddity? I obviously can't test PAL stuff.

I think it's quite obviously caused by use of $0D. You can easily check if games use $0D in emulators' palette viewers. (And yes, Fantastic Adventures of Dizzy does use it, as do many other Codemasters/Camerica games like Micro Machines.)

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi

What is the point in using color $0D?

Camerica reverse engineered the NES themselves, so they didn't have anybody to tell them it was forbidden.

Maybe in their tests, they found it was the darkest output, so they presumed it was supposed to be used for black.

It doesn't mess up all TVs, just some, so I could see them not noticing the problem. I wonder if PAL TVs are less susceptible to this problem too?

A lot of people think it's just regular black. I don't blame them, if I hadn't been told that $0D caused problems, I would have assumed it was the correct black to use, considering that the last 2 columns of the palette ($xE and $xF) look like a bunch of nothing, while column $xD actually has some grays in it. AFAIK, Camerica was not a licensed developer, so they most likely didn't have access to the official documentation, and based on reverse engineering they couldn't have guessed that there was something special about color $0D.

That and perhaps Codemasters' QA department didn't have quite as large of a sample of TVs. For example, the Magnavox TV that I most commonly use for NES doesn't noticeably puke on the $0D through composite or RF. I tried 240p test suite (on PowerPak) and Bee 52 (authentic cart), and neither of them artifacted out the way the screenshot above does. Even emphasized $0D didn't confuse it.

Bee 52's title theme is Sunsoft-tastic, no?

Plus what I've read from interviews with actual licensed developers there was no complete English documentation for a while so learning to develop for it was a pain if they didn't understand Japanese.

If the screen is shaking heavily it could be because it's reading $2004 (but if it worked on you other TV I guess that's not the case). My Famicom is too old for Camerica games anyway.

So I guess the only reason $0D was used was on accident... Well, you know, I wonder how well it would work as an effect in the game, like if the character got shocked, all the regular blacks would turn to $0D for a split second like how many SNES games used the mosaic effect. Of course, this wouldn't work on all TVs though.

I had believed all the Codemasters games use color $0D, at least the ones I had looked at, including the Game Genie. Just now I checked on the recently-released Wonderland Dizzy, and it actually uses color $0E. So it seems they did switch over to a different black at some point.

At wonderlanddizzy.com, "The Story of the Discovery" YouTube video explains:

(2:45) The disk the Oliver twins found had the source code but no final ROM image. They contacted yolkfolk.com owner Andrew Joseph who connected them with Lucas Kur (Denine here on forums.nesdev.com and Dizzy9 in some other places). Lucas was able to compile the source into a ROM image.

(6:10) Lucas asked if he could add Polish into the game. The Oliver twins agreed and also suggested he add other languages, an infinite lives mode, and credits saying thanks to Lucas Kur and Andrew Joseph.

Perhaps Lucas also updated color $0D to $0E while he was making changes.

Edit: I was curious so I just sent Denine a private message asking about it.

Edit 2: Denine says he didn't change it, the code he received already used the $0E color.

Looks like that dizzy game needs a sound fix, just like Dizzy the Adventurer.

More specifically, it has the same bug as Dizzy the Adventurer where it resets the phase of the square channels every frame. This is due to unconditional writes to 0x4003 and 0x4007, and results in an annoying 60hz buzzing noise.
I'd normally make a patch myself, but no point in doing this if someone has the source code and can just change these things easily.

How to fix the bug:
Make a variable somewhere that would be the same as what the sound register at 0x4003 or 0x4007 contained on the last write. When you write to 0x4003 or 0x4007, check if the value is different that the last value written. If it is not different, don't do the write, otherwise do the write and store the last written variable.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

You could have two different notes that have the same 4003/4007 writes. Shouldn't you also check 4002/4006 (the low bits of the frequency)?
...
No, then you might have several notes of the same frequency in a row, and they won't get retriggered. Hmm.

_________________
nesdoug.com -- blog/tutorial on programming for the NES