Suffice it so say:
HUH??? 
Hardware addressing is quite simple, it's just comparison to known values.
Basically, each piece of hardware is assigned a range of addresses from the 2^32 valid addresses (32 bits), listed in the 'memory mao' (i.e., how the memory map to different functions). For NuBus that's the slot area and superslot area.
Each piece of hardware then compare every address outputed by the CPU against its own range, and if there's a match, react to it. For instance, in the IIsiFPGA the relevant hardware definition is:
Code:
# selection logic
my_slot_space = Signal()
self.comb += [ my_slot_space.eq((A_i[24:32] == 0xf9)) ] # fixme: abstract slot $9
If the upper 8 bits of the address are 0xF9, then we're in the PDS pseudo-slot area. The signal 'my_slot_space' is asserted, and the device will react to it appropriately. There's
similar code in the NuBusFPGA comparing the address to a SlotID instead of hardwiring the $9.
The video subsystem in the SE/30 likely does something similar, but for 0xE / $E. It doesn't matter *why* the CPU accesses somewhere in this range of addresses, if it does, then the hardware *will* answer.
The CPU itself has no knowledge of that - it just spits addresses (the 68k was a sort of pioneer for doing everything 'memory mapped', rather than use dedicated I/O operations). The software must be aware of the 'memory map' to deal with it properly. In Macintoshes, the Slot Manager (in the ROM) looks for Declaration Rom in specific addresses of the slot area, and handle what it finds. If you remove the Declaration Rom, it doesn't know there's something there, but the hardware it still present and active and will still answer requests to the address range it 'owns'.
If some other hardware also answers to the same range of addresses... things will go very, very wrong. Do not do that.
