nesdev.org

Are there any known differences in the NES RGB PPU when compared to PAL/NTSC PPU that would allow detecting it from software?

I have no way to confirm or deny, but it's possible that only NTSC and not RGB skips the last dot of the pre-render scanline every other frame. What test covers this?

Are you trying to adapt to the different tint bit behavior?

tepples wrote:Are you trying to adapt to the different tint bit behavior?

Or maybe it has something to do with the colors that are missinh in the RGB PPU.

tepples, good point, that could be indeed true.

I'm considering adding a different palette in my game for RGB PPUs, just for fun, and yes, also adapting the tint bit behavior if I end up using them. Of course it's always an option to add a menu option for this in case automatic detection isn't possible.

If somebody has a RGB modded NES and PowerPak, it would be interesting to see if some of the PPU tests fail that would normally pass on NTSC NES. But I can't remember if there's a specific test that tests for the presence of the missing dot.

The only test I know of that would "fail" on an RGB PPU is the "tv" test that abuses composite artifacts to display visible text on a composite PPU and checkerboard pixels on RGB. That's a visual-only test and I don't believe there's any way to programmatically detect this, short of the possible missing dot (which I guess would be testable via cycle counting across vblank).

So has anyone tried running Blargg's Even-Odd cycle test on a NES with an RGB PPU? If nobody has that hardware here, maybe check if anyone at NintendoAge has a modded NES and PowerPAK.
This would answer whether the one cycle thing still happens on that system. (or even a VS system)

Here are the blargg's test ROMs Dwedit is talking about:

http://thefox.aspekt.fi/even-odd.zip

I have a Playchoice, but I've loaned out my ROM burner. I'll see if I can try it out later this week (or weekend), if no one else gets it first.

Would also be cool too if one could detect the various VS Unisystem PPUs, and include an appropriate palette. I've heard that RBI Baseball does this, but of course selected manually with the mainboard's DIP switches. At least I suppose it can detect the swapped-around registers, if nothing else.

I suppose it could also be done with external hardware, like a photosensor to check for the missing $xD colors (which one is the bright grey on composite and black on RGB? $3D? Not sure myself). Fill the screen with that color, put the photosensor in front of the screen, and if it doesn't detect any light then it's a RGB PPU. You wouldn't need any more than a frame or two, I don't guess.

Make a black screen, turn on emphasis bit, and then read the zapper I guess is what the best option is for LocalH, but that's only good for zapper games.

I actually didn't think of the Zapper, and we know from Tepples' experimentation that it's not necessary to actually pull the Zapper trigger. Perhaps that could be used as an optional thing even in homebrew that doesn't otherwise use the Zapper?

Still, I think that testing for the missing dot is the best possible option, as if it is indeed true, there would be no need for external hardware of any sort. I was just thinking of a "last resort" type of option, in case there is truly no way to programmatically determine composite or RGB.

FYI, according to http://tasvideos.org/EmulatorResources/ ... Tests.html the composite PPU only passes the even/odd test 66% of time, and the even/odd timing test 25% of time. Something to keep in mind. I don't have my CF card reader with me right now so I can't verify that information.

akaviolence wrote:NES-101 with PC10 RGB PPU rom tests

Thanks a lot for testing! BUT: Would it be possible to make a new video where you run the same tests 10 or so times (by pressing reset), just to make sure. If tepples' theory is correct, it should fail every time (assuming nothing is wrong with the test itself).

Even if it fails all the time with the RGB PPU, doesn't the fact that it sometimes fails with the composite PPU invalidate this method of PPU detection?

I wonder if it would be possible to fix the test for this specific purpose... I guess that if you managed to sync with the PPU you could wait 6 or so frames and check whether the sync is lost due to the missing clocks.