PAL color palette emulation
Page 5 of 6

Author:  Eugene.S [ Sun Jun 19, 2016 11:22 am ]
Post subject:  Re: PAL color palette emulation

Here is new PAL info from HardWareMan:
nesdev wiki updated:

Author:  HardWareMan [ Mon Jun 20, 2016 5:17 am ]
Post subject:  Re: PAL color palette emulation

I'm trying rebuild CVBS using PPU rules. For now it first approach to NTSC. I use 9 levels DAC (8 bit R-2R DAC with 9 different level values) and CPLD.
I set phase 8 as color burst (according this) and get this:
As you can see, red and green is swapped. And I don't know why. All phases are correct - I tested it with logic analyzer. Any thoughts?

I guess I know... Need to check it out.

Author:  tepples [ Mon Jun 20, 2016 7:59 am ]
Post subject:  Re: PAL color palette emulation

If only columns 2 (+U) and 8 (-U) have the correct hue, try generating the phases backward. You'll need to add a feature to control the direction of the phases when you add PAL anyway.

Author:  HardWareMan [ Mon Jun 20, 2016 8:00 pm ]
Post subject:  Re: PAL color palette emulation

NTSC method was approved and replicated. Now it is time for PAL.

Author:  Eugene.S [ Fri Sep 30, 2016 10:44 am ]
Post subject:  Re: PAL color palette emulation

I'm confused about PAL aspect ratio:
Image Image

Why it looks so wide on emulators, is this overscan problem?

Here is captures of Dazzle DVC-100 and emulators (with overscan disabled)
Gits2, tvpassfail, linearity (240pee), and SMB title screen

Author:  feos [ Fri Sep 30, 2016 10:58 am ]
Post subject:  Re: PAL color palette emulation

That circle is worng, but the squares from the other test are correct. Obvious mismatch of what test roms are trying to test.

Author:  lidnariq [ Fri Sep 30, 2016 11:18 am ]
Post subject:  Re: PAL color palette emulation

TV tuners that capture a 720x576 image on PAL don't represent "true" square pixels.

BT.601 says that both NTSC and PAL content can be captured at 13.5MHz. At this rate, the sampled pixels on NTSC are slightly narrow (10:11 PAR, i.e. when displayed on a computer monitor with square pixels it'll look too wide), and the sampled pixels on PAL are slightly wide (59:54, roughly 12:11, i.e. when displayed on a computer monitor with square pixels it'll look too narrow).

Given BT.470 (which says the PAL pixels are "square" at a sample rate of 14.75MHz), the PAL NES PAR should be ≈1.4, and the PAL NES DAR should be ≈1.5.

Author:  tepples [ Fri Sep 30, 2016 4:12 pm ]
Post subject:  Re: PAL color palette emulation

Specifically, to convert PAL video captured at 13.5 MHz to square pixels, you need to crop it to 703x576 and then stretch it to 768x576. (For NTSC, crop to 704x480 then shrink to 640x480.) The 720 pixels include a small amount of signal before (to the left of) and after (to the right of) the 4:3 frame, the "nominal analog blanking", to let the signal be recentered later for playback.

Author:  HardWareMan [ Fri Sep 30, 2016 8:59 pm ]
Post subject:  Re: PAL color palette emulation

Analog TV has no any horizontal "pixels", only vertical by scanline count. There is only high frequency limit, that will describe how smallest object can be shown (video clarity). For 576i it is ~5,5MHz for BW only luma and <4MHz with PAL color encoding. For 480i as far I know it will be ~5MHz for BW and <3MHz with NTSC color encoding.

So, for BW 576i in 48us active time can be shown 48/(1/5,5)=264 elements which equvivalent 528 pixels. And it will be signifant less with PAL encoding. But there one importing thing: it is not alligned to any time slot. CRT has "pixels" as luminophore, but they much smaller than signal can pass. Especially for BW CRTs, they "pixels" so small that only beam focus is matters.

Oversampling in digital TVs and TV tuners at 13,5MHz or higher is matters only for color subcarrier capture, otherwise it can't be able to restore right colors. But it produce higher "resolution" for analog signal: 48/(1/13,5)=648 elements or 1296 "pixels".

48us active time in scanline is useful area, with "overscan", which is obiously not exists, it all about how TVs can support TV standard. Early TVs without raster stabilizer and curve CRT edges cropped active time to have some reserve. Latest CRT TVs is so modern, so they can reach this time almost without any artefacts. I remeber one commercial at late 90's about japan TV which allow to see "hidden" parts of picture. With modern digital LCD TVs it is all senseless. But still supported by manufacturer.

