I did a test where I send different solid colours to the screen with immediate data and this is what I see:
defcolour long $00000000 - see black
defcolour long $0000ff00 - see bright blue
defcolour long $00ff0000 - see bright green
defcolour long $00ffff00 - see bright cyan
defcolour long $ff000000 - see low intensity dull red
defcolour long $ff00ff00 - see bluish colour
defcolour long $ffff0000 - see green with a slight yellow tinge
defcolour long $ffffff00 - see cyanish colour
Might be partially my monitor levels - If I send $ff000000 I see a dim red now, but the weird thing is on other parts of the screen there are other characters that are brighter red than this. It's like a bleed of one colour into another, or maybe I have something wrong in the colour space thing.
It should work okay. If you're getting good HDMI colors, that means the analog color channels should be good, too.
On the sync signals, DAC0[0] is used for VGA HSYNC, while the HDMI keys sync signals from DAC0[1]. Ah, maybe those 3x10-bit custom HDMI sync patterns are wreaking havoc with your VGA monitor, as it's getting crazy color data during HSYNC and VSYNC. Maybe I needed to use DAC0[1] as a color lockout bit for VGA, so that DACs would be $00 during HDMI sync.
The only way around this might be to do 'SETCY/I/Q #0' right before the sync periods. You may have to use an extra XCONT to get a hold of the timing.
It should work okay. If you're getting good HDMI colors, that means the analog color channels should be good, too.
But I am not sure what is wrong. I am going to try another cable and move to another set of pins to see if either helps. I see bright red on the monitor in other cases, so I know it it not the red channel brightness in the monitor itself.
Update1: different pins - moved from base 16 to base 8, same result.
Update2: Different monitor, different cable - same result.
Ah, maybe those 3x10-bit custom HDMI sync patterns are wreaking havoc with your VGA monitor, as it's getting crazy color data during HSYNC and VSYNC. Maybe I needed to use DAC0[1] as a color lockout bit for VGA, so that DACs would be $00 during HDMI sync.
The only way around this might be to do 'SETCY/I/Q #0' right before the sync periods. You may have to use an extra XCONT to get a hold of the timing.
I don't think this is the problem but can't rule it out 100%. I think in the past I have safely sent garbage video to the LCD monitor during the sync periods and all is okay, as I have tried things like that in the past with micro controlled video projects.
I will do now an experiment where I disable DVI and clear all the upper parts of the 10b sync codes, and see if that fixes anything, that should tell us.
Aha! That experiment changed things. Looks like what you say Chip may indeed be the case. Without DVI running I see a reasonable white now - it is very different to before.
I don't mind selecting either VGA or DVI. Having both simultaneously could be cool but is it very useful? Perhaps on a traditional full size DVI connector it would be good.
I re-enabled DVI but modified the sync patterns from the first to the second group of patterns below, by clearing red and green data. If seemed to fix the VGA but the DVI is really weird and not usable as I might expect, I see colour crawl in red and green pixels. I guess it is resynchronizing these channels after losing bitsync for a bit during sync period.
sync_000 long %1101010100_1101010100_1101010100_11 '-vsync -hsync
sync_001 long %1101010100_1101010100_0010101011_10 '-vsync +hsync
sync_002 long %1101010100_1101010100_0101010100_11 '+vsync -hsync
sync_003 long %1101010100_1101010100_1010101011_10 '+vsync +hsync
sync_000 long %0000000000_0000000000_1101010100_11 '-vsync -hsync
sync_001 long %0000000000_0000000000_0010101011_10 '-vsync +hsync
sync_002 long %0000000000_0000000000_0101010100_11 '+vsync -hsync
sync_003 long %0000000000_0000000000_1010101011_10 '+vsync +hsync
The only way around this might be to do 'SETCY/I/Q #0' right before the sync periods. You may have to use an extra XCONT to get a hold of the timing.
I had a quick attempt at this but it didn't seem to help. Plus even if there was a way to make it to work it added up to 9 longs more, three to zero the colours, three to re-enable plus 3 longs to hold the rbg co-efficients, and any more for additional XCONTs and XCONT arguments to solve it, so probably 11 longs minimum, perhaps more. For now anyway I am just going to make this driver an either/or choice of DVI or VGA at initialisation time.
I re-enabled DVI but modified the sync patterns from the first to the second group of patterns below, by clearing red and green data. If seemed to fix the VGA but the DVI is really weird and not usable as I might expect, I see colour crawl in red and green pixels. I guess it is resynchronizing these channels after losing bitsync for a bit during sync period.
sync_000 long %1101010100_1101010100_1101010100_11 '-vsync -hsync
sync_001 long %1101010100_1101010100_0010101011_10 '-vsync +hsync
sync_002 long %1101010100_1101010100_0101010100_11 '+vsync -hsync
sync_003 long %1101010100_1101010100_1010101011_10 '+vsync +hsync
sync_000 long %0000000000_0000000000_1101010100_11 '-vsync -hsync
sync_001 long %0000000000_0000000000_0010101011_10 '-vsync +hsync
sync_002 long %0000000000_0000000000_0101010100_11 '+vsync -hsync
sync_003 long %0000000000_0000000000_1010101011_10 '+vsync +hsync
Try again. A valid TMDS code for $00 is %0100000000, but that won't help if two high bytes must be zero for VGA.
sync_000 long %0100000000_0100000000_1101010100_11 '-vsync -hsync
sync_001 long %0100000000_0100000000_0010101011_10 '-vsync +hsync
sync_002 long %0100000000_0100000000_0101010100_11 '+vsync -hsync
sync_003 long %0100000000_0100000000_1010101011_10 '+vsync +hsync
TonyB_ I tried your idea and get no more crawl but only yellow and white colour in DVI. VGA looks okay. I don't think those codes would produce valid 2b data during control period unfortunately, even though they are not for the blue sync channel.
Perhaps use %1101010100 for red & green when syncs active and %010000000 when not, or some other permutation?
It's better but not perfect. I see ghosting now on DVI like a one pixel colour offset between colours in character data, but the colours look reasonable.
I don't have any black level offset set in the colour space data fields in bit 7:0 passed into the setcy, setci, setcq so it should be zero. Plus the CMOD[3:1] bits are all zero too.
Hmm, I wonder if I could use that colour offset to null out the 10b value?
Update: Rethinking that, I'd still be in the same place with the lack of syncing with the xcont instructions and the overhead of all the extra instructions, so no better than simply clearing the co-efficients anyway.
I'm getting an analog VGA signal out now, at the same time as DVI from the same COG
However the colours are wrong and I am not sure what is going on. It's as if another colour like green or blue channel is coming out the red channel pins instead of red, when I swap over to DVI to compare it. It looks like real green and real blue is okay, any pure red appear to come out black on the screen, but I need to make some proper colour patterns to see what is up.
Might be partially my monitor levels - If I send $ff000000 I see a dim red now, but the weird thing is on other parts of the screen there are other characters that are brighter red than this. It's like a bleed of one colour into another, or maybe I have something wrong in the colour space thing.
Is this saying only VGA colours are 'off', the DVI is still all OK ?
Of the VGA is it only RED that is unexpected ?
Ah, maybe those 3x10-bit custom HDMI sync patterns are wreaking havoc with your VGA monitor, as it's getting crazy color data during HSYNC and VSYNC. Maybe I needed to use DAC0[1] as a color lockout bit for VGA, so that DACs would be $00 during HDMI sync..
I've seen VGA monitors get confused by info during sync, but in my case it was errant pixels affecting auto-timing adjustments. Never seen solours go off.
If Green was the errant colour, one could suspect the possible Sync-On-Green option activity, but red alone affected is a puzzle ?
Ah, maybe those 3x10-bit custom HDMI sync patterns are wreaking havoc with your VGA monitor, as it's getting crazy color data during HSYNC and VSYNC. Maybe I needed to use DAC0[1] as a color lockout bit for VGA, so that DACs would be $00 during HDMI sync..
I've seen VGA monitors get confused by info during sync, but in my case it was errant pixels affecting auto-timing adjustments. Never seen solours go off.
If Green was the errant colour, one could suspect the possible Sync-On-Green option activity, but red alone affected is a puzzle ?
I think it's as Chip says, the DACs are getting control codes, not RGB values, during syncs and blanking. Instead of black levels of 0 during back porch, they are R = 213, G = 53, B =< 77. Red much too high.
VGA requires the blanking period to contain only pure black. The obvious issue of retrace lines on CRT monitors aside, the color channels may be AC-coupled on the input before they go into the ADC (thus black level has to be established during HBLANK)
I think it's as Chip says, the DACs are getting control codes, not RGB values, during syncs and blanking. Instead of black levels of 0 during back porch, they are R = 213, G = 53, B =< 77. Red much too high.
Ah, ok, maybe there is a kludge where a lower red can be fed in, but not lose DVI information.
That may be tolerable for some uses, tho the VGA would not quite match the DVI
For now it's going to be one output type (analog vs digital) or the other, this is so the VGA colours don't get messed up when DVI is active. I don't want a workaround that works but still slightly impacts the colours on VGA, or one where the COG resource overhead of the workaround is non-trivial. If I could flip a CMOD bit to make it happen that wouldn't be quite as bad though. Like temporarily stop outputting VGA, then resume it, or float the RGB pins perhaps? The problem is timing the xcont to make it work, you have to do it at the right time and you might be in the middle of doing something else when it happens.
So in the DAC output mode of my driver I am able to get some less demanding non-pixel doubled modes working at 1024x768 resolution now too which is nice. I'm hanging out for high performance external memory driver to see this in high colour depth output. I think 16bpp would be just a bit too much for it unless a 16 bit wide HyperRAM driver was developed perhaps. 800x600x16bpp should be doable @ 40MHz pixel clock with a 200MHz P2.
I've dropped the pixel clock divider down to 5x from 10x so a 325MHz P2 can do text & graphics with XGA timing @60Hz with the pixel clock set at 65MHz. Seems to be working okay in an initial quick test. A 6x clock divider would give more headroom for other pixel doubled modes. Some reduced blanking could drop the P2 clock requirements down too.
Depending on the rev A, rev B streamer differences, this driver code (or a patched version of it) might work on a rev A board in VGA mode perhaps.
Was able to try to get RGBS working (4 pin VGA) without the VSYNC on my LCD monitor by XORing H&V syncs on DAC0 output. I would like to try RGsB (sync on green) too. I think that would be a nice combination of sync capabilities. Perhaps a 1Vp-p vs TTL option too in case some devices might prefer/require composite video sync levels instead of TTL. Then we would have 5 pin RGBHV, 4 pin RGBS, 3 pin RGsB capabilities in the driver, all selectable at initialization time.
From SyncOnGreen, adding YPbPr wouldn't be too far off, either
Yes. It looks like that would just be a colour space change and output the sync on the red/Y channel DAC3 instead of the green channel with DAC2, using different CMOD bits.
I'll probably end up with this combination in my driver for RGB/YUV. There will also in future be some Composite/s-video options as well.
' Sync / Options
' --------------
' In Analog mode this controls if/how the vertical sync is generated and
' in which format to output the video.
'
' If a separate VSYNC signal is desired, then this field indicates which
' P2 pin will output the VSYNC signal, the video output will be RGBHV.
'
' If RGBHV is not required then this field's value should be set to one
' of four special values that would overlap with the pins in the group
' defined by the following Pins field, and otherwise could not be used:
'
' PinGroupBase + 0 - use RGBS with S containing VSYNC XOR HSYNC (TTL)
' PinGroupBase + 1 - use RGBS with S containing VSYNC XOR HSYNC (1Vp-p)
' PinGroupBase + 2 - output RGsB with "Sync-on-Green" (DAC2)
' PinGroupBase + 3 - output YUV with Sync on Y (DAC3)
' Possible future use of this field in Analog Composite/S-video submode:
' bit5 = select NTSC/PAL
' bit4 = select Interlaced/Non-interlaced
' bit3:2 = DAC output selects/enables
' 00 = Composite only on DAC pin[bit1:bit0]
' 01 = Y + optional composite on DAC[1:bit0] if bit1 enables it
' 10 = C + optional composite on DAC[1:bit0] if bit1 enables it
' 11 = Y+C + optional composite on DAC[1:bit0] " " " "
'
Does anyone know if the SyncOnGreen approach where you mix sync to the green channel output also needs to push all colour channels up by the same 0.3V so the absolute levels match and allow the green one to independently be reduced down to 0V when sync is happening?
I am just wondering if that is the case or if the Red and Blue channels still stick to their 0-0.7V range while green is now 0-1V (with its extended range for sync). I guess this might be moot if capacitively coupled...
My Sony monitor specs list this...I also wonder if sync on green only works with negative syncs? The P2 can't really drive negative voltages.
Analog RGB: 0.700 Vp-p(positive), 75 Ω
Sync Signal: H/V separate or composite sync:TTL 2 kΩ, Polarity free Sync on Green: 0.3 Vp-p(negative)
Looking at the equations for the colourspace converter I can't see how it can work with the streamer data either in YPrPb mode or with SyncOnGreen sync without using the LUT (limiting to <=256 colours) or having every coloured pixel in the 24bpp streamed bitmaps having the special sync level pre-inserted into its least significant byte of the long...(and this is assuming that byte doesn't get cleared/ignored, haven't tested it).
The problem is that it appears to need DAC0 data as the sync level offset (switched on or off by one of 3 CMOD bits), and where can it get this value from when streaming in pixels from the HUB if they are not 32 bit based and there is no least significant byte to get carried through?
Is this one of the limitations of the P2? Will YPrPb mode be restricted to 256 colours, or am I missing something here?
@cgracey , have you had the YPrPb mode working yet?
Comments
It should work okay. If you're getting good HDMI colors, that means the analog color channels should be good, too.
On the sync signals, DAC0[0] is used for VGA HSYNC, while the HDMI keys sync signals from DAC0[1]. Ah, maybe those 3x10-bit custom HDMI sync patterns are wreaking havoc with your VGA monitor, as it's getting crazy color data during HSYNC and VSYNC. Maybe I needed to use DAC0[1] as a color lockout bit for VGA, so that DACs would be $00 during HDMI sync.
The only way around this might be to do 'SETCY/I/Q #0' right before the sync periods. You may have to use an extra XCONT to get a hold of the timing.
Update1: different pins - moved from base 16 to base 8, same result.
Update2: Different monitor, different cable - same result.
I don't think this is the problem but can't rule it out 100%. I think in the past I have safely sent garbage video to the LCD monitor during the sync periods and all is okay, as I have tried things like that in the past with micro controlled video projects.
I will do now an experiment where I disable DVI and clear all the upper parts of the 10b sync codes, and see if that fixes anything, that should tell us.
sync_000 long %1101010100_1101010100_1101010100_11 '-vsync -hsync
sync_001 long %1101010100_1101010100_0010101011_10 '-vsync +hsync
sync_002 long %1101010100_1101010100_0101010100_11 '+vsync -hsync
sync_003 long %1101010100_1101010100_1010101011_10 '+vsync +hsync
sync_000 long %0000000000_0000000000_1101010100_11 '-vsync -hsync
sync_001 long %0000000000_0000000000_0010101011_10 '-vsync +hsync
sync_002 long %0000000000_0000000000_0101010100_11 '+vsync -hsync
sync_003 long %0000000000_0000000000_1010101011_10 '+vsync +hsync
I had a quick attempt at this but it didn't seem to help. Plus even if there was a way to make it to work it added up to 9 longs more, three to zero the colours, three to re-enable plus 3 longs to hold the rbg co-efficients, and any more for additional XCONTs and XCONT arguments to solve it, so probably 11 longs minimum, perhaps more. For now anyway I am just going to make this driver an either/or choice of DVI or VGA at initialisation time.
Try again. A valid TMDS code for $00 is %0100000000, but that won't help if two high bytes must be zero for VGA.
It's better but not perfect. I see ghosting now on DVI like a one pixel colour offset between colours in character data, but the colours look reasonable.
Update: Rethinking that, I'd still be in the same place with the lack of syncing with the xcont instructions and the overhead of all the extra instructions, so no better than simply clearing the co-efficients anyway.
Is this saying only VGA colours are 'off', the DVI is still all OK ?
Of the VGA is it only RED that is unexpected ?
I've seen VGA monitors get confused by info during sync, but in my case it was errant pixels affecting auto-timing adjustments. Never seen solours go off.
If Green was the errant colour, one could suspect the possible Sync-On-Green option activity, but red alone affected is a puzzle ?
I think it's as Chip says, the DACs are getting control codes, not RGB values, during syncs and blanking. Instead of black levels of 0 during back porch, they are R = 213, G = 53, B =< 77. Red much too high.
VGA requires the blanking period to contain only pure black. The obvious issue of retrace lines on CRT monitors aside, the color channels may be AC-coupled on the input before they go into the ADC (thus black level has to be established during HBLANK)
Ah, ok, maybe there is a kludge where a lower red can be fed in, but not lose DVI information.
That may be tolerable for some uses, tho the VGA would not quite match the DVI
http://forums.parallax.com/discussion/170676/p2-dvi-vga-driver#latest
I've dropped the pixel clock divider down to 5x from 10x so a 325MHz P2 can do text & graphics with XGA timing @60Hz with the pixel clock set at 65MHz. Seems to be working okay in an initial quick test. A 6x clock divider would give more headroom for other pixel doubled modes. Some reduced blanking could drop the P2 clock requirements down too.
Depending on the rev A, rev B streamer differences, this driver code (or a patched version of it) might work on a rev A board in VGA mode perhaps.
Yes. It looks like that would just be a colour space change and output the sync on the red/Y channel DAC3 instead of the green channel with DAC2, using different CMOD bits.
I'll probably end up with this combination in my driver for RGB/YUV. There will also in future be some Composite/s-video options as well.
I am just wondering if that is the case or if the Red and Blue channels still stick to their 0-0.7V range while green is now 0-1V (with its extended range for sync). I guess this might be moot if capacitively coupled...
My Sony monitor specs list this...I also wonder if sync on green only works with negative syncs? The P2 can't really drive negative voltages.
Analog RGB: 0.700 Vp-p(positive), 75 Ω
Sync Signal: H/V separate or composite sync:TTL 2 kΩ, Polarity free Sync on Green: 0.3 Vp-p(negative)
The problem is that it appears to need DAC0 data as the sync level offset (switched on or off by one of 3 CMOD bits), and where can it get this value from when streaming in pixels from the HUB if they are not 32 bit based and there is no least significant byte to get carried through?
Is this one of the limitations of the P2? Will YPrPb mode be restricted to 256 colours, or am I missing something here?
@cgracey , have you had the YPrPb mode working yet?
FY[7:0] = CY[7:0] + (DAC0 & {8{CMOD[3]}}) + Y[7:0] (VGA R / HDTV Y) FI[7:0] = CI[7:0] + (DAC0 & {8{CMOD[2]}}) + I[7:0] (VGA G / HDTV Pb) FQ[7:0] = CQ[7:0] + (DAC0 & {8{CMOD[1]}}) + Q[7:0] (VGA B / HDTV Pr)