Iterating through SRAM with almost no pins

cbmeeks

So, I've had this little idea in the back of my head for a long time. Recently, I built my own S-Video converter for my Amiga 500 using the AD724. I was so impressed that it worked (and how easy it was), that the old idea came back up again.

The idea is simple (on paper, anyway).

Imagine I have a large and fast SRAM IC connected to the AD724. The purpose would be to drive the AD724 with the data bus and get 256 colors going through an R2R network. What the SRAM drives isn't as important but I wanted to give some context.

Now, without devoting a bunch of pins from the Propeller, I was thinking how could I iterate through some screen buffers? For example, say I devote 32K to one page. That would be 15 pins for the address bus. Then, other pins to control which page was being displayed. I was thinking of using some kind of counter and have the propeller clock it. But a 12 bit ripple counter wouldn't be enough. And, I think the max speed would be about 25 MHz. But I guess this would be fast enough to drive scanlines.

The idea would be to set the page offset at the beginning of the screen. Iterate through the RAM with each byte being one pixel. So 160 x 192 bytes or so. During that, the propeller would only be using a very small amount of pins.

I hope I'm making sense here.

So, any ideas on this? I might just wire up a counter and give it a try. Maybe I use two counters for each half of the screen?

Thanks for any suggestions!

**EDIT**

BTW, such a setup allows for some really neat effects. For example, having a display of RRGGBBII could allow for 64 colors with 4 intensity levels. With just a few resistors. :-)

And, having 512K of SRAM devoted to video allows some smooth scrolling too! Imaging the possibilities with just a handful of chips.

Mike Green

Using a counter for the address lines is a good idea ... for the sequential data stream required to generate the video, but how about writing the data to the SRAM? You need to be able to load an arbitrary address into the counter for writing, say during display retrace (horizontal and vertical sync) times. You'd have a little time during horizontal sync pulses and somewhat more time during vertical sync pulses. You'll also have to have data lines from the Prop to the SRAM for the data to be written. Whether these have to be shared somehow depends on the design of the SRAM.

cbmeeks

Yeah, those are the nitty-gritty details that always plague good ideas. HA!

Seriously, I was thinking about that too. I could do it like the ZX Spectrum did...which is what you're saying. Allow access during the small h-blank time and during the v-blank time. But during screen drawing, the memory is contended.

But I'm not sure how I would set an arbitrary address without using a bunch of pins...which negates the need for the counter. Especially if I wanted fast writes.

Mike Green

You need some kind of shift register. If most of what you want is sequential with occasional setting of a new address, you could use a shift register like the 74HCT595 ... two in series for 16 bits. For more speed, you can use two independent ones and load them both with 8 clocks. Your counter needs to have a parallel count load.

jmg

cbmeeks wrote: »

So, any ideas on this? I might just wire up a counter and give it a try. Maybe I use two counters for each half of the screen?

There are some choices for this :
* Use Parallel SRAM+ Logic Counters - someone did this around P1, but this needs many packages.
* Use Parallel SRAM + CPLD Counters - more compact, and faster, but needs CPLD design
* use Serial SRAM
if you want NTSC/PAL then this gets it in one package.... No need for costly AD724 at all...
http://www.vlsi.fi/en/products/vs23s010.html
http://webstore.vlsi.fi/epages/vlsi.sf/en_GB/?ObjectPath=/Shops/2015020901/Categories/"Circuits and KITs"/VS23S010

Or, you could look at QuadSPI SRAM from Microchip etc, which has the counters inbuilt, and can CLk at 20Mhz

or, try HyperRAM, much faster and larger, but a little trickier to drive.
http://www.digikey.com/product-search/en?keywords=HyperRAM

cbmeeks

Those are some great suggestions!

I admit the AD724/5's are expensive. Even though they market them as cheap. I guess it's relative. Cheap considering you don't need many external components. :-) One reason I would use them is because I have a few of them already. I got some as free samples a long time ago. Which is why I have more 724's.

But I didn't know about the VLSI IC! That looks pretty cool! I'm going to look into that as well. The HyperRAM seems to be only BGA so no deal for me. My old eyes can barely handle SOIC. lol

Thanks again.

kwinn

You could also dedicate a second propeller to drive the video ram. Adds a lot of processing power to the system, simplifies updating video, and is probably close in cost to doing it in hardware.

cbmeeks

That's actually an idea I've had as well. I'm still working on my 6502 SBC which I'm designing to use an entire propeller as the GPU.

jmg

cbmeeks wrote: »

That's actually an idea I've had as well. I'm still working on my 6502 SBC which I'm designing to use an entire propeller as the GPU.

IIRC another design used P1 as the Y axis counter, and Logic for the X-axis.
If you do not need a lot of pixels (ie Composite rather than VGA) then a P1 may be able to manage X-axis to mid-400 pixels up to 20MHz, by using a whole cog as the counter.
It might be possible to combine a small counter (2-4b) and P1, to push above 20MHz/4xx pixels, but that gets complex as you have P1 pins and counter pins and a clock enable all with their own skews.