[comp.sys.mac] SIMM RAM for the MacII

korn@cory.Berkeley.EDU.UUCP (09/01/87)

A few weeks ago comp.sys.mac saw a discussion of SIMM RAM for the MacII,
with the consensus being that one *had* to use either 120 or 100 ns RAM
SIMMS (which all the new Mac+ and SEs had in 'em anyway).  Well, we 
just upgraded our Mac+ to 2 Meg via the DOVE 2H board, and I decided to
put the 256K SIMMs into my MacII.  Trouble was, these SIMMS were the 
older 150ns SIMMs.  But, lo and behold, THEY WORKED.  I haven't had a 
chance to benchmark 'em, but as far as I can tell, they're causing no
problems.

So, it seems that 150ns DRAMs are perfectly kosher for a MacII.  When
I get a chance, I'll run some timing benchmarks, and re-post those
findings.


Peter

P.S.  The Dove upgrade worked quite well, and I'm very happy with it.  To
      get only 2 Meg out of it (vs. 2.5 Meg), you have to solder a 150 ohm
      resistor onto the motherboard.  After doing that, it works fine.
--
Peter "Arrgh" Korn
korn@ucbvax.Berkeley.EDU
{decvax,dual,hplabs,sdcsvax,ulysses}!ucbvax!korn

stuart@ihlpf.UUCP (09/01/87)

In article <20389@ucbvax.BERKELEY.EDU>, korn@cory.Berkeley.EDU (Peter "Arrgh" Korn) writes:
[a nice intro about SIMM RAM speeds needed for Mac II]
> just upgraded our Mac+ to 2 Meg via the DOVE 2H board, and I decided to
> put the 256K SIMMs into my MacII.  Trouble was, these SIMMS were the 
> older 150ns SIMMs.  But, lo and behold, THEY WORKED.  I haven't had a 
> chance to benchmark 'em, but as far as I can tell, they're causing no
> problems.
> 
> So, it seems that 150ns DRAMs are perfectly kosher for a MacII.  When
> I get a chance, I'll run some timing benchmarks, and re-post those
> findings.
> 

Yes, they may work, but this is the same argument as with single-side
floppies being used as double-sided ones.  They may work, but there is
a question of reliability.  It would be REALLY nasty if you were doing
your taxes in EXCEL and some memory glitch  changed your results and sent
you into IRS-AUDIT land.

So its not just *DO* they work, but HOW RELIABLY.  How does one test that?

Stu

-- 
Stuart Ericson		USnail:		AT&T Bell Laboratories
USENET: ..!ihnp4!ihlpf!stuart		IH 6M-313
voice: (312) 979-4152			Naperville-Wheaton Rd.
"A fool knows everything and nothing"	Naperville,  Il 60566

dchen@rainier.UUCP (09/02/87)

In article <2085@ihlpf.ATT.COM>, stuart@ihlpf.ATT.COM (Stu Ericson) writes:
> In article <20389@ucbvax.BERKELEY.EDU>, korn@cory.Berkeley.EDU (Peter "Arrgh" Korn) writes:
> [a nice intro about SIMM RAM speeds needed for Mac II]
> > So, it seems that 150ns DRAMs are perfectly kosher for a MacII.  When
> > I get a chance, I'll run some timing benchmarks, and re-post those
> > findings.
> 
> [point made that these memories are being run faster than rated]
> So its not just *DO* they work, but HOW RELIABLY.  How does one test that?
	Well, what I've seen done is burn hardware in either a) slightly
faster than it's intended to be run (kick your crystal up to 18 MHz or such).
Doesn't seem too likely on a Mac II.  The b) option, which I might
do myself if I didn't want to spend the bucks, is to burn those memories in
at some elevated temperature (shut off the fans, or (much safer
to your Mac) build an envelope to cover the SIMMs in question).
This generates some margin in MOS, because MOS tends to run slower
at elevated temperatures.
	This is not recommended for the nervous;  nobody's going
to listen if you blow up your Mac II and cry.

Disclaimer:  That includes me.

jww@sdcsvax.UCSD.EDU (Joel West) (09/04/87)

A friend who'd unsuccessfully bought two third-party SIMM upgrades
for his II may have found the problem.  Turns out he didn't have the
same initial SIMM bank as everyone else -- i.e., it was from a
different manufacturer.  The local guru at Levco suggested that
adding a second bank of RAM, not from that manufacturer, would
probably screw up the timing -- particularly if the second bank
of RAM became ready (on each cycle) before the first.

Wish I had the manufacturer's names to offer more.  But this might
explain why some of these upgrades work for some, not all.
-- 
	Joel West  (c/o UCSD)
	Palomar Software, Inc., P.O. Box 2635, Vista, CA  92083
	{ucbvax,ihnp4}!sdcsvax!jww 	jww@sdcsvax.ucsd.edu
   or	ihnp4!crash!palomar!joel	joel@palomar.cts.com

fjo@ttrde.UUCP (Frank Owen ) (09/08/87)

in article <20389@ucbvax.BERKELEY.EDU>, korn@cory.Berkeley.EDU (Peter "Arrgh" Korn) says:
> put the 256K SIMMs into my MacII.  Trouble was, these SIMMS were the 
> older 150ns SIMMs.  But, lo and behold, THEY WORKED.  I haven't had a 
> chance to benchmark 'em, ...
> So, it seems that 150ns DRAMs are perfectly kosher for a MacII.  

This is a dangerous thing to do, although the results you are having are
not surprising. In many cases, rams spec'ed at 150ns will typically
have access times much less than 150ns. The 150ns spec means that under
a certain set of operating circumstances the rams will exibit an access
time less than or equal to 150 ns. However, in practice, you will rarely
reach the limits of the conditions that would bring that access time
close to the 150ns spec.

Also, some manufacturers "over-spec" their parts more than others.
(Manufacturers will often call an "x"ns part an "x+margin"ns part to
cover themselves.)

Also, there is a certain amount of uncertainty in the access-time from
part to part. Some parts from a certain "good" lot may greatly exceed
the 150ns spec, whereas others may be right at the borderline.

So, if you use a 150ns part where a 100ns part is specified, you are
walking on thin ice. You might be lucky and get an overspeced part,
and you might not ever approach the limits of operation (like high temperature)
but if you do, you could be in trouble.

Also, using a slower or faster part will not in any way affect the speed
that the MacII will operate. If you were to use a 2ns access part, the
memory cycle time of the MacII will still be governed by the same
timing constraints as if you were to use a 100ns part.

So my advice:
   Buy the part specified, but don't pay more for a part with
   greater speed. You will be wasting your money.

   Frank Owen (..ihnp4!ttrde!fjo)