Shop Learn
PSRAM vs HyperRAM testing - Page 3 — Parallax Forums

PSRAM vs HyperRAM testing

13»

Comments

  • evanhevanh Posts: 10,803
    edited 2021-04-05 07:23

    Looking at it, probably the hblanking is too small for VGA signalling.

    Where the sync lands within the blanking will affect the picture position on display. I prefer to make the frontporch minimal. I've see-sawed between having a wide hsync and not. I'm tending back to small for both and leaving a large backporch. Same for vblanking timings. This usually works best for adjustment ranges in the OSD.

    EDIT: CVT hasn't proved all that useful for me in the end. I've tried it many times but I always end deviating off.

  • evanhevanh Posts: 10,803

    PS: An old rule of thumb I had for VGA was add 20% to the horizontal resolution to give you the minimum htotal.

  • roglohrogloh Posts: 3,116

    Yeah I know it isn't something that certainly wouldn't work with CRT VGA monitors, I was hoping in vain that it might work with monitors that accept VGA but scale to an LCD panel. I know my Dell monitor accepts a reduced blanking 1920x1200 mode over VGA for example @ around 7.7% blanking to total horizontal time.

    There still might be something that sits between the 325MHz and 268MHz P2 speed that would work with UXGA and let it run with HyperRAM too. It'll be non-standard though.

  • evanhevanh Posts: 10,803
    edited 2021-04-05 08:37

    It would be a lot easier to drop the 2:1 sysclock to pixel ratio. Go 1:1. That would allow large blanking and good flexibility on sysclock. Extend/trim the backporches to suit whatever sysclock frequency you want.

  • roglohrogloh Posts: 3,116
    edited 2021-04-05 09:10

    I could do that but the HyperRAM bandwidth halves as well. At least we could get a picture.

    I've been experimenting for a bit with UXGA around 300MHz (150MHz dot clock) but just can't get things to sync. Monitor always says "cannot display this mode" etc.

    I guess we can still get a 4bpp mode at UXGA but lose the 8bpp one. This 16 bit PSRAM board is nice in that it runs at P2 clock speeds that prevent the reliable HyperRAM transfer (v1 anyway). I've pushed it to over 350MHz (175MHz RAM) and it was still going. So if the P2 Edge gets PSRAM, it won't be an issue.

    Update: Ok, I tried it at 170MHz, LCD monitor gets a picture but it's offset a bit. Could probably work with that.

    I found an EDID dumper and found some limits to my monitor. Looks like it can't go over 170MHz dotclocks.

    ./edid-decode < edid.txt 
    Extracted contents:
    header:          00 ff ff ff ff ff ff 00
    serial number:   10 ac 10 a0 53 4d 31 31 1c 0f
    version:         01 03
    basic params:    80 34 21 78 ee
    chroma info:     ee 50 a3 54 4c 9b 26 0f 50 54
    established:     a5 4b 00
    standard:        81 80 a9 40 71 4f b3 00 01 01 01 01 01 01 01 01
    descriptor 1:    28 3c 80 a0 70 b0 23 40 30 20 36 00 07 44 21 00 00 1a
    descriptor 2:    00 00 00 ff 00 50 36 35 34 30 35 37 34 31 31 4d 53 20
    descriptor 3:    00 00 00 fc 00 44 45 4c 4c 20 32 34 30 35 46 50 57 0a
    descriptor 4:    00 00 00 fd 00 38 4c 1e 51 11 00 0a 20 20 20 20 20 20
    extensions:      00
    checksum:        27
    
    EDID version: 1.3
    Manufacturer: DEL Model a010 Serial Number 825314643
    Digital display
    Maximum image size: 52 cm x 33 cm
    Gamma: 2.20
    DPMS levels: Standby Suspend Off
    RGB color display
    Default (sRGB) color space is primary color space
    First detailed timing is preferred timing
    Display x,y Chromaticity:
      Red:   0.6396, 0.3300
      Green: 0.2998, 0.6074
      Blue:  0.1494, 0.0595
      White: 0.3125, 0.3281
    Established timings supported:
      720x400@70Hz 9:5 HorFreq: 31469 Hz Clock: 28.320 MHz
      640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz
      640x480@75Hz 4:3 HorFreq: 37500 Hz Clock: 31.500 MHz
      800x600@60Hz 4:3 HorFreq: 37900 Hz Clock: 40.000 MHz
      800x600@75Hz 4:3 HorFreq: 46900 Hz Clock: 49.500 MHz
      1024x768@60Hz 4:3 HorFreq: 48400 Hz Clock: 65.000 MHz
      1024x768@75Hz 4:3 HorFreq: 60000 Hz Clock: 78.750 MHz
      1280x1024@75Hz 5:4 HorFreq: 80000 Hz Clock: 135.000 MHz
    Standard timings supported:
      1280x1024@60Hz 5:4 HorFreq: 64000 Hz Clock: 108.000 MHz
      1600x1200@60Hz 4:3 HorFreq: 75000 Hz Clock: 162.000 MHz
      1152x864@75Hz 4:3 HorFreq: 67500 Hz Clock: 108.000 MHz
      1680x1050@60Hz 16:10 HorFreq: 64700 Hz Clock: 119.000 MHz
    Detailed mode: Clock 154.000 MHz, 519 mm x 324 mm
                   1920 1968 2000 2080 hborder 0
                   1200 1203 1209 1235 vborder 0
                   +hsync -vsync 
                   VertFreq: 59 Hz, HorFreq: 74038 Hz
    Serial number: P654057411MS 
    Monitor name: DELL 2405FPW
    Monitor ranges (GTF): 56-76Hz V, 30-81kHz H, max dotclock 170MHz
    Checksum: 0x27 (valid)
    EDID block does NOT conform to EDID 1.3!
        sRGB is signaled, but the chromaticities do not match
    EDID block does not conform at all!
        Bad year of manufacture
    
  • evanhevanh Posts: 10,803

    @rogloh said:
    I could do that but the HyperRAM bandwidth halves as well.

    What is most desirable sysclock frequency?

  • evanhevanh Posts: 10,803
    edited 2021-04-05 11:07

    Man, all these constants I need to find and expose/makeup to use your driver ain't much fun. How easy is it to supply a custom screen mode via p2textdrv.spin2? I'm using the demo helloworld.spin2 to test with.

    EDIT: I see initVgaCustom(). I guess I can just use that in place of initVga().

  • evanhevanh Posts: 10,803
    edited 2021-04-05 11:27

    Right got helloworld.spin2 compiling now with this vid.initVgaCustom( -1, VGA_BASE_PIN, VGA_BASE_PIN+4, vid.FLASH_TEXT, 288_000_000, 2, 0, 16, 64, 240, 1600/8, 0, 1, 2, 47, 1200 )

    ... And picture is displayed good.

  • roglohrogloh Posts: 3,116

    Hmm, that is the text driver stuff which was intended to simplify things by removing complexity, LOL. I am putting together a demo that is going to hopefully make it easier to use with any luck. The custom screen mode stuff is slightly messy right now. I was thinking of combining the constants for stock resolutions with a pointer for custom timing in the same parameter. Eg, if the value is > 2^20 it is a constant, but if <2^20 it points to a timing structure in HUB RAM.

    One annoying thing about SPIN2 is that if you want to wrap some complex functionality with a simpler API, but need to use something from the lower included object, you almost have to duplicate that API in the wrapper object and that adds overheads. It's okay for rarely used APIs but if it's something that is meant to be higher performance it becomes painful. Soon enough your wrapper layer becomes almost as complex as the one underneath. :s

  • roglohrogloh Posts: 3,116
    edited 2021-04-05 11:33

    @evanh said:
    Right got helloworld.spin2 compiling now with this vid.initVgaCustom( -1, VGA_BASE_PIN, VGA_BASE_PIN+4, vid.FLASH_TEXT, 288_000_000, 2, 0, 16, 64, 240, 1600/8, 0, 1, 2, 47, 1200 )

    ... And picture is displayed good.

    Good work. Wasn't that hard now was it. :wink:

  • roglohrogloh Posts: 3,116

    Just tried those settings as well, my monitor still didn't like it. I think it is a crapshoot as to whether it would work or not.

    Here try out this binary if you'd like... for some HyperRAM gfx fun - your UXGA mode is in there too.

    VGA on P0-7, HyperRAM on P16-31 (some current debug output sent @115kbps):

  • evanhevanh Posts: 10,803
    edited 2021-04-05 11:52

    Really? That was an easy one I thought. Try this: vid.initVgaCustom( -1, VGA_BASE_PIN, VGA_BASE_PIN+4, vid.FLASH_TEXT, 320_000_000, 2, 0, 120, 152, 264, 1600/8, 0, 1, 2, 45, 1200 )

  • evanhevanh Posts: 10,803
    edited 2021-04-05 12:00

    Here try out this binary if you'd like... for some HyperRAM gfx fun - your UXGA mode is in there too.

    VGA on P0-7, HyperRAM on P16-31 (some current debug output sent @115kbps):

    Ah, the 1600x1200 mode doesn't work for me either. Your parameters must be different to what I posted.

  • roglohrogloh Posts: 3,116
    edited 2021-04-05 12:10

    Weird, this is what I used from your numbers...and is what is in the demo for UXGA.

    UPDATE: Oops, I see the problem, divisor is still 1. Let me update this post with the new values.

    uxga_timing ' 1600x1200@60Hz at 162*2 MHz
                long   0 'CLK325MHz
                long   288000000
                       '_HSyncPolarity___FrontPorch__SyncWidth___BackPorch__Columns
                       '     1 bit         7 bits      8 bits      8 bits    8 bits
                long   (0<<31) | (16<<24) | (64<<16) | (240<<8 ) |(1600/8)
                       '_VSyncPolarity___FrontPorch__SyncWidth___BackPorch__Visible
                       '     1 bit         8 bits      3 bits      9 bits   11 bits
    
                long   (0<<31) | ( 1<<23) | (  2<<20) | (47<<11) | 1200
                long   1 << 8
                       '_Breezeway__C-Burst__FrontPorchHi__SyncWidthHi__BackPorchHi
                       '  8 bits     8 bits     8 bits        4 bits        4 bits
                long   (0 << 0)  ' Back porch MSBs
                long   0   ' reserved for CFRQ parameter
    

    COOL, it worked for me now at UXGA 8bpp when I fixed the divisor. Here's the updated binary...

  • evanhevanh Posts: 10,803

    PS: I like the blit speed! Seems snappy as. Could easy do a GUI with that.

  • evanhevanh Posts: 10,803
    edited 2021-04-05 12:10

    :) I see you solved it.

  • roglohrogloh Posts: 3,116

    @evanh said:
    PS: I like the blit speed! Seems snappy as. Could easy do a GUI with that.

    That's the plan my man.

  • roglohrogloh Posts: 3,116

    Did the final WUXGA (1920x1200) resolution work for you? That is the last one in the sequence but you many not have a 16:10 monitor.

  • roglohrogloh Posts: 3,116
    edited 2021-04-05 12:26

    The cool thing is this fully works in with all the region stuff in my video driver, so you could have a region of the screen as a GUI or something feeding data in from external memory bitmaps, or from a sprite driver, as well as some text status for COGs/debug/coding etc, all at once and just add/remove or slide them up/down dynamically as you need them. Plus it works with PAL, NTSC, component and DVI output too. Also different regions can be in different colour depths at the same time. Only the resolution and border colour is common, though it can be changed on the fly as well (with care).

  • evanhevanh Posts: 10,803

    @rogloh said:
    Did the final WUXGA (1920x1200) resolution work for you? That is the last one in the sequence but you many not have a 16:10 monitor.

    Yep. Some random data at the bottom of the scrolling blit but everything else looked good. I'm using the old DVI monitor, which is 1920x1200. But it is set 4:3 aspect at the moment so the widescreen modes looks squashed.

  • roglohrogloh Posts: 3,116

    Cool, yeah ignore random data at the bottom in the frame buffer. This is just a quickly hacked up simple API feature test/demo and it's not really polished in any way. I just wanted something that could cycle through the modes and draw things in different colour depths etc. I might add bigger font support at some point as the 8x16 text can look quite small on a hi-res monitor. In graphics modes you could do fonts in any size really.

  • evanhevanh Posts: 10,803
    edited 2021-04-05 12:41

    Okay, so the key to VGA signalling is to use the sync frequencies for mode signalling to the monitor. For 1600x1200@60 the needed hsync is 75 kHz. You can then add lots of extra hblank to accommodate higher clock frequencies if desired. And, obviously, remove blanking if wanting to down clock. But must retain the hsync frequency.

    Knowing what the right frequencies are, mostly involve scraping the web for sites that tell you. Wikipedia has zip on the matter, sadly.

  • evanhevanh Posts: 10,803

    Oh, and I did find it an advantage to move the hsync position closer to the centre of the blanking too. The CVT spec is good for VGA it seems. Funny that.

Sign In or Register to comment.