I realized as I thought about this, I muddled up pseudo-slot with nubus. Pseudo-slots behave like nubus from a software perspective (mapped to the same addresses and interrupts are handled the same way), but nubus shouldn't be involved since there's no nubus transport and no nubus arbitration.
Pseudo-slots have interrupts, as designated by the 3 irq lines on the 030 pds. I'm not entirely sure how nubus maps interrupts, I was just guessing that was handled by the non-master request line, since afaict, there's no designated interrupt pin on the nubus connector. Which makes sense, because...
There are 3 ways to generate interrupts from nubus according to designing cards & drivers:
1) card writes to a designated area of memory that will generate a page fault, and the OS knows that portion of memory that was accessed was generated by a nubus card, and handles the interrupt. Not supported by MacOS.
2) Shared non-master request line between cards, which generates a processor interrupt, and the interrupt handler polls individual cards to figure out which generated the interrupt. Not supported by MacOS (but more on this later) because there's no defined way to poll cards to see if they're the ones interrupted, so Slot Manager can't route the interrupt.
3) Dedicated non-master request line for each slot. This is how nubus is implemented on macs, and all the NMRQ lines get ORed together into one SLOTIRQ interrupt line that actually interrupts the processor. Additionally, they get sent to VIA2. When the processor is interrupted by the SLOTIRQ interrupt, the Slot Manager's interrupt handler gets run, it reads VIA2, determines which slot(s) interrupted, and runs the appropriate interrupt handler(s).
Now, I don't know anything about nubus expansion cards. I don't have one, never used one. But, if I were trying to solve this interrupt problem for an expander, I'd make the expander card keep track of which of the expanded slots generated the interrupt, OR those into my own NMRQ line, and then have my own software (installed via the declrom, preferably) register an interrupt handler as an interrupt router for the expanded slots, which would then query my card for which expanded slot really generated the interrupt, and then route the interrupt as appropriate. This means you do the shared NMRQ approach above, except you're doing the routing on behalf of the Slot Manager.
A hacky alternative might be to manually run wires from a 4th pseudoslot card to both the SLOTIRQ line and the appropriate pin on VIA2, since I'm pretty sure slots C and D pins on VIA2 are unused on the SE/30... That might avoid the need for a full blown expander. Maybe.
Pseudo-slots have interrupts, as designated by the 3 irq lines on the 030 pds. I'm not entirely sure how nubus maps interrupts, I was just guessing that was handled by the non-master request line, since afaict, there's no designated interrupt pin on the nubus connector. Which makes sense, because...
There are 3 ways to generate interrupts from nubus according to designing cards & drivers:
1) card writes to a designated area of memory that will generate a page fault, and the OS knows that portion of memory that was accessed was generated by a nubus card, and handles the interrupt. Not supported by MacOS.
2) Shared non-master request line between cards, which generates a processor interrupt, and the interrupt handler polls individual cards to figure out which generated the interrupt. Not supported by MacOS (but more on this later) because there's no defined way to poll cards to see if they're the ones interrupted, so Slot Manager can't route the interrupt.
3) Dedicated non-master request line for each slot. This is how nubus is implemented on macs, and all the NMRQ lines get ORed together into one SLOTIRQ interrupt line that actually interrupts the processor. Additionally, they get sent to VIA2. When the processor is interrupted by the SLOTIRQ interrupt, the Slot Manager's interrupt handler gets run, it reads VIA2, determines which slot(s) interrupted, and runs the appropriate interrupt handler(s).
Now, I don't know anything about nubus expansion cards. I don't have one, never used one. But, if I were trying to solve this interrupt problem for an expander, I'd make the expander card keep track of which of the expanded slots generated the interrupt, OR those into my own NMRQ line, and then have my own software (installed via the declrom, preferably) register an interrupt handler as an interrupt router for the expanded slots, which would then query my card for which expanded slot really generated the interrupt, and then route the interrupt as appropriate. This means you do the shared NMRQ approach above, except you're doing the routing on behalf of the Slot Manager.
A hacky alternative might be to manually run wires from a 4th pseudoslot card to both the SLOTIRQ line and the appropriate pin on VIA2, since I'm pretty sure slots C and D pins on VIA2 are unused on the SE/30... That might avoid the need for a full blown expander. Maybe.