"RGB Burger" - generating 480*400 video using external SRAM

Tubular

Microcontrolled's recent thread sparked an idea to use one external SRAM per bit plane for video generation. In a nutshell the idea is to encode the entire video stream, including front and back porches and sync intervals, into the SRAM.

Most of the time the SRAMs are in synchronous Dot-Clocked output mode. They can be updated during the vertical sync interval, or by "going offline" for a frame or two to write the full buffer. "Going offline" would allow simple SPIN updates at leisure.

If it works the concept could readily be extended to more color depth. The SRAMS, Microchip 23K256, are about $1 each and available in DIP.

Increasing the horizontal resolution might be harder as it would involve overclocking the SRAM (anyone know if this can be done?). 40 MHz FRAM may be the way to go for that. The choice of 480 horizontal is both to satisfy SRAM limits and allow for large porches for monitors. Its also the horizontal res of the Sharp PSP screen (480*272, Sparkfun etc)

LATEST STATUS - I'll update this line as work progresses -
Proto hardware except driver/amp built, SRAMs talking via Tim Moore's SPI object.

NEXT STEP -
Encode the video signals; test without driver/amp

PICS

Tubular

reserved for experimental results

Bill Henning

Cool, you are trying it!

Keep us updated...

Tubular said...
Microcontrolled's recent thread sparked an idea to use one external SRAM per bit plane for video generation. In a nutshell the idea is to encode the entire video stream, including front and back porches and sync intervals, into the SRAM.

Most of the time the SRAMs are in synchronous Dot-Clocked output mode. They can be updated during the vertical sync interval, or by "going offline" for a frame or two to write the full buffer. "Going offline" would allow simple SPIN updates at leisure.

If it works the concept could readily be extended to more color depth. The SRAMS, Microchip 23K256, are about $1 each and available in DIP.

Increasing the horizontal resolution might be harder as it would involve overclocking the SRAM (anyone know if this can be done?). 40 MHz FRAM may be the way to go for that. The choice of 480 horizontal is both to satisfy SRAM limits and allow for large porches for monitors. Its also the horizontal res of the Sharp PSP screen (480*272, Sparkfun etc)

LATEST STATUS - I'll update this line as work progresses -
Proto hardware except driver/amp built, SRAMs talking via Tim Moore's SPI object.

NEXT STEP -
Encode the video signals; test without driver/amp

PICS

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this week)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers

localroger

Tubular, I believe this approach will work; I was looking into something similar but put it aside because of other priorities. Please keep us updated on your results.

Microcontrolled

Nice job!! Glad I gave you the idea and I will try it as well.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontroled.

Tubular

For timing discussions, it might be worth disclosing the screens I have in mind (aside from VGA monitors). I intend to use Bill's 6.25Mhz crystal, PLL16x, divide by 5 to generate the 20 Mhz for the clocked SRAM

1) The Sharp LQ043T3DX0A (PSP), the touch verion of that sold by Sparkfun
4.3", 480*272, 9MHz dot clock
This screen has very lean blanking intervals but a low dot clock

2) AU Optronics G065VN01 (TTL version)
6.5", 640*480, 20 MHz dot clock
This screen *may* have relatively large blanking intervals which would allow some sprite manipulation at the end of each horizontal line. According to the datasheet,
Horizontal max: 640 active pixel clocks + (130-430 blanking clocks) 430 is 40%, double the standard
Vertical max: 480 active lines + (40-142 blanking lines). 142 is 22.8%, again about double the standard.
*If* all stretches can be simultaneously exploited, that gives an overall active % of (640*480)/(1070*622) or 46%, leaving up to 54% of the time for SRAM writing

I should declare my own goal is just to prove the concept for static images at 20 Mhz. I probably will just pre-load the SRAMs at leisure using SPIN with a blank screen, then switch over to 'sync clocked display mode'. I'll do a simple PCB to suit the proto board. Then others more familiar with this PASM can work on the driver smarts.


tubular

solarprism

pardon for digging up this but is the project complete or not?

Dr_Acula

Sounds an interesting concept.

Rough calcs - 640x480=307200 and I think the clock is about 25mhz. Not sure if you can read data from an sram and into the prop, then out of the prop in that time. The ram chips I've been using are 55ns which is close to the mark.

Or - do you use the prop to pre-load the sram and then clock it out continuously - back and front porch all pre created? There is dual port sram that allows you to load data in at the same time. Or the concept explored here http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=58818&view=next with two ram chips. Interesting reading the discussion about the problems likely to be faced.

Phil Pilgrim (PhiPi)

I've had a similar board in the works for some time, too. It uses six of the Microchip serial RAMs. They are double-buffered, so that three can be displaying, while the other three are being loaded with new data. Once loaded, the RAMs get swapped. I was hoping to push the "dot clock" speed to 25 MHz, which is standard for VGA, but I don't know if the RAMs can handle it. But, as was the case with localroger, other projects took priority, and I never finished it.

-Phil

hinv

Has anyone tried this concept with newer serial SRAMs, like SDI or SQI ones?

jmg

hinv wrote: »

Has anyone tried this concept with newer serial SRAMs, like SDI or SQI ones?

Yes, now you can buy 45MHz SRAMs to 4MBbit, in stock at Mouser.
http://www.issi.com/US/product-asynchronous-sram.shtml#jump5
Not available back in 2009

Also recent are the low-cost 8 pin PSRAMs
https://lcsc.com/product-detail/RAM_Lyontek-Inc-LY68L6400SLIT_C261881.html

and of course HyperRAM...

Mark_T

I am reminded of my project using SDRAMs with control signals driven by the video generator:
https://forums.parallax.com/discussion/150407/video-graphics-controller-using-propeller-to-control-sdram

I kept the 16 bit datapath off the Prop for speed.