Prop 1 with a low pin-count 512KB SRAM
Cabbage
Posts: 37
If you had a 512KByte SRAM module with a 13 pin interface (3.3 Volt GPIO), capable of data transfer rates of up to 20Mbit/second... and a Propeller 1 to connect it to... what kind of project would you build?
I'm having a major failure of inspiration at the moment. I thought of making a logic analyser, but that's obvious and boring (and besides I already have one).
Could such a slow SRAM be useful as some kind of video framebuffer? I'm not very familiar with the Prop's video capabilities.
Can anyone think of an interesting project that could benefit from a decent amount of volatile RAM?
Here's a picture if anyone's interested...
The eagle eyed will notice that it's open source. If anyone wants the schematic and PCB files (Diptrace format) let me know. 
I designed it because I wanted a good amount of storage, but without using lots of IO pins. The sacrifice is speed of course, the address gets latched in in two parts (using MOVS) and this lets me compress the IO interface down to 13 pins.
The 20MBit/sec figure is based on my old PASM driver that I wrote ages ago. It turns out that it takes 32 instructions to read / write 32 bits of data to / from the SRAM module. The module is optimised for 32-bit long transfers but you could theoretically stripe each column at 8 bits at a time if you were to re-write the driver. I'll provide the code if there's any interest.
The Alliance ram chips don't seem to be easily available these days, but alternatives do exist from other manufacturers.
What could I use this (completely impractical thing) for?
Comments
You might be able to use Catalina C, after writing a small memory driver. XMM support in PropGcc seems to be abandoned and - as far a I know - FlexProp & Co do not support external memory.
Enjoy!
Mike
@Cabbage If you can only ever get 20Mbps from your RAM then you would not be able to do too much more than 2bpp 320x200/240 type of NTSC video resolutions, or monochrome 640x240 NTSC or mono 320x240 VGA with a direct framebuffer from RAM approach. However if you are able to keep the upper address bytes latched and only latch the least significant address byte on each read as it changes you might be able to boost this significantly. I doubt it would take 32 P1 instructions just to change the bottom latched address and read the next value unless the memory latency is really bad. If you post a picture of the schematic and current code it should become obvious if this is possible.
Edit: on second thoughts, maybe with all the bus turnaround overheads and hub latency and loop overheads this type of single byte access won't help speed things up, this is a P1 not a P2 after all. I've been spoiled in P2 land for too long.