So, quite long post. In conclusion, PAL Dendy (famiclone) and seems like PAL NES to can't have square pixels. I clearly remeber that by this scene from Bucky O'Hare:
On my 4:3 61cm TV it was vertically shrunk and horizontally stretched. At that time (early 90s) I worked at repair shop and was able to fine adjust of my TV. It almost hasn't any overscan (raster stabilizer was able to hold size within 2..3mm swing for 61cm size).

Beside, not 256x224 nor 256x240 can't have square pixels on 4:3 TV (and 16:9 especially). I know that because I participated in BreakNES project. PPU has 341 pixels in whole scanline (with blanking and sync). And only 256 is video. So, only 341-256=85 left for HSync and HBlank. And within 64us scanline for PAL, 16us (4+4+8) is for HSync and HBlank. Now, watch the hands:
That why PPU crop some pixels at left and right.

Author:  r57shell [ Wed Apr 11, 2018 4:01 am ]
Post subject:  Re: PAL color palette emulation

HardWareMan wrote:
Ok. Here two records, converted to B/W picture (warning: huge sizes).
500MHz sample rate

Here is my decodes:
(OLD BUGGED: U&V swaped at the same time R,B swapped in saving routine causing error to be hidden)
bug was found while checking magnitudes of UV for same luma of decoded output.

Decode done in basic mode. Simple Low pass approach, and sync with burst for fixed pixel range.
Burst frequency assumed to be: 4.43361875 MHz.
Pixel frequency assumed to be: 500 MHz

Formula used to convert RGB from png into IRE:
thus, 0 IRE is 0x33 byte. From high level of burst (20 IRE) to sync level (-40 IRE), considered to be 0x5D,
so delta in 60 IRE = 0x5D delta in png.

composite: N - signal in png; luma: Y = lowpass(N); chroma is detected by lowpass of multiplication (without pre-highpass of N).
svideo: same as composite but Y = N (no lowpass).
comb filter: hue averaging for adjacent lines.
hue rotation correction: after digging into "why hue slightly differ for adjacent lines", it was detected effect discussed below. This is correction provided below.

HUE artifacts.

In provided dump there is some HUE artifacts.
According to what we know about internals of PPU, there are 12 different phases, with 30 degrees step.
and subcarrier is generated by alternating of HIGH and LOW for selected luma.
this means, that HUE can't drift from 30 degrees step...
but in signal there is drift less than 30 degrees, it means that there is analog stuff which make phase drift.

after some investigation (took for me two days of headache), it was determined that most of drift is caused by luma levels.
luma 0 is considered as "without drift", then
luma 1 has drift ~3.8 degrees
luma 2 has drift ~3.8*2 degrees
luma 3 has drift ~3.8*3 degrees
and drift changes sign by each line, similarly to phase alternation of PAL.
this means, that probably it's so called phase delay.
but for linear filters, we use bode plot to show phase delay, but in bode plot phase delay depends on frequency.
here is different case, it depends on voltage, either highest voltage, or average voltage.
Because luma 3 has tiny amplitude, similar to luma 0. If drift would depend on amplitude of oscilation,
it would be similar drift for luma 3 and for luma 0, but NOPE. Luma 3 has biggest drift.

All degrees here is phase of oscilation in signal. In other words, it's angle in axis V*0.877 and U*0.493.
Even though I call it "HUE rotation", it's in V*0.877 U*0.493 space, phases of oscilation.
My correction has a bit more precise values, it uses table:
0 0
0.0651628589 0.065681
0.1157002756 0.11697625
0.2222102756 0.2225894167

in radians. even odd rows, luma 0..3.

There is also other kind of hue drift, that's why "best" correction result still has some hue artifacts.
By "best" correction I mean: composite+hue rotation correction+comb filter.

Here is table for those who interested in investigation hue effects.
amplitude: half of amplitude of oscilation.
phase: in radians from burst, without any fix for even/odd lines.
same here, radians is phase of oscilation in signal. In other words, it's angle in axis V*0.877 and U*0.493.
middle: middle value.
amplitude & middle is in IRE/100 units. i.e. 100 is 1.0
btw, burst half amplitude is 0.105919 0.107037 (even, odd)
and burst middle level is 0.077083 0.072939 (even, odd)

table has 16*4 rows. to understand what single row mean...
there is 8x8 cells on screen. almost all has colors in it, except 8 cells in second half of screen.
16*4 rows is all cells including "empty ones"
first 16 is all colors of luma 0, i.e. full first row from left to right, and then full fifth row from left to right.
and so on, for all 4 lumas.

