Shop Learn P1 Docs P2 Docs
P2 Edge PSRAM is working - Page 4 — Parallax Forums

P2 Edge PSRAM is working

124»

Comments

  • evanhevanh Posts: 13,836

    @rogloh said:
    So really, you have several options here...

    Ow, sorry, that was a big write up. I think I've got over my frustration. Realising that some modes are best left fixed. Too many uncooperative old monitors out there.

    None of these options require you to change or add any timing structures in the driver which it seems you were doing.

    I'm working with existing the text demo code. Way too hard to work out to use the driver from scratch.

    As to why there are different names in the text driver vs lower level video driver, I am actually hoping to combine them to use the same set of regular names like (VGA,SVGA,XGA,WXGA,UXGA) in the next release. I just need to modify one of the VGA constants for the output type to RGB instead of VGA to avoid namespace collisions.

    I am also thinking of allowing these names to be passed into the timing value for initDisplay() and my code would detect them to avoid needing to use RES_640x480 etc. I could do this if some upper bits were used to indicate the constant vs the address. This would eliminate the need to call getTiming(RES_800x600) etc (as done in case 1 above), and you could just do this which I think is probably the simplest it can be while remaining generic enough to cover all options needed:

    driver.initDisplay(cog, @display, driver.RGB,basePin, syncPin, flags, lineBuf, linesize, driver.VGA, 0, @region) 
    

    Sounds promising. Especially since using the preset modes is going to be common practice.

  • evanhevanh Posts: 13,836
    edited 2022-01-31 01:35

    Here's the new function in the driver I'm now using when DVI_VIDEO_TYPE = 1 in the text demo program. It sits right below the createCustomTiming() function in p2videodrv.spin2. Sharing the description of timing structure.

    PUB  computeCustomDvi(timing, p2freq, hres, vres, vfreq) : r | divisor
    {{
    So there is a total of four effective parameters to build complete HDMI timings from:
    1 - sysclock frequency (sysfrq)
    2 - horzontal resolution (hres)
    3 - vertical resolution (vres)
    4 - vertical frequency (vfrq)
    
    Remaining timings are:
    dotfrq (>= 25 MHz) = sysfrq / 10
    htot = hres + 80
    hfp = 8
    hsw = 64
    hbp = 8
    vtot = dotfrq / htot / vfrq
    vfp = 1
    vsw = 2
    vbp (>= 9) = vtot - vres - 3
    }}
        p2freq #>= 250_000_000
        p2freq <#= MAXVCO_HZ
        divisor := 10
        vfreq #>= 10    'sane minimum
        hres &= $7f8    '8-bit range (x8)
        vres &= $7ff    '11-bit range
    
        long[timing][0] := 0    'auto compute clock mode
        long[timing][1] := p2freq
        long[timing][2] := (8 & $7f) << 24    'hfp
        long[timing][2] |= (64 & $ff) << 16    'hs
        long[timing][2] |= (8 & $ff) << 8    'hbp
        long[timing][2] |= hres >> 3
        long[timing][3] := (1 & $ff) << 23    'vfp
        long[timing][3] |= (2 & 7) << 20    'vs
        r := divisor * vfreq * (hres+80)
        r := ((p2freq + r/2) / r - vres - 3) #> 9
        r <#= $1ff
        long[timing][3] |= r << 11    'vbp
        long[timing][3] |= vres
        long[timing][4] := (divisor +< 256) ? (divisor << 8) : divisor
        long[timing][5] := ((8 << 1) & $ff00)
        long[timing][5] |= ((64 >> 4) & $f0)
        long[timing][5] |= ((8 >> 8) & $f)
        long[timing][6] := 0
    'Calculate final vertical scan frequency (in tenths of hertz)
    '    r := (hres + 80) * (vres + 3 + r)    'htot * vtot
    '    r := (p2freq + r/2) / r              'vfreq = dotfreq / (htot * vtot)
        return timing
    
  • evanhevanh Posts: 13,836
    edited 2022-01-31 02:23

    Lol, DVI output at 1280x1024@25Hz still using 350 MHz sysclock.

  • roglohrogloh Posts: 4,602

    @evanh said:
    First limit I hit is the timing structure has a limit of
    9 bits for vertical back porch. Modern monitors can handle far greater vblank now.

    Interesting you've hit that limit. So far I've been able to get by with the ranges supported. I think I might be able to extend the 5th long to allow extended VBP's to be specified when they exceed 9 bits. I'd probably overload it with breezeway and colourburst settings, given they would be exclusive groups of parameters in the different output modes.

  • evanhevanh Posts: 13,836

    @rogloh said:
    I'd probably overload it with breezeway and colourburst settings, given they would be exclusive groups of parameters in the different output modes.

    That'd be great to have 16 bits just for the back porch.

  • roglohrogloh Posts: 4,602

    How many bits is realistic? I'd probably save some to potentially extend the VFP and VSYNC portions too.

  • evanhevanh Posts: 13,836
    edited 2022-01-31 03:13

    I don't know for vbp. But the vfp and vsync are already plenty big. They work fine as both small values in all modes, even the old PC modes. Moving the sync away from the bottom of the visible just shifts the picture up the screen.

    EDIT: Well, maybe not the old modes. Turns out there is use for some front porch on CRT monitors. The existing 8 bits is heaps though.

    EDIT2: Time for some more testing ...

  • evanhevanh Posts: 13,836
    edited 2022-01-31 04:54

    Okay, I'll take that back about the front porch. Putting sync in middle of blanking is best for CRTs. DVI devices don't seem to care. I'll be using vfp from now on. Which means need same size store for both front and back porches.

    EDIT: I do wonder how VRR works in detail in this respect. Does the sync get put in the middle of the blanking even then? Not really a concern here though. Just pondering.

    EDIT2: Updated computeCustomDvi()

    PUB  computeCustomDvi(timing, p2freq, hres, vres, vfreq) : r | divisor, vblank
    {{
    So there is a total of four effective parameters to build complete HDMI timings from:
    1 - sysclock frequency (sysfrq)
    2 - horzontal resolution (hres)
    3 - vertical resolution (vres)
    4 - vertical frequency (vfrq)
    
    Remaining timings are:
    dotfrq (>= 25 MHz) = sysfrq / 10
    htot = hres + 80
    hfp = 8
    hsw = 64
    hbp = 8
    vtot = dotfrq / htot / vfrq
    vblank = vtot - vres
    vsw = 2
    vfp = (vblank - vsw) / 2
    vbp = vblank - vsw - vfp
    }}
        p2freq #>= 250_000_000    'min DVI link speed 
        p2freq <#= MAXVCO_HZ      'max sysclock
        divisor := 10   'fixed ratio dot-clock
        vfreq #>= 10    'sane minimum
        hres &= $7f8    '8-bit range (x8)
        vres &= $7ff    '11-bit range
    
        long[timing][0] := 0    'auto compute clock mode
        long[timing][1] := p2freq
        long[timing][2] := (8 & $7f) << 24    'hfp
        long[timing][2] |= (64 & $ff) << 16    'hs
        long[timing][2] |= (8 & $ff) << 8    'hbp
        long[timing][2] |= hres >> 3
        r := divisor * vfreq * (hres+80)
        vblank := ((p2freq + r/2) / r - vres) #> 12    'min blanking is 12
        r := (vblank - 2) >> 1
        r <#= $ff                     'max front porch
        long[timing][3] := r << 23    'vfp
        long[timing][3] |= 2 << 20    'vs
        r := vblank - 2 - r
        r <#= $1ff                    'max back porch
        long[timing][3] |= r << 11    'vbp
        long[timing][3] |= vres
        long[timing][4] := (divisor +< 256) ? (divisor << 8) : divisor
        long[timing][5] := ((8 << 1) & $ff00)
        long[timing][5] |= ((64 >> 4) & $f0)
        long[timing][5] |= ((8 >> 8) & $f)
        long[timing][6] := 0
    'Calculate final vertical scan frequency (in tenths of hertz)
    '    vblank := long[timing][3].[30..23] + 2 + long[timing][3].[19..11]
    '    r := (hres + 80) * (vres + vblank)    'htot * vtot
    '    r := (p2freq + r/2) / r              'vfreq = dotfreq / (htot * vtot)
        return timing
    
  • roglohrogloh Posts: 4,602

    @evanh said:
    Okay, I'll take that back about the front porch. Putting sync in middle of blanking is best for CRTs. DVI devices don't seem to care. I'll be using vfp from now on. Which means need same size store for both front and back porches.

    I could possibly try to give 7 more bits to VBP and 9 more bits to VFP to split them evenly with 64k max lines possible in each or I could perhaps give one less bit to each (32k lines) and 2 bits more to the VSYNC (32 lines max). It still seems massive to go that big though for the porches. Maybe 12 bits each is enough.

  • evanhevanh Posts: 13,836

    I'd be tempted to change the driver to use the same stored value for both porches.

  • evanhevanh Posts: 13,836
    edited 2022-01-31 05:50

    Operating a mode right now (using a different driver): 480x270@50Hz with 350 MHz sysclock.
    35 MHz / (480 + 80 = 560) = 62.5 kHz hfreq
    hfreq / 50 Hz = 1250 vtot
    270 / 1250 = 21.6 % is visible lines.

    Might be limited to something like 1000 vblanking. The TV doesn't like it if I push further.

    EDIT: vtot of 1276 is working. So maybe 1023 is max vblank.
    EDIT2: BTW: That was 502-2-502. If I bias it to 1-2-1003 it still works. Which means it's the whole blanking that's important.

  • evanhevanh Posts: 13,836

    I expect that VRR capable monitors will allow much higher blanking again.

  • roglohrogloh Posts: 4,602

    To keep things easy I think I could probably just allocate an extra nibble to each vertical porch allowing 13 bits 8k for VFP and 12 bits for VBP (4k). Should be heaps. Maybe no need for any more vsync bits.

  • evanhevanh Posts: 13,836

    Yep. That'll do. Sounds like it helps on the code size in the driver.

  • evanhevanh Posts: 13,836

    I've been reading up more on VRR monitors. Turns out, as is often the case, the early cheaper models don't do a good job.

    LCDs have a history of being difficult to tune the LCD's drive parameters. It affects motion blur particularly badly but also colour quality and contrast. And that's the main reason for limited refresh rates. And even to the point of not being sync'd at all. The basic panel used to be built for only one refresh rate so feeding it something else required the scan converter to desync the two sides, video input and LCD, from each other.

    So the trend to allowing wider range of refreshes is producing various quality issues. Particularly with cheap VRR spec'd monitors.

    What I've found out is there is an optional feature that really is needed on them all, called "Low Framerate Compensation". Here's the blurb from AMD:

    Low framerate compensation (LFC), allows FreeSync technology to work when the framerate falls below the minimum refresh rate of the display. When the framerate drops below the minimum refresh rate of the display, frames are duplicated and displayed multiple times so that they can sync to a refresh rate that is within the displays refresh rate range. For example, a display with a 60 – 144Hz refresh rate, would be able to sync the frames of a game running at 40 FPS, by doubling them so that the display could sync and run at 80 Hz. A display with LFC effectively results in the removal of the minimum refresh rate boundary. All displays in the FreeSync Premium and FreeSync Premium Pro tier are certified to meet mandatory LFC requirements.

    So, with LFC, aside from the gaming advantages, because the monitor can run the LCD at double/triple the refreshes of the video input, this in turn allows the LCD drive parameters to stay in a narrower working range and therefore better quality display.

  • jmgjmg Posts: 14,979

    @evanh said:
    What I've found out is there is an optional feature that really is needed on them all, called "Low Framerate Compensation". Here's the blurb from AMD:

    Low framerate compensation (LFC), allows FreeSync technology to work when the framerate falls below the minimum refresh rate of the display. When the framerate drops below the minimum refresh rate of the display, frames are duplicated and displayed multiple times so that they can sync to a refresh rate that is within the displays refresh rate range. For example, a display with a 60 – 144Hz refresh rate, would be able to sync the frames of a game running at 40 FPS, by doubling them so that the display could sync and run at 80 Hz. A display with LFC effectively results in the removal of the minimum refresh rate boundary. All displays in the FreeSync Premium and FreeSync Premium Pro tier are certified to meet mandatory LFC requirements.

    So, with LFC, aside from the gaming advantages, because the monitor can run the LCD at double/triple the refreshes of the video input, this in turn allows the LCD drive parameters to stay in a narrower working range and therefore better quality display.

    Interesting. They give an example of 40Hz, but I wonder how far that can be pushed ?

  • evanhevanh Posts: 13,836
    edited 2022-01-31 07:04

    @jmg said:
    Interesting. They give an example of 40Hz, but I wonder how far that can be pushed ?

    nVidia lists down to 1 Hz for all their certified models. AMD doesn't make it clear. Probably manufacturer dependant. I would expect 1 Hz will be the default for all because nVidia appears to require that.

    That's the thing, once the repeat feature (LFC) is in place, it can repeat indefinitely. Kind of like DRAM doing self refresh. :)

  • evanhevanh Posts: 13,836
    edited 2022-01-31 07:04

    Which is why vblank from the video card can now dynamically grow and shrink enormously.

  • evanhevanh Posts: 13,836

    Roger,
    Oh, is that what you've already done with hfp, hbp, and hsyncpixels? I note all of those are being placed in timing[5] as well as timing[2]. And the shifts being done work out for that too.

  • roglohrogloh Posts: 4,602
    edited 2022-01-31 09:44

    Yes any horizontal blanking and sync additional bits are already in the lower 16 bits of this timing[5] long if they need to be extended. That's already part of the existing driver.

  • evanhevanh Posts: 13,836

    Where is this? I'm working from p2textdriver0.93.zip from here - https://forums.parallax.com/discussion/170676/p2-dvi-vga-driver/p1

  • roglohrogloh Posts: 4,602

    It's from my yet to be released documentation I've been collating...

  • evanhevanh Posts: 13,836

    Stop cheating! :P

  • hinvhinv Posts: 1,190
    edited 2022-02-01 04:58

    @pik33 said:

    Probably would be good to have a fan or heatsink to control the temperature rise of the module when the user code is pushing things at such limits! At least for long term use.
    I was thinking of @CJMJ 3D printed module holder... maybe that could have a small fan attached to the back for overclocking experiments in a convenient form factor....

    Preparing parts for the project :) A 3D printed holder. A heatsink :)

    I think you would get more heat out of the chip going from the back side, but you will have to take off the conformal coating from the grid of vias.

Sign In or Register to comment.