baron@runx.UUCP (11/28/86)
Should we support 64K ROMs anymore?
===================================
First, a few details...
A few months ago I bought my ROM/Drive upgrade through the Australian
Apple University Consortium for A$570 installed.
A couple of weeks later I bought LightspeedC v1.02.
I have Inside Mac Volume 4 plus Technotes, and am very pleased with the
128K ROMS and their new routines (like ZoomWindow,>32K resources & HFS).
The Apple ROM/Drive upgrade is reasonably priced.
A friend of mine is currently writing a program that would be great using
128K ROMs and less great on 64K ROMs
Now, my questions...
1) How should we treat the new features of the 128K ROMs that have
*NO* 64K ROM counterpart (e.g. QuickDraw(CalcMask,etc), List Manager,
Time Manager) ?
2) Do you think new programs should support 64K ROMs at all?
*Please* reply in this newsgroup - I have to pay for Overseas mail.
"...New York must be the
friendliest place on earth"
Michael J. "Crocodile" Dundee
/* Jason Haines ACSnet: baron@runx
* Sydney, Australia CSNET: baron@runx.oz
* ARPA: baron%runx.oz@seismo.css.gov
* UUCP:
* {enea,hplabs,mcvax,prlb2,seismo,ubc-vision,ukc}!munnari!runx.oz!baron
*/tim@hoptoad.uucp (Tim Maroney) (12/01/86)
Well, at Centram this has never been an issue. There are tens of thousands
of Macintoshes with old ROMs in use, and so it would be insane not to
support them, or to add an effective $300 additional cost (for the upgrade)
in order to use our product. Consider a site with 1000 Macintoshes, which
is not particularly unusual at universities these days. It would cost
$300,000 to upgrade all those Macs. That is not likely to be available.
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
(which is highly optimized and comparable to maintainable hand-written
assembly language in efficiency) and take over its support and distribution.
It was, after all, only 64K of code originally, which is only a few
man-months of effort in a high-level language; Apple has, in my opinion,
over-estimated the difficulty of re-implementing the Mac OS, because they
fail to separate design from implementation (obviously, the design part is
already done) and because they employed only assembly language and the
atrocity called Lisa Pascal (slow compiler, producing slow code that had to
be hand-optimized) in implementation, causing long delays. However,
everyone seems to have accepted Apple's estimates.
--
Tim Maroney, Electronic Village Idiot
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)dlc@lanl.ARPA (Dale Carstensen) (12/01/86)
> 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.
rs4u#@ANDREW.CMU.EDU (Richard Siegel) (12/01/86)
Probably the best way to work is to have your program be sensitive to which version of the ROM is installed, and then act accordingly; this is the best of both worlds. I think it is bad practice right now to assume that everyone has the new ROMs, and to ignore the old ROM users... I disagree that it's a bad idea to place so much functionality in ROM. Consider what would happen if the entire OS and Toolbox had to be loaded at bootup. Besides, the System file would be much much bigger than it is now. Also, having a user interface toolbox and operating system in ROM makes life much easier for the user and programmer, by assuring a consistent user interface and selection of tools to help get the job done. Corrections to ROM routines can be written by Apple or the programmer -- these are in the System file (in the case of ROM patches), or else implemented for the duration of the application's execution, as Lightspeed Pascal does. I don't think that Apple's limiting the upgrades to 2 years apart; I think it's a matter of how much programming time it takes to implement the new version....and testing...and so on. Perhaps a user-installable connector (a cartridge?) is a good idea.... --Rich
dgold@apple.UUCP (David Goldsmith) (12/02/86)
In article <1366@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >It was, after all, only 64K of code originally, which is only a few >man-months of effort in a high-level language; Apple has, in my opinion, >over-estimated the difficulty of re-implementing the Mac OS, because they >fail to separate design from implementation (obviously, the design part is >already done) and because they employed only assembly language and the >atrocity called Lisa Pascal (slow compiler, producing slow code that had to >be hand-optimized) in implementation, causing long delays. However, >everyone seems to have accepted Apple's estimates. You are welcome to try this; however, you will find that 50% of the existing applications break, because they rely on features of the ROM above and beyond those documented in IM, including those which are not "features" but actually implementation details. Many commercial applications: - Rely on undocumented low memory variables which are in fact internal to the ROM's implementation. If it's not in IM, you're not supposed to do anything but look at it when debugging. - Rely on behavior specific to the ROM's implementation rather than its interface. - Depend on values coming back in registers which are not part of a ROM call's interface, or depend on the global state (such as current GrafPort) being set a certain way which isn't part of the interface, and so on. The 128K ROM has many places where it specifically sets a certain register to a certain value before returning so a specific application won't break. - Some applications do things which are incorrect and just happen to work, and changing one tiny thing makes them break. Maintaining and enhancing the ROM is hard because so many applications go beyond IM in what they do. Of course, if you'd rather have a machine which didn't run any of your existing software, implementing the ROMs would be a snap. You're welcome to try. -- David Goldsmith Apple Computer, Inc. MacApp Group AppleLink: GOLDSMITH1 UUCP: {nsc,dual,sun,voder,ucbvax!mtxinu}!apple!dgold CSNET: dgold@apple.CSNET, dgold%apple@CSNET-RELAY
werner@ut-ngp.UUCP (Werner Uhrig) (12/02/86)
In article <342@apple.UUCP>, dgold@apple.UUCP (David Goldsmith) writes: > In article <1366@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > > [ gripes about various things - possibly justified > You are welcome to try this; however, you will find that 50% of the existing > applications break, because they rely on features of the ROM above and > beyond those documented in IM, including those which are not "features" > but actually implementation details. Many commercial applications: > [ mostly interesting and probably valid points ] when I first saw IM I threw it into a corner and decided that it was suicidal to even try to develop software based on "that mess" - anyone who did has my deepest admiration (and sympathies). For many types of applications I suspect that it was nearly impossible to get things done without going beyond what IM told the developer about. I think it is unfair to make it sound as if all developers had to do was to "follow the IM-guidelines", I suspect. am I terribly off the track with such "heresy"?
dlc@lanl.ARPA (Dale Carstensen) (12/02/86)
In <MS.V3.18.rs4u.80020c10.mcmurray.ibm032.4598.15@andrew.cmu.edu> rs4u#@ANDREW.CMU.EDU (Richard Siegel) writes: > I disagree that it's a bad idea to place so much functionality in ROM. > Consider what would happen if the entire OS and Toolbox had to be loaded at > bootup. Besides, the System file would be much much bigger than it is now. > Also, having a user interface toolbox and operating system in ROM makes life > much easier for the user and programmer, by assuring a consistent user > interface and selection of tools to help get the job done. I see I've done it again -- assumed that what is obvious to me is obvious to everyone else. What happens at bootup is exactly what I was considering. The boot file on a boot disk (as distinguished from a Mac system disk) would have the system heap and, for that matter, all memory that defines the start-up state preconfigured. It would have the toolbox, more consistent than the present or any past ROM versions, in a form that results from correcting bugs, not patching bugs (buy MacNosy and read Steve Jasik's comments about Apple's "come from" instructions, if you think ROM patches are clean.) It seems to me that there are only two points to consider about what happens at bootup: how long it takes; and how useful a system environment results. I believe an Appletalk boot could be done in about the same time as a floppy boot is now done with the ROM and System file (around 30 seconds.) A floppy boot would take 5-10 seconds. A SCSI boot would take 1-2 seconds. The environment would be equivalent, even nearly identical if writes to the RAM where the toolbox is copied were disabled after the copy. Maybe there would be alternative systems such as CP/M-68K, OS/9, or FLEX since the Mac would then be more of a generic 68000 machine, but probably not, since such systems could be done with the current ROM Mac and haven't been (maybe they've been done, but they are not widely advertised.) The boot disk would be ejected and set aside, a disk with System resources could be used as is now done. This System file would have no INIT, PTCH, INTL, DRVR (that really is a driver), any resources that are in the 128K ROM, etc., therefore it would be a SMALLER System file. On a single-floppy system, I would like to see such resources as DAs and FONTs accessible from a separate floppy (the Other... DA pretty much does it for DAs, but there is no analog for FONTs), so less disk swapping would be necessary, the user would know when to expect that a disk swap should occur. Also, the System file plus your application wouldn't take your entire disk, so there would be room for data files and the clipboard on the application disk (and a System.) In article <342@apple.UUCP>, dgold@apple.UUCP (David Goldsmith) writes: > Maintaining and enhancing the ROM is hard because so many applications go > beyond IM in what they do. I really think having the toolbox on a boot disk would have changed the implementation of the toolbox enough in 1984 that the applications would have "straightened up and flown right." I also think Apple brought some of the problem on itself by putting all its documentation "eggs" in the IM "basket." The Apple ][ Reference Manual has a listing of the ROM Monitor, the IBM Technical Reference Manuals have listings of the ROM BIOS, so why didn't Apple publish a listing of the Mac ROM, with comments about what was interface and what was implementation? Why don't they do it now? Of course, they need to include listings of the INITs, PTCHs, etc. too. And why don't they publish schematics?
olson@endor.harvard.edu (Eric Olson) (12/03/86)
Just thought I'd point out that the List Manager is a PACKage, and works just dandy under the 64K ROMs. My own opinion is that the RAM HFS should also implement the other missing routines in the 64K ROM. Until that's the case, I won't use any of the routines that exist in the 128K ROM (except, of course, as optimizations to my own code if it happens to be running under 128K ROM). -Eric
olson@endor.harvard.edu (Eric Olson) (12/03/86)
In article <4372@ut-ngp.UUCP> werner@ut-ngp.UUCP (Werner Uhrig) writes: >In article <342@apple.UUCP>, dgold@apple.UUCP (David Goldsmith) writes: >> In article <1366@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >> > [ gripes about various things - possibly justified >> You are welcome to try this; however, you will find that 50% of the existing >> applications break, because they rely on features of the ROM above and >> beyond those documented in IM, including those which are not "features" >> but actually implementation details. Many commercial applications: >> [ mostly interesting and probably valid points ] > >when I first saw IM I threw it into a corner and decided that it was suicidal >to even try to develop software based on "that mess" - anyone who did has >my deepest admiration (and sympathies). For many types of applications I >suspect that it was nearly impossible to get things done without going beyond >what IM told the developer about. I think it is unfair to make it sound as >if all developers had to do was to "follow the IM-guidelines", I suspect. > >am I terribly off the track with such "heresy"? Yes (my opinion, of course). In fact, since you through it into a corner and presumably the Mac User Interface with it, you didn't give it a chance. I've spent the last year writing some of the weirdest code I've ever written for any machine, code that breaks all the rules, and yet it still runs on every configuration of the Macintosh, including any kind of disk, memory size, processor (68000 or 020), and I have a high degree of confidence that it will continue to run on virtually all future architectures. It's worth pointing out, however, that code that I wrote 2 years ago for the Mac doesn't work, the reason being the I WROTE IT WRONG. I used TRAP instructions to get into supervisor mode (I now know that the Mac is always in supervisor mode). I hard-coded the address of the serial chip (which is available in lo-mem global SCCBase) [If you're wondering why I didn't use system software to access the SCC, I was reading at 500KBaud]. I compiled some code with SUMacC (which doesn't run on a Prodigy 4 - don't know why). The point being that there ARE correct ways to do these things. I just didn't know them. And I won't take al the blame, either-- this was when Inside Mac was changing every month (I have a very old chapter that talks about triple clicking!). So it's to be expected that some things won't be right in implementation, but I firmly believe that the OS/Toolbox provides a correct way to do most anything. -Eric
tim@hoptoad.uucp (Tim Maroney) (12/05/86)
In article <342@apple.UUCP> dgold@apple.UUCP (David Goldsmith) writes: >You are welcome to try this; however, you will find that 50% of the existing >applications break, because they rely on features of the ROM above and >beyond those documented in IM, including those which are not "features" >but actually implementation details. Well, the best estimates I've seen were that 50% of the existing applications either broke under HFS, or just barely limped along under it, so that new versions were neccessary. The conversion process overall took less than six months, and would have taken even less time if Apple had made HFS more widely available for compatibility testing before its release. So this is not really an unsustainable burden. Converting to HFS has, if anything, accelerated the speed at which applications are produced; there has been no perceptible drag. A similar phenomenon might be associated with cleaning up the operating system. In addition, if the re-implementation had available source code, there would be a lot of desire by developers to use it instead, accelerating the conversion process. I think you're overestimating the market power of your ill-defined compatibility hacks. Finally, this attitude seems like it must itself be rather a large drag on OS improvement. Why not just say that you will continue to be compatible with correct applications? If you can't re-implement, then you can't find and implement faster and/or smaller algorithms, for instance. > Many commercial applications: >- Rely on undocumented low memory variables which are in fact internal to > the ROM's implementation. If it's not in IM, you're not supposed to do > anything but look at it when debugging. There are low-memory globals defined and even recommended in the Tech Notes that are not mentioned in Inside Macintosh. So this is not quite true. In any case, I don't see this as a problem. If one developer could figure out the low-memory global's use using the list in the Software Supplement, then the re-implementer can figure it out and use it the same way. >- Rely on behavior specific to the ROM's implementation rather than its > interface. This is a serious programming error. If someone does that, then tell them to take a hike. they are risking their future compatibility; you don't make guarantees about future behavior of this sort, so for all they know you could blow them away with the next System file. >- Depend on values coming back in registers which are not part of a ROM > call's interface, or depend on the global state (such as current GrafPort) > being set a certain way which isn't part of the interface, and so on. > The 128K ROM has many places where it specifically sets a certain register > to a certain value before returning so a specific application won't break. See previous answer. This will also wind up presenting you problems when you go to multitasking with the 68020 Mac. Furthermore, the Mac documentation has insisted that you not do this for a long time, and again, the person is risking their future compatibility if they do it. The future compatibility notes released (twice) in the Software Supplement say so. >- Some applications do things which are incorrect and just happen to work, > and changing one tiny thing makes them break. There is no way that you can maintain compatibility with every case of doing this and make any improvements to your OS. Once again, I really think that supporting incorrect applications is not a serious problem, because it doesn't have to be done. Anything which breaks under a re-implemented Mac OS might just as easily break in the next Apple ROM release. >Maintaining and enhancing the ROM is hard because so many applications go >beyond IM in what they do. Of course, if you'd rather have a machine which >didn't run any of your existing software, implementing the ROMs would be a >snap. You're welcome to try. I thought you said 50%? If half of those are a result of semi-documented low-memory globals, then the figure is more like 25%, and all those would be applications which contained glaring errors. Given that 50% of applications broke under HFS, this does not seem like such a huge problem; particularly if developers have access to the new system before its release to users. Still, thanks for your quick and well-informed reply. You brought up some interesting points. There are some things on the Mac that just can't be done within the bounds of the future compatibility guidelines, Inside Mac, the Software Supplement, and the Tech Notes. I'd like to hear more discussion of these things here. To start off, has anyone discovered a way of accessing globals at the interrupt level without using writes into code resources (which may be marked read-only in a hypothetical memory-managed Mac)? There are tricks if you are running inside a completion routine (putting the globals register in an unused field) or a vertical retrace task (stick it in the VRQ element), both involving the semi-documented fact that the address of the parameter block or retrace task will be in a0, but this trick is not available in every case where code runs at the interrupt level. -- Tim Maroney, Electronic Village Idiot {ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp) hoptoad!tim@lll-crg (arpa)
dgold@apple.UUCP (David Goldsmith) (12/05/86)
In article <1411@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >Well, the best estimates I've seen were that 50% of the existing >applications either broke under HFS, or just barely limped along under it, >so that new versions were neccessary.... If you look at the most popular commercial applications, this wasn't true; most worked without modification. It's possible that as an absolute fraction of ALL Mac applications, it might well be true. >...I think you're overestimating the market power of >your ill-defined compatibility hacks. I can't agree. I think the fact that a majority of existing applications continued to run with new releases of the ROM was vitally important to keeping Mac attractive in the marketplace. >Finally, this attitude seems like it must itself be rather a large drag on >OS improvement. Why not just say that you will continue to be compatible >with correct applications? If you can't re-implement, then you can't find >and implement faster and/or smaller algorithms, for instance. It IS a drag, but it's not an insurmountable problem. Solving it involves 1) educating developers as to the right thing to do, 2) as you say, giving developers as much advance warning as possible, and 3) making changes carefully to give people time to react. >There are low-memory globals defined and even recommended in the Tech Notes >that are not mentioned in Inside Macintosh. So this is not quite true. Of course, I never meant to exclude the Tech Notes; I consider them an extension of Inside Macintosh. Sorry. >In any case, I don't see this as a problem. If one developer could figure >out the low-memory global's use using the list in the Software Supplement, >then the re-implementer can figure it out and use it the same way. That may be true, but then you're no longer talking about an easy project. >>- Rely on behavior specific to the ROM's implementation rather than its >> interface. >This is a serious programming error. If someone does that, then tell them >to take a hike. they are risking their future compatibility; you don't make >guarantees about future behavior of this sort, so for all they know you >could blow them away with the next System file. The problem is that people don't do this intentionally; their programs just happen to work -- until we change the ROMs or System file, that is. The Clint Eastwood attitude is unacceptable: if we blow away these applications, some of which are extremely popular, the losers are our customers, whose software doesn't work -- not the developers, who can always come out with a new version. Even in cases where people did incorrect things deliberately, we can't shaft all of our users because of that. >Still, thanks for your quick and well-informed reply. You brought up some >interesting points. There are some things on the Mac that just can't be >done within the bounds of the future compatibility guidelines, Inside Mac, >the Software Supplement, and the Tech Notes. I'd like to hear more >discussion of these things here. To start off, has anyone discovered a way >of accessing globals at the interrupt level without using writes into code >resources (which may be marked read-only in a hypothetical memory-managed >Mac)? There are tricks if you are running inside a completion routine >(putting the globals register in an unused field) or a vertical retrace task >(stick it in the VRQ element), both involving the semi-documented fact that >the address of the parameter block or retrace task will be in a0, but this >trick is not available in every case where code runs at the interrupt level. Thank you for bringing these points up. I disagree emphatically that Inside Mac, the Software Supplement, and the Tech Notes are insufficient. I have very rarely seen something done outside the bounds of what we say is OK which couldn't have been done the "right" way. For example, if you want to access application globals, the low-memory global CurrentA5 (documented in IM) contains the value of the application's A5 register (although naturally you have to worry about concurrency when accessing you own globals from interrupt level). When people do run into these problems, our Developer Tech Support department tries to come up with a "correct" way of doing it, which then winds up in a Tech Note. You should certainly bring these things up for discussion. Apologies to all for the length of this message. -- David Goldsmith Apple Computer, Inc. MacApp Group AppleLink: GOLDSMITH1 UUCP: {nsc,dual,sun,voder,ucbvax!mtxinu}!apple!dgold CSNET: dgold@apple.CSNET, dgold%apple@CSNET-RELAY