Path: utzoo!attcan!uunet!husc6!bloom-beacon!bu-cs!dartvax!eleazar.dartmouth.edu!earleh
From: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Newsgroups: comp.sys.mac
Subject: Re: Why do Macs have ROMs?
Keywords: Macs, ROMs
Message-ID: <9095@dartvax.Dartmouth.EDU>
Date: 1 Jul 88 18:29:37 GMT
References: <453@etive.ed.ac.uk>
Sender: news@dartvax.Dartmouth.EDU
Reply-To: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Organization: Dartmouth College, Hanover, NH
Lines: 52

In article <453@etive.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes:
>I hope this isn't a silly question - it isn't supposed to be. But, I admit to
>being a newcomer to the Mac world, so perhaps this is obvious. So: Why do
>Macs have ROMs?
...(He then goes on to say that the question is not really "Why ROMs?"
but rather "Why are they so big, Grandma?")

     There are practical and economic reasons for putting code in ROM,
as well as arguments against.  There are also (Heh, heh) legal ones.

     ROM code is tough.  A runaway program has a hard time corrupting
ROM-based code.  RAM code is a sitting duck for an errant pc (I mean
program counter here, and not the other kind of pc).

     ROM code can be smaller, since it doesn't have to be
position-independent.  I don't know how much this feature is used in
the Mac, it might not even be used at all.

     Code is ROMs is typically capable of faster access than code in
RAM.  I know this is true for the Mac Plus; I am not sure about newer
machines.  For a graphics-oriented interface to be convincing, it must
be fast, and perhaps this is why QuickDraw started out in ROM.  This
argument might be less valid now with the availability of faster
memory chips.  Evidence against this argument is the appearance of
QuickerGraf for the Mac II.

     ROM is a real good place to put machine-dependent code.  It is
real annoying, to me at least, to have to find out what machine I am
running on before I can decide which routine to call.  Designers of
ROM code never have to make this test in their code.

     When was the last time you saw a Macintosh clone?  The effort
spent in developing the software for the Macintosh interface must have
been considerable, perhaps more effort than went into the hardware
design.  You can't put all this good stuff on disk, and let any
clone-maker take advantage of it, not if you want to remain the sole
source of Macintosh computers and to maintain a high degree of control
over all aspects of the supporting products market.  Pop the back or
the top off a Macintosh sometime and look at what's inside.  Not very
impressive, is it?  The Macintosh is in some sense a cheap but
attractive box in which to package a bunch of very fancy graphics
routines.

     To summarize, there is probably minimal benefit to the final
customer of having so much Macintosh code in ROM, at least from a
performance standpoint.  The benefits to Apple can, however, be
considerable.  It inhibits cloning.  It allows Apple to specify
exactly which machines they will, and will not, support, and allows
them to do so in a more authoritative fashion than would be possible
were the OS to be RAM-based.

Earle Horton