HyperRam/Flash as VGA screen buffer (Now in Spin2!)

RaymanRayman Posts: 10,939
edited 2020-05-26 - 15:33:33 in Propeller 2
Use HyperRam or HyperFlash as a screen buffer was previously demonstrated in pure assembly:

Now, I've converted the code to Spin2 (although still mostly assembly).
It also works with both PNut and FastSpin.

This loads up an embedded bmp file into HyperRam and then reads into a line buffer, coordinated with VGA driver.

Update: The HyperVGA_640_x_480_8bpp_3f.spin2 example can load 2 images from uSD and then flip between them on display.
Update2: The HyperVGA_8bpp_3i.spin2 example can flip back and forth between two images on uSD, up to 1080p.
Update3: The HyperVGA_8bpp_4a.spin2 is much like the above with a fixed timeout issue in FSRW so that several seconds can elapse between images. There's about a 1 second of white between images, while loading.


  • RaymanRayman Posts: 10,939
    edited 2020-05-19 - 19:05:07
    I’ll try to get the other resolutions, up to 1080p updated too. And the flash version too.
  • For higher resolutions, it would be convenient to load the images from uSD card...
    Here is a version of the files in top post, modified to load image from uSD instead.
    Works with both PNut and FastSpin
  • Here's a version that loads up 2 images from uSD into HyperRam and then flips between them on VGA display.
    Some of the image parameters and row settings are now abstracted to make it easier to extend to larger images.
  • RaymanRayman Posts: 10,939
    edited 2020-05-24 - 19:41:20
    I got 720p@8bpp working this morning and then just tried 1080p again after seeing @rogloh 's driver thread.
    It works. I think before it was violating some spec. But, looks good.
  • evanhevanh Posts: 9,502
    edited 2020-05-25 - 13:43:48
    Here's the revamped sdspi low level code with optimised sysclock/8 performance. Note it relies on the latest master build of Fastspin for this to compile correctly: Fastspin Version 4.1.12-beta-05342967 from https://github.com/totalspectrum/spin2cpp

    Pnut compiles it okay but gets SD errors. Presumption is Pnut handles inlined assembly differently so timing is out.

    EDIT: File updated with extra comments
  • @evanh , If the in-line assembly now works in lut, I guess I’d use the FIFO for wfbyte in the loop. Is that what you did?
  • evanhevanh Posts: 9,502
    edited 2020-05-25 - 13:09:11
    WFLONG ... and more. There's a run up needed to significantly overlap the clock outs to receiving the serial data back. The nice outcome is that at sysclock/8 there is still a sweet spot for the compensation (#14) that doesn't need any adjustment for frequency bands.

    Once I get the streamer into action then it'll need an adjustable compensation based on sysclock. Or maybe based more on the SPI clock.

  • RaymanRayman Posts: 10,939
    edited 2020-05-25 - 18:50:13
    Here's a test program that switches back and forth between two images on SD card.
    Can be 480p, 720p or 1080p mode.

    Need to try with faster block reads next.
    Also, there is something strange going on with the "bashed" version of sdspi that makes me need to remount between images. Something to do with the timeout I think... Need to investigate that...
    Update: Fixed some timeout issues with FSRW in the newly attached.
  • Looks like can do a slideshow in 1080p at 8bpp with 1 second of blackness when advancing the slide.
    I.e, it takes 1 second to load a new image from uSD into HyperRam.

    Not horrible, but hopefully eMMC will improve things...
  • jmgjmg Posts: 14,328
    Rayman wrote: »
    Looks like can do a slideshow in 1080p at 8bpp with 1 second of blackness when advancing the slide.
    I.e, it takes 1 second to load a new image from uSD into HyperRam.

    Not horrible, but hopefully eMMC will improve things...

    Does that mean you can load one HyperRam display pane, whilst viewing another, to change the 1 sec black, to 1 sec update ?
  • I changed from black to white while reloading HyperRam. Think it's better.
    Here's what it looks like in 1080p:

    I wish I could load while viewing. Might have that kind of bandwidth in 720p, but probably not at 1080p.
  • Is the load/view issue just a palette update one? Just double buffer your next image in HyperRAM and sync the palette flip when you display the next screen. That's what I do to make it seamless.
  • Actually it's probably more likely you can't read while writing HyperRAM. Pretty soon you can use my driver for fixing that. Spin2 code is all coded now, just testing.
  • RaymanRayman Posts: 10,939
    edited 2020-05-26 - 00:50:24
    I think I’ll wait for your driver before I try that...

    Think that needs sysclock/1 speed
  • Yeah 1080p60 8bpp would need sysclk/1 reads on a P2 operating at 297MHz. IIRC I had some success there but it's right on the limit of what can be achieved with overclocking it.
  • I guess if I installed my other HyperRam thing, I could jump to the next slide instantly...
  • Just throw more resources at the problem. :smile: Yep that works. Ping-ping two HyperRAM chips on different buses.
  • I'm hoping eMMC will drop that 1s by a factor of 8 or more. Would be a lot more acceptable then...
  • Any luck accessing your eMMC device registers yet or otherwise getting a response from it?
  • Not yet, wanted to play with this first...
    I saw some interesting things in your hyperram thread btw.
  • This version flips between two 1080p images (you need to copy the bmp files to uSD card).
    There's about 1 second of white screen between images, while it loads from uSD to HyperRam.

    This version has the fixed FSRW, where the timeout issues have been addressed.
  • 750 ms for me. :P
  • I found a bug in the 4a version above that prevented it from working when hyperram basepin moved from 32 to 0.
    All better in this one.
  • Just tested the 1080p slideshow with the eMMC version of FSRW swapped in place of the uSD version.
    It works and load time reduce from ~1000 ms to ~250 ms.

    I think it could be reduced even further using only multiblock reads.
    This uses a combination of single block reads (currently very slow in my eMMC driver) and mult-block reads.

    Still it looks acceptably fast now to actually be used in real life:
Sign In or Register to comment.