> 
> On Sun, 17 Dec 1995, John D. Smerdon wrote:
> 
> > Sector zero of any disk is the boot block.  I think if the boot block
> > version number is setup correctly, execution will start at offset $8x in
> > sector zero and can do anything that we want.  This is before the "Welcome
> > To Macintosh" is displayed, and before the Finder or the System files are
> > opened.  The boot block is 12 or 16 sectors long.

AFAIK, HFS drives are the same on HD as on floppy. So there's a partition
map in there somewhere (starting at sector 2). Also, for reference,
the boot blocks on my 7.1 startup HD don't even fill the full sector
(512 bytes). The code sets up the disk, and lets it all rip.

> That's a good possibility.  The only thing is, I think it's important to 
> make the disk as MacOS compatible as possible.  I'm not sure if this 
> would cause problems or not.  12-16 sectors -- how large is a Macintosh 
> sector?  512 bytes like Apple II's?  Without doing the math, I seriously 
> doubt that would hold the booter, but it could conceivably hold some 
> simple HFS reading code to bootstrap another program.  Another 
> possibility is, assuming the boot disk is distributed as a disk image, 
> there would be no problem with hard-referencing the starting location of 
> the booter program in the bootstrap loader, without even needing any 
> HFS-reading code on the disk.  This would allow us to use a modified 
> booter that would be the same regardless of whether a user booted into 
> the MacOS first.  Simply make the user interface section call the boot 
> section with one set of parameters if under MacOS, and another with it.  
> If the boot section isn't running under MacOS, it would use kernel-style 
> output throughout the boot.  If it's using MacOS, it would use the 
> present display code.  The only patches necessary would be to eliminate 
> MacOS calls to get the system configuration info and to setup some sort 
> of switch(MacOS) statement to call one printf style code to print to a 
> window under MacOS or the other printf style code (copied into the booter 
> from the kernel) if not under the MacOS.
> 
> The advantages to this include not having to completely rewrite the 
> booter code for non-MacOS use, as well as being able to use the rest of 
> the free disk space for such things as the installer, mkfs, and other 
> MacOS-side utilities.
> 
> Any thoughts on this?

A few. I've got some technical ones (like for HFS-readers, we just
initialize the file system manager), but I'm still wondering what we
get besides a neat thing? For me at least, NetBSD is important enough
to warrant as much MacOS partition space as it needs; I don't need
to keep the installer, etc on a floppy. Also, at work, where I'm
pushing for us to hook a system up as part of our net administation,
the floppy drives in the computers old-enough for NetBSD to run are
marginal. Dust just kills them after 3-5 years (much less after the
8 years we've had some of these beasties).

I'll admit it's neat to dig into things & figure out how the Mac works.
As part of this thread, I've dug into how the startup process works,
and disassembled the boot block on my HD. It's fun. It's cool. But
I think we need some other stuff first, like SONIC Ethernet. Or
IDE. Or the SCSI in the Q700 & later. Or to figure out what's wrong
w/ the serial ports. Allen's to-do list says it all. Fixing these
things will let us get to more computers & get more people using
NetBSD. :-)

Take care,

Bill