PAL color palette emulation

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

r57shell
Posts: 9
Joined: Thu Jul 23, 2015 9:56 am

Re: PAL color palette emulation

Post by r57shell »

NewRisingSun wrote:I think he's asking about out-of-range R/G/B levels coming out of the color decoder after all automatic gain controls have been applied, which happens quite often in the NES since it does not start with R/G/B to begin with.
Yes, I'm talking about this.
NewRisingSun wrote:I cannot imagine any analog TV adding DC to the entire RGB tuple just because one of them goes negative, and all old TVs that I have seen certainly didn't.
How about not so old? in 1995 there was already tvs that had OSD for example.
Also, perhaps some circuits may clamp somewhere in matrixing, or I don't know.

Anyway. Here is what it looks like now:
https://imgur.com/a/pHnQn1D
Read descriptions.

Almost all colors has some clipping issue.

Yes, I was trying to reduce contrast until all clipping values will fit. In result I had 0.5 contrast (half).
NewRisingSun wrote:There is one partial PAL raw recording in this post. Partial because the capturing program is for NTSC only, and so still samples only for 1/60th time at 8*NTSC-Fsc.
I thought it has only mario inside. I would like to check normal PAL TV recording.

Regarding AGC. I wan't to know how I should exaclty scale voltages into IRE.
I don't think that decoder is forecaster of what white level is, without having white on screen.
So, it has to align voltages according to some rules without information about colors on picture.
At this moment I simply set color 1d to black = 0 IRE and white color 30 to 100 IRE.
Perhaps I should do this in other way. For example white is 120 IRE.

One additional note.
Consider decoded is R'G'B'.
Its theoretical luma is: 0.299R'+0.587G'+0.114B'
Now, assume R' is negative.
Then, clipped luma is 0.587G+0.114B, and it's greater than theoretical, because R is negative.
That's why I even started to think about this issue.
Similar consideration leads to darker clipped luma for colors which have component over 1.

I still don't get it though. Why we use linear transforms and equations for colors which are gamma precorrected.
As far as I understand, they have 1/2.2 gamma, and so you have to correct them to linear first.

Also, I was trying to assume that R'G'B' have 1/2.2 gamma, and then correct to RGB, and assuming that it is CIE RGB,
convert to XYZ, and then convert to sRGB. I got some trash in the end.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: PAL color palette emulation

Post by NewRisingSun »

Your picture's "simple clipping" looks exactly right to me. I'm not sure what kind of different colors you are expecting.
r57shell wrote:Regarding AGC. I wan't to know how I should exaclty scale voltages into IRE.]
There are two AGC methods used by TVs: adjust to sync, and adjust to burst. Adjust to sync is usually done for RF input, adjust to burst for baseband input. Adjust to sync means taking into account that sync tip to blanking is defined as 40 IRE, so measure and scale accordingly. (To be more precisely: since an RF signal is negative modulated, the sync tip will resemble the peak-to-peak amplitude.) Adjust to burst means that the color burst peak-to-peak amplitude is defined as 40 IRE, so measure and scale accordingly.
For the NES, adjusting gain according to sync will lead to a brighter than normalized picture, while adjusting to color burst will lead to a darker than normalized picture, "normalized" meaning you just define the NES' white level as 100 IRE (which is certainly not what any TV does, as the TV has no prior knowledge about what level is supposed to be "white").
r57shell wrote:How about not so old? in 1995 there was already tvs that had OSD for example.
Doesn't matter. Regardless of age, there is no reason for a TV to add a DC offset to all three R/G/B simultaneously just because one of them goes negative. Just clip negative to zero individually and be done with it.
r57shell wrote:I still don't get it though. Why we use linear transforms and equations for colors which are gamma precorrected. As far as I understand, they have 1/2.2 gamma, and so you have to correct them to linear first.
That might be correct in some abstract colorimetric sense, but NES/PAL systems are defined for gamma pre-corrected signals, not for some idealized signal, so transforming in linear space is wrong for those particular signals. (If you wanted to use abstract-idealized transformations, you would have to use different coefficients than 0.299/0.587/0.114 for current phosphor characteristics as well.)
r57shell wrote:I thought it has only mario inside. I would like to check normal PAL TV recording.
I cannot seem to find the raw file of that Trappatoni picture at the moment. Attached is the only other raw PAL capture from normal TV programming that I have left. If you want, I can get out my setup and take some additional pictures.
Attachments
OttoRehhagel.zip
(262.93 KiB) Downloaded 350 times
r57shell
Posts: 9
Joined: Thu Jul 23, 2015 9:56 am

