P2 DVI/VGA driver

12345679»

Comments

  • TonyB_TonyB_ Posts: 1,524
    edited 2020-08-30 - 09:24:11
    According to the AT070TN92 spec, HBlanking (HSync + HBackPorch) = 46 always, therefore
    custom_lcd_timing
    '800 x 480, option 1
    long	CLK270MHz
    long	270000000
    long	(1<<31) | (36 << 24) | (16 << 16) | (30 << 8) | (800/8) ' 882 pixels
    long	(1<<31) | (7 << 23) | (3 << 20) | (20 << 11) | 480  ' 510 lines
    long	10 << 8
    long	0
    long	0
    
    or
    custom_lcd_timing
    '800 x 480, option 2
    long	CLK270MHz
    long	270000000
    long	(1<<31) | (16 << 24) | (16 << 16) | (30 << 8) | (800/8) ' 862 pixels
    long	(1<<31) | (19 << 23) | (3 << 20) | (20 << 11) | 480  ' 522 lines
    long	10 << 8
    long	0
    long	0
    
    Option 2 tests minimum pixels/line and is slightly closer to 60.0Hz, but Option 1 might be preferable as 20 extra pixels/line means a little more time to do things.

    EDIT:
    After testing, these two options do not work with the Parallax 7" HDMI display.
  • roglohrogloh Posts: 2,768
    edited 2020-08-30 - 11:22:45
    Yeah TonyB_ option 1 is nicer on the driver, but interestingly the original values of horizontal sync width and back porch that don't add up to 46 pixels still did work for dgately so perhaps that data sheet is not 100% applicable to that panel, not really sure there.

    Fiddling about with my Dell monitor over DVI, I can also get it to sync at 800x480 settings that dgately used.

    I can also hit 800x600 over DVI at ~50Hz with the P2 @252MHz using this:
    svga_dvi_timing   ' massively reduced blanking for 800x600 50Hz at 25.2MHz clk YMMV
                long   CLK252MHz
                long   252000000
                       '_HSyncPolarity___FrontPorch__SyncWidth___BackPorch__Columns
                       '     1 bit         7 bits      8 bits      8 bits    8 bits
                long   (SYNC_POS<<31) | (  8<<24) | (  8<<16) | (  8<<8 ) | (800/8)
                       
                       '_VSyncPolarity___FrontPorch__SyncWidth___BackPorch__Visible
                       '     1 bit         8 bits      3 bits      9 bits   11 bits
                long   (SYNC_POS<<31) | (  2<<23) | (  2<<20) | ( 11<<11) | 600
                long    10 << 8
                long    0
                long    0   ' reserved for CFRQ parameter
    

    Also I then pushed it up to ~60Hz refresh with this (824 x 623) @ 308MHz:
    svga_dvi_timing   ' massively reduced blanking for 800x600 60Hz at 30.8MHz clk YMMV
                long   CLK308MHz
                long   308000000
                       '_HSyncPolarity___FrontPorch__SyncWidth___BackPorch__Columns
                       '     1 bit         7 bits      8 bits      8 bits    8 bits
                long   (SYNC_POS<<31) | (  8<<24) | (  8<<16) | (  8<<8 ) | (800/8)
                       
                       '_VSyncPolarity___FrontPorch__SyncWidth___BackPorch__Visible
                       '     1 bit         8 bits      3 bits      9 bits   11 bits
                long   (SYNC_POS<<31) | (  4<<23) | (  2<<20) | ( 17<<11) | 600
                long    10 << 8
                long    0
                long    0   ' reserved for CFRQ parameter
    

    Not sure how many DVI monitors will like that fairly extreme reduced blanking but it worked for me. Of course it can be tweaked further and/or use other P2 clock rates to gain more horizontal blanking which is nicer for the driver if you wanted a mouse sprite or borders to operate in its spare cycles. But at least 800x600 is possible at 60Hz over DVI which is quite handy.

    Update : 1024x600 output at ~50Hz is also achievable at 320MHz over DVI with my driver. This is another common panel size. 320MHz is probably just asking too much from the overclocked HyperRAM though. Of course for lower panel refresh we can go higher resolutions, I know Chip was able to get HD (1280x720) going at low refresh too. The good thing is this is all programmable and easy to play around with to see what works and what doesn't.
  • Sorry, could not get TonyB_'s or rogloh's latest to work on the 7 inch LCD...
  • roglohrogloh Posts: 2,768
    edited 2020-08-30 - 02:11:45
    Ok, stick with what worked dgately. I tried your working timing on my Dell monitor with my latest driver and found it still is able to get a mouse sprite rendered too over coloured text and still runs the demanding 8 bit LUT mode. Even with up to 48 pixel border width at the sides all modes seemed to work and allow the mouse to be rendered. At some point it should fail if the border gets too big but I didn't push it. I also didn't try multiple regions with text and the mouse enabled, I suspect that might also eventually hit a wall.

    The really good thing with DVI modes is that it always gives you a 10x P2 clock, so there are typically plenty of cycles to go around.
  • dgately wrote: »
    Sorry, could not get TonyB_'s or rogloh's latest to work on the 7 inch LCD...

    Thanks for trying my two options. I've edited my post to say they don't work with the Parallax 7" display, which obviously doesn't agree totally with the AT070TN92 spec posted earlier.

    I'm very impressed that rogloh's 270MHz suggested values (reproduced below) worked first time!
    DAT
    custom_lcd_timing
    long CLK270MHz
    long 270000000
    long (1<<31) | (16 << 24) | (16 << 16) | (50 << 8) | (800/8) ' 882 pixels
    long (1<<31) | (7 << 23) | (3 << 20) | (20 << 11) | 480  '510 lines
    long 10 << 8
    long 0
    long 0
    
  • roglohrogloh Posts: 2,768
    edited 2020-08-30 - 11:46:29
    In the code for the next release I've added a couple of enhancements to the custom timing setups which I was testing out today.

    The sixth long in the timing structure above (ie. the first "long 0" shown) was redefined to allow for its 16 LSBs to extend the range of all the horizontal timing settings. They increase the range up to 12 bits for horizontal sync and back porch, and up to 15 bits for horizontal front porch (way more than needed for each, but easier to simply work with nibble sized arguments instead of splitting into less bits). This was in response to finding out that the 1600x1200 mode needed a wider back porch than what the prior 8 bits supported. The 720p modes needs a very wide front porch although this was already supported before.

    The full expanded definition of this long is now this:
    '                 '_Breezeway__C-Burst__FrontPorchHi__SyncWidthHi__BackPorchHi
    '                 '  8 bits     8 bits     8 bits        4 bits        4 bits
    '         long    0    ' Optional timing extension/mode dependent parameters.
    '                      ' Bits 15:0 extend the horizontal timing range further.
    '                      ' This increased range enables support for wider front
    '                      ' porches used in 720p50 modes etc.
    '                      '  bits 3:0 become bits 11-8 of horizontal back porch
    '                      '  bits 7:4 become bits 11-8 of horizontal sync width
    '                      '  bits 15:8 become bits 14-7 of horizontal front porch
    '                      ' Additionally, for PAL/NTSC composite/S-video output:
    '                      '  bits 23:16 hold colour burst size (pixels)
    '                      '  bits 31:24 hold colour burst breezeway size (pixels)
    

    I also made it so that if the clock mode timing parameter (CLK270MHz above) is set to 0, the video driver can automatically determine the PLL settings for the requested frequency using the second long that follows it - and in addition, if that second long is also zero, then this means the application is responsible for configuring the PLL not the driver. This should allow plenty of flexibility as to who sets up the PLL and when. It also lets you set finer clocks, I think to 500kHz granularity right now. The following are the current defaults used in the PLL calculations but these can also be tweaked if required. My code will try to find an exact match, and if none are found then it will pick the closest found to meet the tolerance parameter.
    ' parameters used when automatically determining PLL settings
        TOLERANCE_HZ = 500000    ' pixel clock accuracy will be constrained by this when no exact ratios are found
        MAXVCO_HZ    = 350000000 ' for safety, but you could try to overclock even higher at your own risk
        MINVCO_HZ    = 100000000
        MINPLLIN_HZ  = 500000    ' setting lower can find more PLL ratios but may begin to introduce more PLL jitter
    
  • roglohrogloh Posts: 2,768
    edited 2020-09-01 - 11:52:42
    Thought I'd post a crazy little drawing demo of 640x480x8bpp graphics I was testing out while doing some USB mouse+keyboard integration with my graphics driver. I have another one that works with 1080p 8bpp with HyperRAM, that is coming soon, but this demo works with just HUB RAM only.

    Uses @garryj USB driver (the original one that is hardcoded to pins & freq, I still need to get the new one integrated and tested).

    Fit the VGA breakout board on P0-7. Demo uses VGA port.
    Fit the USB breakout board on P48-P55 - this demo needs a USB mouse, the USB keyboard is optional, can fit these in either USB port.

    Runs at 252MHz (to allow DVI testing) but in VGA mode this application could probably run as low as 50MHz (just needs at least 2x pixel clock for mono text) or whatever the USB driver allows.

    Responds to left, middle and right button click hold and drag. L+R click clears display.
    Keyboard also responds to space, "," and "." for size adjustments and can be held down while moving.

    Try drawing some coil spring shapes or your name and have some fun.

    Binary in zip file.

    Cheers!
Sign In or Register to comment.