HomeForumsWhat's newResources 
 
 
DRAM cartridge
patroclus02 - May 8, 2006
  patroclus02 May 8, 2006
After getting my expansion port cartridge to run perfectly, I would like to make a bigger cartridge to play backup and larger games.

Flash ROM is slow when writting to it.

SRAM prize is high.

I heard of people proposing DRAM, as if Genesis could handle it, but I don't get this clear.

DRAM would still need a DRAM controller for it to refresh it, and that is quite very complex to do. Is there any way out?

 ExCyber May 8, 2006
There's no easy way out, although it seems it's not as bad as needing a full-blown DRAM controller chip. Genesis provides some signals that look like they can be coopted to be used as DRAM control signals, but you would still at least need to build a circuit to insert refresh pulses (either conventional with a row counter or CBR)

 patroclus02 May 9, 2006
But what about if a read request comes while refreshing??

I suppose Genesis has a read cicle. SNES for example is 200 or 120ns. refreshing one DRAM row takes at very leas about 60ns. Then you will have to do all the read task...

 ExCyber May 9, 2006
Well, there are a couple approaches to this. One is to use multiple DRAM banks and interleave words among the banks. This would consume more power than a single-bank approach, but you could then refresh one bank while accessing the other (most SDRAM puts multiple banks on a single chip for exactly this reason, but I think most 72-pin SIMMs are multi-bank also). Another is to try to do "hidden refresh" which basically amounts to sneaking in a refresh cycle after a read. Micron has some good info on the various approaches in their datasheets. Another option would be to detect when Genesis is not accessing the cart area at all (e.g. /AS asserts without cart /CE asserting, which IIRC even happens during VDP DMA) and insert your refreshes then. In that case there might be a problem with idle loops that wait for an interrupt, though, e.g.:

Code: 
  
vdpwait:

BRA vdpwait
I don't think this type of code would generate any access to a non-cart area and might run for the better part of a frame depending on the circumstances...