Re: PAL color palette emulation

Post by r57shell »

NewRisingSun wrote:
r57shell wrote:I thought it has only mario inside. I would like to check normal PAL TV recording.
I cannot seem to find the raw file of that Trappatoni picture at the moment. Attached is the only other raw PAL capture from normal TV programming that I have left. If you want, I can get out my setup and take some additional pictures.
So, my decoder is sane. https://imgur.com/a/XmjZV17
This means, that actual PAL you have, has bars which can be emulated.
HardWareMan's dump has no such bars, or at least if the bars that it has, has same source, then they much less noticable.
I guess I need to find out how these bars made.

Edit:
r57shell wrote:Also, I was trying to assume that R'G'B' have 1/2.2 gamma, and then correct to RGB, and assuming that it is CIE RGB,
convert to XYZ, and then convert to sRGB. I got some trash in the end.
I've found my mistake with sRGB conversion.
I had 0.031308 instead of 0.0031308.
Now it's not trash on output anymore.
r57shell
Posts: 9
Joined: Thu Jul 23, 2015 9:56 am

Re: PAL color palette emulation

Post by r57shell »

Here is result of all my struggle.

https://gist.github.com/realmonster/b89 ... 1c42acf9e7
https://youtu.be/3f7UVUSlE0o

It's not final, but I hope I'll drop it for a long time.
Too much time spent into it. Need a break.
Possible addition for example: use different kernels instead of moving average.

Side note: crt-royale - not mine, all I do is applying it over mine result.
User avatar
Eugene.S
Posts: 317
Joined: Sat Apr 18, 2009 4:36 am
Location: UTC+3
Contact:

Re: PAL color palette emulation

Post by Eugene.S »

Links to this and this discussion topics.

Here are NEW hi-resolution OSC captures, including real RP2C07-0 PAL NES PPU:
2C07_CYUV_4555
2C07_Composite

6538_CYUV_4555
6538_Composite

Link to old capture is here.
User avatar
Eugene.S
Posts: 317
Joined: Sat Apr 18, 2009 4:36 am
Location: UTC+3
Contact:

Re: PAL color palette emulation

Post by Eugene.S »

I did some tests.
There are interesting observations about PAL aspect ratio of capture-cards (Dazzle DVC-100, Avermedia 305 PCI) vs Mesen/puNES vs CRT PAL TV.
Note that 240pee linearity test has automatic NTSC/PAL aspect adjustment, GITS2 doesn't.
Attachments
GITS2.png
240pee.png
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: PAL color palette emulation

Post by lidnariq »

Most SDTV capture cards sample at 13.5MHz, as per Rec. 601; at this speed, a PAL scanline is 703 out of 864 pixels long, an NTSC scanline is 704 out of 858 pixels long, and neither have a square pixel aspect ratio.

For square pixels, PAL should sample at 14.75MHz (also per Rec. 601) and NTSC at 12 3/11 MHz. This means that 13.5MHz PAL pixels are too narrow (and need to be stretched wider when on a display with square pixels) and 13.5MHz NTSC pixels are too wide (and need to be stretched taller when on a display with square pixels).

Tepples mentions these properties on the wiki: https://wiki.nesdev.com/w/index.php/Overscan
User avatar
Eugene.S
Posts: 317
Joined: Sat Apr 18, 2009 4:36 am
Location: UTC+3
Contact:

