[Coco] Dynamic RAM Q

[jdaggett at gate.net]

Phil

You are correct in that the DRAM chips do latch row and colum address in on the falling 
edge  of the RAS and CAS lines.  From the SAM data sheet it appears that the RAS and 
CAS are derived from the 14MHz clock. The total period of both is 8 clock periods. Three 
high and five low. The CAS is delayed by two clock cycles. When the MPU is in slow mode 
this is fine. You get one RAS/CAS period in one half cycle of the E clock. When the MPU is 
in fast mode that is different. That would casue so issues if both the MPU  and the VDG 
were to want to acess ram at the same time. There maybe some other gating logic that is in 
the 6847 that may help prevent this. 

AS for the data that is presented on the Z buss there is a final stage multiplexer that is 
controlled probably by the Eclock that switches the row and colum data between the MPU, 
VDG and the refresh counter. Refresh is done during the horizontal sync period. Four row 
addresses per line for 32 lines will refresh 128 rows in 2 mS. This will fit the bill for 4116 
Drams. Actual row and column data is switched by another multiplexer that feeds the output 
multiplexer. The internal switching is done by a stack of 8 bit multiplexer that multiplex the 
row an dcolumn data for the upper and lower address from the MPU, the VDG and the row 
address from the refresh counter. After that the rest of the SAM chip is fairly straight 
forward. 

What I would do is keep your  memory expansion configured in an array in which there is 
128 rows by what ever columns needed. That way the current refresh counter in the SAM 
chip will refresh all the ram. Use what ever extension on the column address to do 
essentially bank switching. Then your external CPLD would need the CAS line to control the 
expanded columns in teh memeory array. This would be okay for 128K or maybe up to 
256K of ram. This would limit the dram that you can use though. Another solution is to 
replace the 74LS783 with an 74LS785 that could be gotten out of one of the late model 
Coco2s. Then you could use  4164 drams or even 41256 drams. 


james
On 8 Oct 2006 at 15:51, Phill Harvey-Smith wrote:

> Richard Atkinson wrote:
> > Hi Phill,
> > 
> > Good to see another UK person on the list!
> 
> :)
> Yeah I'm on the Dragon one too, dunno if you are a CoCo or a Dragon
> person :)
> 
> > Your best bet may be to make A8 and A9 functions of the 14.3MHz SAM
> > clock, as well as or instead of E and/or Q. What you're trying to do
> > is replicate the internal state machine inside the 6883 SAM, so that
> > your A8 and A9 lines change state on the same 14.3MHz cycle as the
> > Z0-Z7 lines do.
> 
> Yes this is what I am trying to do, so that I effectivly increse the
> size of the memory the SAM can address.
> 
> > There are a number of different ways you could do this. Firstly you
> > could make a purely digital finite state machine as described above,
> > using the 14.3MHz clock source. It may well need some buffering to
> > drive your circuit; the SAM oscillator circuit isn't expecting to
> > drive anything other than the crystal / SAM combination.
> 
> Yeah I did wonder about that though it would make things a little more
> complex.
> 
> > An alternative would be to observe the transitions of Z0-Z7 on an 
> > oscilloscope relative to the edges of one of the other clocks, for 
> > example E and/or Q. If there is a fixed timing relationship between
> > them, such that the transitions on Z0-Z7 lag a known edge on E and Q,
> > you could generate a select signal for your multiplexers from a
> > suitably delayed version of that. The SAM datasheet may give
> > guaranteed values for such timing. This may involve some
> > combinational logic and some time delay elements such as RC networks.
> > This might not be as 'pure' or 'neat' a solution as above, but it 
> > avoids using the 14.3MHz clock (and having to clock your CPLD that
> > high).
> 
> When I looked at it with my logic analiser, it did seem like the video 
> clock could possibly be used as it seemd to rise just before RAS, and 
> fall just before CAS. However I have been reading some RAM data sheets 
> which seem to suggest that the RAM latches the address lines shortly 
> after the fall of RAS and CAS, in this case I can just use these signals 
> to gate the Z lines, if I have a fast enough CPLD, which I believe that 
> I do.
> 
> > Have you thought about what to do on VDG cycles as well as CPU
> > cycles?
> 
> Yeah at the moment, Z8 and above are forced to 0 when the E clock is 
> low, which of course means that the VDG is limited to the first 64K, but 
> it also keeps things simple for the time being, I may later if my CPLD 
> has enough free logic space add an offset reg for the VDG which would 
> allow it to address the whole 1M.
> 
> Cheers.
> 
> Phill.
> 
> -- 
> Phill Harvey-Smith, Programmer, Hardware hacker, and general eccentric !
> 
> "You can twist perceptions, but reality won't budge" -- Rush.
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 
> 
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.407 / Virus Database: 268.13.1/466 - Release Date: 10/7/2006
>