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.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. There's other reasons too.mikejmoffitt wrote:I don't see why we wouldn't want to map black to 0,0,0 and white to 255,255,255, though.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?
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).
RGB output from composite PPU
Moderator: Moderators
- mikejmoffitt
- Posts: 1353
- Joined: Sun May 27, 2012 8:43 pm
Re: RGB output from composite PPU
Re: RGB output from composite PPU
This is wrong.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.
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.
Re: RGB output from composite PPU
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)
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)
Re: RGB output from composite PPU
If you don't clip the values, the TV will. Does it matter where the clipping happens?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.
The only possible advantage would be working around TVs that can't be configured to accept full-range RGB.
- mikejmoffitt
- Posts: 1353
- Joined: Sun May 27, 2012 8:43 pm
Re: RGB output from composite PPU
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.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)
Re: RGB output from composite PPU
Yes, you're right...
- mikejmoffitt
- Posts: 1353
- Joined: Sun May 27, 2012 8:43 pm
Re: RGB output from composite PPU
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...
Re: RGB output from composite PPU
No, because different inputs clamp different ways and in different analog fashions.
Re: RGB output from composite PPU
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.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
Re: RGB output from composite PPU
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
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
Re: RGB output from composite PPU
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