EISA boards have no control over ISA card resource allocation. They work similar to MCA and PnP boards where they soft configure supported cards. You can configure "placeholder" resources for legacy ISA cards (like PnP BIOS has for reserving IRQs) so the EISA configuration tool doesn't auto allocate those resources to EISA cards when you run an "auto config". In no way can the motherboard "block" ISA card address ranges from appearing.

Another possibility since Star Control II is likely not a protected mode game, is to write a port trapping TSR to block the MPU detection routine. think SoftMPU, minus the MPU part! (port reads return nothing).

Thanks a lot for the complete review of the issue. I was nearly expecting this. Compatibility and reliability requirements would make EISA designers leave the ISA part of the EISA slot 'quite the same'. With no unique controls added to it.

Indeed I was also thinking along these lines that a 'system patch/TSR' might correct this intrusive hardware detection in SC-II.
Something should be done about this, removing the holy MPU-401 is intolerable 😀
From the topic mentioned above:

> 5u3
"Before I had two Roland cards in my 486, I would simply not initialize my Soundblaster PnP card, set the GUS to the desired values, and enjoy the game.
Now I'd have to physically remove two Roland cards as well to get it working. 😒"

As McGee Alice said it, "It's simply awful!"