HDTV Signalling
cgracey
Posts: 14,206
Since the Prop2 can generate HDTV signals in Y/Pb/Pr component format, I thought I'd share a link to the document covering HDTV signal generation. I offer this because it is almost impossible to find if you don't know what to ask for. I haven't tried recently, but when I started doing work to support HDTV, I could not find anything that described the signal format from many, many searches. Somehow, after much time, I discovered that what I needed to know was in "RECOMMENDATION ITU-R BT.709-3". It's all here:
http://www.itu.int/rec/R-REC-BT.709-5-200204-I/en
I will post some Prop2 code here soon that does 1080p video generation. It just takes three pins on the Prop2 configured as DACs. The output signals are called Y (luma), Pb (blue difference), and Pr (red difference). These are typically connected via RCA (or phono) cables.
http://www.itu.int/rec/R-REC-BT.709-5-200204-I/en
I will post some Prop2 code here soon that does 1080p video generation. It just takes three pins on the Prop2 configured as DACs. The output signals are called Y (luma), Pb (blue difference), and Pr (red difference). These are typically connected via RCA (or phono) cables.
Comments
Can you even post NTSC and PAL configurations and examples ?.
''********************* ''* HDTV 1920x1080p * ''********************* ' P3 = Y ' P2 = Pb ' P1 = Pr CON _clkmode = xinput _xinfreq = 60_000_000 s = 43 'scales DAC output (s = 0..128) DAT org reps #256,#4 'start 8-bit incrementing sequence at $BB setspa #$BB incmod x,#63 wc if_c mov luma,lumas pusha luma add luma,lumad setctra #%00111 'set ctra for PLL*8 setfrqa frqa_ 'set frqa setvid #%0110 'set vid for hdtv output setvidy vidy_ 'set yiq coefficients setvidi vidi_ setvidq vidq_ cfgdacs #%11_11_11_00 'set top three dacs to video mode (Y/Pb/Pr) cfgpins pinmask,pindacs 'set pins for dac outputs ' ' ' Field loop ' field mov x,#36 'top blanks call #blank mov y,lines_vis 'set visible lines line call #sync 'do horizontal sync waitvid v60,sync_color1 'porch waitvid mode,#0 '256 pixels per waitvid djnz y,#line 'another tile line? mov x,#4 'bottom blanks call #blank mov x,#10 'low vertical syncs vsyncl call #sync waitvid v880,sync_color2 djnz x,#vsyncl mov x,#10 'high vertical syncs vsynch call #sync waitvid v880,sync_color1 djnz x,#vsynch jmp #field 'field loop blank call #sync 'blank lines waitvid v1980,sync_color1 djnz x,#blank blank_ret ret sync waitvid v44,sync_color1 'horizontal sync sync_ret retd waitvid v44,sync_color2 waitvid v44,sync_color3 waitvid v88,sync_color1 ' ' ' Initialized data ' luma long $03020100 lumas long $03020100 lumad long $04040404 frqa_ long $4F33_3333 '148.5 MHz vidy_ long 80 << 24 + ((+27*s/128) & $FF) << 16 + ((+92*s/128) & $FF) << 8 + (( +9*s/128) & $FF) vidi_ long 128 << 24 + ((-15*s/128) & $FF) << 16 + ((-49*s/128) & $FF) << 8 + ((+64*s/128) & $FF) vidq_ long 128 << 24 + ((+64*s/128) & $FF) << 16 + ((-58*s/128) & $FF) << 8 + (( -6*s/128) & $FF) pinmask long %1110 'pin mask for P3..P1 pindacs long %1111_101100000 'pin configuration for video DAC ' color base mode clocks/pixel clocks/waitvid mode long $BB << 24 + $A << 20 + 5 << 13 + 1920 lines_vis long 1080 sync_color1 long $1_000000 sync_color2 long $1_E00000 | ((-105*s/128) & $FF) 'sync- on all three outputs sync_color3 long $1_E00000 | ((+105*s/128) & $FF) 'sync+ on all three outputs v44 long 44 v88 long 88 v880 long 880 v60 long 60 v1920 long 1920 v1980 long 1980 x long 0 y long 0The R-2R DACs are imperfect on the FPGA boards, so you see some lines. The Prop2 chip should be perfectly smooth.
I'll try to post an NTSC example tonight.
Y-Pb-Pr is a good way to simply avoid Chroma carrier effects, but it is something of a fading standard.
Finding displays with Y-Pb-Pr is getting harder and harder, as everything moves away.
It seems the Chip-Sets do support VGA => LCD and Y-Pb-Pr => LCD, but the Y-Pb-Pr is seldom implemented, due to connector size/cost ?
The poorer quality Chroma carrier (PAL/NTSC) displays seem to have life in them, as Camera displays in Backing Cameras etc
I did notice some Chinese vendors offering VGA signals, but using a Mini-USB cable - an interesting way to side-step connector bulk.
Not sure if that idea will hit critical mass, but they could do the same thing for Y-Pb-Pr
I just browsed through models from every brand of HDTV on newegg, and didn't find any without component in. Even the newest models that just came out.
Even the new 4k res TVs from Sony and others have component inputs. So, really, no idea at all why you think it's going away...
But Prop2 pcb designers could go the Roku way too.
At the very high end / large screen sure, but how many projects want to connect to a 40" TV ?
I can find only one unit, under 10" that mentions Y-Pb-Pr, and below 32", they seem to be thin, with HDMI easily dominating.
This is kind of nice, because you have VGA, anyway, and if you want to do HDTV, just use this cable and change the video generation. No need for HSYNC or VSYNC signals - only R, G, B.
http://www.gerarmall.com/jack-35mm-rgb-component-video-cable15m-p-439.html
And here's an SMT jack for the 3.5mm phone plug:
http://www.digikey.com/product-detail/en/SJ-43514-SMT-TR/CP-43514SJCT-ND/669734
I only have a 'ended' ebay listing link, but you can see the Mini-usb-VGA cable etc
http://www.ebay.com.au/itm/7-LCD-Color-TV-AV-VGA-Car-Rearview-16-9-Monitor-/170631583602?pt=US_Rear_View_Monitors_Cams_Kits&hash=item27ba6f5772
I thought it was a good idea, but hard to guage if it hit 'critical mass' ?
Hope to see the NTSC example soon. : ]
Re: YCbCr
This input standard is popular with people who do high end home theater. Most mid and large sized displays will have them where they don't always have RGB.
I personally like it because a monochrome signal just requires one connection. The "Y" input for this format literally displays anything you throw at it from ordinary NTSC TV video to HDTV 1080i or p.
One thing I plan to try, and I almost did this with P1, is to run detail at high resolution, color differences at a more modest one for the illusion of HD, but not really. Sort of a play on what NTSC does, only without so many ugly artifacts.
Could run the monochrome signal at say 640x400, and the two color differences at 160x200 for example.
Everyone:
it is easy to find 15"+ HDTV's with component video input here in Canada, and I suspect the same is true in the states.
Search for TV's, NOT monitors. BestBuy, Costco, Newegg, TigerDirect etc should all have quite a selection.
Chip: Those AV cables to video/stereo are available on eBay for about $1-2 shipped. Be careful of the pinout as there are two common variants, the AV (video cameras and Nokia phones) and the Apple variant (third pin is ground instead of fourth with first pin being the tip).
That was my conclusion.
Of course, what would make this appealing, is not so much the connections, as the molded cable-set, if it comes at the right price.
Clearly some are being made. Not sure on the volumes tho.
I did find this [MiniUSB To VGA Cable] : (US $5.98 FREE - Economy Int'l Shipping ex China )
http://www.ebay.com.au/itm/Mini-USB-Male-5-pin-To-VGA-D-SUB-15-pins-Male-Adapter-Cable-For-Mobile-DVD-EVD-/281067703428?pt=LH_DefaultDomain_0&hash=item4170f0cc84
You can see here that the Prop2's video modulators generate sinusoidal signals, not square waves. This works much better, along with real RGB source colorspace remapped to whatever you need:
Here is the program:
''****************** ''* NTSC 256x192 * ''****************** ' P0 = YIQ CON _clkmode = xinput _xinfreq = 60_000_000 s = 46 'scales DAC output (s = 0..128) r = s * 78 / 128 'adjusts for modulator expansion lntsc = 3640 'NTSC colorburst cycles per line * 16 sntsc = 624 'NTSC colorburst cycles per sync * 16 DAT org reps #64,#2 'start 8-bit incrementing sequence at $BB setspa #$BB pusha luma add luma,lumad setctra #%00111 'set ctra for PLL*8 setfrqa frqa_ 'set frqa setvid #%1110 'set vid for composite output setvidy vidy_ 'set yiq coefficients setvidi vidi_ setvidq vidq_ cfgdac0 #%11 'set bottom dac to video mode (YIQ) cfgpins pinmask,pindacs 'set P0 for dac output ' ' ' Field loop ' field mov x,#34 'top blanks call #blank mov x,#192 'set visible lines line call #hsync 'do horizontal sync waitvid v_bo,#0 'black left border waitvid mode,#0 '256*9 clocks per waitvid waitvid v_bo,#0 'black right border djnz x,#line 'another line? mov x,#28 'bottom blanks call #blank mov x,#6 'high vertical syncs call #vsynch mov x,#6 'low vertical syncs call #vsyncl mov x,#6 'high vertical syncs call #vsynch jmp #field 'field loop blank call #hsync 'blank lines waitvid v_bl,#0 djnz x,#blank blank_ret ret hsync waitvid v_bs,c_sh 'horizontal sync waitvid v_sn,c_sl hsync_ret retd waitvid v_bc,c_sh waitvid v_cb,c_cb waitvid v_bv,c_sh vsynch waitvid v_bs,c_sh 'vertical sync high waitvid v_hs,c_sl waitvid v_hr,c_sh djnz x,#vsynch vsynch_ret ret vsyncl waitvid v_bs,c_sh 'vertical sync low waitvid v_ls,c_sl waitvid v_lr,c_sh djnz x,#vsyncl vsyncl_ret ret ' ' ' Initialized data ' luma long $03020100 lumad long $04040404 frqa_ long $1E8B_A2A7 '57.272720 MHz (colorburst * 16) vidy_ long (110*s/128 & $FF) << 24 + ((+38*s/128) & $FF) << 16 + ((+75*s/128) & $FF) << 8 + ((+15*s/128) & $FF) vidi_ long (100*s/128 & $FF) << 24 + ((+76*r/128) & $FF) << 16 + ((-35*r/128) & $FF) << 8 + ((-41*r/128) & $FF) vidq_ long 128 << 24 + ((+27*r/128) & $FF) << 16 + ((-67*r/128) & $FF) << 8 + ((+40*r/128) & $FF) pinmask long %1 'pin mask for P0 pindacs long %1111_101100000 'pin configuration for video DAC ' color base mode clocks/pixel clocks/waitvid mode long $BB << 24 + $A << 20 + 9 << 13 + 256*9 v_bo long (lntsc-sntsc-256*9)/2 'left/right border v_bs long 100 'before sync horizontal sync v_sn long 269 'sync v_bc long 50 'before colorburst v_cb long 144 'colorburst v_bv long sntsc-144-50-269-100 'before visible v_hs long 135 'high sync high vertical sync v_hr long lntsc/2-135-100 'high sync remainder v_ls long 1564 'low sync low vertical sync v_lr long lntsc/2-1564-100 'low sync remainder v_bl long lntsc-sntsc 'blank visible c_sh long $1_000000 'sync high c_sl long $2_000000 'sync low c_cb long $1_707000 'colorburst reference color x long 0Thanks
Minimum clock frequency: 25.175 MHz *10bits = 251.75 mhz serializer needed.
I guess is no way to get that, even if using 2-4 cogs.
You could push the video shifter to 251.75 MHz. Bit I think there is some NRZ encoding needed, too.
Maybe the LUT could be used as a lookup table for these 8bit to 10bit conversions.
And to simplify I think of not using accumulator error handling that keeps track of accumulator errors of 0 or 1 in majority so far.
As normally there are 460 combinations for representing an 8-bit data value, as most of the 256 possible values have two encoded variants (some values have only one),
Though the differential data out is at 251.75mhz, the clock-out is still at 25.175mhz.
And if we could put a hdmi connector on a Prop2 pcb, we could use it both for dvi and vga with this cable.
http://www.aliexpress.com/item/1Pcs-HDMI-Gold-Male-to-VGA-HD-15-Cable-6ft-1-8M-Free-shipping-Drop-ship/291350570.html
or hdmi to component
http://www.aliexpress.com/item/12-PCS-HDTV-1080P-5FT-HDMI-to-3-RCA-Male-Audio-Video-Component-Convert-Cable-1/662763196.html
or hdmi to vga+video+audio
http://www.aliexpress.com/item/HDMI-HDTV-to-VGA-3-RCA-Converter-Adapter-Cable-1080p/680356214.html
Looks great!
http://www.mouser.com/ProductDetail/Texas-Instruments/DS90LV031ATMX-NOPB/?qs=sGAEpiMZZMtTXF9i0pOGl%2fbsaGN3nQrHlCzttN70mc8%3d
But using something like a TPF410 is a pin waster and so prop1 and also costly.
Look at this 50" 1080P TV from Newegg for $399. Pretty amazing how cheap things are becoming: http://www.newegg.com/Product/Product.aspx?Item=N82E16889112066&cm_sp=DailyDeal-_-89-112-066-_-Homepage
If you want 1080i/p over hdmi, these converter IC from NXP are in the $5 range.
http://www.mouser.com/Search/Refine.aspx?Keyword=TDA998