I got the component colour working now (in SD resolution) on my Dell LCD with my driver. It looks rather nice. I used the coefficients Wuerful_21 mentioned. When mapped to a 0.7Vpp Y signal and 1Vp-p Pr Pb signals I believe you get this...
Y = (27/128) x R + (53/128) x G + (10/128) x B
Pb = (-22/128) x R + (-42/128) x G + (64/128) x B
Pr = (64/128) x R + (-53/128) x G + (-10/128) x B
Offset for Y is 76 in CY[7:0] to leave -0.3V headroom for sync.
Offset for Pb/Pr is 128, in CI[7:0] and CQ[7:0]
Looks somewhat colour saturated on my monitor so I might like to scale the colour difference signals down just a little bit. In the link below I read that PAL component signals uses 700mVp-p, while NTSC uses 933mVp-p both for 100% colour bars, not the full 1Vp-p range but this is only one source and it's likely there'll be other values used.
I think I'll make the 3 colour space registers updatable per frame in my driver so there are ways to adjust it dynamically.
I looked at Chip's HD component video stuff too, the sync for that looks a bit trickier with its 3 levels. I'll have to figure out how to do it right in the driver in time, but for now a least we can have some SD component support (tested at VGA resolution on one device so far).
Here's a picture of Rayman's bird pic, on my LCD monitor in Picture By Picture mode. One input is the component on the left, the other is DVI on the right. I spawned two COG's outputting the same frame, one in DVI mode and the other in component mode. I should spawn another COG in VGA mode and feed it to my Sony.
The DVI input does look quite bright but the colours seem nicer nicer on the component input now I adjusted it a bit. I dialled them back to 75% or so. I don't know what the LCD is doing to these images internally, it's probably doing something different there anyway.
UPDATE: Just tried 1280x720p60 timing on my LCD and it worked in component mode, along with on my Plasma, so you many not need that fancy HD triple level sync on all devices for it to work. Photo's looks really amazing on the plasma. Now need to test full HD...
@evanh, No massive blanking for 576i over HDMI. It does pixel repetition to get the pixel transfers up over the minimum 250MHz, actually using 270MHz HDMI timing I believe. The TV then throws away half the pixels.
I wasn't able to get 1920x1080p recognised by my Plasma over component with the P2. Not sure what gives there. I am reading it's specs and it says it can do 1080p it but it's listed under the HDMI section and I can't find any component only specs in the manual. I do have a PVR that upscales it's TV source to component 1080i so if I can yank it out and move it over from another room I might be able to try that too. Perhaps the Pioneer plasma's component input would be limited to 1080i which probably makes sense given the age of this thing (mid-late 2000's).
@evanh, No massive blanking for 576i over HDMI. It does pixel repetition to get the pixel transfers up over the minimum 250MHz, actually using 270MHz HDMI timing I believe. The TV then throws away half the pixels.
Really?! Boy, does that sound like a hack. Reiterates the blindness of the 30 kHz minimum spec.
Was 1080p over component ever really a thing?
Dunno, presumably just not supported. Probably considered too fast for analogue to carry cleanly.
Chip's 1080 component example code didn't work either. When I run it looks like the TV is about to show something then it blanks out. Input status detects something but nothing shown on screen. I noticed Chip's code was doing something weird with the number of vertical sync pulses, and I changed it to something I read online for 1080 progressive (from Figure 12A in Rec ITU-R BT.709-4) where you do 4 front porch blank lines, then 5 lines of negative sync, then 36 lines of back porch blanks then your 1080 active lines, still using tri-level hsync pulses. Still didn't help unfortunately. Might be just my TV's limits.
Every 50 Hz capable TV can do that. It's just interlaced with both interlaced fields from the same frame in time.
Well, 48 hz is different from 50. The 24hz is to eliminate the odd jitter in motion caused by timing mismatch. My high end plasma does 24p and my other sets will do 50/60, but not 24p specifically. One can tell on slow, grand camera dolly in scenes easily, along with the mode indicator not showing 24p.
To get it, a specially mastered blue ray is needed. 24p is shown in the modes list on the back of the packaging. Not all players appear to offer it either.
I mentioned it because there may be signal options available that are not otherwise.
Can't wait to join the fun!
Re: 1080p analog
Not all sets will take it in my experience. Official support ends at 1080i. Thank the movie studios for that one.
Got the scope out today to see exactly what the P2 was outputting and played with sync pulses accord to some HDTV timing information found in this pdf...
I then tweaked Chip's demo code to support 1080i. I now have it working both on my Pioneer plasma and Dell LCD via component at 74.25MHz pixel rate, with the upside down birds due to the reversed bmp file order. Happy now. Chip's code I modified for 1080i is also attached below.
'***************************************************
'* HDTV 1080i component Y-Pb-Pr, 16bpp 5:6:5 RGB *
'***************************************************
CON
s = 60 'scales DAC output (s = 0..128)
sync_color1 = $000000_00
sync_color2 = (-105*s/128) & $FF 'sync- on all three outputs
sync_color3 = (+105*s/128) & $FF 'sync+ on all three outputs
BASEPIN = 8
DAT org
'
'
' Setup
'
hubset clkinit1 'set clock to 148.5MHz
waitx clkwait
hubset clkinit2
'rdfast ##640*350*2/64,##$1000 'set rdfast to wrap on bitmap
setxfrq ##$4000_0000 'set transfer frequency to clk rate/2
setcy cy_ 'Y set colorspace for Y-Pb-Pr
setci ci_ 'Pb
setcq cq_ 'Pr
setcmod #%01_1_111_0 'enable colorspace conversion
wrpin dacmode_rgb,#(2<<6) + BASEPIN + 1 'enable dac modes in pins 3,2,1 for Y,Pb,Pr
drvl #(2<<6) + BASEPIN + 1 'enable dac outputs
'
'
' Field loop
'
mov odd, #1 'odd/even field
field
mov x,#14 'top blanks
if_c add x,#1
call #blank
rdfast ##640*350*2/64,##$1000 'set rdfast to wrap on bitmap
mov x,##540 'set visible lines
line call #hsync 'do horizontal sync
xcont m_60,#sync_color1 'porch
xcont m_1920v,#1 'visible line
djnz x,#line 'another line?
xor odd, #1 wc
mov x,#2 'bottom blanks
call #blank
if_c call #hsync
if_c xcont m_880,#sync_color1 ' high vsync 1/2 width
mov x,#10 'low vertical syncs 1/2 width
.vsync1 call #hsync
xcont m_880,#sync_color2
djnz x,#.vsync1
mov x,#1 'high vertical syncs 1/2 width
if_nc add x,#1
.vsync2 call #hsync
xcont m_880,#sync_color1
djnz x,#.vsync2
jmp #field 'loop
'
'
' Subroutines
'
blank call #hsync 'blank lines
xcont m_1980,#sync_color1
_ret_ djnz x,#blank
hsync xcont m_44,#sync_color1 'horizontal sync
xcont m_44,#sync_color2
xcont m_44,#sync_color3
_ret_ xzero m_88,#sync_color1
'
'
' Initialized data
'
clkinit1 long %1_100111_0100101000_1111_10_00 '20MHz / 40 * 297 * 1 = 148.5MHz
clkinit2 long %1_100111_0100101000_1111_10_11
clkwait long 25_000_000 / 200
dacmode_rgb long %0000_0000_000_1011100000000_01_00000_0 '75-ohm 2.0V
cy_ long ((+27*s/128) & $FF) << 24 + ((+92*s/128) & $FF) << 16 + (( +9*s/128) & $FF) << 8 + 80
ci_ long ((-15*s/128) & $FF) << 24 + ((-49*s/128) & $FF) << 16 + ((+64*s/128) & $FF) << 8 + 128
cq_ long ((+64*s/128) & $FF) << 24 + ((-58*s/128) & $FF) << 16 + (( -6*s/128) & $FF) << 8 + 128
m_44 long $7F010000+44 'syncs/blanks
m_88 long $7F010000+88
m_60 long $7F010000+60
m_880 long $7F010000+880
m_1920 long $7F010000+1920
m_1980 long $7F010000+1980
m_1920v long $BF050000+1920 'visible rfword rgb16 (5:6:5)
x res 1
odd res 1
'
'
' Bitmap
'
orgh $1000 - 70 'justify pixels at $1000
file "birds_16bpp.bmp" 'rayman
Yeah, if I can squeeze the interlaced part and three level sync into my driver I will, as 1080i may be popular over component for (older) HDTVs. Since I restructured some init code and made more use of LUT RAM I have about 30 COGRAM longs left and I still want a couple of things (sprite/pass through mode, and sync status) to put in before then but its almost complete. I keep saying that, then adding more .
On the P1 in the past I've found it's also handy/kind to not fill COGRAM 100% so you can leave a little space for later experimenting/debug etc. But it is a precious commodity so if I need it I use it.
In time people may like other capabilities like NTSC composite, Y/C outputs, HDMI framing etc, but they might require slightly different codebases to be initialized at startup time, which should now be possible by the way I do things. I like the idea that one driver could pretty much support any type of video output, selectable at COG startup time, so your application code can mostly remain the same while still supporting different outputs, unlike the P1 where you mostly had to locate a specific driver for a given output type or resolution.
One question, will SD PAL be 100% supportable by the P2, given the way the chroma signal is done? I know PAL requires phase reversals which might have been why the P1 had some problems with it, but I'm not sure as I never really played with composite that much on the P1, predominantly it was just VGA.
The problem with PAL on P1 seems to be twofold:
- P1 counter PLLs seem to have difficulty generating 4.43MHz*16 from 80MHz master clock. Not a problem on P2?
- Some TVs seem picky about horizontal timing (due to using a fixed-length analog delay line to correlate chroma from the previous line with the current line)
The phase reversal basically just means inverting the V (or in P2 terms, Q) coefficient's sign every line, as far as I understand.
So I was wondering this morning, what do you do on the P2 to generate a colour burst? Do you just send a single value with the I and Q fixed and let the colour modulator oscillator cycle through its values at its own SETCFRQ programmed rate thereby generating a counting pattern output in IQ[7:0], or is there some other special burst pattern you need to construct and output?
I am presuming the former approach would apply as you'd probably want a pure reference colour "tone", though perhaps it also gets flipped for PAL every two lines. I still need to dig into how it all works a bit more.
So I was wondering this morning, what do you do on the P2 to generate a colour burst? Do you just send a single value with the I and Q fixed and let the colour modulator oscillator cycle through its values at its own SETCFRQ programmed rate thereby generating a counting pattern output in IQ[7:0], or is there some other special burst pattern you need to construct and output?
I am presuming the former approach would apply as you'd probably want a pure reference colour "tone", though perhaps it also gets flipped for PAL every two lines. I still need to dig into how it all works a bit more.
The ideal would be to adjust phase only on each line, so that the average frequency (which the TV's crystal PLL-lock to) stays correctly precise.
I'm not sure if the Smartpins support phase adjust ?
I think the colour space converter and modulator needs to do it by the looks of the P2 video output design. I guess you could mix in signals from another pin but that is not ideal.
"Since the carrier is not transmitted with the video information it has to be generated locally in the receiver. In order that the phase of this locally generated signal can match the transmitted information, a 10 cycle burst of colour subcarrier is added to the video signal shortly after the line sync pulse, but before the picture information, during the so-called back porch. This colour burst is not actually in phase with the original colour subcarrier, but leads it by 45 degrees on the odd lines and lags it by 45 degrees on the even lines. This swinging burst enables the colour decoder circuitry to distinguish the phase of the R-Y vector which reverses every line."
So for PAL it looks like we need to modify the colour burst output phase every second line and so we don't use the SETCFRQ phase, but something phase leading or lagging from it by 45 degrees. I would think that is just a matter of altering the I/Q input values used, hopefully.
...So for PAL it looks like we need to modify the colour burst output phase every second line and so we don't use the SETCFRQ phase, but something phase leading or lagging from it by 45 degrees. I would think that is just a matter of altering the I/Q input values used, hopefully.
Yes, you'd output some RGB color to cause the colorburst to be the appropriate phase and amplitude. You could, also/instead, alter the YIQ coefficients that are applied to the RGB input values.
Thanks Chip. I'll hoping to try to have a play around with composite and/or Y-C output soon, then I'll have them all covered.
After we caught up Friday I'm also trying out some of ozpropdev's hyperRAM test code too to see if I can't get a full screen high colour output from my video driver using external memory. That's sort of what I've been striving towards achieving for most of this time. So far it's at least proven my HyperRAM board is functional and I'm getting some data back, but I need to spend more time on it with some integration work. Single file for sharing code is not ideal....does flexgui support multiple input files to build a project? I'll have to check it out if it does.
I've been trying to use this table below to control the streamer sending analog composite/Y+C video output to different DAC pins. I am seeing strange behaviour and wonder if the P2 documentation is accurate or not, or if there is some P2 or code issue...
DAC Channel
dddd 3 2 1 0 description .
0000 -- -- -- -- no streamer DAC output
0001 X0 X0 X0 X0 output X0 on all four DAC channels
0010 -- -- X0 X0 output X0 on DAC channels 1 and 0
0011 X0 X0 -- -- output X0 on DAC channels 3 and 2
0100 -- -- -- X0 output X0 on DAC channel 0
0101 -- -- X0 -- output X0 on DAC channel 1
0110 -- X0 -- -- output X0 on DAC channel 2
0111 X0 -- -- -- output X0 on DAC channel 3
1000 !X0 X0 !X0 X0 output X0 diff pairs on all four DAC channels
1001 -- -- !X0 X0 output X0 diff pairs on DAC channels 1 and 0
1010 !X0 X0 -- -- output X0 diff pairs on DAC channels 3 and 2
1011 X1 X0 X1 X0 output X1, X0 pairs on all four DAC channels
1100 -- -- X1 X0 output X1, X0 on DAC channels 1 and 0
1101 X1 X0 -- -- output X1, X0 on DAC channels 3 and 2
1110 !X1 X1 !X0 X0 output X1, X0 diff pairs on all four DAC channels
1111 X3 X2 X1 X0 output X3, X2, X1, X0 on all four DAC channels
My code does this...and I'm trying the case with syncoptions bit2:0 = 101
' Use of this syncoptions field in the HDTV/SDTV analog submode:
' bit5 = select HD tri-level (1) or standard SD sync (0) timing
' bit4 = select Interlaced (0) or Progressive(1) video frame
' bit3 = select NTSC (0) or PAL (1) colour system for composite video
' bit2:0 = select video output type and DAC(s) used in the pin group
' 000 = Composite video output on DAC0 pin
' 001 = Composite video output on DAC1 pin
' 010 = Composite video output on DAC2 pin
' 011 = Composite video output on DAC3 pin
' 100 = Y-C output on DAC0(Y) & DAC1(C) pins
' 101 = Y-C output on DAC2(Y) & DAC3(C) pins
' 110 = Y-C output on DAC0(Y) & DAC1(C) pins, Composite on DAC2 pin
' 111 = Component video output on DAC1(Pb), DAC2(Y), DAC3(Pr) pins
...
getnib a, pb, #5 'extract pin group
getbyte b, pb, #3 'get syncoptions field
testb b, #2 wc 'test for composite (0), other (1)
if_nc jmp #compositevideo
rczr b wcz 'convert two lsb's into flags
if_z_and_c jmp #componentvideo
svideo
mov cmodval, #%00_10_1000_0 'enable Y/C video generation
mul a, #4 'convert pin group to pin base
if_z add a, #2 'high DAC pair output selected
if_z setnib m_bs, #%1011, #6 'output X0 and X1 on upper pins
if_z setnib m_sn, #%1011, #6 'output X0 and X1 on upper pins
if_z setnib m_bv, #%1011, #6 'output X0 and X1 on upper pins
if_z setnib m_vi, #%1011, #6 'output X0 and X1 on upper pins
if_z setnib m_rf, #%1011, #6 'output X0 and X1 on upper pins
add a, #(1<<6) 'setup two pins (Y+C)
if_c add a, #(1<<6) 'setup three pins (Y+C+Composite)
wrpin dacmode_c, a 'enable DAC modes on pins
dirh a 'enable pin output
mov sync_003, #1 'idle hsync, idle vsync
mov sync_002, #2 'active hsync, idle vsync
mov sync_001, #1 'idle hsync, active vsync
mov sync_000, #2 'active hsync, active vsync
...
' these modes get patched with the driving cog ID too
dacmode_s long %0000_0000_000_1011000000000_01_00000_0 'hsync 123-ohm 3.3V
dacmode_c long %0000_0000_000_1011100000000_01_00000_0 'R/G/B 75-ohm 2.0V
m_bs long $7fb10000 + H_FP 'before sync
m_sn long $7fb10000 + H_SYNC 'sync
m_bv long $7fb10000 + H_BP 'before visible
m_vi long $7fb10000 + H_VISIBLE 'visible
m_rf long $7fb60000 + H_VISIBLE 'visible 8x4b for LUT lookup
I've tried setting both %1011 and %1101 into the streamer command's dddd field to get the Y/C X0 and X1 output on the high pair of the 4 bit pin group and it behaves differently in each. %1101 seems to give a diminished output with clipped off negative sync pulses and the other value looks like the inverse of normal as my sync pulses come down from the top, so it's like some type of complemented output. So I am wondering if the DAC channel table above is accurate or not? I'll also need to check that this isn't another p2asm opcode bug too. My setci, setcq, setcy values also remained the same in all cases tested.
Update: p2asm output opcodes look okay:
setnib D,#/S, #n encoding is EEEE1000_00NN_NIDD_DDDDDDD_SSSSSSSSS
10e8c 313 a837080d if_z setnib m_bs, #%1101, #6 'output X0 and X1 on upper pins
10e90 314 a8370a0d if_z setnib m_sn, #%1101, #6 'output X0 and X1 on upper pins
10e94 315 a8370c0d if_z setnib m_bv, #%1101, #6 'output X0 and X1 on upper pins
10e98 316 a8370e0d if_z setnib m_vi, #%1101, #6 'output X0 and X1 on upper pins
10e9c 317 a837100d if_z setnib m_rf, #%1101, #6 'output X0 and X1 on upper pins
Update2: Here are my YIQ parameters for this experiment...
mov b,##(27 << 24) + (53 << 16) + (10 << 8) + 76
setcy b
mov b,##((((64*SAT)/100) & $ff)<<24)+((((-53*SAT)/100) & $ff)<<16)+((((-10*SAT)/100) & $ff)<<8) + 74
setci b
mov b,##((((-22*SAT)/100) & $ff)<<24)+ ((((-42*SAT)/100) & $ff)<<16)+ ((((64*SAT)/100) & $ff)<<8) + 0
setcq b
' colour saturation depth SAT was set to 70
Here's some captures to show what I mean in the previous post. Each video signal was captured unloaded so you will see it should be 2Vp-p instead of 1Vp-p into 75ohms and is so in the first image.
First picture below is a good output of a composite signal when X2 is sending out composite. The Y signal on X0 is essentially the same. This is pretty much what I expected to see.
This second picture below is the diminished Y output on DAC channel 2 pin mapped to X0 with streamer dddd nibble set to %1101. I first thought perhaps this could have been the Chroma channel, but the C channel amplitude is much bigger if I look at it on DAC1 when Y+C is mapped to the lower two pins of the 4 pin group.
Third picture below is possibly complemented? Y output on DAC channel 2 pin mapped to X0 with streamer dddd nibble set to %1011. Though if were were complemented the front and back porch levels should be inverted too and they do not appear to be.
Not sure why I am getting these 2 bad video outputs unless possibly the DAC channel mapping is broken with the colour space converter + streamer output, or the P2 documentation is different to reality.
Update: I'm also seeing some video output on DAC2+DAC3 pins when the streamer nibble 6 "dddd" is set to %1100. It should not be sending out on those pins in that mode from what I can tell. So something is messed up here.
So with help from looking through Chip's 480p demo I was able to add in NTSC video (interlaced 480i) to my driver. Right now it's partially hacked up but soon to be permanent, and it is showing good signs of life on my LCD.
So we soon should be able to target VGA, SD/HD component, composite, S-video and DVI over HDMI from the same video driver at various resolutions all with the same control interface and graphics capabilities. That's the plan anyway.
Doing PAL might be tricky with it's special burst flips. I am also not really adhering to any of the rules regarding blanking out the colour burst on particular line sequences over 4/8 frames either due to a lack of COGRAM, but I'll still give it a crack to see how it goes.
I now have 9 COG RAM registers left. With this I want to try to add that pass through sprite mode plus tri-level HD component syncs if I can squeeze it down any further...hopefully the tri-level things shouldn't add any more COGRAM as I set it up at init time. It's becoming a bit of a puzzle to make it all fit now.
I am also not really adhering to any of the rules regarding blanking out the colour burst on particular line sequences over 4/8 frames either
Don't worry, NTSC/PAL is not an exact science. 99% of displays won't care about minor differences from a proper broadcast signal (most don't even care about quite major differences, such as refresh rate / line count, which is why PAL60 works on almost everything that supports regular PAL50 (some need a V-HOLD adjustment though...). And let's not forget good old 240p/288p progressive scan.)
So we soon should be able to target VGA, SD/HD component, composite, S-video and DVI over HDMI from the same video driver at various resolutions all with the same control interface and graphics capabilities. That's the plan anyway.
One Driver to rule them all, ..., and in the lightness bind them.
So we soon should be able to target VGA, SD/HD component, composite, S-video and DVI over HDMI from the same video driver at various resolutions all with the same control interface and graphics capabilities. That's the plan anyway.
One Driver to rule them all, ..., and in the lightness bind them.
Arrggh, you're killing me! Maybe the video DACs could be set into 3.3V output and something could sort of work with the LUT modes, but I'm not sure I'll officially try to support that (yet). Now that's really retro, CGA style.
Has the code been optimized to death? SKIPFed to the max??
Yeah I'm on the hunt for places to try more SKIPF after we had so much success with it with our pixel doubling.
Also: aliasing variables that are never relevant at the same time to the same register
Yes I've starting finding a few of those, and a couple of days back I gained 4 longs in the process for the mouse registers. I am on the hunt for more and there will be some left. I know of 3 more COG RAM regs I can gain over what I have already by doing this, and I think I can map more state flags/counters into a common register instead of separate. What I don't like is having to save/restore the two pointer registers ptra/ptrb. That needs 4 longs each time, either 2 push/pop or 4 moves to/from temp regs. I do this twice as the auto-incrementing pointers are so useful for both LUT and HUB read/writes, so that is 8 longs.
I know I will need 1 more instruction for doing the PAL colour burst flip (XOR) every scan line. I already have the second long allocated for the XOR mask in my existing budget.
HD-Sync should be able to hopefully just squeeze in place (with a code overlay at cog setup time).
I will need some more regs for sprite mode (not sure how many, hopefully just a small number), plus any other things I've missed. I could always start to use HUB RAM for code, but it will prevent me from doing ping/pong LUTRAM in 256 colour mode for operating at lower power 1:1 pixel clock:P2 clock ratios.
Interlacing input source data is a problem. Right now in my interlaced NTSC output mode I am sending the same source data each field so it's really more like seeing 240p instead of getting proper 480i source data. Ideally I should offset every second field reading out of the source data. I might be able to do this with my second screen source reg, though that is intended for wrapping. We'll see how best to do it...
Don't worry, NTSC/PAL is not an exact science. 99% of displays won't care about minor differences from a proper broadcast signal (most don't even care about quite major differences, such as refresh rate / line count, which is why PAL60 works on almost everything that supports regular PAL50 (some need a V-HOLD adjustment though...). And let's not forget good old 240p/288p progressive scan.)
I'm glad to hear it. I don't think I'll manage to match every single rule. The HD/SD video modes have been added in right at the end and I just don't have enough resources to be 100% compliant. This driver just started out as DVI text only intended for VGA resolution only operating at 252MHz (it came from some early HDMI+audio experiments), but has grown and grown since then with features and it really does a whole lot more now.
Don't worry, NTSC/PAL is not an exact science. 99% of displays won't care about minor differences from a proper broadcast signal (most don't even care about quite major differences, such as refresh rate / line count, which is why PAL60 works on almost everything that supports regular PAL50 (some need a V-HOLD adjustment though...). And let's not forget good old 240p/288p progressive scan.)
Hey you are right about some displays not caring about the standards so much. I am sending the PAL colour burst frequency with Chip's NTSC phase angle colour instead of PAL's 135/225 degree version, and not alternating it and my LCD is showing a reasonable colour picture (albeit quite saturated) and recognizing it as 50Hz "PAL". LOL.
I've certainly seen some quite interesting old school video effects showing while debugging this thing. Reminds me so much of old worn out videotapes flagging at the top etc. Very retro.
So I was able to squeeze the different types of sync code into the same COGRAM footprint, and come up with versions for SDTV PAL/NTSC interlaced/progressive and HDTV interlaced/progressive. All variants are coded now on a spreadsheet and interlaced ones have been tested in my working driver however the actual sync code is very unlikely to expand into needing more COGRAM so I am highly confident it will fit okay even though not all is tested out yet. Sync type is selected at COG boot time and the code gets configured accordingly.
I did some more hunting and found some low hanging fruit and now have about 20 free COGRAM registers. There might be a few more but it is starting to become slim pickings now.
With this extra scrounged RAM I hope to do the following...
1) allow a simple sprite mode, passing through from external COG rendered data buffers directly instead of copying
2) interlaced source address offset in graphics regions (allows page flipping and/or independent field source for 50/60 fields/sec video)
3) better palette handling (see below)
4) a proper status frame counter, right now it is sharing a counter that only counts to 16 for flashing the cursor (may need 2-3 extra regs)
5) option for a shared set of mouse co-ordinates over all regions to help the user out (this would need 3 regs)
6) (eventually) support a low power 1:1 pixel/P2 clock mode for basic "transparent" frame buffer pass through. In this mode no text/mouse/pixel doubling is possible and it would work a bit like the sprite mode but not really have any other capabilities. This mode would not take more register space as it would be patched at boot time, but it would be good to have as it could allow decent NTSC/PAL frame buffer output at 13.5MHz P2 rates, or VGA at 25MHz etc. I think this will come after the initial release.
The 256 entry palette load approach I started out with VGA is now becoming an issue, due to the different hsync options taking more CPU time, with different tri-level and colour bursts etc needing more streamer commands and not leaving large contiguous blocks of CPU time to load the palette. You need over 256 clock cycles to load a 256 entry palette and for low pixel clock ratios and small blanking intervals it may not load in time. So what I think I will have to do is to keep any 256 entry palette in low LUT RAM, and reload it in place on region changes during the active portions on the scanline after the text/graphics scanline has been rendered. This may mean that two sequential regions with different 256 colour palettes changing in the middle of the frame could see colours disrupted towards the end of the scanline. To alleviate this issue I think I will keep the smaller 2/4/16 entry palette in high LUT RAM so this potentially can be hidden if you change different 256 colour regions via the 16 colour palette first - e.g. insert a single black (or other coloured) scanline between two 256 colour regions to avoid noticing it. You could also use a direct colour mode region too instead of one using the 16 colour palette. Both should work.
Unfortunately I don't think I can do any double buffering of 256 entry palettes in my normal operating mode because I need the LUTRAM for my text buffer/pixel doubler (though it may be possible to do this doubling buffering in a future cut-down transparent mode). I think this is all I can do about it right now. I may have similar issues with rendering the mouse in some cases, though only for external RAM sourced data with lower P2 pixel clock ratios. I'm hoping there will be sufficient time available to display one but can't guarantee it over all operating conditions.
I've updated my VGA ANSI driver to support 2 bytes/char (using the standard VGA format that you also use) and 1 byte/char (7 bit ASCII plus 1 bit blinking effect for the cursor). It should be pretty straightforward to adapt the ANSI character output code in vga_text_routines.spinh to your driver.
Comments
Offset for Y is 76 in CY[7:0] to leave -0.3V headroom for sync.
Offset for Pb/Pr is 128, in CI[7:0] and CQ[7:0]
Looks somewhat colour saturated on my monitor so I might like to scale the colour difference signals down just a little bit. In the link below I read that PAL component signals uses 700mVp-p, while NTSC uses 933mVp-p both for 100% colour bars, not the full 1Vp-p range but this is only one source and it's likely there'll be other values used.
https://www.maximintegrated.com/en/design/technical-documents/tutorials/1/1184.html
I think I'll make the 3 colour space registers updatable per frame in my driver so there are ways to adjust it dynamically.
I looked at Chip's HD component video stuff too, the sync for that looks a bit trickier with its 3 levels. I'll have to figure out how to do it right in the driver in time, but for now a least we can have some SD component support (tested at VGA resolution on one device so far).
The DVI input does look quite bright but the colours seem nicer nicer on the component input now I adjusted it a bit. I dialled them back to 75% or so. I don't know what the LCD is doing to these images internally, it's probably doing something different there anyway.
UPDATE: Just tried 1280x720p60 timing on my LCD and it worked in component mode, along with on my Plasma, so you many not need that fancy HD triple level sync on all devices for it to work. Photo's looks really amazing on the plasma. Now need to test full HD...
Then the question becomes: What is the HDMI clock rate in this case? Is it lower than 250 MHz or is there massive blanking times?
I wasn't able to get 1920x1080p recognised by my Plasma over component with the P2. Not sure what gives there. I am reading it's specs and it says it can do 1080p it but it's listed under the HDMI section and I can't find any component only specs in the manual. I do have a PVR that upscales it's TV source to component 1080i so if I can yank it out and move it over from another room I might be able to try that too. Perhaps the Pioneer plasma's component input would be limited to 1080i which probably makes sense given the age of this thing (mid-late 2000's).
Was 1080p over component ever really a thing?
Dunno, presumably just not supported. Probably considered too fast for analogue to carry cleanly.
Well, maybe that is true. I do have a 50/60 hz capable LCD that do
Well, 48 hz is different from 50. The 24hz is to eliminate the odd jitter in motion caused by timing mismatch. My high end plasma does 24p and my other sets will do 50/60, but not 24p specifically. One can tell on slow, grand camera dolly in scenes easily, along with the mode indicator not showing 24p.
To get it, a specially mastered blue ray is needed. 24p is shown in the modes list on the back of the packaging. Not all players appear to offer it either.
I mentioned it because there may be signal options available that are not otherwise.
Can't wait to join the fun!
Re: 1080p analog
Not all sets will take it in my experience. Official support ends at 1080i. Thank the movie studios for that one.
https://www.appliedelectronics.com/documents/Guide to Standard HD Digital Video Measurements.pdf
I then tweaked Chip's demo code to support 1080i. I now have it working both on my Pioneer plasma and Dell LCD via component at 74.25MHz pixel rate, with the upside down birds due to the reversed bmp file order. Happy now. Chip's code I modified for 1080i is also attached below.
'*************************************************** '* HDTV 1080i component Y-Pb-Pr, 16bpp 5:6:5 RGB * '*************************************************** CON s = 60 'scales DAC output (s = 0..128) sync_color1 = $000000_00 sync_color2 = (-105*s/128) & $FF 'sync- on all three outputs sync_color3 = (+105*s/128) & $FF 'sync+ on all three outputs BASEPIN = 8 DAT org ' ' ' Setup ' hubset clkinit1 'set clock to 148.5MHz waitx clkwait hubset clkinit2 'rdfast ##640*350*2/64,##$1000 'set rdfast to wrap on bitmap setxfrq ##$4000_0000 'set transfer frequency to clk rate/2 setcy cy_ 'Y set colorspace for Y-Pb-Pr setci ci_ 'Pb setcq cq_ 'Pr setcmod #%01_1_111_0 'enable colorspace conversion wrpin dacmode_rgb,#(2<<6) + BASEPIN + 1 'enable dac modes in pins 3,2,1 for Y,Pb,Pr drvl #(2<<6) + BASEPIN + 1 'enable dac outputs ' ' ' Field loop ' mov odd, #1 'odd/even field field mov x,#14 'top blanks if_c add x,#1 call #blank rdfast ##640*350*2/64,##$1000 'set rdfast to wrap on bitmap mov x,##540 'set visible lines line call #hsync 'do horizontal sync xcont m_60,#sync_color1 'porch xcont m_1920v,#1 'visible line djnz x,#line 'another line? xor odd, #1 wc mov x,#2 'bottom blanks call #blank if_c call #hsync if_c xcont m_880,#sync_color1 ' high vsync 1/2 width mov x,#10 'low vertical syncs 1/2 width .vsync1 call #hsync xcont m_880,#sync_color2 djnz x,#.vsync1 mov x,#1 'high vertical syncs 1/2 width if_nc add x,#1 .vsync2 call #hsync xcont m_880,#sync_color1 djnz x,#.vsync2 jmp #field 'loop ' ' ' Subroutines ' blank call #hsync 'blank lines xcont m_1980,#sync_color1 _ret_ djnz x,#blank hsync xcont m_44,#sync_color1 'horizontal sync xcont m_44,#sync_color2 xcont m_44,#sync_color3 _ret_ xzero m_88,#sync_color1 ' ' ' Initialized data ' clkinit1 long %1_100111_0100101000_1111_10_00 '20MHz / 40 * 297 * 1 = 148.5MHz clkinit2 long %1_100111_0100101000_1111_10_11 clkwait long 25_000_000 / 200 dacmode_rgb long %0000_0000_000_1011100000000_01_00000_0 '75-ohm 2.0V cy_ long ((+27*s/128) & $FF) << 24 + ((+92*s/128) & $FF) << 16 + (( +9*s/128) & $FF) << 8 + 80 ci_ long ((-15*s/128) & $FF) << 24 + ((-49*s/128) & $FF) << 16 + ((+64*s/128) & $FF) << 8 + 128 cq_ long ((+64*s/128) & $FF) << 24 + ((-58*s/128) & $FF) << 16 + (( -6*s/128) & $FF) << 8 + 128 m_44 long $7F010000+44 'syncs/blanks m_88 long $7F010000+88 m_60 long $7F010000+60 m_880 long $7F010000+880 m_1920 long $7F010000+1920 m_1980 long $7F010000+1980 m_1920v long $BF050000+1920 'visible rfword rgb16 (5:6:5) x res 1 odd res 1 ' ' ' Bitmap ' orgh $1000 - 70 'justify pixels at $1000 file "birds_16bpp.bmp" 'raymanOn the P1 in the past I've found it's also handy/kind to not fill COGRAM 100% so you can leave a little space for later experimenting/debug etc. But it is a precious commodity so if I need it I use it.
In time people may like other capabilities like NTSC composite, Y/C outputs, HDMI framing etc, but they might require slightly different codebases to be initialized at startup time, which should now be possible by the way I do things. I like the idea that one driver could pretty much support any type of video output, selectable at COG startup time, so your application code can mostly remain the same while still supporting different outputs, unlike the P1 where you mostly had to locate a specific driver for a given output type or resolution.
One question, will SD PAL be 100% supportable by the P2, given the way the chroma signal is done? I know PAL requires phase reversals which might have been why the P1 had some problems with it, but I'm not sure as I never really played with composite that much on the P1, predominantly it was just VGA.
- P1 counter PLLs seem to have difficulty generating 4.43MHz*16 from 80MHz master clock. Not a problem on P2?
- Some TVs seem picky about horizontal timing (due to using a fixed-length analog delay line to correlate chroma from the previous line with the current line)
The phase reversal basically just means inverting the V (or in P2 terms, Q) coefficient's sign every line, as far as I understand.
I am presuming the former approach would apply as you'd probably want a pure reference colour "tone", though perhaps it also gets flipped for PAL every two lines. I still need to dig into how it all works a bit more.
I'm not sure if the Smartpins support phase adjust ?
"Since the carrier is not transmitted with the video information it has to be generated locally in the receiver. In order that the phase of this locally generated signal can match the transmitted information, a 10 cycle burst of colour subcarrier is added to the video signal shortly after the line sync pulse, but before the picture information, during the so-called back porch. This colour burst is not actually in phase with the original colour subcarrier, but leads it by 45 degrees on the odd lines and lags it by 45 degrees on the even lines. This swinging burst enables the colour decoder circuitry to distinguish the phase of the R-Y vector which reverses every line."
So for PAL it looks like we need to modify the colour burst output phase every second line and so we don't use the SETCFRQ phase, but something phase leading or lagging from it by 45 degrees. I would think that is just a matter of altering the I/Q input values used, hopefully.
Yes, you'd output some RGB color to cause the colorburst to be the appropriate phase and amplitude. You could, also/instead, alter the YIQ coefficients that are applied to the RGB input values.
After we caught up Friday I'm also trying out some of ozpropdev's hyperRAM test code too to see if I can't get a full screen high colour output from my video driver using external memory. That's sort of what I've been striving towards achieving for most of this time. So far it's at least proven my HyperRAM board is functional and I'm getting some data back, but I need to spend more time on it with some integration work. Single file for sharing code is not ideal....does flexgui support multiple input files to build a project? I'll have to check it out if it does.
DAC Channel dddd 3 2 1 0 description . 0000 -- -- -- -- no streamer DAC output 0001 X0 X0 X0 X0 output X0 on all four DAC channels 0010 -- -- X0 X0 output X0 on DAC channels 1 and 0 0011 X0 X0 -- -- output X0 on DAC channels 3 and 2 0100 -- -- -- X0 output X0 on DAC channel 0 0101 -- -- X0 -- output X0 on DAC channel 1 0110 -- X0 -- -- output X0 on DAC channel 2 0111 X0 -- -- -- output X0 on DAC channel 3 1000 !X0 X0 !X0 X0 output X0 diff pairs on all four DAC channels 1001 -- -- !X0 X0 output X0 diff pairs on DAC channels 1 and 0 1010 !X0 X0 -- -- output X0 diff pairs on DAC channels 3 and 2 1011 X1 X0 X1 X0 output X1, X0 pairs on all four DAC channels 1100 -- -- X1 X0 output X1, X0 on DAC channels 1 and 0 1101 X1 X0 -- -- output X1, X0 on DAC channels 3 and 2 1110 !X1 X1 !X0 X0 output X1, X0 diff pairs on all four DAC channels 1111 X3 X2 X1 X0 output X3, X2, X1, X0 on all four DAC channelsMy code does this...and I'm trying the case with syncoptions bit2:0 = 101
' Use of this syncoptions field in the HDTV/SDTV analog submode: ' bit5 = select HD tri-level (1) or standard SD sync (0) timing ' bit4 = select Interlaced (0) or Progressive(1) video frame ' bit3 = select NTSC (0) or PAL (1) colour system for composite video ' bit2:0 = select video output type and DAC(s) used in the pin group ' 000 = Composite video output on DAC0 pin ' 001 = Composite video output on DAC1 pin ' 010 = Composite video output on DAC2 pin ' 011 = Composite video output on DAC3 pin ' 100 = Y-C output on DAC0(Y) & DAC1(C) pins ' 101 = Y-C output on DAC2(Y) & DAC3(C) pins ' 110 = Y-C output on DAC0(Y) & DAC1(C) pins, Composite on DAC2 pin ' 111 = Component video output on DAC1(Pb), DAC2(Y), DAC3(Pr) pins ... getnib a, pb, #5 'extract pin group getbyte b, pb, #3 'get syncoptions field testb b, #2 wc 'test for composite (0), other (1) if_nc jmp #compositevideo rczr b wcz 'convert two lsb's into flags if_z_and_c jmp #componentvideo svideo mov cmodval, #%00_10_1000_0 'enable Y/C video generation mul a, #4 'convert pin group to pin base if_z add a, #2 'high DAC pair output selected if_z setnib m_bs, #%1011, #6 'output X0 and X1 on upper pins if_z setnib m_sn, #%1011, #6 'output X0 and X1 on upper pins if_z setnib m_bv, #%1011, #6 'output X0 and X1 on upper pins if_z setnib m_vi, #%1011, #6 'output X0 and X1 on upper pins if_z setnib m_rf, #%1011, #6 'output X0 and X1 on upper pins add a, #(1<<6) 'setup two pins (Y+C) if_c add a, #(1<<6) 'setup three pins (Y+C+Composite) wrpin dacmode_c, a 'enable DAC modes on pins dirh a 'enable pin output mov sync_003, #1 'idle hsync, idle vsync mov sync_002, #2 'active hsync, idle vsync mov sync_001, #1 'idle hsync, active vsync mov sync_000, #2 'active hsync, active vsync ... ' these modes get patched with the driving cog ID too dacmode_s long %0000_0000_000_1011000000000_01_00000_0 'hsync 123-ohm 3.3V dacmode_c long %0000_0000_000_1011100000000_01_00000_0 'R/G/B 75-ohm 2.0V m_bs long $7fb10000 + H_FP 'before sync m_sn long $7fb10000 + H_SYNC 'sync m_bv long $7fb10000 + H_BP 'before visible m_vi long $7fb10000 + H_VISIBLE 'visible m_rf long $7fb60000 + H_VISIBLE 'visible 8x4b for LUT lookupI've tried setting both %1011 and %1101 into the streamer command's dddd field to get the Y/C X0 and X1 output on the high pair of the 4 bit pin group and it behaves differently in each. %1101 seems to give a diminished output with clipped off negative sync pulses and the other value looks like the inverse of normal as my sync pulses come down from the top, so it's like some type of complemented output. So I am wondering if the DAC channel table above is accurate or not? I'll also need to check that this isn't another p2asm opcode bug too. My setci, setcq, setcy values also remained the same in all cases tested.
Update: p2asm output opcodes look okay:
setnib D,#/S, #n encoding is EEEE1000_00NN_NIDD_DDDDDDD_SSSSSSSSS
Update2: Here are my YIQ parameters for this experiment...
mov b,##(27 << 24) + (53 << 16) + (10 << 8) + 76 setcy b mov b,##((((64*SAT)/100) & $ff)<<24)+((((-53*SAT)/100) & $ff)<<16)+((((-10*SAT)/100) & $ff)<<8) + 74 setci b mov b,##((((-22*SAT)/100) & $ff)<<24)+ ((((-42*SAT)/100) & $ff)<<16)+ ((((64*SAT)/100) & $ff)<<8) + 0 setcq b ' colour saturation depth SAT was set to 70First picture below is a good output of a composite signal when X2 is sending out composite. The Y signal on X0 is essentially the same. This is pretty much what I expected to see.
This second picture below is the diminished Y output on DAC channel 2 pin mapped to X0 with streamer dddd nibble set to %1101. I first thought perhaps this could have been the Chroma channel, but the C channel amplitude is much bigger if I look at it on DAC1 when Y+C is mapped to the lower two pins of the 4 pin group.
Third picture below is possibly complemented? Y output on DAC channel 2 pin mapped to X0 with streamer dddd nibble set to %1011. Though if were were complemented the front and back porch levels should be inverted too and they do not appear to be.
Not sure why I am getting these 2 bad video outputs unless possibly the DAC channel mapping is broken with the colour space converter + streamer output, or the P2 documentation is different to reality.
Update: I'm also seeing some video output on DAC2+DAC3 pins when the streamer nibble 6 "dddd" is set to %1100. It should not be sending out on those pins in that mode from what I can tell. So something is messed up here.
DAC Channel dddd 3 2 1 0 description . 1100 -- -- X1 X0 output X1, X0 on DAC channels 1 and 0So we soon should be able to target VGA, SD/HD component, composite, S-video and DVI over HDMI from the same video driver at various resolutions all with the same control interface and graphics capabilities. That's the plan anyway.
Doing PAL might be tricky with it's special burst flips. I am also not really adhering to any of the rules regarding blanking out the colour burst on particular line sequences over 4/8 frames either due to a lack of COGRAM, but I'll still give it a crack to see how it goes.
I now have 9 COG RAM registers left. With this I want to try to add that pass through sprite mode plus tri-level HD component syncs if I can squeeze it down any further...hopefully the tri-level things shouldn't add any more COGRAM as I set it up at init time. It's becoming a bit of a puzzle to make it all fit now.
What about all of us with RGB TTL monitors?
Has the code been optimized to death? SKIPFed to the max??
Arrggh, you're killing me! Maybe the video DACs could be set into 3.3V output and something could sort of work with the LUT modes, but I'm not sure I'll officially try to support that (yet). Now that's really retro, CGA style.
Yeah I'm on the hunt for places to try more SKIPF after we had so much success with it with our pixel doubling.
Yes I've starting finding a few of those, and a couple of days back I gained 4 longs in the process for the mouse registers. I am on the hunt for more and there will be some left. I know of 3 more COG RAM regs I can gain over what I have already by doing this, and I think I can map more state flags/counters into a common register instead of separate. What I don't like is having to save/restore the two pointer registers ptra/ptrb. That needs 4 longs each time, either 2 push/pop or 4 moves to/from temp regs. I do this twice as the auto-incrementing pointers are so useful for both LUT and HUB read/writes, so that is 8 longs.
I know I will need 1 more instruction for doing the PAL colour burst flip (XOR) every scan line. I already have the second long allocated for the XOR mask in my existing budget.
HD-Sync should be able to hopefully just squeeze in place (with a code overlay at cog setup time).
I will need some more regs for sprite mode (not sure how many, hopefully just a small number), plus any other things I've missed. I could always start to use HUB RAM for code, but it will prevent me from doing ping/pong LUTRAM in 256 colour mode for operating at lower power 1:1 pixel clock:P2 clock ratios.
Interlacing input source data is a problem. Right now in my interlaced NTSC output mode I am sending the same source data each field so it's really more like seeing 240p instead of getting proper 480i source data. Ideally I should offset every second field reading out of the source data. I might be able to do this with my second screen source reg, though that is intended for wrapping. We'll see how best to do it...
I'm glad to hear it. I don't think I'll manage to match every single rule. The HD/SD video modes have been added in right at the end and I just don't have enough resources to be 100% compliant. This driver just started out as DVI text only intended for VGA resolution only operating at 252MHz (it came from some early HDMI+audio experiments), but has grown and grown since then with features and it really does a whole lot more now.
Hey you are right about some displays not caring about the standards so much. I am sending the PAL colour burst frequency with Chip's NTSC phase angle colour instead of PAL's 135/225 degree version, and not alternating it and my LCD is showing a reasonable colour picture (albeit quite saturated) and recognizing it as 50Hz "PAL". LOL.
I've certainly seen some quite interesting old school video effects showing while debugging this thing. Reminds me so much of old worn out videotapes flagging at the top etc. Very retro.
I did some more hunting and found some low hanging fruit and now have about 20 free COGRAM registers. There might be a few more but it is starting to become slim pickings now.
With this extra scrounged RAM I hope to do the following...
1) allow a simple sprite mode, passing through from external COG rendered data buffers directly instead of copying
2) interlaced source address offset in graphics regions (allows page flipping and/or independent field source for 50/60 fields/sec video)
3) better palette handling (see below)
4) a proper status frame counter, right now it is sharing a counter that only counts to 16 for flashing the cursor (may need 2-3 extra regs)
5) option for a shared set of mouse co-ordinates over all regions to help the user out (this would need 3 regs)
6) (eventually) support a low power 1:1 pixel/P2 clock mode for basic "transparent" frame buffer pass through. In this mode no text/mouse/pixel doubling is possible and it would work a bit like the sprite mode but not really have any other capabilities. This mode would not take more register space as it would be patched at boot time, but it would be good to have as it could allow decent NTSC/PAL frame buffer output at 13.5MHz P2 rates, or VGA at 25MHz etc. I think this will come after the initial release.
The 256 entry palette load approach I started out with VGA is now becoming an issue, due to the different hsync options taking more CPU time, with different tri-level and colour bursts etc needing more streamer commands and not leaving large contiguous blocks of CPU time to load the palette. You need over 256 clock cycles to load a 256 entry palette and for low pixel clock ratios and small blanking intervals it may not load in time. So what I think I will have to do is to keep any 256 entry palette in low LUT RAM, and reload it in place on region changes during the active portions on the scanline after the text/graphics scanline has been rendered. This may mean that two sequential regions with different 256 colour palettes changing in the middle of the frame could see colours disrupted towards the end of the scanline. To alleviate this issue I think I will keep the smaller 2/4/16 entry palette in high LUT RAM so this potentially can be hidden if you change different 256 colour regions via the 16 colour palette first - e.g. insert a single black (or other coloured) scanline between two 256 colour regions to avoid noticing it. You could also use a direct colour mode region too instead of one using the 16 colour palette. Both should work.
Unfortunately I don't think I can do any double buffering of 256 entry palettes in my normal operating mode because I need the LUTRAM for my text buffer/pixel doubler (though it may be possible to do this doubling buffering in a future cut-down transparent mode). I think this is all I can do about it right now. I may have similar issues with rendering the mouse in some cases, though only for external RAM sourced data with lower P2 pixel clock ratios. I'm hoping there will be sufficient time available to display one but can't guarantee it over all operating conditions.
I've updated my VGA ANSI driver to support 2 bytes/char (using the standard VGA format that you also use) and 1 byte/char (7 bit ASCII plus 1 bit blinking effect for the cursor). It should be pretty straightforward to adapt the ANSI character output code in vga_text_routines.spinh to your driver.
The source code is in github at:
https://github.com/totalspectrum/p2_vga_text