OK,

	Someone tell me if I wasting my time!  I've got a Mac IIx,
currently running netbsd 1.0B (very stable) and netbsd -current (flies
like a lead balloon!!!).  Since the MRG kernal and the -current kernel
don't look so different on my machine (they both die at the same point,
although -current is much more verbose about it's death) I decided to
acquire the -current source and take a look.
	So ... I got past the sunos compatibility bugs, got a clean
compile, check to make sure it died at the point I was expecting it to
(it did), and then went digging.  On my IIx -current comes up with the
message on preserving the symbol table, then i get DEBUG: console
initialized.  Then get_mapping() maps physical memory (1 meg at a time),
then I get an error as follows:
	get_mapping(): Too many NuBus ranges.

	While I was digging through the source I found that the NuBus
ranges are mapped from what the MMU thinks exists in the slot card space.
BUT ... once mapped to the system by the slot manager under MacOS can't a
NuBus card occupy superspace as well ???  Any ways, this routine will not
work on my machine, and possibly many others.  I only have six slots (only!)
but -current insists that I have > sixteen !!??!!
	So ...  with this in mind I'm thinking of rewritting the NuBus
probing code to be more slot manager like.  Is someone else working on
this, or should I proceed ?  How many classes of machine are affected ?
Does anyone care ?  Get back to me and let me know.  I already have
some assembly code that will probe the slots for a declaration ROM, but
if no one cares then why bother.  I am willing to entertain discussions
as well on how I ought to do this, so we can get maximum utility out of
the routines (like maybe access to other NuBus devices), but for now I'm
going to concentrate simply on getting the information about which slots
have cards and initializing the first video card!!  This is about all the
old code (conditionally excluded under -cureent source) does.
	I assume this should be enough since we just want to glean as
much info as we can from the MMU before we wipe it clean ??  If you want
to look at the code yourself, the two files to examine are:
	../src/sys/arch/mac68k/mac68k/locore.s
	../src/sys/arch/mac68k/mac68k/machdep.c
	Well, let me know, and in the mean time I'll keep hacking away
until I get it to work.  Can someone tell me if Booter 1.6 exists on
it's own (outside of the bundled archive with the mrg kernal) ??  I
trashed my copy on accident just the other night!  And could other IIx
users (or in fact any other user of -current) tell me if they are
affected by the get_mapping: Too many nubus ranges bug ???  Thanks.

							Erik Vogan
						vogan@binah.cc.brandeis.edu