NuBus Slot ID Assignment Encoding . . . maybe?

[Trash80toHP_Mini]

I think I may have this figured out, please let me know if it makes sense. Here what I had to go on. It didn't make much sense until I digested the info about there being 16 possible slots. I always wondered why the Mac's Slot IDs jumped from $0 straight to $9, it jseemd odd. Slot ID encoding didn't seem like a proper progression until sank in that if there were 16 possibilities, those curiously missing Slot IDs in the Mac would make for a perfect 4bit encoding progression from $0 - $F almost having to be IDs 1 - 8 in Hex.

Info from DCaDftMF3e p.54: Card slot identification signals

Identification signals 3 through 0 (/ID3-/ID0) are binary encoded to specify the physical location of each slot. The highest numbered slot ($F) has the four signals wired low. The lowest numbered slot ($0) has all ID signals high.

< snip >

.  .  .  each of the 16 possible NuBus card slots has an address  .  .  .

____________________________________________________________________

So I worked out this table:

View attachment 10797

Does this look right? For clarity I've only show the "held high" state for Slot $0 as spec'd. The blank spaces would be the same up arrows, but I've only designated the signals pulled low as the encoding of $F is spec'd.

Does this make sense? There's a dearth of Slot ID info in DCaDftMF3e because such is for building Slots on MoBos, not designing cards to use them.

I wonder if the Expanse NuBus Expansion Chassis implemented Slots 1-8?

 

[Trash80toHP_Mini]

Just thought I may have it backwards. Would the normal states for signals usually be high and pulled low or where "wired low" is pulled pulled high for encoding?

 

[Trash80toHP_Mini]

View attachment 10864

 

[Trash80toHP_Mini]

 

[Trash80toHP_Mini]

OK, it's time to ask for a little help again. I've fixed the colors and added symbols to indicate which Slot ID pins are tied to ground (need to error check them) on the first go through. You can ignore the components, I'm assuming that's Black Magic due to complexities stemming from a slot"s tie-in to the PDS Slot in those machines.



What I could really use would be information about the NuBus Slots implemented in these Macs. Black IDs are known from the IIcx Docs as $9-$B, but the Hex encoding confusion for $B (assumed encoding) is indicated in Red as are Slot ID assumptions based on PDS presence and standard slot implementation practice.

Slots S9, $A and $C appear to be correct. Problematic coding notations are indicated by Red .TXT.

I haven't got thr Devnotes for any but the IIcx, so direction of a source would be greatly appreciated. Hopefully that will also lead me to the DevNotes for the remainder of my NuBus Macs.

TIA for any help!

 

[Trash80toHP_Mini]

Still need to check out the way Slot ID is encoded on the pet IIfx, but that may just be a formality. I got hung up on actually trying to understand the encoding process, silly me.

Took another look at what I'd come up with so far and had one of those EUREKA moments. IOW, hack NASTY!!! You can see form the diagram above that about the only thing that seems to be at all consistent with my theories about encoding would be for $9 and $A in the IIcx. Lo and behold, those are the only Slot IDs I need for the Two NuBus Slots in a IIsi hack.

Basic electron plumbing seems to be in order here! NASTYhack time! I don't even need to understand the levels of the HIGH and LOW signals, just steal the real deal from a handy source and apply liberally!



For all you SEEED PCB prototypers, take a look at this silly diagram of some really UGLY wire wrap hackage. [] ]'>

 

[Trash80toHP_Mini]

I guess it's not clear, the jumper wires will be routed underneath the NuBus connector replacements to be installed on the DuoDock's Gemini  twin slot adapter. The diagram sort of makes it look like thepass over the connector (impossible) or over the top of the cards.which would be problematic and even uglier than the rest of this brutal hack. The lower slot's wire wrap pins will be nipped off. The full length wire wrap pins of the top slot's connector will pass through untouched, mating with the NuBus Slot on the IIsi Adapter.

