Nubus Slots
Volume Number: 6
Issue Number: 4
Column Tag: XCMD Corner
Exploring NuBus Slots 
By Donald Koscheka, Ernst & Young, MacTutor Contributing Editor
Getting on the NuBus
One of the more salient differences between a personal computer and a mini
computer is the bus architecture that is used to pipe data between the processor and its
peripherals. Minicomputer designers expend great amounts of energy trying to
optimize the system’s bus for throughput and flexibility. Personal computer
designers seem to be willing to trade bandwidth for cost and “plug compatibility”.
The Macintosh II clearly falls into this latter category. The choice of NuBus could only
have been made on economic grounds; technologically it is one of the least inspiring
choices possible as is evidenced by the use of byte lanes to correct the fact that NuBus
is optimized for intel 808x processors.
While I’m underwhelmed with the choice of NuBus, I have to admit that it’s well
documented in yet another outstanding technical reference piece available from Apple,
Designing Cards and Drivers for Macintosh II and Macintosh SE (Addison Wesley).
A friend of mine asked if I could put together an XCMD that would return the
names of all the NuBus cards plugged into the slots on a Macintosh II. I thought this a
reasonable request so I plunged into the Slot Manager documentation in IM Volume V to
figure out how to assemble such an XCMD. Like the rest of Inside Macintosh, the Slot
Manager is a reference piece; it does a good job of documenting the calls to the slot
manager but doesn’t go into a lot of depth on how to use these calls.
I called my friend to tell him that I thought the problem was solvable but that the
documentation just didn’t lead to a quick solution. He suggested that I scan “Phil and
Dave’s Excellent CD” for some examples on how to use the slot manager. Well the only
thing I was able to turn up was a hastily written little application called “getsinfo”.
To my chagrin, I couldn’t find any source code to this example so I took out MacNosy
and began disassembling the code. Supplementing the information gleaned from
MacNosy with some careful TMON walk throughs of the application , I pieced together
enough information to write the XCMD.
Listing 1 presents an xcmd that returns a Hypercard list of each card plugged
into the slots on a Macintosh II. If no card is plugged into a particular slot, it returns a
“Empty Slot”. The information presented here augments what I’ve learned by reading
the available documentation and by disassembling some code. Although the code in
listing 1 works, it may not be complete or bulletproof so make sure that you use it as
a point of embarkation. If you intend to explore NuBus further, I suggest that you get
both Inside Macintosh, Volume V and Designing Cards and Drivers. I will be happy to
publish any corrections or enhancements to this code if anyone feels inclined to take it
out for a spin.
Talking to the Slots
Understanding this code requires a quick refresher course in I/O addressing on
the Macintosh. The traditional Macintosh II memory map is depicted in Figure 1.
Note that the NuBus cards are addressed just as if they were memory chips located
between $90 000 and $EF FFFF. Each slot has up to one megabyte of address space
assigned to it. Slot memory starts at location $90 0000 (above the ROM) so the six
slots are number from $9-$E rather than from from 1 to 6 as might be expected.
When making calls to the slot manager that require a slot number, you’ll want to make
sure that the number falls between $9 and $E. Although the Mac II is assigned to slot
0, accessing its memory space will generate a bus error (its memory is assigned from
$F0 0000 to the top of memory).
These rules change for 32 bit addressing but the 24-bit mode suffices for
illustration.
FIGURE 1. Mac II Memory Model (24 bit addresses )
This memory map goes a long way towards explaining why slots are number
starting at 9 rather than at 0 or 1. This doesn’t imply that the slots below 9 are
reserved by Apple but rather that slots are numbered to correspond with where they
reside in memory.
Communication with the slot manager takes place via a record called the SpBlock
(think of it as a parameter block for slots). This “slot block” contains fields that are
filled in as needed for a given call (See IM V-439 for more details on the slot block).
Typically, you need to supply the slot number in the spSlot field and a slot list
identification number in spID. Results are returned in the appropriate field or in the
spResult field as needed.
Each NuBus card has associated with it a block of firmware called the declaration
ROM. This area of card memory is used to store information that is needed by the card.
The declaration ROM is organized into slot resources which act like resources in the
Macintosh resource manager (they are related but are not interchangeable). Each
sResource has a type and a name. For our purposes, we don’t need to concern ourselves
with the exact structure of each sResources. We do need to figure out how to find the
card name within the card’s declaration ROM.
Before querying a card in slot x for its name, it’s a good idea to check to see that
slot x has a card installed in the first place. In listing 1, this is accomplished using
the call to SReadInfo. We pass this call the slot number and the address of an
sInfoRecord. Poll the siInitStatusA field of this record to determine whether the card
is initialized. If the card is installed and initialized, this field will be set to 0
otherwise it will contain an error message describing why the card couldn’t be
initialized. If the slot is empty , siInitStatusA will be set to -300, (smEmptySlot). In
our slot loop, we ignore slots that are not installed and set the appropriate entry in the
slot name list to “empty slot”.
If the slot is initialized, then we get the spID of the first sResource on the card
with the call to sNextTypesRsrc. Now I determined this by disassembling the getsinfo
application but it seems to me that sNextRsrc might have been just as useful. Since
cards can have multiple functions, they can also have multiple resources. To get the
name of each “sub device” you will probably need to walk through the sResource list,
thus the call to sNextTypesRsrc.
All I’m really interested in is the spID returned by sNextTypesRsrc. Once gotten,
I pass this id to sReadDrvrName to get the name of the driver that handles this card (it
seems reasonable to associate the name of the card with the name of the driver that
codes for it). This is accomplished with a call to sReadDrvrName although getsinfo
appears to take another tack preferring to use SGetCString to extract the card name via
a slightly more convoluted scheme. The problem with sGetDrvrName is that it returns
the card name as a pascal string preceded by a “.” so that this name can be passed
directly to openDriver. No big deal, I simply convert the string back to a “C” string
and ignore the first character as it was added to the string anyway.
SlotInfo.c loops for as many slots as it can get information about in the call to
SReadInfo. I chose this approach rather than using a for loop (0x09..0x0E) because
not all Mac II’s have six slots. Thus slotinfo returns an entry for each slot in the
physical machine regardless of whether the slot holds a card or not.
The results of this investigation were interesting. For example, the Apple video
card is named the “Toby Frame Buffer” no doubt in honor of its inventor, Toby Frame
Buffer. This name may not be too meaningful to the average user so my Hypercard
handler for this XCMD converts it to “Apple Video Card”.
Conclusion
At any rate, this is a starting point for anyone that needs to explore programming
for NuBus. I hope that the information is mostly correct, but if I’ve made any errors,
please be kind enough to pass on the corrections to this magazine so that we can all
expand our knowledge of this area.
Ther’s lots of things that you can do once armed with this information such as
poll choice locations on the cards, return card status information and, of course,
provide a software mechanism for telling the user what’s got under the hood so people
don’t have to go around popping their tops every time they want to find out how their
Macs are configured.
/****************************************/
/* File: SlotInfo.c */
/* */
/* Returns a hypercard compatible list */
/* of the names of the cards in each of */
/* the nuBus slots. */
/****************************************/
#define UsingHypercard
#include
#include
#include
#include
#include
#include “HyperXCmd.h”
#include
/* obtained from back issues of MacTutor */
#include
#define SLOT1 0x09
pascal void main( paramPtr )
XCmdBlockPtr paramPtr;
{
short slotnum = SLOT1;
OSErr err;
Handle SlotList = NewHandle( 0L );
short sResIndex;
SpBlock slotblok;
SInfoRecord slotinfo;
char slotName[256];
/*** Loop until no more slots found ***/
while( 1 ){
slotblok.spSlot = slotnum;
slotblok.spResult = (long)&slotinfo;
if( (err = SReadInfo( &slotblok ) ) == noErr ){
if( slotinfo.siInitStatusA == 0 ){
/*** have a card in this slot ***/
sResIndex = 0;
slotblok.spSlot = slotnum;
slotblok.spID = sResIndex;
slotblok.spTBMask = 3;
slotblok.spCategory = 1;
slotblok.spCType = 0;
slotblok.spDrvrHW = 0;
slotblok.spDrvrSW = 0;
slotblok.spHwDev = 0;
slotblok.spExtDev = 0;
err = SNextTypesRsrc( &slotblok );
slotblok.spResult = (long)&slotName;
DebugStr(“\p read name”);
err = SReadDrvrName( &slotblok );
if( !err ){
PtoCstr( (char *)&slotName );
CopyStrToHandle( (char *)&(slotName[1]), SlotList );
}
AppendCharToHandle( SlotList, ‘\r’ );
}
else
pStrToField( “\pEmpty Slot”, ‘\r’, SlotList );
slotnum++;
}
else
break;
}
AppendCharToHandle( SlotList, ‘\0’ );
paramPtr->returnValue = SlotList;
}
Listing 1. SlotInfo.c XCMD