With all three having individual offset enables, for sync, just toggle the one needed at each sync edge. The other two can stay on or off continuously, depending on whether wanting them biased or not. I think.
The addition isn't saturating, is it? So you could have the offset in CY[7:0] and use a DAC0 value > $80 to indicate sync?
I might not understand the problem quite correctly though.
The addition isn't saturating, is it? So you could have the offset in CY[7:0] and use a DAC0 value > $80 to indicate sync?
I might not understand the problem quite correctly though.
The problem is selecting the DAC0 level itself, not so much enabling/disabling it in the SETCMOD instruction.
What is controlling this value? Yes you can control/boost the signal during sync periods with immediate data, but what about active portion of the video? Does the overall level of Y then drop back to a lower value? If CY/CI/CQ also need dynamic adjustment to compensate between active/blanking portions it is tricky to retime things with the start of pixel data, sync edges etc, though perhaps not impossible.
Wow, just got 1280x720@50Hz out of my P2 driver onto the Dell LCD in analog mode at 5x pixel clock (252MHz). Because the pixels are being scaled up by 1.5x to get 1920 pixel resolution on the panel its not the sharpest text but it is really sending it from the P2 at this speed. I could likely do 60Hz with increase in the P2 clock. Here’s the reduced timing that worked…
When I've done those experiments the monitor/TV sometimes picks the wrong resolution on top of what scaling it might be attempting. That then really messes up the image with pixels at varying widths.
The addition isn't saturating, is it? So you could have the offset in CY[7:0] and use a DAC0 value > $80 to indicate sync?
I might not understand the problem quite correctly though.
The problem is selecting the DAC0 level itself, not so much enabling/disabling it in the SETCMOD instruction.
What is controlling this value? Yes you can control/boost the signal during sync periods with immediate data, but what about active portion of the video? Does the overall level of Y then drop back to a lower value? If CY/CI/CQ also need dynamic adjustment to compensate between active/blanking portions it is tricky to retime things with the start of pixel data, sync edges etc, though perhaps not impossible.
Uhm, as far as I can tell:
- Set up DAC for 1V p-p
- 255*0.3 = 76 (roughly)
- Set up matrix such that Y goes between 0 and 179 (=255-76)
- Set CY[7:0] to 76
- To send a sync pulse, send immediate pixels with DAC1/2/3=0 and DAC0=180 (180+76=256=0)
Or am I misunderstanding your problem and/or the hardware doc?
Here's what the 1280x720 mode looks like... text is pretty ugly, might look better on a real 1280 panel. The picture was from a 16bpp photo I'd scaled to test 640x400 stuff, so it is shown twice in the 1280 wide mode. Monitor does have a bit of a hard time auto adjusting on to the pixels when it first starts.
Update: going to try 1920x540 to see if it takes it...
Here's what the 1280x720 mode looks like... text is pretty ugly,
Yeah, that's picked a lower resolution than you're outputting. There should be an info of what the monitor thinks in its menus. Often can be turned on as an automatic message for a few seconds for each detected change.
Yeah, that's picked a lower resolution than you're outputting. There should be an info of what the monitor thinks in its menus. Often can be turned on as an automatic message for a few seconds for each detected change.
832x624 @50Hz is what it sensed on the info screen of the Dell LCD. It doesn't like it much.
During active video, DAC0 would then be zero (as most streamer modes seem to set it)
Ok, I see what you are doing, you are letting the addition of the sync wrap around back to zero. I'll think about this more, that may help resolve things.
Just tried sending 1920 wide, my monitor displays an image but again it sensed the wrong resolution. It says 800x600 when I am sending 1920x540 (inside 2048x635 total envelope) at 325MHz with a 5x pixel divider. The good thing is the driver is still doing its thing. I also tried a variant with 600 active lines (as this panel is 1920x1200) but it didn't fix it, still reads 800x600. Damn, would be cool to find a way to really show 1920 pixels. Perhaps the cable quality isn't helping...
The cable should have nothing to do with this, the monitor just picks its sampling rate based on the vertical resolution.
Try digging through the OSD menu and see if the "clock" adjustment goes far enough to fix the issue.
The cable should have nothing to do with this, the monitor just picks its sampling rate based on the vertical resolution.
Try digging through the OSD menu and see if the "clock" adjustment goes far enough to fix the issue.
I just tried doing manual adjustment but it doesn't let me reach the range needed to fix the problem.
For VGA LCDs at least, it's all about hsync and vsync frequencies. I think it will only chose from the modes it knows. The monitor will decide on the resolution before it even attempts to sync up with the dot clock. If it only has, say, five modes with 50 Hz vsync in its list, then those are all it will choose from.
I should also try 60Hz then too (if I can get that high).
Update: Tried it at 350MHz with 70MHz dot clock sending 1920x540@60Hz, didn't help. Now it thinks it's 640x480 res. So doesn't look good for a 1920 wide mode at this point. Maybe an HDTV might do better if it takes 30Hz signals over VGA or possibly component.
What are you doing with the vsync width? Is it always 3? Might be worth trying 8 or 10
I tried 8 and 10 doesn't fix it. I think as evanh mentions the LCD monitor is just choosing based on the sync frequencies. I am going to feed it to my CRT now to see what it gives.
I should also try 60Hz then too (if I can get that high).
Update: Tried it at 350MHz with 70MHz dot clock sending 1920x540@60Hz, didn't help. Now it thinks it's 640x480 res. So doesn't look good for a 1920 wide mode at this point. Maybe an HDTV might do better if it takes 30Hz signals over VGA or possibly component.
1080i is basically 1920x540, except with half-lines for interlacing. Every HDTV should support it on the component input. 1080i @ 50Hz is also a thing.
Also +1 on CRT crispness. Have you ever tried 320x240@120Hz? Looks similar to an expensive SD broadcast monitor.
Uhm, as far as I can tell:
- Set up DAC for 1V p-p
- 255*0.3 = 76 (roughly)
- Set up matrix such that Y goes between 0 and 179 (=255-76)
- Set CY[7:0] to 76
- To send a sync pulse, send immediate pixels with DAC1/2/3=0 and DAC0=180 (180+76=256=0)
...
Further to your suggestion Wuerfel_21 I tried this out:
I setup the CMOD as
%00_01_0_010_0
I setup the SETCY, SETCI, SETCQ values as:
$5a_00_00_4c
$00_5a_00_4c
$00_00_5a_4c
respectively. In theory this gives each DAC colour channel a range from 0.70Vp-p range and offset of ~+0.3V.
I setup the hsync0 (inactive sync, blanking portion symbol for DAC0) as #180 ($b4),
which in theory should cancel out the $4c offset value above to get 0 when sent out and activated.
and I setup hsync1 (active sync portion symbol for DAC0) as #0
and I swap these two values around prior to/and after active VYSNC. I also disabled HSYNC DAC 0 channel and the VSYNC pin I was using prior to this.
It doesn't sync on my CRT monitor which I know is capable of SyncOnGreen. I don't know why yet. I'll have to dig out the scope tomorrow to see what video signals it is sending out, or maybe this technique doesn't work for SyncOnGreen.
I also tried reversing the initial values of hsync0 and hsync1 too, didn't help.
EDIT: Whoa, I'm lying above, after the swap and a retest, it does seem to work. Need to double-check everything now to make sure I did what I said above.
EDIT2: It is working. It needed the swap. I guess it always needs negative HSYNC polarity and it gets flipped during VSYNC, I must have started with it the other way around.
So now I know how to support RGBHV, RBGS and RGsB in my driver, I'll try to add it in properly now.
EDIT: Whoa, I'm lying above, after the swap and a retest, it does seem to work. Need to double-check everything now to make sure I did what I said above.
Happens to me all the time. Change something in the code, run it, see no change, be confused. Until I realize that I never actually compiled it.
Just plugged my SyncOnGreen test video output into the Dell monitor's component inputs when sending VGA resolution. I see a picture but the colours are all obviously wrong. I'll have to figure out the right coefficient mappings and see what it looks like in YPrPb mode. Not the clearest looking thing (very soft) but this monitor never did particularly nice video.
Does anyone already know what the SETCQ/SETCI/SETCY values should be?
Great, but how do we map this according to the 0.3V sync thing above?
Would I be right in thinking we need to scale all these by a factor of 0.7 and add the $4c to each CI/CQ/CY again, or is more complicated now due to the negative offsets? Are the negative coefficients treated as subtractions from additions to $80 after being scaled by 0.7 and multiplied by 128?
No, only Y is 0.7V p-p with -0.3V sync.
Pb and Pr use the full 1V range (but their black level is at the center)
Also don't forget to set CMOD[4] to enable sign-extension of coefficents
Comments
I might not understand the problem quite correctly though.
The problem is selecting the DAC0 level itself, not so much enabling/disabling it in the SETCMOD instruction.
What is controlling this value? Yes you can control/boost the signal during sync periods with immediate data, but what about active portion of the video? Does the overall level of Y then drop back to a lower value? If CY/CI/CQ also need dynamic adjustment to compensate between active/blanking portions it is tricky to retime things with the start of pixel data, sync edges etc, though perhaps not impossible.
' 50Hz 1280x720
V_VISIBLE = 720
V_FP = 1
V_SYNC = 2
V_BP = 1
H_VISIBLE = 1280
H_FP = 16
H_SYNC = 48
H_BP = 48
HZ = 50
V_SYNC_POLARITY = SYNC_NEG
H_SYNC_POLARITY = SYNC_NEG
Uhm, as far as I can tell:
- Set up DAC for 1V p-p
- 255*0.3 = 76 (roughly)
- Set up matrix such that Y goes between 0 and 179 (=255-76)
- Set CY[7:0] to 76
- To send a sync pulse, send immediate pixels with DAC1/2/3=0 and DAC0=180 (180+76=256=0)
Or am I misunderstanding your problem and/or the hardware doc?
Update: going to try 1920x540 to see if it takes it...
What about the DAC0 value during active video portion? What should it be and where is it sourced from, and how does it affect the outputs?
832x624 @50Hz is what it sensed on the info screen of the Dell LCD. It doesn't like it much.
Ok, I see what you are doing, you are letting the addition of the sync wrap around back to zero. I'll think about this more, that may help resolve things.
This is what I used but not that great.
' 50Hz 1920X600 V_VISIBLE = 600 V_FP = 10 V_SYNC = 4 V_BP = 21 H_VISIBLE = 1920 H_FP = 32 H_SYNC = 64 H_BP = 32 HZ = 50 V_SYNC_POLARITY = SYNC_NEG H_SYNC_POLARITY = SYNC_NEGTry digging through the OSD menu and see if the "clock" adjustment goes far enough to fix the issue.
I just tried doing manual adjustment but it doesn't let me reach the range needed to fix the problem.
Update: Tried it at 350MHz with 70MHz dot clock sending 1920x540@60Hz, didn't help. Now it thinks it's 640x480 res. So doesn't look good for a 1920 wide mode at this point. Maybe an HDTV might do better if it takes 30Hz signals over VGA or possibly component.
I tried 8 and 10 doesn't fix it. I think as evanh mentions the LCD monitor is just choosing based on the sync frequencies. I am going to feed it to my CRT now to see what it gives.
Update: I tell you what 1024x768 looks really fabulous on this CRT monitor from the P2, so clean. 315MHz P2.
1080i is basically 1920x540, except with half-lines for interlacing. Every HDTV should support it on the component input. 1080i @ 50Hz is also a thing.
Also +1 on CRT crispness. Have you ever tried 320x240@120Hz? Looks similar to an expensive SD broadcast monitor.
Further to your suggestion Wuerfel_21 I tried this out:
I setup the CMOD as
%00_01_0_010_0
I setup the SETCY, SETCI, SETCQ values as:
$5a_00_00_4c
$00_5a_00_4c
$00_00_5a_4c
respectively. In theory this gives each DAC colour channel a range from 0.70Vp-p range and offset of ~+0.3V.
I setup the hsync0 (inactive sync, blanking portion symbol for DAC0) as #180 ($b4),
which in theory should cancel out the $4c offset value above to get 0 when sent out and activated.
and I setup hsync1 (active sync portion symbol for DAC0) as #0
and I swap these two values around prior to/and after active VYSNC. I also disabled HSYNC DAC 0 channel and the VSYNC pin I was using prior to this.
It doesn't sync on my CRT monitor which I know is capable of SyncOnGreen. I don't know why yet. I'll have to dig out the scope tomorrow to see what video signals it is sending out, or maybe this technique doesn't work for SyncOnGreen.
I also tried reversing the initial values of hsync0 and hsync1 too, didn't help.
EDIT: Whoa, I'm lying above, after the swap and a retest, it does seem to work. Need to double-check everything now to make sure I did what I said above.
EDIT2: It is working. It needed the swap. I guess it always needs negative HSYNC polarity and it gets flipped during VSYNC, I must have started with it the other way around.
So now I know how to support RGBHV, RBGS and RGsB in my driver, I'll try to add it in properly now.
Happens to me all the time. Change something in the code, run it, see no change, be confused. Until I realize that I never actually compiled it.
Does anyone already know what the SETCQ/SETCI/SETCY values should be?
Technically ITU-R BT.709 is the new HDTV colorspace, but I couldn't find a nice graphic for that, lol. Doesn't matter that much I think.
Would I be right in thinking we need to scale all these by a factor of 0.7 and add the $4c to each CI/CQ/CY again, or is more complicated now due to the negative offsets? Are the negative coefficients treated as subtractions from additions to $80 after being scaled by 0.7 and multiplied by 128?
Pb and Pr use the full 1V range (but their black level is at the center)
Also don't forget to set CMOD[4] to enable sign-extension of coefficents