after getting a recent kernel built, i decided to give my supermac 8/24 card
another try.  here are the results: (btw, all of this is on a mac IIcx)

low = 0x0  high = 0x800000   (hey 8 megs)
log = 0xf9000000 phys = 0xf9000000 len = 0x6000000
  video address = 0x902aaab0
  wierd mapping = 0x0
  length = 0x0
DEBUG: ...
DEBUG: about to set MMU control (hold your breath)

well, i held my breath until i turned blue but nothing happened.  just frozen.
putting my mac II hi res video card, back in the messages appear as:

low = 0x0  high = 0x800000
log = 0xf9000000 phys = 0xf9000000 len = 0x6000000
  video address = 0xf9900020
  wierd mapping = 0x0
  length = 0x0

ok, so i am going to take a wild stab (after reading a bit of the source code)
and say "what is going on?"  i see that the nubus is mapped to the last 6M of 
virtual memory (which is where it "physically" resides apparently i.e. the
linear mapping comment in machdep.c)

i look at the video address of the mac ii card, and say "ah yes, the video
card is in nubus space, and when the mmu takes over i will have a map back
to that address" becuase get_mapping() took care of mapping these ranges.
why is the supermac card not in nubus space?  i am going to take a guess
that a logical to physical mapping for the supermac is never created and
turning on the mmu makes the card "disappear"

reading other parts of the source code, i notice that internal video can be
mapped to nubus space, making it necessary to remap some of nubus space.
i suppose some vendors could make nubus space somewhere else.  would you do
this to get around non-32 bit clean ROMs (dirty ROMs?) if you where going to
be providing things like accelerated quickdraw, etc.

am i nuts?  i almost managed to eat a whole bag of pistachios while thinking
about this.

--chas iii
chas@ohm.nrl.navy.mil