Any ideas from where HUE drift based on voltage may come from?

Also, it's considered that PPU has rectangle output. But here it's more like to have more sinus-like output than rectangle.
"Best fit" distorted sine that I come with, is this:
Any consideration why this form also would be nice.
This form of signal doesn't affect angle of U*0.493 V*0.877, it is only changing its magnitude, and leak a bit into Y.
So, this form of signal doesn't rotate HUE.

table.csv [3.52 KiB]
Downloaded 31 times

Author:  NewRisingSun [ Wed Apr 11, 2018 8:36 am ]
Post subject:  Re: PAL color palette emulation

Regarding hue artifacts in NTSC and PAL NES consoles, in case you have not already done so, please have a look at my posts from 2017 in this thread on this issue.

Author:  r57shell [ Fri Apr 20, 2018 8:06 am ]
Post subject:  Re: PAL color palette emulation

Thanks for link.
Do you have RAW recoriding of some PAL TV signal? I want to check sanity of my decoder.

Question to everyone.
Does someone knows how old TVs (1995 and below) handle out of range RGB values?
It means negative ones and over 1 ones.
Because as far as I understand my results only differs where I get out of range values.

So, I have found one old post: ... 10#p117000
NewRisingSun wrote:
You can either just clip at 0 and 255, or reduce saturation for that color until none clip.

Clip - was by default. Bad result.
Reduce saturation - tried, it makes colors greyish too much.
Best result so far is my dirty hack. But it's stupid. Old TV should not use my dirty hacks :lol:

Also, can you explain in details alignment of levels by TV: black and white.
I thought scale is fixed by voltage, but looks like I'm wrong. I thought 1 V is always 100 IRE.

Author:  HardWareMan [ Fri Apr 20, 2018 11:45 pm ]
Post subject:  Re: PAL color palette emulation

None. TVs recover black level from front porch. Where color burst placed. Manipulating with this level was a copy protection at that years. And that's why "darker than black" color a present: Luma0 is lower than black level. On CRT TV you can see that luma level only if add some brightness. Black level recover happen in color module, in luma path where brightness adjust happen. Brightness is simple difference from recovered black level.

About white level. TV always trying to stabilize input signal twice: in radio demodulator and at luma path in color module by AGC (Automatic Gain Control). If you use RCA connection only second one used. In luma path, where contrast adjustment happen, because contrast is a difference white level from black level. In addition, contrast adjust also R-Y/B-Y signals to compensate color distortion and overflow in RGB recover. It is not math overflow, it is level limit.

About saturation. Saturation is gain control of signal from color decoder (R-Y/B-Y). This signals are with sign. The have positive and negative values and 0 is mean a BW. Of course TV does not use negative voltage, because it is a complicated things, so they shift to some level to handle gain (some DC added). Then, R-Y and B-Y mixed up with resistor matrix to recover G-Y. And then, full bundle of signal are added to luma.

Author:  NewRisingSun [ Sat Apr 21, 2018 12:05 am ]
Post subject:  Re: PAL color palette emulation

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.

I cannot see how negative R/G/B levels coming from the color decoder (and after applying contrast, i.e. gain, and brightness, i.e. bias) would not just be effectively clipped (or "limited") to zero, because you cannot excite a phosphor to produce negative light. 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.

On the other end, assuming that the R/G/B levels coming from the color decoder directly drive the beam on an analogue CRT TV, then values above R/G/B 1.0 would just make the picture brighter, as if you had increased contrast for those pixels, until the phosphor is saturated, after which is does not become any brighter. Sort of an "optical" rather than an "electric" clip.

This is difficult to emulate correctly, because on modern systems, R/G/B levels do not drive the display directly, so R/G/B 255 just gets you the maximum brightness at the monitor's current contrast setting. You could remove the overall brightness (on linear light signals, not gamma pre-corrected signals) to give you some headroom, but that of course will make the picture look subjectively darker in general.
r57shell wrote:
Do you have RAW recoriding of some PAL TV signal? I want to check sanity of my decoder.
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.

Author:  HardWareMan [ Sat Apr 21, 2018 12:24 am ]
Post subject:  Re: PAL color palette emulation

Of course here no negative values at RGB output to the tube. Because the last stage with DC path. And at this stage does secondary recover black level right before x-Y signals meets with Y. Before this all paths separated with capacitors, so they have negative signals, like any other amplifiers does. Sample color module with diagrams from 8 color bars picture. Like SMPTE bars but with black one.

Page 5 of 6 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group