Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: 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 > 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.