Why make this change, Why make this change? 5 – Apple iMac User Manual
Page 56
C H A P T E R 5
Software
56
Why Make This Change?
The Apple iMac computer is different from previous Macintosh computers in
that it has no single, large ROM that contains the toolbox software, the 68K
emulator, hardware initialization, and the nanokernel. A small ROM provides
hardware initialization functions and provides a mechanism to load the Mac OS
Toolbox ROM image into RAM. The new software architecture that is centered
around ROM-in-RAM and its ramifications has the code name NewWorld.
Why Make This Change?
5
Historically, the Macintosh ROM has been structured as one monolithic ROM,
known as the ToolBox ROM, that contains both low level and high level
software. That is, the ROM contains the hardware-specific code needed by the
computer at power-up time as well as higher level Mac OS ToolBox software.
Examples of hardware-specific code are drivers, feature tables, diagnostics, and
hardware initialization code. Examples of higher level software are high-level
ToolBox managers, QuickDraw, SCSI Manager, and so on.
As features have been added to the Mac OS software, some of the higher level
code expanded beyond the practical limits provided by ROMs, so the ROM has
been augmented and modified by system software such as the System file and
the Enabler. In this way the functionality of the ROM has been spread out
among the ROM, the Enabler, and disk-based system software. This
intertwining of low-level and high-level code spread out from ROM to disk has
made it difficult and time consuming to release new computers.
One way to address this problem is to separate the system software into two
logically distinct pieces. One piece holds most of the hardware-specific
components needed to boot the computer, while the other contains boot-time
ToolBox routines and components that are common to many Macs. With this
scheme, much of the hardware-specific code is isolated in the Boot ROM, and
the ToolBox and system software code can be made abstract and generic. This
approach has several benefits.
• When hardware changes are needed, only the hardware-specific code in the
Boot ROM has to be modified, greatly decreasing turnaround time for new
product releases, and reducing testing time and expenses.
• The high-level ToolBox and system software does not need to change often.
When making a new build as a result of changing hardware-dependent code,
there is high confidence that the high-level software has not been changed.