Related Info: Slot Manager Resource Manager

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<MacTypes.h>
#include<OSUtil.h>
#include<MemoryMgr.h>
#include<pascal.h>
#include<string.h>
#include “HyperXCmd.h”
#include<HyperUtils.h>
/* obtained from back issues of MacTutor */
#include<SlotMgr.h>

#define SLOT1  0x09

pascal void main( paramPtr )
 XCmdBlockPtr  paramPtr;
{
 short  slotnum  = SLOT1;
 OSErr  err;
 Handle SlotList = NewHandle( 0L );
 short  sResIndex;
 SpBlockslotblok;
 SInfoRecordslotinfo;
 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