Adding DRAM to the Genesis

[cgfm2]

Has anyone figured out the details about how to use DRAM on the Genesis? I'm assuming it is capable of automatic refresh, which would simplify the glue logic used. My guess is that the DRAM control register at $A11000 is used to enable it, periodically halting the 68000 to insert a refresh cycle.

But I don't know the details; for example the cartridge port has two /CAS strobes and no /RAS. Likewise the expansion slot has two /CAS, one /RAS, but no /AS so I don't see how external logic can know the address bus is valid.

Also I'm wondering what limitations there are on how many addresses are refreshed, basically what the size of the refresh counter is. I'd like to think it could handle 4MB, but it could be much smaller.

Any tips?

 

[ExCyber]

I remember reading in an old Genesis doc that pin B21 (I think this is one of the "CAS" ones on the schematic that's floating around) goes at a variable range when the CPU is running but maximizes at a constant rate in the KHz range when the CPU is halted, which suggests that it might be used to trigger refresh logic. Unfortunately I don't know much of anything about it beyond that.

 

[Pinchy]

From what Ive seen of backup units for cart consoles is they just make there own refresh signals.

When OE or what have you is asserted and the cpu is wanting to see some data. the CBR refresh stops and then whatever is controlling the dram does its RAS along with address high, then CAS and address low then the data will appear. IIRC most dram from that time was like 60ns or so, so you had plenty of time to do all the setup of cas/ras and address, since those cpus gave you about 150ns to get the data valid.

You might have to watch some other signal to know when the 68k has OE low but doesnt require data so you can go on and continue CBR refresh.

If you plan on connecting some dram, try to gate the data bus from the dram to the cart so you can electrically disconnect it and write to it from whatever your going to use. Thats one problem I had was not being able to write to dram when it was connected. And use some modern sdram, they have some at digikey. Those old 72 pin simms where absolute power hogs, like 1A at peak.

I guess what im saying is to forget those CAS RAS on the cart, there useless .. i think

 

[ExCyber]

I'm not sure you can rely entirely on 68K signals/timing, since the VDP can also read from the cart. I think where I got stuck was that I didn't know of a cart signal that the VDP would assert while writing to VRAM (there may be one; I didn't examine it thoroughly), and I thought a cart-to-VRAM DMA transfer might take longer than a refresh could wait. Now that I think about it a bit more, I wonder if it would be better to stick the bank address pins on the low bits and just do a refresh on whichever bank isn't being accessed at the moment. I suppose you might need some other kind of backup in the case of a branch instruction branching to itself though (or would prefetch still grab the next instruction in that case?).

 

[Chilly Willy]

You can get 2Mx16 static RAM chips for less than $10. Don't bother with DRAM.

 

[ExCyber]

I looked at the schematic a bit, and it appears that /CAS2 doesn't connect to anything other than the glue chip and its respective cart/expansion pins. The more I look at it, the more it looks like this is indeed intended to control external DRAM refresh, though I can't draw any conclusions without looking at the signal itself.

Anyway, for regular reads and writes it seems like it would work to just use cart /CE as /RAS and delay it to generate /CAS (aside from decoding it, which would be wildly different depending on whether you're using 2 32-pin SIMMS, a 72-pin SIMM, or individual chips). Assertion of /CE implies a valid address, so there's no need to watch the /AS signal unless you want to know when the 68K is accessing some other area for some reason (e.g. you want to be able to access from a PC connection and need to know when you can sneak in a cycle).

As for refresh, I think you'd be better off using CAS-before-RAS refresh than relying on a row counter with unspecified behavior. That way you only need to worry about detecting where you can stick in a refresh cycle. If you're only interested in using this for crazy homebrew experiments, you might be able to get away with doing the refresh in software as well.

Originally posted by "Chilly Willy"

You can get 2Mx16 static RAM chips for less than $10.

I'm pretty sure that would be PSRAM, which tends to run at inconvenient voltages (for Genesis) and come in fine-pitch SMT packages. I'd be interested to know if you are aware of any well-distributed 2Mx16 SRAM, actually...

 

[Chilly Willy]

Well, the TC55VEM416AXBN from Toshiba is 1Mx16, fully static, and TTL compatible. A number of companies list it, but say "call for a quote," so it's probably a lot more than PSRAMs.

The Toshiba TC51WHM516AXBN is a PSRAM 2Mx16 part. It's also TTL compatible.

 

[Pinchy]

Heres some readings of the signals off the expansion port.

http://www.crazynation.org/SEGA/Genesis/Files/MyLa.zip

GEN_ALL2.mla is the best example and was taken during streets of rage2.

Use the mouse wheel to zoom in and out of the data , right click and drag etc..

Looks like CAS0 is actually RAS and CAS2 is column. I didnt ever see it do a CBR style refresh though. Doesnt VRAM share the same bus as the rest of system memory? Look like theres some instances in the capture where VDP does some DMAesque bus operations.

So it looks like you would only need to use CAS0 (ras) and CAS2 and you would be done, except I dont know about if refresh is taken care of.

Using SRAM of course would be easy but no fun, HARD way = FUN way.

 

[cgfm2]

Looks like CAS0 is actually RAS and CAS2 is column. I didnt ever see it do a CBR style refresh though. Doesnt VRAM share the same bus as the rest of system memory? Look like theres some instances in the capture where

VDP does some DMAesque bus operations.

VRAM is on a separate bus, but I agree that some of the funkier bus activity is probably due to DMA.

So it looks like you would only need to use CAS0 (ras) and CAS2 and you would be done, except I dont know about if refresh is taken care of.

There's a DRAM 'control' register, maybe for enabling refresh. Writing $0100 to $A11000 turns it on, IIRC. Would be interesting to see how CAS0/CAS2 react with this bit set.

I would imagine it's off by default, since the VDP probably delays /DTACK during refresh which would slow down the 68000. That said, I should do some timing tests on a Genesis and see if any noticable change happens in execution speed when the DRAM control register is off or on.

Maybe with it on, you'd see CBR refresh or something similar.

 

[ExCyber]

Pinchy, are your AS, CE0, CAS0 and CAS2 waveforms showing logical levels or physical levels?

 

[ExCyber]

After looking at Pinchy's LA capture, I'd say it looks like:

1) Timings for /CAS0 and /CAS2 are consistent with /RAS and /CAS respectively (as Pinchy previously mentioned; just concurring and mentioning for completeness).

2) /CAS0 and /CAS2 are not asserted during RAM/VRAM/fill DMA

3) /AS is asserted normally during RAM/VRAM/fill DMA transfers, which should take care of the concerns I mentioned about using it to trigger refresh logic. With appropriate bank organization and /AS triggering some CAS-before-RAS refresh logic, I think you could refresh semi-nicely without the Genny generating refresh cycles.