January 90 - DEBUGGING DECLARATION ROMS
DEBUGGING DECLARATION ROMS
MARK BAUMWELL
Through system software, the Macintosh can read the declaration ROMs in NuBus and
pseudo-NuBus slots, like those in the Macintosh SE/30. This article tells you what
you must know about NuBus addressing and the structure of correct declaration ROMs
to successfully debug the ROM. It walks you through the structure of an example
declaration ROM and gives common errors and strategies for debugging declaration
ROMs.
The Slot Manager's flexibility in providing a layer between the hardware and
higher-level software benefits developers and customers alike. Users can easily
expand the Macintosh II family and the Macintosh SE/30 with additional hardware that
goes in slots. The Macintosh card architecture lets them plug new cards into the
Macintosh without worrying about using the right slot, setting dip switches, or
running system configuration software. As a developer, you may need to know more
about the architecture that makes this self-configuring environment possible.
THE SLOT MANAGER AND DECLARATION ROMS
Part of the Macintosh operating system, the Slot Manager can find the ROM on each
expansion card installed in a system and identify the card's special capabilities. It
makes use of predefined data structures called slot Resources (sResources) to
initialize and configure a card and report the card's location. Each card installed in a
Macintosh expansion slot needs a declaration ROM, also known as a configuration ROM,
with information for using the card's hardware. The expansion hardware could be as
simple as a memory card that needs to publish its address ranges or as complicated as a
video card with initialization code, a driver, and declaration data.
In addition to letting the system determine what hardware is available, the Slot
Manager frees applications from being dependent on a particular type of hardware. In
other words, the Slot Manager helps insulate an application from the hardware by
being able to locate underlying, intermediate driver software that will know about and
talk to the specific hardware. The application can be free of the details and need only
deal with higher-level functions. The degree of insulation depends on the software and
data structures in the declaration ROM.
The Slot Manager:
• locates and lists the cards with declaration ROMs.
• defines a uniform structure for information in the declaration ROM and a
set of library routines to access the information.
• includes routines to allow host applications to transparently access
information in the ROMs without regard to NuBus or byte lanes.
• allows ROM initialization code to run on the host CPU during the host's
startup sequence.
• allows cards to have drivers from their declaration ROMs loaded into the
host CPU.
• initializes and manipulates the parameter RAM on the host CPU for the
card during startup.
When applications are insulated from particular hardware implementations, they
don't have to be revised for each new version of a vendor's board, or even for
compatible boards made by competitors. Besides reducing maintenance work for the
developer, information hiding of this sort saves wear and tear on customers.
Suppose a customer owns an application and a card and happens to buy another board,
from the same or a different vendor, with even slightly different hardware. The
difference might be a change in address or meaning of some register or memory
location. The customer has to mix and match applications or drivers or INITs to
boards. This is not very Macintosh-like, and the board manufacturer is sure to be
savaged by the customers and the press. Matching various card-specific versions of
software and different revisions of hardware can be a headache for distributors and