nick@lfcs.ed.ac.uk (Nick Rothwell) (06/29/88)
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? I can see some of the philisophy behind the original 128K Macs. You had some pretty sophisticated software rattling around inside a tiny skull with access to 400K of disk, and not much else, so having the graphics and resource management stuff somewhere safe where you could get hold of it at all times seemed like a good idea, I guess. But things have changed a little. Users are flying 1-2Meg Macs with hard disks, so memory space and disk access aren't so much of a problem. In which case, why have a ROM for the OS? Why not just put it somewhere fixed in RAM instead? This question was prompted by a look at the size of the System Files for System 3.0 and 4.3, which came with my Mac+ recently. System 3.0 is 118K, System 4.3 is 327K. I suppose 4.3 has MultiFinder hooks and so on, in which case I can't help thinking that a lot of this code is just bypassing the original ROM code to make stuff re-entrant (Ok, so that's a wild guess, I admit). But if the system's heading for 400K, and the ROM is only 128K, and (I suggest) less and less of the ROM is being used with each system release, why have it at all? Why not 128K (or less) of Kernel file on the startup disk instead? I can see some need for ROM-based code, of course. You want some bombproof code to handle system crashes, and something to start it when you switch on! But the "higher-level" system functions? I'm sure there's some easy answer to this. I'm not flaming the approach, but just curious about how valid it is these days. It would be odd to find a Sun3 (or generic Unix box) with a ROM to do graphics, so why in a MacII? Or am I being naive about the Mac philosophy and mechanics? Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.nd .ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!ni kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk~~ ~~ ~~ ~~ ~~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gillies@p.cs.uiuc.edu (07/02/88)
I would guess that only very proprietary software goes into the ROM.
I think it has something to do with suing people:
(a) If Macs didn't have ROM, a hardware manufacturer could easily
build macintosh hardware-compatible machines and sell them legally.
They could implement it differently to avoid copyright rules
Customers could buy the machines, steal the latest (patched)
version of the toolbox from friends, and run macintosh software.
Apple would have to discover & sue these people individually.
(b) However, since Macs have ROMs, it is a crime to copy this part
of the machine in a Mac "clone". It is much easier for Apple's
lawyers to sue the computer MANUFACTURER for breach of ROM
copyright, than to sue the CUSTOMER for the same crime.
Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801
ARPA: gillies@cs.uiuc.edu UUCP: {uunet,ihnp4,harvard}!uiucdcs!gillies
lsr@Apple.COM (Larry Rosenstein) (07/02/88)
In article <453@etive.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes: > But things have changed a little. Users are flying 1-2Meg Macs with hard >disks, so memory space and disk access aren't so much of a problem. In which As has been discussed recently, I don't think the majority of users have more than 1Mb. I don't know what percentage have hard disks. All the discussion about FullWrite, HyperCard, LSC, ... taking 1Mb or more means that RAM space is still at a premium. On a Mac Plus, there are only about 30K of patches. Putting everything in RAM would require an additional 80-90K of RAM. Plus there would be increased boot time while the stuff was being loaded. > This question was prompted by a look at the size of the System Files for >System 3.0 and 4.3, which came with my Mac+ recently. System 3.0 is 118K, >System 4.3 is 327K. I suppose 4.3 has MultiFinder hooks and so on, in which Looking at the System file size is misleading. The System file contains patches for 3 different machines, plus fonts, color resources, etc. It is difficult to squeeze everything onto 1 800K disk as it is now, it would be almost impossible to release a bootable system if it also had to include the ROM image (especially for a Mac II with 256K of ROM). I don't think much of the ROM code is "wasted" (ie, not used), and the percentage is not constantly increasing. Of the changes made in System 6.0 vs. System 5.0, most were additions to the ROM (eg, Notification Manager, Sound Manager for Mac Plus/SE), rather than replacements for ROM routines. Another historical reason for the ROM is that on all the Macs before the Mac SE and Mac II, the video circuitry was competing with the CPU for the RAM. Therefore, code running out of ROM ran faster than out of RAM. Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 27-AJ Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
olson@endor.harvard.edu (Eric K. Olson) (07/02/88)
In a recent article 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? Macs have ROMs so that you can't build Mac clones (without rewriting the ROM). -Eric Lexington Software Design: Tomorrow's Software Yesterday Eric K. Olson olson@endor.harvard.edu harvard!endor!olson D0760 (Name) (ArpaNet) (UseNet) (AppleLink)
earleh@eleazar.dartmouth.edu (Earle R. Horton) (07/02/88)
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
jimc@iscuva.ISCS.COM (Jim Cathey) (07/02/88)
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? Clone-proofing is the chief reason. The ROM image is copyrighted, and writing a functionally equivalent version of what's in the Mac ROMs is much harder than rewriting from scratch an IBM PC's BIOS. Of course, floppy-only Macs are saved a fair chunk of disk space by whatever's in ROM (whatever's not broken, that is). +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC Systems Corp. ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!iscuva!jimc ! II CCCCCC ! (509) 927-5757 +----------------+ "With excitement like this, who is needing enemas?"
tedj@hpcilzb.HP.COM (Ted Johnson) (07/02/88)
The Mac ROMs are the reason why all Mac programs have such a nice consistent user-interface: all the user-interface subroutines (which are used to create windows, icons, dialog boxes, etc.) are burned into the ROM. Programmers just call them, rather than making up their own. -Ted
jimc@iscuva.ISCS.COM (Jim Cathey) (07/06/88)
In article <13155@apple.Apple.COM> lsr@apple.apple.com.UUCP (Larry Rosenstein) writes: >Another historical reason for the ROM is that on all the Macs before the Mac >SE and Mac II, the video circuitry was competing with the CPU for the RAM. >Therefore, code running out of ROM ran faster than out of RAM. It is my understanding that the CPU and Video still compete for RAM access on an SE, but that they do it less often (because the Video grabs 32 bits at a time rather than 16). A minor nit in any case. +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC Systems Corp. ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!iscuva!jimc ! II CCCCCC ! (509) 927-5757 +----------------+ "Yours for excruciating correctness..."
jimc@iscuva.ISCS.COM (Jim Cathey) (07/06/88)
In article <9095@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: > 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. In fact, PIC is smaller/faster on the 68000 than non-PIC (for common references like JMP, JSR and LEA -- jump tables would be slowed). On the other hand, absolute variables in the first 32K are faster than register-relative variables. +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC Systems Corp. ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!iscuva!jimc ! II CCCCCC ! (509) 927-5757 +----------------+ "Yours for excruciating correctness..."