The interboard connection is the equivalent of a speaker wire plugging into the bent pins of the modified NuBus wire wrap connector for installation/removal. Actual header pins probably won't be used as a breadboard jumper wire will allow more clearance, but they illustrate the concept more clearly..

Pics are missing from the old thread, time for a new one. [] ]'>

 

[Trash80toHP_Mini]

Heh! I was looking at the encoding of the DuoDock's two slots all wrong/bass ackwards. It turns out the encoding perfectly aligns with what I was expecting from the Slot ID/Hex Table after I sorted everything out! Of course the wiring in the diagram is now upside down  .  .  .   :blink:



I have to order new wire wrap connectors, the ones I ordered from DigiKey turned up in 2x32, not the 3x32 connectors required  .  .  .  oh well! At least I can test tolerances and practice modifying the bad connectors.

Time for that new Hacks thread!  :mellow:

 

[Trash80toHP_Mini]

OK, so I've been talking to myself in here long enough! Here's the last update (maybe) to this thread. New graphic has the Slot ID encoding fixed so that it matches the Hex chart of Slot IDs above. That's what this thread's about after all.



Graphic also shows hijinks involved in the original thread  TWO SLOT IIsi Nubus Card hack . . . (SE/30 hacks)

That was an admittedly a crude first attempt, but the results sent me into this crazy line of research.

There are three possible states when the hacked Gemini Card is inserted into the IIsi NuBus Adapter:

A - Radius Card installed in top slot - Unserviceable Slot Interrupt
B - No NuBus Card installed - boots normally
C - Radius Card installed in bottom slot - boots normally

Changing the Slot ID encoding to $9 for the top slot should get rid of that pesky Unserviceable Slot Interrupt error code. Hopefully, setting up the bottom Slot ID as $A will fall right into line  .  .  .  maybe  .  .  .  :

 

[techfury90]

I did some digging in DCaDftMF 3rd edition. According to page 65, interrupts are handled by each slot having its own /NMRQ line (which is used to assert an interrupt) with the ability for the system to decode which /NMRQ line was triggered. There is an italicized notice saying that shared /NMRQ doesn't work. I'm guessing the Radius card needs it, and Slot Manager is throwing the error because it knows it has no way to distinguish which slot (and thus device) the IRQ originated from.

 

[Trash80toHP_Mini]

Thanks for the help, tf, I've been talking to myself for a bit here! [] ]'>

You're making a good point, I hadn't seen that page yet but it dovetails nicely with the IIsi experiment's results and my understanding of the Slot Manager/DeclRom setup in the Mac's (sub - non-standard) NuBus implementation.

In a quick review before going to work I see two possibilities:

IF - the /Slot ID signal for a physical slot is reported in the $1 - $8 range

OR - any /Slot ID signal floats by being pulled high and low simultaneously

THEN - Slot Manager reports the Unserviceable Slot Interrupt error.

Once I've done the Slot ID conversion for Gemini's Higher (physical/unsupported in ROM) and Lower ($D) to IIsi supported Slot ID $9 and the lower slot to $A or $B (set by jumper config on the little kluge board (documented in another thread) I'll be able to confirm that analysis by testing the Gemini Slot iD hack in the IIcx. If the lower slot fails to be functional, exhibiting the same Unserviceable Slot Interrupt error code ther might be a problem getting the TwinSlot hack up and running in the IIsi without further hackage, but vague memories of documentation of the SE/30 PDS lead me to believe it may be workable in that machine without such complications.

IIRC, the IIsi has that single /NuBus pin documented on its PDS. Feasibility testing of the GeminiHack in the IIcx will tellthe tale.

edit: in the meantime, the notion I had of comparing the "passive" SuperMac PDS RA Adapter Card into the mix will take precedence. When I did the "Wrong Angle" conversion to a vertical riser config, the NuBus Adapter failed to function. Much food for thought here. Keep it up! [] ]'>