Steve from Big O'Mess of Wires (homebuilt CPUs, among other things) has started a discussion at http://www.bigmessowires.com/2015/09/04 ... ubstitute/ about what hobbyists can use instead of SRAM given that those are rather small and expensive. I had wondered at one point if there isn't a way to hide the crazy refresh details of DRAM in some standardized CPLD chip the same way the 65SPI takes care of the SPI details? I admit I have no idea what I am talking about here, but this seems to be a common problem, and with the 65816, it would be nice to use more of that memory range without having to pay over €100.

Indeed, the difficulty is in hiding the refresh. I can think of three ways:
- there's an access pattern that already accomplishes refresh - either video accesses, or perhaps interrupt-driven accesses
- run the DRAM slowly enough that you can hide a refresh cycle next to a regular access cycle without the bus master needing to know
- be in a system which supports wait states or slow memory (using RDY in our case) so the CPU can be stalled about 2% of the time to allow refresh cycles.

As you say, a CPLD might be just the thing to do the work of incrementing the refresh address and marshalling the various strobes.

Could the refresh be done during dead bus cycles? The next thing with modern, large DRAMs is that they're not truly random-access, but go in bursts, intended for filling cache. The first byte of a burst takes quite a few cycles to fetch if I understood and remember it correctly, and then subsequent ones in the burst have to be in order, ie, you can't skip around like the 6502 does in memory accesses when doing alternately instructions, data, stack accesses, I/O, etc.. These are reasons we stick with SRAM.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Not just the refresh is a problem, but regular transfers also require several cycles for opening and closing rows, plus CAS latency.

You could hide that with a CPLD, but then it needs to run quite a bit faster than the CPU (maybe 10 times). It gets easier when you're allowed to insert wait states for the worst cases, but if SRAM is also used for video, then that may not be possible.

The linked pseudo-SRAM looks like it could be run as an SRAM up to something like 14MHz - it seems to hide its self-refresh into periods when CS is high.
http://www.mouser.com/ds/2/198/66WVE4M16BLL-258704.pdf
"The IS66WVE4M16BLL is an integrated memory device containing 64Mbit Pseudo Static Random Access
Memory using a self-refresh DRAM array organized as 4M words by 16 bits."

I did this this with a Spartan-3 FPGA a few years ago, making a 64MB SDRAM appear as SRAM to an external micro-controller.
The unit also read from the SDRAM to display 800x600 VGA to a monitor.

I learned a HUGE amount from Xess, and recommend their boards, which are well made...

http://www.xess.com/static/media/appnotes/an-071205-xsasdramcntl.pdf

The results of using SDRAM as pseudo SRAM were less than optimal, and a 10ns SRAM would outperform this setup easily.
Add the cost of the FPGA, power supply, config ROM, etc, and at $5.00, a 512K SRAM seems reasonably priced.

Digikey has constant stock of 32K SRAM and 512K SRAM in speeds from 55ns to 10ns all the time.
These must be needed someplace, as they have never been out of stock in the 10 years I have been ordering them!

There are many manufacturers, here are just the ones from Cypress I am using in my current project...

http://www.digikey.com/product-search/e ... ageSize=25

http://www.digikey.com/product-search/e ... ageSize=25


Brad

The Cypress 1049D (512KB) in SOJ36 is what I will be using in POC V2. I believe that is the same SRAM that Garth uses in his 4MB module.

BTW, Cypress also makes a 10ns 128KB SRAM in 300 mil wide SOJ32 (part number CY7C1009D). That one fits my POC V1.1 unit.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!