Path: utzoo!attcan!uunet!tektronix!percival!bucket!leonard
From: leonard@bucket.UUCP (Leonard Erickson)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Speeding up old PC's
Message-ID: <1113@bucket.UUCP>
Date: 18 Oct 88 23:38:23 GMT
References: <235494b5@ralf> <1109@bucket.UUCP> <3312@pt.cs.cmu.edu>
Reply-To: leonard@bucket.UUCP (Leonard Erickson)
Organization: Rick's Home Grown Unix; Portland, OR
Lines: 30

In article <3312@pt.cs.cmu.edu> ralf@b.gp.cs.cmu.edu (Ralf Brown) writes:
<In article <1109@bucket.UUCP> leonard@bucket.UUCP (Leonard Erickson) writes:
<}In article <235494b5@ralf> Ralf.Brown@B.GP.CS.CMU.EDU writes:
<}<Your experience must be exclusively with systems using extremely slow logic
<}<chips.  My 9.8/1 AT clone works just fine with 150ns chips....
<}
<}You should have paid more attention to what I posted. *my* example was a 10 
<}Mhz *XT*, not an AT. And II've checked with some others. 10Mhz XT motherboards
<}WILL NOT work with 150 ns RAM. 
<
<What could possibly be so slow that 150ns chips work with the 300ns cycle time
<of a 10MHz AT but not with the 400ns cycle time of a 10MHz XT?

I think I've found the answer to all of this...

In the Byte special issue on IBM there is a note about this. The 150ns is
the *access* time. But DRAM requires a "recharge" time before the next access
that is only slightly shorter than the access time. So reading one byte will
work.  Reading widely scattered bytes will work. But reading sequential bytes
will quite likely fail.

See page 102 of "BYTE IBM Special Edition" for details.

I'd say the question isn't why our machines require the faster RAM, but
rather how your machine manages to work with the slow RAM.
-- 
Leonard Erickson		...!tektronix!reed!percival!bucket!leonard
CIS: [70465,203]
"I used to be a hacker. Now I'm a 'microcomputer specialist'.
You know... I'd rather be a hacker."