RGB output from composite PPU

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

User avatar
mikejmoffitt
Posts: 1353
Joined: Sun May 27, 2012 8:43 pm

Re: RGB output from composite PPU

Post by mikejmoffitt »

yxkalle wrote:
mikejmoffitt wrote:
yxkalle wrote: And now when I think of it, isn't black supposed to be at RGB(16, 16, 16) and white at RGB(235, 235, 235) on a TV?
I don't see why we wouldn't want to map black to 0,0,0 and white to 255,255,255, though.
Because a well calibrated TV can't show colors darker than #101010 or lighter than #EBEBEB so you won't see any difference between red, green and blue or red, green and blue. There's other reasons too.

Modern TV's and computer monitors on the other hand can use the whole range and often have a higher bit depth too. (i.e. if you can't tell the difference of colors in the words above your screen is not correctly calibrated (or maybe you're color blind, sorry about that).
I can differentiate those colors. What I don't understand is how a television that is unable to display this difference isn't poorly calibrated.
Joe
Posts: 650
Joined: Mon Apr 01, 2013 11:17 pm

Re: RGB output from composite PPU

Post by Joe »

yxkalle wrote:Because a well calibrated TV can't show colors darker than #101010 or lighter than #EBEBEB so you won't see any difference between red, green and blue or red, green and blue.
This is wrong.

A properly calibrated TV will be set to accept the signal with the correct levels. Digital RGB signals can either be full-range (0,0,0 is black and 255,255,255 is white) or limited-range (16,16,16 and lower is black, 235,235,235 and higher is white). The HDMI specification requires RGB formats in typical TV resolutions to be limited-range, but computers typically produce full-range. That discrepancy causes exactly the symptoms you've described.

Your examples are flawed because, on a properly-calibrated setup, those values would be converted from full-range RGB (which is the representation used in HTML/CSS/whatever) to the nearest corresponding value in the output colorspace. If you've properly set up limited-range RGB, your full-range #101010 will be converted to approximately #1E1E1E and therefore still be visibly lighter than black.
User avatar
yxkalle
Posts: 62
Joined: Sun Jan 27, 2013 7:30 pm

Re: RGB output from composite PPU

Post by yxkalle »

The main reason I want to use [16..235] is to reduce the clipping caused when we converts YIQ to RGB. Even though you set black at 16,16,16 and white at 235,235,235 you can still allow a single color channel to go above 235 or below 16. Don't get me wrong, the picture quality out of this thing is pretty amazing just as it is, I just hope that Evil Tim eventually makes this open source so everybody with a JTAG programmer and some VHDL know-hows can customize palettes and add other functionality to their NESRGB's.

In the end it's impossible to get 100% accurate colors as some of the colors generated by an unmodified NES is outside of the ordinary RGB color space. (as I showed in an earlier post in this thread)
Joe
Posts: 650
Joined: Mon Apr 01, 2013 11:17 pm

Re: RGB output from composite PPU

Post by Joe »

yxkalle wrote:The main reason I want to use [16..235] is to reduce the clipping caused when we converts YIQ to RGB. Even though you set black at 16,16,16 and white at 235,235,235 you can still allow a single color channel to go above 235 or below 16.
If you don't clip the values, the TV will. Does it matter where the clipping happens?

The only possible advantage would be working around TVs that can't be configured to accept full-range RGB.
User avatar
mikejmoffitt
Posts: 1353
Joined: Sun May 27, 2012 8:43 pm

Re: RGB output from composite PPU

Post by mikejmoffitt »

yxkalle wrote: In the end it's impossible to get 100% accurate colors as some of the colors generated by an unmodified NES is outside of the ordinary RGB color space. (as I showed in an earlier post in this thread)
So, we say that, but consider that almost every color television ever made ends up displaying in the RGB color space, be it through subpixels on a digital display or as separate phosphor struck by an electron gun in a tube.
User avatar
yxkalle
Posts: 62
Joined: Sun Jan 27, 2013 7:30 pm

Re: RGB output from composite PPU

Post by yxkalle »

Yes, you're right... :roll:
User avatar
mikejmoffitt
Posts: 1353
Joined: Sun May 27, 2012 8:43 pm

Re: RGB output from composite PPU

Post by mikejmoffitt »

My point is if you can see it on the screen, no matter which connection delivered it, then it can surely be represented in an RGB signal...
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: RGB output from composite PPU

Post by lidnariq »

No, because different inputs clamp different ways and in different analog fashions.
User avatar
Drakon
Posts: 183
Joined: Mon Aug 16, 2010 4:48 am
Contact:

Re: RGB output from composite PPU

Post by Drakon »

hyarion wrote:Nice Drakon! But why do you use hot glue on that cable (by the contact)? Wouldn't it be better to use heat shrink tubing instead?
You can buy it dirty cheap at: http://dx.com/p/1m-black-heat-shrink-tu ... -5mm-23450
Thanks for the tip. This is a personal system I built years ago. The connector was already wired up and it works great anyway. I don't see the harm in using hot glue on a connector that's not even making contact with the pcb or the console case.
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: RGB output from composite PPU

Post by aquasnake »

Replace the bg/spr palette with black(0x0f)/white(0x30) respectively, gate at the PPU address $3f00-$3f1f (including its mirror addresses) and put it on the PPU data bus.

The CVBS generated by NES is synchronously decoded to separate the composite sync signal, compare the level during the visible scanline and output high /low level, take this as bit 4 of ext lines.

Ext [4:0] as the index, look up the external palette table (stored in the additionnal flash ROM) to obtain the RGB value. Then 3 groups of digital rgb are converted into analog level signals through DAC. The output RGB value can be rgb444 and the storage table is an rgb888 format
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: RGB output from composite PPU

Post by aquasnake »

lidnariq wrote: Mon Jun 03, 2013 1:29 pm So, here's a list, with "CPU side interceptions" first:
[*]Mask top 8/16 scanlines to conceal pop-on; mask right 8 columns to add symmetry to $2001.
Based on the idea of minimum cost, only shield pixels without any resolution improvement, and 8 pixels on the left and right can be shielded

When hsync is detected, the pixel_clk_cnt is initialized, set to 255. In every falling edge of pixel_clk, count accumulation (pixel_clk = 1 / 4 or 1 / 5 sys_clk)

Pixels can be shielded between [0,7]. Similarly, so does the right pixels of [247, 255].

The parity field signal can be obtained by vblank detection, and the scan line counter can be obtained by hsync detection. In this way, we can achieve the effect of pseudo interlaced 240i, which is, shielding a scan line, but the synchronization signal is still 240p timing
Post Reply