Article View: comp.sys.mac
Article #13655Re: Should we support 64K ROMs anymore?
From: Dale Carstensen
Date: Mon, 01 Dec 1986 04:33
Date: Mon, 01 Dec 1986 04:33
80 lines
5671 bytes
5671 bytes
> I feel that it was a big mistake to price the new ROMs so high, and not to
> provide a RAM-based version of the new operating system. Apple seems
> consistently resistant to issues of customer goodwill and developer
> convenience; as a result they have little customer loyalty. It is my hope
> that someone will re-implement the Macintosh operating system in MPW C
> . . .
> Tim Maroney, Electronic Village Idiot
> {ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
> hoptoad!tim@lll-crg (arpa)
My opinion is that putting a lot of functionality in ROM is a mistake, period.
The Commodore VIC and C64 have a language in ROM (but it's BASIC.) And
lots of VIC and C64 owners only got a cassette, or maybe just some cartridges,
so maybe a boot disk doesn't make sense in that market. But IBM took a step
backward with ROM BIOS on the PC where most CP/M machines had only a quick
boot routine in ROM, and Apple followed IBM's lead with the Mac. The Mac is
a mess with trying to limit ROM upgrades to at least 2 years apart and
kilobytes of patches in the System. A service technician has to open the box
to install new ROMs, so changing ROMs is an expensive proposition. If there
were some user-accessible ROM connector, passing FCC requirements would be
more difficult (maybe.)
There is a serious bug in using Finder 5.3/ System 3.2 with a 64K ROM. A random
amount of time after boot, the floppy driver stops doing anything but bringing
up the "eject or initialize" dialog. With 5.2/3.1.1 the problem has only
shown up for me if I also have "Hard Disk 20" on the boot disk, too, but that
doesn't mean it would never happen without "Hard Disk 20." I know that my
external 800K floppy is a paper-weight without "Hard Disk 20."
The above-quoted message states that no RAM-based version of the new operating
system is provided. Due to the nature of Apple's distribution (or rather, non-
distribution) of Systems and Finders, no user is notified of that statement.
If you run 5.3/3.2 on a 64K ROM, it is not apparent that you have made a
mistake, and I think Apple intends for users to run in such a way. However,
(unannounced again) you will not have SCSI Manager (you couldn't possibly
have the hardware, so why would you need the software) or the new Open which
knows there are large differences between DRVRs that are drivers and DRVRs
that are Desk Accessories (same reasoning, I guess -- only needed to boot from
a SCSI disk, in Apple's mind.) And I suppose that not having ZoomWindows or
extended trap processing is a matter of making it fit in a 128K Mac (guess
they figured they didn't even have room to check how much memory is
available, even.)
Getting back to the topic of how much functionality to put in ROM, I thought
the bad press Amiga had for having the "kickstart" was badly misplaced. The
machine ought to have a ROM with something like MacsBug and a few flexible
boot options. For example, the Mac might have:
- if you hold down the interrupt button during power-on or reset, go
to diagnostic mode (actually, the Mac does run a memory test!)
- if you hold the reset button for over 2 seconds, go to MacsBug
- a quick reset or power-on without interrupt or reset depressed will
boot from the first boot device with boot sectors, in the order
established by the parameter RAM
And MacsBug would have commands for selecting a boot device and setting the
boot device search order in parameter RAM. The boot devices supported
should include the Sony floppy, SCSI, Appletalk/printer, Appletalk/modem,
and such other devices as agree with Apple to provide boot code. Any disk
drive manufacturer or hardware hacker should be able to program EPROMs that
include the Apple stuff plus boot code for their own device. The boot would
typically consist of reading a full track from the disk and jumping to it (my
CP/M boot reads two tracks of 128-bytes/sector, 26-sectors/track from an 8"
floppy.) It takes about 3 seconds. It is very fast compared to the Mac, you
notice. Actually, the Sun machines are similar to this.
I suppose the biggest reason Apple, IBM, etc. are not doing this is that they
think they can't protect their property rights in their system if it is on a
floppy or hard disk instead of ROM. Their lawyers just know that somehow
what is written in ROM is better protected. I've read some articles lately
that indicate reporters are being told by someone who should know better that
the Intel-vs-NEC proceedings justify just such an opinion.
I wonder how much time is wasted at Apple trying to figure out how to make ROM
patches the minimal size? I guess the time is enough to relegate providing
128K ROM features for 64K ROM users to the "don't do" box.
Almost addressing the original question -- should the 64K ROM be supported --
I think maybe the 128K RAM should not be supported, but perhaps Apple's
system should be modified to support 128K ROM features on >=512K RAM Macs
with a 64K ROM. If Apple won't do it, they shouldn't be allowed to sue
anyone who does do it for copying parts of the Apple system to do it.
Technical Details
Message-ID:
<10023@lanl.ARPA>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!seismo!cmcl2!lanl!dlcReferences:
<385@runx.OZ> <1366@hoptoad.uucp>Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!cmcl2!lanl!dlc From: dlc@lanl.ARPA (Dale Carstensen) Newsgroups: comp.sys.mac Subject: Re: Should we support 64K ROMs anymore? Message-ID: <10023@lanl.ARPA> Date: Sun, 30-Nov-86 23:33:24 EST Article-I.D.: lanl.10023 Posted: Sun Nov 30 23:33:24 1986 Date-Received: Mon, 1-Dec-86 02:49:14 EST References: <385@runx.OZ> <1366@hoptoad.uucp> Organization: Los Alamos National Laboratory Lines: 80