Shop Learn
All PASM2 gurus - help optimizing a text driver over DVI? - Page 12 — Parallax Forums

All PASM2 gurus - help optimizing a text driver over DVI?

191012141529

Comments

  • evanhevanh Posts: 12,894
    edited 2019-10-27 04:41
    rogloh wrote: »
    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)
    
    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.
  • evanh wrote: »
    ...just toggle the one needed at each sync edge.

    Wuerfel_21 wrote: »
    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…

    ' 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
  • evanhevanh Posts: 12,894
    edited 2019-10-27 05:41
    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.
  • Wuerfel_21Wuerfel_21 Posts: 2,494
    edited 2019-10-27 05:49
    rogloh wrote: »
    evanh wrote: »
    ...just toggle the one needed at each sync edge.

    Wuerfel_21 wrote: »
    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?

  • roglohrogloh Posts: 4,025
    edited 2019-10-27 05:54
    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...
    1280 x 858 - 2M
  • Wuerfel_21 wrote: »
    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?

    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?
  • During active video, DAC0 would then be zero (as most streamer modes seem to set it)
  • evanhevanh Posts: 12,894
    rogloh wrote: »
    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.

  • "evanh wrote:
    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.
  • Wuerfel_21 wrote: »
    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.
  • roglohrogloh Posts: 4,025
    edited 2019-10-27 06:13
    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...

    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_NEG
    
  • 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.
  • Wuerfel_21 wrote: »
    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.
  • evanhevanh Posts: 12,894
    edited 2019-10-27 06:39
    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.
  • roglohrogloh Posts: 4,025
    edited 2019-10-27 06:48
    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
  • Tubular wrote: »
    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.
  • Works on the CRT! Looks crisp, LOL. Aspect ratio is a bit weird, I have 1920x520 lines @ 60Hz, but it works. I am running at 350MHz though.
  • roglohrogloh Posts: 4,025
    edited 2019-10-27 09:26
    Here's what the 1920x520 looks like on the big Sony CRT.

    Update: I tell you what 1024x768 looks really fabulous on this CRT monitor from the P2, so clean. 315MHz P2. :smile:
    1280 x 918 - 2M
  • Nice work Roger. Always pays to try a different monitor doesn't it?
  • rogloh wrote: »
    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.
  • roglohrogloh Posts: 4,025
    edited 2019-10-27 11:06
    Wuerfel_21 wrote: »
    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.
  • rogloh wrote: »
    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.
  • Been there before.
  • roglohrogloh Posts: 4,025
    edited 2019-10-27 12:04
    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?
  • Wuerfel_21Wuerfel_21 Posts: 2,494
    edited 2019-10-27 12:16
    Assuming ITU-R BT.601... (note that Pb and Pr are signed and thus CI/CQ[7:0] have to be $80)

    24807e87309699852a750cb9c2faff0505220c63

    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.
  • roglohrogloh Posts: 4,025
    edited 2019-10-27 12:35
    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
Sign In or Register to comment.