Might the wizards at Radius have cut the controller out of the schematic entirel? That would set the PDS up to control only a single card from MDU directly through the GALs onto the MUX ICs?
Thinking about it more, I'm not sure there's anything to gain in the 'controller' by assuming there's just one slot. In fact, I think the 'controller' is pretty much just a NuBus master/slave device - the master side propagates the requests from the CPU bus, while the slave side takes request from the other masters and translate them into CPU bus request.
Not an expert here (I hadn't looked at the NuBus specifications before the last end-of-year vacations...), but to go from 1 to N slot, you only need:
a) to add a /NMRQ line per extra slot going to the interrupt handler - that goes to the VIA2 and not the NuBus logic so shouldn't affect the 'controller'
b) to add the proper pull-down on the /ID* lines so each extra slot can identify itself - again the 'controller' doesn't care;
c) the arbitration logic is shared lines between masters - again the 'controller' doesn't care how many other masters there is (except for extra contention), if it has to compete, competing with 1 or N other master(s) is handled the same way.
The four FSM of the 'controller' described in the DCDMIIMSE (1-8) don't seem to care, either.
a) one is just the time-out to generate an ACK to /START when no-else does - that's probably the only thing special about the 'controller' compared to other masters on the bus;
b) bus-to-nubus (master) only look at addresses; presumably anything in the NuBus areas is transmitted - one could avoids some time-outs by rejecting addresses for non-existent slots, but it would be extra logic for not much gain (and any such filtering would probably be identifiable from a schematic + PLA logic);
c) nubus-to-processor-bus (slave) "controls accesses from the NuBus, through the processor bus, to RAM, ROM, and I/O." It is only concerned by the destination, the source is just "the bus" - whichever master on the bus doesn't seem to matter (and shouldn't per the specs);
d) NuBus slave state "tracks the state changes on the NuBus" synchronously - AFAICT there's no information on the bus itself about how many devices there is or which one is currently active; the arbitration is between masters as mentioned previously; the slaves only look at the addresses to decide whether to answer or not; this is just the 'normal' bus tracking in all likelihood.
So I don't see anything one might cut off from the 'controller' (which is just those state machines implemented in one chip, I suppose) and still have a proper NuBus implementation.