PAL color palette emulation
Page 5 of 5

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.

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