Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!mbaker From: mbaker@ucs.adelaide.edu.au (Matthew Baker) Newsgroups: comp.sys.atari.st Subject: Re: TT ram revisited Message-ID: <3590@sirius.ucs.adelaide.edu.au> Date: 8 Jun 91 08:23:23 GMT Article-I.D.: sirius.3590 References: Organization: Information Technology Division, The University of Adelaide, AUSTRALIA Lines: 38 From article , 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