The chassis was originally intended to run audio gear, with a DSP card paired with an ATTO SCSI card, which would allow IO to bypass the host's buss and remain entirely on the expansion chassis. The chassis was not intended to allow arbitrary nubus cards to work with the host (at least without driver/software changes), and as such not all cards work.
The chassis comes with a Nubus controller card for the host, and a delicate cable from the chassis to the card. The chassis (obviously) has its own PSU, 3 fans, and 12 slots each with a slot selector. There are 2 different types of Nubus controller cards: an 68k only card, and a smaller PPC & 68k capable card. I happen to have the latter.
I had been warned that having the host powered on while the expansion chassis is connected but not powered on will "fry" the host computer. I could potentially see a situation where the expansion chassis could end up drawing power from the host over the controller card and over-current the host, but I have not tested this. I leave the expansion chassis always on when it is connected to the host, just in case.
Each slot in the expansion chassis has a dial switch next to it which selects the slot id for that particular slot, from 0 through F.
The DigiTest software can recognize the ECI controller card, the expansion chassis, and cards connected to the expansion chassis. It can also recommend slot id settings for the particular host being used.
A little background on nubus cards, and how they work in a mac.
Each nubus slot in a mac has a hard wired slot id associated with it, which the card can read to determine which slot it is located in (Pins A-26 & 27, C=26&27). In the Macintosh use of nubus (although not specifically required by the specification), each slot has 1 IRQ. However, to support multifunction nubus cards, the Slot Manager supports a queue for each slot IRQ, so more than one handler can be registered for the same interrupt, and the slot manager will traverse the queue until a handler indicates it has handled the interrupt.
Each card has 3 different address ranges it can use:
In 24bit addressing mode, each slot shows up as 0xS00000-0xSFFFFF, where S = slotid (typically 0x9-0xE)
In 32bit addressing mode, each slot shows up as 0xFS000000-0xFSFFFFFF, where S = slotid
Then there is a super slot space, which is 0xS0000000-0xSFFFFFFF, where S = slotid
The digidesign software requires 32bit addressing mode, and refuses to load in 24bit addressing mode. This makes sense, given the following.
From my investigation, the controller card only has its 1 slot IRQ, and only shows up in its normal installed slot in the 32bit address space.
However, the slots within the expansion chassis get their normal nubus space (0xFS000000-0xFSFFFFFF) mapped into the controller slot's super space. So Slot 1 within the expansion chassis will show up in the host address space at 0xS1000000-0xS1FFFFFF, where S = slotid of the controller card.
As a result, the Slot Manager is unaware of the cards in the expansion chassis, although they are available for host software that knows where to look.
I am curious as to whether it is possible to craft software to look for the expansion controller card, the look in it's address space, and then add those slots to the Slot Manager's slot list. It'd be an interesting hack.
Nah. You don't need a declrom. The card will show up in the address space as long as things are electrically fine. Once it's in the address space, you can do whatever you want from software. The declrom is only necessary to work with slot manager, and use mac os toolbox routines to interact with the card.
The cards in the expansion chassis are showing up in the super slot address space, and I could use any card there, if I felt like rewriting all of the software for those cards to not use slot manager...
Someday teaching slot manager about probing superslot space would be nice, although it's not exactly straightforward. I don't think it's impossible, just tedious.
The Slot Manager doesn't see cards in the expansion chassis at all. The controller card presents the cards in the chassis in the controller card's superslot space.
Here's an example. The normal location of regular slot space of Slot A in 32bit address space is 0xFA000000 through 0xFAFFFFFF. Slot A's superslot space would be 0xA0000000 through 0xAFFFFFFF. Similarly, Slot 9 would be 0xF9000000 through 0xF9FFFFFF for regular slot space, and 0x90000000 through 0x9FFFFFFF for superslot space.
So if the expansion controller card is in Slot A of the host controller, it presents Slot 9 of the expansion chassis regular slot space in 0xA9000000 through 0xA9FFFFFF, with no superslot space.
The Slot Manager is completely unaware of this because that's inside Slot A's superslot space. That belongs to the card in Slot A.
Remapping doesn't help because you now have "shared" or overlapping slots. The expansion chassis is an entirely separate bus. So, there may be a card in Slot 9 of the host's nubus bus and in Slot 9 of the expansion chassis. With 12 expansion slots + 6 regular slots, there's no way you can do a 1:1 mapping with the address space allocation above.
So, a modification would be to either just give up on superslot space entirely (other than the expansion chassis, I don't know anything that uses it), and just have Slot Manager probe 0xXYFFFFFF for declrom information instead of just 0xFXFFFFFF. This gets kind of complicated because it's not just probing, but Slot Manager also provides pointer arithmetic APIs so things can get pointers to their address space. So it would probably also involve growing the Slot Manager data structures to keep track of the extra bits of information on where the card lives. Plus deal with addressing in a clever way that is compatible with existing software.
Anyway. It might be possible, but isn't top of the todo yet. The expansion chassis is neat, but not exactly common, so any changes would mostly just be for myself. And I don't have any pressing need to run 12 to 17 nubus cards at the moment.
I'm interested to hear what all happens with this project. Somewhere in a box, I have a 5 slot Digi/Avid Nubus expander - just the mainboard, no case, cable or power supply (because shipping) - and an unknown, untested, unmatched Nubus host card. Picked up both of them seperately and cheap in the same week after years of seeing prohibitively expensive sets with prohibitively expensive shipping costs to .au.
I have ... plans.
I note with some chagrin that the Radius Rocket is listed as unsupported, so no DIY Skylab by this method :/
Hey, welcome aboard!
As best I can tell, since electrically this is a separate Nubus bus, a Rocket wouldn't be able to work properly in the expansion chassis at least as an accelerator. I'm not sure about standalone mode, with software support pointing to the right space. The Rocket kinda uses a lot of features, so I'm a bit skeptical it'd work in any mode, even with software support.
Thanks for the welcome. I will probably be mostly a spectator around here for the time being, though I have a small idea or two that are probably worth following up. I'll post on those when I get closer to being in a position to make a move on them (ie, when my workbench is up and running and I have a little cash to invest in them)