> 
> > IMHO it is more important to get NetBSD/mac68k to boot _native_ without
> > requiring a MacOS license, or 'Booter'.

What do you mean by "native?" I see an advantage to skipping the MacOS
boot time, but isn't MacOS the native operating system (the one the
ROMs are built to support)? Also, why do we need a MacOS licence? The
only computers our port runs on came w/ Apple ROMs and a version of MacOS?

> This would be nice, but the main hurdles that have to be cleared are:
> 	- dealing with 32-bit/24-bit/memory map issues
> 	  I don't know how bad this might be
> 	- dealing with re-locating the boot program so the
> 	  kernel can be loaded at address 0
> 	- dealing with various disk formats/machine configurations
> 	- getting the information that booter now passes to the kernel

>From what I'm learning about the variability of hardware configurations,
we'd be duplicating a lot of work the MacOS does now. Without
documentation. Problems like the apparent power control stuff on
the PowerBooks might be quite nasty.

> > 	How could this work for a hard-disk where the ROMs expect to
> > 	load a device driver from the disk?  The ROMs obviously have
> > 	to be able to read blocks from the disk, so wouldn't the
> > 	bootblock just use this feature to read the second-level boot,
> 
> I need to look over the docs again, but I'm not sure that this is a
> problem.  If it is, we can certainly work with it, providing a minimal
> partition map with a driver partition.  I am willing to cede that much
> to the Mac ROMs...  ;-)
> 
> > 	Would the MRG code still work? (considering no ROM patching
> > 	done by MacOS)
> 
> That's an issue now.  The ROM patches from the MacOS aren't loaded into
> NetBSD.  (One of my arguments against using something like MRG in the
> first place.)
> 
> > 	What would it take to have NetBSD/mac68k support "native"
> > 	disklabels, which would be required for standalone?
> 
> Some sweat.  That's about it.

Maybe we could just steal the Sun port's partitioning stuff? A few months
ago I started a long thread on current-users about being able to read
other ports' disklabels. Everyone hashed out a lot of problems, and
then nothing got done. Maybe this would be a time to start on that road,
seeing as we'll need to be able to read "native" (NetBSD-modifiable)
and MacOS-based disklabels.

> > The real question, I guess, is:  Does anyone other than me want this
> > functionality?  I personally don't use the IIci for any "Mac" type stuff,
> > so having the ability to use MacOS isn't necessary for me.
> 
> I'd like to see it.  It's just not a priority for me.  ;-)

I don't really care about booting w/o MacOS, but I agree it would be nice
to boot to NetBSD quicker than presently. One intermediate solution might
be to work to squeeze everything onto a floopy. Doesn't System 7 still
respect the "first-launch" parameter of the boot block even though the
Finder is a special program for the OS? If we made a boot floppy w/
just the system file and Booter, couldn't we get the system to run Booter
automatically?

Take care,

Bill