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

PSRAM vs HyperRAM testing

124

Comments

  • roglohrogloh Posts: 3,313
    edited 2021-05-26 04:03

    Yeah those 16MB v1 parts used a dual die approach too, although that was split by top address bit not data. You ended up with two sets of registers that you had to setup if things changed which got a bit ugly really. If you split by data instead the registers in both dies would hopefully be duplicated already during the transfer. The address phase RWDS is the only thing that needs to be handled. Presumably if either die needs refresh the two RDWS outputs could both go low inside the chip but they might not have dealt with it like that and might have left it to the user of the chip to figure it out which would not be good. We'll have to see when they release more information...

    EDIT: looks like the x16 HyperRAM parts are 1.8V.

  • hinvhinv Posts: 1,058

    @rogloh said:
    Here's a table for number of lines to hit 50Hz operation as close as possible as you vary the P2 clock and the total line count (assuming 1056 pixels per line).

    and another for 60Hz...

    Are these minimum MHz where the yellow is the cutoff to maintain an exact 50 or 60Hz refresh?
    What has 1056pixels/line? Is that 960 + front porch + back porch?

  • evanhevanh Posts: 11,064
    edited 2021-05-29 20:03

    @hinv said:
    Are these minimum MHz where the yellow is the cutoff to maintain an exact 50 or 60Hz refresh?
    What has 1056pixels/line? Is that 960 + front porch + back porch?

    Yep, it'll be my example 960x540 mode. I used the minimum 96 dots for reduced horizontal blanking over a DVI/HDMI port.

    That worked well but it was also later discovered that older DVI monitors can still impose a limiting minimum hsync of 30 kHz. This affected 50 Hz vsync modes. EDIT: In other words, you want at least 315 MHz sysclock to bring up the hsync to 30 kHz ... and therefore make the 50 Hz mode universal.

  • evanhevanh Posts: 11,064
    edited 2021-05-29 21:10

    Lets say 350 MHz sysclock: 35 MHz dotclock / 1056 dots htotal = 33.1 kHz hsync / 50 Hz vsync = 663 lines vtotal - 540 = 123 lines vblank.

    EDIT: Or, if wanting greater hblanking, 35M/30k = 1168 (nearest multiple of 8): 35 MHz / 1168 = 30 kHz / 50 = 599 vtotal - 540 = 59 vblank.

    EDIT2: Or at pik33's preferred 354 MHz sysclock: 35.4M/30k = 1184 (nearest 8). 35.4 MHz / 1184 = 29.9 kHz / 50 = 598 vtotal - 540 = 58 vblank.

  • evanhevanh Posts: 11,064
    edited 2021-05-29 21:27

    Newer HDMI based TVs and monitors no longer appear to have the old minimum 30 KHz hsync hangover from the VGA days. So they can handle hugely varied mode settings parameters with the HDMI port.

    But any VGA port on same display still only has a select set of known preset modes. CRT VGA monitors didn't do this, they were far more open ended but still had the minimum 30 kHz hsync.

  • evanhevanh Posts: 11,064
    edited 2021-05-29 21:52

    @evanh said:
    EDIT2: Or at pik33's preferred 354 MHz sysclock: 35.4M/30k = 1184 (nearest 8). 35.4 MHz / 1184 = 29.9 kHz / 50 = 598 vtotal - 540 = 58 vblank.

    Another target might be the PAL 15625 Hz hsync. 2x that is 31250 Hz. 35.4M / 31.25k = 1136 (nearest 8): 1136 x 31.25k = 35.5 MHz dotclock. So that's a needed change of sysclock to 355 MHz. 35.5 MHz / 1136 = 31.25 kHz / 50 = 625 vtotal - 540 = 85 vblank.

  • hinvhinv Posts: 1,058

    @evanh said:

    @hinv said:
    Are these minimum MHz where the yellow is the cutoff to maintain an exact 50 or 60Hz refresh?
    What has 1056pixels/line? Is that 960 + front porch + back porch?

    Yep, it'll be my example 960x540 mode. I used the minimum 96 dots for reduced horizontal blanking over a DVI/HDMI port.

    That worked well but it was also later discovered that older DVI monitors can still impose a limiting minimum hsync of 30 kHz. This affected 50 Hz vsync modes. EDIT: In other words, you want at least 315 MHz sysclock to bring up the hsync to 30 kHz ... and therefore make the 50 Hz mode universal.

    So if I can get stable operation at 360MHz, like on Cluso's board, I can pick any resolution below 960*540 at 16 bits without changing my system clock?

  • hinvhinv Posts: 1,058

    Why not create a windowing system so that the whole framebuffer doesn't have to exist in memory? Let's say for instance, you could have a render list that schedules bitmaps to be pulled out of PSRAM, while things like text windows get generated on the fly, thus removing some of the bandwidth required for the PSRAM. You could still move windows around without having to snap to character boundaries and use nicely shaped window frames and generate them on the fly, I would think. Other things like image windows, oscilloscope windows, WYSIWYG word processors, etc could have a section of framebuffer.
    I,and not I alone use a LOT of text terminal windows or editors that would work just fine in a text only interface. I could see Chip's debug output windows handled the same way where the serial stream window would be rendered on the fly with a fixed width font, and in another window, fully bitmapped including sprites and other drawing tools.

  • roglohrogloh Posts: 3,313

    @evanh said:
    Newer HDMI based TVs and monitors no longer appear to have the old minimum 30 KHz hsync hangover from the VGA days. So they can handle hugely varied mode settings parameters with the HDMI port.

    But any VGA port on same display still only has a select set of known preset modes. CRT VGA monitors didn't do this, they were far more open ended but still had the minimum 30 kHz hsync.

    I'm hopeful this applies to most small LCD panels too. Because of the Raspi effect those 800x480 HDMI panels are getting cheap/plentiful now, as are the 1024x600 ones and can save many pins vs parallel TTL RGB. I just don't know how slow they'll clock and that 10x multiplier for DVI does put a higher burden on the P2. Maybe LVDS is another option, because in theory it only needs a 7x multiplier in the P2, but it does limit the colour modes possible - I'm hopeful that 256 colours from a 18/24 bit palette could be achieved in my own driver with some customizations for LVDS but I've not dug fully into it.

  • hinvhinv Posts: 1,058

    What would it take to drive a Dell UltraSharp U2410F via DVI, 8-bit color (1920x1200)?

  • roglohrogloh Posts: 3,313
    edited 2021-05-30 02:51

    @hinv said:
    Why not create a windowing system so that the whole framebuffer doesn't have to exist in memory? Let's say for instance, you could have a render list that schedules bitmaps to be pulled out of PSRAM, while things like text windows get generated on the fly, thus removing some of the bandwidth required for the PSRAM. You could still move windows around without having to snap to character boundaries and use nicely shaped window frames and generate them on the fly, I would think. Other things like image windows, oscilloscope windows, WYSIWYG word processors, etc could have a section of framebuffer.
    I,and not I alone use a LOT of text terminal windows or editors that would work just fine in a text only interface. I could see Chip's debug output windows handled the same way where the serial stream window would be rendered on the fly with a fixed width font, and in another window, fully bitmapped including sprites and other drawing tools.

    I've tried to provide some of that in my video driver with regions. Some screen regions can be text, some can be bitmap graphics (sourced either from HUB or external memory), some sprite based etc, and you can dynamically create/destroy move and resize these regions. The only limitation is that it is per scanline, so you can't mix different region types horizontally, only vertically. If you want to mix horizontally you'd need another COG that can generate the entire scan line (eg. another type of sprite or compositing driver). It's probably doable but would obviously require more COGs.

  • roglohrogloh Posts: 3,313
    edited 2021-05-30 03:08

    @hinv said:
    What would it take to drive a Dell UltraSharp U2410F via DVI, 8-bit color (1920x1200)?

    It would take a VGA to DVI adapter. I've successfully done this on a Dell Ultrasharp 2405FPW at 1920x1200. Cost about AUD$14.

    Update: This assumes you want 1920x1200. If you only want 960x600 then perhaps you can clock slower with a lower resolution and let the scaler sort it out. I know the scaler in the Dell 2405 is very good, not sure about the U2410F. I still need vsync above 49Hz though and hsync > ~30kHz.

  • evanhevanh Posts: 11,064

    @hinv said:
    So if I can get stable operation at 360MHz, like on Cluso's board, I can pick any resolution below 960*540 at 16 bits without changing my system clock?

    Yep. Although many older monitors/TVs won't like it. My limited testing has noted 2015 models as happy to but 2012 models not. I suspect this is related to the trend towards VRR capable monitors.

  • roglohrogloh Posts: 3,313
    edited 2021-05-30 03:04

    @rogloh said:

    @hinv said:
    What would it take to drive a Dell UltraSharp U2410F via DVI, 8-bit color (1920x1200)?

    It would take a VGA to DVI adapter. I've successfully done this on a Dell Ultrasharp 2405FPW at 1920x1200. Cost about AUD$14

    If you don't want to have the analog path and are building your own board/system, you could go parallel out from the P2 and use a DVI/HDMI encoder chip like TI TFP410. This would allow 165MHz pixel clocks supporting WUXGA with reduced blanking. But it burns a lot of P2 pins for 24 bit colour (26 pins at least).

  • Cluso99Cluso99 Posts: 17,772

    @hinv said:

    @evanh said:

    @hinv said:
    Are these minimum MHz where the yellow is the cutoff to maintain an exact 50 or 60Hz refresh?
    What has 1056pixels/line? Is that 960 + front porch + back porch?

    Yep, it'll be my example 960x540 mode. I used the minimum 96 dots for reduced horizontal blanking over a DVI/HDMI port.

    That worked well but it was also later discovered that older DVI monitors can still impose a limiting minimum hsync of 30 kHz. This affected 50 Hz vsync modes. EDIT: In other words, you want at least 315 MHz sysclock to bring up the hsync to 30 kHz ... and therefore make the 50 Hz mode universal.

    So if I can get stable operation at 360MHz, like on Cluso's board, I can pick any resolution below 960*540 at 16 bits without changing my system clock?

    Just be careful not to overload my board. It’s not designed to be operated at maximum as i took some design decisions to limit total power usage to about 500mA. This is due to the limited planes to dissipate power in the linear regulators and P2. Adding little heatsinks would help push it further.

  • pik33pik33 Posts: 1,031
    edited 2021-05-30 06:05

    You can have 1024x576/50 Hz at 354 MHz. In my driver only 4pp is available at this resolution OR you have to add borders to restrict the visible screen resolution to, for example, 896x496: no RAM for more, but while using PSRAM, 8 bpp is of course possible and maybe 16 bpp too.

    Now I have several PSRAM chips: I have to make a simple board for them to connect them to P2 and experiment.

  • evanhevanh Posts: 11,064
    edited 2021-05-30 07:06

    I just discovered 720x480 is very well supported. Apparently what DVD used. It's not a particularly square pixel, but is okay due to sitting in the middle between 4:3 aspect and 16:9 aspect.

  • TonyB_TonyB_ Posts: 1,728

    @evanh said:
    I just discovered 720x480 is very well supported. Apparently what DVD used. It's not a particularly square pixel, but is okay due to sitting in the middle between 4:3 aspect and 16:9 aspect.

    Can TVs or monitors display 720x480/60Hz or 720x576/50Hz with square pixels?

  • evanhevanh Posts: 11,064
    edited 2021-05-30 11:35

    Well, DVD aspect depended. The video content was made to suit either 4:3, or 16:9, or even wider film aspects sometimes. The stored resolution was more a factor in the compression than the display aspect.

    Whether a TV had feature for forcing square pixels or not would be model specific.

    EDIT: 720x576 is 5:4 for square pixels so it's something of a mirror of 720x480 around 4:3.

  • hinvhinv Posts: 1,058

    @rogloh said:

    @rogloh said:

    @hinv said:
    What would it take to drive a Dell UltraSharp U2410F via DVI, 8-bit color (1920x1200)?

    It would take a VGA to DVI adapter. I've successfully done this on a Dell Ultrasharp 2405FPW at 1920x1200. Cost about AUD$14

    If you don't want to have the analog path and are building your own board/system, you could go parallel out from the P2 and use a DVI/HDMI encoder chip like TI TFP410. This would allow 165MHz pixel clocks supporting WUXGA with reduced blanking. But it burns a lot of P2 pins for 24 bit colour (26 pins at least).

    Yeah, I would like to avoid going analog at all, but I don't want to burn that many pins either.

  • hinvhinv Posts: 1,058

    @rogloh said:

    @hinv said:
    What would it take to drive a Dell UltraSharp U2410F via DVI, 8-bit color (1920x1200)?

    It would take a VGA to DVI adapter. I've successfully done this on a Dell Ultrasharp 2405FPW at 1920x1200. Cost about AUD$14.

    Update: This assumes you want 1920x1200. If you only want 960x600 then perhaps you can clock slower with a lower resolution and let the scaler sort it out. I know the scaler in the Dell 2405 is very good, not sure about the U2410F. I still need vsync above 49Hz though and hsync > ~30kHz.

    The U2410F has VGA in already, so this wouldn't be a problem...I was just trying to avoid analog. I would like pixel2pixel accuracy, so full res at 1920x1200. It has HDMI and Display Port too. Can I use either of these at full res?

  • hinvhinv Posts: 1,058

    @rogloh said:

    @hinv said:
    Why not create a windowing system so that the whole framebuffer doesn't have to exist in memory? Let's say for instance, you could have a render list that schedules bitmaps to be pulled out of PSRAM, while things like text windows get generated on the fly, thus removing some of the bandwidth required for the PSRAM. You could still move windows around without having to snap to character boundaries and use nicely shaped window frames and generate them on the fly, I would think. Other things like image windows, oscilloscope windows, WYSIWYG word processors, etc could have a section of framebuffer.
    I,and not I alone use a LOT of text terminal windows or editors that would work just fine in a text only interface. I could see Chip's debug output windows handled the same way where the serial stream window would be rendered on the fly with a fixed width font, and in another window, fully bitmapped including sprites and other drawing tools.

    I've tried to provide some of that in my video driver with regions. Some screen regions can be text, some can be bitmap graphics (sourced either from HUB or external memory), some sprite based etc, and you can dynamically create/destroy move and resize these regions. The only limitation is that it is per scanline, so you can't mix different region types horizontally, only vertically. If you want to mix horizontally you'd need another COG that can generate the entire scan line (eg. another type of sprite or compositing driver). It's probably doable but would obviously require more COGs.

    Well, we have 8 cogs, so using 2 of them for local debug wouldn't be that much of a problem. Alternatively, using a separate P2 for debug & development for target P2 would be sweet. Maybe it could use a much faster serial or parallel connection too. This brings to mind Baggers dedicated Propeller for graphics idea from years ago. P2 has SOOOO much more umph!

  • evanhevanh Posts: 11,064
    edited 2021-05-30 21:26

    @hinv said:
    The U2410F has VGA in already, so this wouldn't be a problem...I was just trying to avoid analog. I would like pixel2pixel accuracy, so full res at 1920x1200. It has HDMI and Display Port too. Can I use either of these at full res?

    With the prop2's built-in TMDS encoder? No, because that mode at 60 Hz refresh uses a bit clock of something like 1.9 GHz, EDIT: or maybe half that with dual link. Whereas the prop2 is topping out at 360 MHz on a good day.

  • evanhevanh Posts: 11,064

    It would be interesting to know what it takes to perform dual link. Never looked at it before. Maybe two cogs could work together to double the max bandwidth.

  • Problem is that HDMI is single-link. Well, there is a dual-link variant, but it's a total unicorn because some idiot decided to make it a totally incompatible connector to single-link HDMI.

  • evanhevanh Posts: 11,064
    edited 2021-05-30 22:01

    @evanh said:
    With the prop2's built-in TMDS encoder? No, because that mode at 60 Hz refresh uses a bit clock of something like 1.9 GHz, EDIT: or maybe half that with dual link. Whereas the prop2 is topping out at 360 MHz on a good day.

    Okay, first sqizz at the Wikipeadia page looks like max bit clock supported is 1.65 GHz. So, yeah, that mode would require DVI's six serial channel dual link setup, ie: can't be done over HDMI v1.4.

  • evanhevanh Posts: 11,064
    edited 2021-05-30 22:11

    DisplayPort is a different beast. You're looking at a separate converter for that.

    EDIT: Oh, wow, DP is fixed clock rate. That ties in nicely with VRR's dynamic vertical blanking and sort of explains why DP has been leading the charge.

  • roglohrogloh Posts: 3,313
    edited 2021-05-31 01:54

    @evanh said:
    It would be interesting to know what it takes to perform dual link. Never looked at it before. Maybe two cogs could work together to double the max bandwidth.

    Yeah, I have this perfectly fine 30 inch 2560x1600 Dell monitor sitting on a bench that only supports dual-link DVI that not a lot of devices can drive anymore, so it has sort of become a dinosaur. It would be interesting to get it running from a P2. I was sort of wondering if I could somehow use two of those cheap VGA to DVI converters to achieve something with a dual link connector board to split the TMDS lanes but syncing them both to the common clock will be difficult if not impossible to perfect without a lot of trouble. I basically need to interleave two 800x1600 portrait mode displays together at the pixel level. Software on the P2 is potentially doable, it's the hardware side where the problems lie.

    Might be better for a FPGA project I think. It would also make an awesome camera inspection magnification monitor for soldering but so little can drive it now that it's almost useless there. Cheaper/simpler to just buy another large HDMI based monitor.

  • roglohrogloh Posts: 3,313
    edited 2021-05-31 03:07

    @hinv said:

    @rogloh said:

    @hinv said:
    What would it take to drive a Dell UltraSharp U2410F via DVI, 8-bit color (1920x1200)?

    It would take a VGA to DVI adapter. I've successfully done this on a Dell Ultrasharp 2405FPW at 1920x1200. Cost about AUD$14.

    Update: This assumes you want 1920x1200. If you only want 960x600 then perhaps you can clock slower with a lower resolution and let the scaler sort it out. I know the scaler in the Dell 2405 is very good, not sure about the U2410F. I still need vsync above 49Hz though and hsync > ~30kHz.

    The U2410F has VGA in already, so this wouldn't be a problem...I was just trying to avoid analog. I would like pixel2pixel accuracy, so full res at 1920x1200. It has HDMI and Display Port too. Can I use either of these at full res?

    Like evanh said. No full 1920x1200 res over DVI/HDMI from the P2 unless you find a monitor that can be driven at very low refresh rates or use parallel RGB out with an external TMDS encoder, or use VGA with a converter to DVI. 1920x1200 with reduced blanking at 60Hz refresh needs a pixel clock around 154 MHz or thereabouts.

    Give VGA a try at WUXGA. I still use it on my 2405FPW and it looks rather good and is pixel perfect when the monitor syncs to it. I don't have an issue with VGA, it's still very useful on a P2.

  • evanhevanh Posts: 11,064
    edited 2021-05-31 02:58

    @rogloh said:
    ... 1920x1200 with reduced blanking at 60Hz refresh needs a pixel clock around 154 MHz or thereabouts.

    Oh, that's a big reduction from the VGA spec, that rate would fit in a single link and therefore HDMI. Not that that helps a prop2.

Sign In or Register to comment.