> > 1) Replace the code in the boot blocks with code which will fire up
> > NetBSD. Note: At this point in startup, we don't have a MacOS yet.
> > We just have rudiments which can deal w/ hardware. We don't even have
> > the ability to read files yet. This method would be the fastest, as
> > we don't load ANY MacOS, but we have a 24-bit memory scheme at this
> > point, so we'd need to screw heavily w/ the PMMU tables.
> 
> Assuming the system even supports 24 bit addressing.  Yeah.  Disassemble 
> MODE32 and stick the relevant sections in, set to execute only on older 
> systems.

Uhm, the system supports 24-bit addressing; they all do. Since MODE32
is copywritten, "Using it as an engineering example" might be a
better thing to do. :-) All we'd really need to do is muck around with
getting the memory map into a nice 32-bit mode. :-(

> > 2) Let MacOS come up. Note: we'd probably want to run w/ a minimal
> > system, possibly one just for the machine in question. We then either
> > relabel the booter to be the startup program (as described in the
> > bootblocks), or we just stick the booter in a Startup items folder
> > and set its preferences to boot after launch. The advantage of this
> > technique is that we don't really have to do anything new. We just make
> > minimal OS disks, stick on a booter, and away we go. 
> 
> Easier than that.  Install a minimum system, move the system file out of 
> the system folder to the root directory.  Move the enabler if one exists 
> to the root directory also (either that or delete the DSAT resources to 
> eliminate checking of system type and cross your fingers that it will 
> boot -- this worked last night, anyway).  Then delete the system folder 
> and the rest of its contents, *including* the finder.  Finally, copy the 
> program that you want to autoboot to the root directory of the disk.  
> When you start up with the disk, your program will boot without the 
> finder as the only executable program.  I don't know of a way to add 
> extensions this way, though.  Good reason to include MODE32 in the 
> booter.  (It would run at the time extensions normally do, anyway, 
> approximately.)

DSAT resources are _messages_ about system type incompatabilities. They
aren't the code itself. Eliminating them only makes us die a hideous
death if the system is incompatable.

Mr. Norton's Disk Editor can shed some light on this. Make a new minimal
system, and check out the boot block and the 1st sector of the partiton
map. In the partition map, two values give the directories of the
boot program and of the system. I bet if you do the above deletion, the
finder will just change the directory values for that disk.

If the root level gets made the system folder (in the partition table),
then we just put extentions/control panels there or in subfolders.

Why the extreme distaste for a system folder and for the Finder? I can
see loosing the Finder if we don't have enough space on the disk
for it and the Booter. But a minimal 7.1 floppy for just one machine
leaves us w/ about 200k of space; enough for the Booter.

If we're making a boot partition on a Hard Disk, I think we'd want to
keep the finder around, along w/ the Startup Disk CP, and maybe the
Monitors CP. Thus if the user needs to fire up a full MacOS from
another drive, he/she can.

Take care,

Bill