Compatible RGB PPUs

Is it true that the only Nintendo PPU's that are candidates for an RGB mod for the NES/FC are the following:

RP2C03B
RC2C03B
RC2C03C

I've read places that RP2C04-000X will work if you combine it with "other circuitry", but no details are available. Can anyone speak to these 2 points definitively?

The 2C03s should be "compatible" with a normal NES, at least mostly; given that they don't have the extra grays at palette indices 0D/1D/2D/3D, some games might look wrong.
The 2C04s are not compatible because they have scrambled palettes.
The 2C05s are not compatible because registers $2000 and $2001 are reversed.

The "other circuitry" is a fairly simple-to-describe but obnoxious project: three 3-bit ADCs running at the pixel rate, three 3-bit DACs, and a 512×9b lookup table to convert the scrambled colors to the ones you want.

*bump*

rc2c05-04 works too using this schematic posted by baku:



The rgb amp isn't needed to get it working, I wound up using a sony cxa2075 circuit instead (the 2075 has a built in amp and generates the best s-video).

And yes the rc2c05-04 shares the same pallette as all the rgb chips:





To save people the effort of having to build extra circuitry I've been collecting rc2c05-04 ppus by making straight trades of them for rp2c03b / rc2c03bs. I now have three rc2c05-04 chips and I'm down to my last rp2c03b which I'll probably want to hold on to.

And hopefully it'll all be obsolete once devices that spy on a stock PPU to construct a higher quality video signal become widely available.

At which point you might as well be playing roms on your xbox using an emulator.

Or not. It's still using an original PPU and will be 100% compatible with anything that will ever be released for the NES, as where an emulator never will be as there will always be new hardware to implement.

It's a fpga ppu, it's not the real thing. Sure it's compatible, but so are emulators.

That'd be fine and dandy...if it was true, but it's not. TheFox specifically says it uses the original. You are wrong. Nobody is emulating anything, TheFox just reads the colors output somehow, and then Bunny probably processes the AV out and turns it in to HDMI out. Neither are changing the PPU chip with anything else. It's not an emulator. It will be accurate with everything, ever, as emulators will not be.

It's not an FPGA PPU, it doesn't render the content. It listens to what the real PPU is doing, either by listening to the EXT bus or oversampling the VIDEO_OUT signal, and transforming that back into RGB. There is no chance of rendering inaccuracies¹. It would do the right thing on reads of 2007 during rendering, and we didn't even have that behavior specified until 2⅔ years ago.

¹ Beyond those intrinsic to the colorspace transformation.

The image is generated by the fpga and not the ppu. Call it a fpga image generator if you wish. It's cool that you get absolute 100% compatibility that is really awesome.

The image is transcribed by the FPGA, it's generated by the PPU. Whatever it is, it's making the RGB mod useless and hopefully just utterly expensive, sorry.

That's totally inaccurate. If you draw the line at not using the normal PPU, any RGB PPU means you might as well use an xbox. The RGB PPU is not the correct device for running NES and Famicom games. Its colors are wrong. Certain colors are incompatible. Also certain games have art intended to be viewed as NTSC video and not RGB video as I recall. So it's pointless to get into some argument about this.

Devices that can reconstruct the video signal into a higher quality signal without the issues that come with NTSC Composite Video is a good thing. As others stated the functionality of the NES and from the point of view of the software running is identical to if you had no device attached to the PPU at all. Afterall, you're just spying to recreate the video signal. You aren't interfering with the operation of the system.

bunnyboy's HDMI NES is a separate endeavour, it's not based on my work.

As for accuracy/compatibility of these things, it depends.

1) A device that analyzes the composite signal would be 100% compatible and accurate.
2) A device like mine has to capture the palette, so if the program does something totally broken, it MIGHT be able to glitch out the palette in a way that wasn't expected (e.g. it might trash the registers while rendering is enabled, causing the palette to be corrupted in a way that depends on PPU's internal implementation, which is hard to duplicate exactly). It should be 100% compatible with anything that works "correctly", but maybe not with glitch demos.
3) More the device emulates, whatever it is, more the accuracy suffers.

I can't imagine any situation that would screw with generating the color waveform. Wouldn't the color it intends to draw be latched and fixed somewhere by the time it reaches that point? Even if there was some writes to 2007 or something messing with the palette, I don't think it would interrupt pixel generation.
Does changing color emphasis interrupt pixel generation?

Not pixel generation, but rogue writes might make FPGA's shadow palette out of sync with what NES has.

I never said it's a bad thing.

Okay, but to compare it to an emulator is very far off the mark.

Your comment seemed to imply that it was a bad thing. I think it's a cool way to improve video quality for those bothered by Composite Video particularly on Digital TVs. Though for me personally the stock original model NES works great for me.