NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/sys/mac/hardware/20968

Internet Message Format | 1992-11-07 | 3.7 KB

Path: sparky!uunet!snorkelwacker.mit.edu!paperboy.osf.org!think.com!eplunix!das
From: [e-mail] (David Steffens)
Newsgroups: comp.sys.mac.hardware
Subject: Re: 25 mHz IIsi--another success story
Message-ID: <[e-mail]>
Date: 5 Nov 92 23:39:55 GMT
References: <[e-mail]>
Organization: Eaton-Peabody Lab, Boston, MA
Lines: 58

In article <[e-mail]>,
[e-mail] (Andrew Johnson) writes:
> Why doesn't someone with a IIsi look at the number on top of their CPU and
> look up in a Motorola manual to see what clock speed that chip is rated for?
> Ditto for the other bits (although 74ALS shouldn't be bothered...

Because it's not that simple.  What matters are the time delays in the critical
signal paths, _not_ the speed of the individual chips!  The issue is whether
the decreased clock period is so short that one or more critical signals
cannot reach a stable level before the next clock edge.  If so, a setup time
violation might occur, resulting in erratic operation of the entire system
even though each of the chips taken individually might be "fast enough"
according to the data sheets.

Note also that timing calculations cannot be made without complete and detailed
logic diagrams.  And they must be done for each and every signal pathway in
the entire machine because if _any_ signal pathway is too slow for the faster
clock, then you _cannot_ guarantee that the upgrade will work reliably.

Furthermore, some of the chips are almost certainly Apple-proprietary, e.g.
custom PALs and/or ASICs, so a datasheet won't be readily available for them.
That makes it even _harder_ to guarantee that all timing is within spec.

> ...The practice of engieering products with margins of safety to cope with
> random variations in component nominal characteristics has also been normal
> for many many years...

Which is why some upgrades will be successful and some will not (as another
poster already pointed out).  If you are "lucky", most of the chips will be
slightly faster than "typical", none of the critical timing constraints will
be violated, and the upgrade will "work".  If you are "unlucky", some of the
chips may be much slower than "typical", the machine may already be operating
on the hairy edge, and when such a machine is upgraded, well... so it goes.

Remember, too, that timing margins are also designed to cover variations
in chip speed due to changes in power supply voltages and in temperature.
Thus, an upgraded IIsi might work in summer, but not in winter (or vice versa).
Or it might fail when the wall socket voltage is particularly low (or high).
And without running all the numbers, you have absolutely _no_ way of knowing!

> ...And yes I'm biased. I'm an Electronic Engineer...

So am I, but that proves nothing.  How much digital design have you done?
Your posting doesn't indicate a great depth of experience in this area.

Nevertheless, I actually agree with you... If I had a IIsi I'd probably try
the upgrade, but only if the following three conditions applied:
1) I was reasonably sure that I could switch back to the old oscillator
   if the new one didn't work out very well.
2) I was willing to tolerate the loss of productivity caused by a possibly
   flakey machine that might crash at the most inopportune time.
3) I'd never use (or allow anyone else to use) an upgraded machine for work
   so critical that I was unwilling to risk the possible loss of a file.
--
David Allan Steffens       | I believe in learning from past mistakes...
Eaton-Peabody Laboratory   | but why does a good education require so many?
Mass. Eye & Ear Infirmary, 243 Charles Street, Boston, MA 02114
{harvard,mit-eddie}!eplunix!das    Tel [phone]    Fax [phone]