At 3:25 PM 12/17/95, "The Great Mr. Kurtz " <davagatw@mars.ut wrote:
>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.
>
>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.
>

MacOS sectors are any size they want.  IE - depends on disk size, since
there is a max of signed long blocks (i think), then there has to be more
than just 512 bytes per sector.  I think we could fit a lot into there.

I don't have the booter source, but if someone pointed me to it, and
pointed me to the printf code used for the kernel in MacBSD to boot,
(assembly is ok), I'll try to work on this.  I think I can handle it.
Biggest thing is getting things such as the time/date, etc into the kernel
from the booter...

I see us doing it as a very TINY macOS partition that when booted to (using
the startup disk control panel), it would boot directly into MacBSD - no
date except this bypass booter on the disk.  But, in order to change boot
values, you'd use a MacOS program similar to the current one, off a normal
MacOS disk.  We could also write a booter editor for MacBSD and let them
edit it in MacBSD using a simple editor - thus completely eliminating the
MacOS.  Of course, once we play around with the boot sectors of the disk,
you won't be able to boot into MacOS with that disk unless you format it
again...


Shawn.

######################################################################
#  In Jersey: The Digital Information Network of the Garden State    #
#      Freelance HTML/Graphics/Programmer                            #
######################################################################
#                                                                    #
# http://nj5.injersey.com/~spearce/  ###  http://www.injersey.com/   #
######################################################################