Re: PAL color palette emulation

Post by Eugene.S »

Fresh measurements of voltage levels.
RP2C02E/G, RP2C07-0, UA6528/6538
Info from HardWareMan

Please add these tables to the NesdevWiki:

https://www.nesdev.org/wiki/NTSC_video
https://www.nesdev.org/wiki/PAL_video

I guess RP2C07-0 and UA6538 info are necessary for wiki
RP2C07-0 and UA6538 have slightly different palette. This is noticeable on the capture cards and the real CRT
Attachments
VDAC.TXT
(2.96 KiB) Downloaded 37 times
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: PAL color palette emulation

Post by lidnariq »

Previous measurements of the PPU's output had an in-circuit voltage where sync tip wasn't 0 volts due to there being a subtle pull-up of 3kΩ through a PNP transistor. But these measurements were taken having removed that - hence why the sync voltage is measured as 0V and not 0.8ish V . And we know that the output impedance of the PPU is heavily a function of the specific tap that's been multiplexed in. So how certain are we removing the stock 3kΩ pullup doesn't significantly change the colors?

When I plot kevtris's old data ("Absolute" column in nesdevwiki:NTSC video § Initial measurement ; unknown PPU ) vs mine into a 75 ohm load ( nesdevwiki:NTSC video § Terminated measurement ; 2C02G ) I get very good linearity, R²=0.9994. But when I plot my direct measurements vs. the new ones not only is the R²=0.997 noticeably less awesome, but I see swings of ±5 IRE on almost half the measurements.
User avatar
HardWareMan
Posts: 209
Joined: Mon Jan 01, 2007 11:12 am

Re: PAL color palette emulation

Post by HardWareMan »

In fact, I measured the floating output, since the high-resistance input of the TCS7314 does not really affect the output of the PPU DAC. I will remind you how the DAC works:
Image
This is just resistor chain. And yes since the output resistance different on every level Lxx then outside pullup or pulldown will change the every voltage step with non linear rule. My measurements as floating output can be used to calculate the value of every Rx resistor and rebuild this chain in the math perspective. Then you can virtually load it with any pullup or pulldown and calculate factical result.

So, with this values as the base you can simulate any of exists video amplifier schematic.
User avatar
Jarhmander
Formerly ~J-@D!~
Posts: 569
Joined: Sun Mar 12, 2006 12:36 am
Location: Rive nord de Montréal

Re: PAL color palette emulation

Post by Jarhmander »

I remember the description of the output DAC as a resistor chain, but I never saw before a drawing with the color emphasis.

And BTW, welcome back! Long time no see!
((λ (x) (x x)) (λ (x) (x x)))
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: PAL color palette emulation

Post by lidnariq »

HardWareMan wrote: Tue Feb 28, 2023 11:27 pm My measurements as floating output can be used to calculate the value of every Rx resistor and rebuild this chain in the math perspective.
Only if we also have a response to a known external load. In isolation, we can only determine the ratio of the various resistors relative to each other.
User avatar
HardWareMan
Posts: 209
Joined: Mon Jan 01, 2007 11:12 am

Re: PAL color palette emulation

Post by HardWareMan »

lidnariq wrote: Wed Mar 01, 2023 12:06 pm Only if we also have a response to a known external load. In isolation, we can only determine the ratio of the various resistors relative to each other.
My measurements was done with 19k1 summary external load (as 9k1 and 10k to divide almost 1:2).
Image
Inside THS7314:
Image
Are you happy now?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: PAL color palette emulation

Post by lidnariq »

Which data is the no-load data and which data is the with-known-load data?
User avatar
HardWareMan
Posts: 209
Joined: Mon Jan 01, 2007 11:12 am

Re: PAL color palette emulation

Post by HardWareMan »

lidnariq wrote: Wed Mar 01, 2023 3:38 pm Which data is the no-load data and which data is the with-known-load data?
Image
Post Reply