It is currently Fri Apr 20, 2018 12:54 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 72 posts ]  Go to page Previous  1, 2, 3, 4, 5
Author Message
PostPosted: Sun Jun 19, 2016 11:22 am 
Offline
User avatar

Joined: Sat Apr 18, 2009 4:36 am
Posts: 267
Location: Russia
Here is new PAL info from HardWareMan:
viewtopic.php?f=22&t=13394&start=75#p173791
nesdev wiki updated:
http://wiki.nesdev.com/w/index.php/PAL_video


Top
 Profile  
 
PostPosted: Mon Jun 20, 2016 5:17 am 
Offline
User avatar

Joined: Mon Jan 01, 2007 11:12 am
Posts: 203
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.
Image
I set phase 8 as color burst (according this) and get this:
Image
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.


Top
 Profile  
 
PostPosted: Mon Jun 20, 2016 7:59 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19923
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Mon Jun 20, 2016 8:00 pm 
Offline
User avatar

Joined: Mon Jan 01, 2007 11:12 am
Posts: 203
NTSC method was approved and replicated. Now it is time for PAL.


Top
 Profile  
 
PostPosted: Fri Sep 30, 2016 10:44 am 
Offline
User avatar

Joined: Sat Apr 18, 2009 4:36 am
Posts: 267
Location: Russia
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


Top
 Profile  
 
PostPosted: Fri Sep 30, 2016 10:58 am 
Offline
User avatar

Joined: Tue Apr 19, 2011 11:26 am
Posts: 107
Location: RU
That circle is worng, but the squares from the other test are correct. Obvious mismatch of what test roms are trying to test.


Top
 Profile  
 
PostPosted: Fri Sep 30, 2016 11:18 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7001
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Fri Sep 30, 2016 4:12 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19923
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Fri Sep 30, 2016 8:59 pm 
Offline
User avatar

Joined: Mon Jan 01, 2007 11:12 am
Posts: 203
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:
Image
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:
85/256=0,33203125
16/48=0,333333333
That why PPU crop some pixels at left and right.


Top
 Profile  
 
PostPosted: Wed Apr 11, 2018 4:01 am 
Offline

Joined: Thu Jul 23, 2015 9:56 am
Posts: 6
HardWareMan wrote:
Ok. Here two records, converted to B/W picture (warning: huge sizes).
500MHz sample rate


Here is my decodes:
UPDATE:
https://imgur.com/a/auMgr
(OLD BUGGED: https://imgur.com/a/5FVak 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.

Explanation:
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:
(double(rgb[0])-0x33)/(100.*0x5D/60.)*100.0
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:
Code:
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: https://i.imgur.com/8KKoi12.png
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.


Attachments:
table.csv [3.52 KiB]
Downloaded 4 times


Last edited by r57shell on Wed Apr 11, 2018 9:44 am, edited 3 times in total.
Top
 Profile  
 
PostPosted: Wed Apr 11, 2018 8:36 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 496
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.


Top
 Profile  
 
PostPosted: Fri Apr 20, 2018 8:06 am 
Offline

Joined: Thu Jul 23, 2015 9:56 am
Posts: 6
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 72 posts ]  Go to page Previous  1, 2, 3, 4, 5

All times are UTC - 7 hours


Who is online

Users browsing this forum: grynold, zob64 and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group