This is actually not quite true. The original Mac had some of the library code in ROM - Quickdraw, the file system, and various IO drivers come to mind, but the OS was most definitely supplied on floppy disk, and the disk was absolutely required for the Mac to boot and run. Updates to the OS were applied on mini floppies for quite some time. Also, over time things like the file system (going from MFS to HFS), drivers, and most other items were moved to disk. There was a 2x speed advantage to running from ROM instead of RAM, but that quickly disappeared as the Mac hardware evolved. By the time the Mac II was introduced, everything was on disk except for the boot code.
Yes, I have been programming Macs since the original 128K Mac. I still have two of those around here, and both booted last time I tried. Still have the original loose-leaf version of "Inside Macintosh" also... Now I feel old… Jack B, W6FB p.s., I can't think of anyone who would even consider supporting products that have had the firmware modified by non-company programmers… Your assessment is right-on in that respect! Embedded control systems (especially radios) are kept very tight for a reason. On Jan 10, 2012, at 4:10 PM, kevinr wrote: > When the original Macintosh was introduced it booted from ROM. Hooks > were provided in the ROM code to allow external fixes to the OS. An API > was released so application or OS programmers could modify the existent > code. There are good and bad sides to this. In the case of the K2, K1, > K3 (and most probably the KX1 and KX3) the timing of the RTOS is fairly > strict. If an API programmer added their own code through the hooks > into the RTOS the timing would change for many things. You could write > your own code and add it to the mix but then the RTOS timing would be > upset and you would most probably break many things. The interactions > between the many and varied tasks of the RTOS would change and mostly > for the worse. I realize the RTOS code for the Elecraft gear will never > be released to the public. So the work of adding new tasks to the > timing loops of the rigs' RTOS falls on the in-house code jockey(s). > Remember this when you ask for new features or tweaks to existing code. > Do you want a rig that works quickly and smoothly when you enter > commands via the front panel or the serial bus? Or would you rather > have a kluge of mashups? Don't ask about the divergent meanings of > kluge and kludge. I appreciate the effort the Elecraft team has put > into making fine products which work well. > 73, > Kevin. KD5ONS > ______________________________________________________________ > Elecraft mailing list > Home: http://mailman.qth.net/mailman/listinfo/elecraft > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:Elecraft@mailman.qth.net > > This list hosted by: http://www.qsl.net > Please help support this email list: http://www.qsl.net/donate.html ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html
