[comp.sys.atari.st] TT ram revisited

meulenbr@cst.prl.philips.nl (Frans Meulenbroeks) (06/07/91)

Hi,

Thanks to all who responded on my TT ram question.
I won't summarize here. Allen Pratt dealt with the question in great 
detail. I don't think I should just duplicate that.

I'm left with a few small questions.

Allen says that in the future you can buy 16 MB of TT RAM
from atari. Could I do such an upgrade by myself by just
replacing the 1 MB simms by 4 MB ones, or are there other caveats?

Also I found out that the TT ram is 100ns ram. I do not have any 68030
doc handy, but with a 32 Mhz clock, I think at least one (and very maybe 2) 
wait states will be required to access this memory.
Would it be technically feasible to replace this memory with faster
memory, and get rid of this wait state? Will 80 ns be enough to get rid
of the wait state, or should 60 ns be used??

Since, if I'm not mistaken, the 68030 requires at least 3 clock cycles to
do a memory access. So removing a wait cycle would speed up the memory
access from 4 to 3 cycles. which would (in theory)  lead to a speed
gain of something like 25 %. Now of course not all cpu activity is 
memory access, so perhaps this figure is on the high side, but it seems
to me that a substantial gain could be obtained here.

--
Frans Meulenbroeks        (meulenbr@prl.philips.nl)
	Centre for Software Technology

mbaker@ucs.adelaide.edu.au (Matthew Baker) (06/08/91)

From article <meulenbr.676276267@cstw163>, by meulenbr@cst.prl.philips.nl (Frans Meulenbroeks):
> Hi,

Hi... :)

> Also I found out that the TT ram is 100ns ram. I do not have any 68030
> doc handy, but with a 32 Mhz clock, I think at least one (and very maybe 2) 
> wait states will be required to access this memory.
> Would it be technically feasible to replace this memory with faster
> memory, and get rid of this wait state? Will 80 ns be enough to get rid
> of the wait state, or should 60 ns be used??

At the risk of making a fool of myself, I should call to notice the fact 
that most larger Intel-powered systems use 70 or 80ns DRAMs, with
similar clock speeds. Even these chips aren't fast enough to keep up
with the CPU. Various techniques are used to ensure that, most of the time, 
the same DRAM is not read twice in two machine cycles... on the rare 
occurence that it is, a wait state is inserted... - thus, you get quotes
of 0.01 wait states, etc.

> Since, if I'm not mistaken, the 68030 requires at least 3 clock cycles to
> do a memory access. So removing a wait cycle would speed up the memory
> access from 4 to 3 cycles. which would (in theory)  lead to a speed
> gain of something like 25 %. Now of course not all cpu activity is 
> memory access, so perhaps this figure is on the high side, but it seems
> to me that a substantial gain could be obtained here.

Not being sure of the exact details for the '030, but with the 000 and 010
there are 4 clock cycles between /AS and the first scan for /DTACK.
As I said, if the memory architecture is properly designed, in most 
instances, the memory will be capable of responding immediately.

Any comments from those more familiar with the 030 and the TT's 
architecture are welcome...

> Frans Meulenbroeks        (meulenbr@prl.philips.nl)
> 	Centre for Software Technology

Matthew

Roger.Sheppard@actrix.gen.nz (Roger Sheppard) (06/09/91)

In article <3590@sirius.ucs.adelaide.edu.au> mbaker@ucs.adelaide.edu.au (Matthew Baker) writes:
> From article <meulenbr.676276267@cstw163>, by meulenbr@cst.prl.philips.nl (Frans Meulenbroeks):
> > Hi,
> 
> Hi... :)
> 
> > Also I found out that the TT ram is 100ns ram. I do not have any 68030
> > doc handy, but with a 32 Mhz clock, I think at least one (and very maybe 2) 
> > wait states will be required to access this memory.
> > Would it be technically feasible to replace this memory with faster
> > memory, and get rid of this wait state? Will 80 ns be enough to get rid
> > of the wait state, or should 60 ns be used??
> 
> At the risk of making a fool of myself, I should call to notice the fact 
> that most larger Intel-powered systems use 70 or 80ns DRAMs, with
> similar clock speeds. Even these chips aren't fast enough to keep up
> with the CPU. Various techniques are used to ensure that, most of the time, 
> the same DRAM is not read twice in two machine cycles... on the rare 
> occurence that it is, a wait state is inserted... - thus, you get quotes
> of 0.01 wait states, etc.
> 
> > Since, if I'm not mistaken, the 68030 requires at least 3 clock cycles to
> > do a memory access. So removing a wait cycle would speed up the memory
> > access from 4 to 3 cycles. which would (in theory)  lead to a speed
> > gain of something like 25 %. Now of course not all cpu activity is 
> > memory access, so perhaps this figure is on the high side, but it seems
> > to me that a substantial gain could be obtained here.
> 
> Not being sure of the exact details for the '030, but with the 000 and 010
> there are 4 clock cycles between /AS and the first scan for /DTACK.
> As I said, if the memory architecture is properly designed, in most 
> instances, the memory will be capable of responding immediately.
> 
> Any comments from those more familiar with the 030 and the TT's 
> architecture are welcome...
> 
> > Frans Meulenbroeks        (meulenbr@prl.philips.nl)
> > 	Centre for Software Technology
> 
> Matthew

Well from what I have read, its only the CPU that runs at 32 mhz, the
other bits (buss) runs at 16 mhz.
Is it not the same as these 16 mhz Turbo options for the ST, you still keep
you standard Rams and Roms, ie, only the CPU runs at that speed ?.
-- 
***  Roger W. Sheppard        *    Roger.Sheppard@bbs.actrix.gen.nz  ***
***  85 Donovan Rd          *  *   At least I don't Flicker, not     ***
***  Kapiti New Zealand..    *     like a dying light globe. !       ***

stigvi@Lise.Unit.NO (Stig Vidar Hovland) (06/10/91)

|> From article <meulenbr.676276267@cstw163>, by meulenbr@cst.prl.philips.nl (Frans Meulenbroeks):
|> 
|> > Also I found out that the TT ram is 100ns ram. I do not have any 68030
|> > doc handy, but with a 32 Mhz clock, I think at least one (and very maybe 2) 
|> > wait states will be required to access this memory.
|> > Would it be technically feasible to replace this memory with faster
|> > memory, and get rid of this wait state? Will 80 ns be enough to get rid
|> > of the wait state, or should 60 ns be used??
|> 

If the cpu need to read data, it is done in burst modus. This means that the cpu reads the first long word in two cycles and the next three long words in three cycles. You will only speed up writing to memory if you replace the memory card with a faster one. There are some third party ram cards which are faster than Ataris, but I don't know nothing about these cards.

Stig Vidar Hovland - stigvi@lise.unit.no