<davagatw@mars.utm.edu>
From: Rick C. Petty <pett0019@gold.tc.umn.edu>
List: port-mac68k
Date: 12/20/1995 16:10:38
On Sun, 17 Dec 1995, The Great Mr. Kurtz <davagatw@mars.utm.edu> wrote:
> 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, 1024 on large-media devices.
> 512 bytes like Apple II's?
ProDOS on the Apple ][ treats a "block" as 512 bytes, and a sector is
dependant on the device. For instance, the Disk ][ (5.25") has 256-byte
sectors and ProDOS doubles them up (interleaving). Most of the other
devices recognized by ProDOS have 512. ---FYI
> 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.
Yes, and this is currently what the booter does. Now, you don't NEED to
fit the booter into 15 sectors. The number of sectors allocated for the
boot blocks is given in the partition table, I believe. Or at least, you
can stuff it somewhere permanently near the boot block, but it would be
cleaner if you just have the boot block call some CODE in some file
somewhere...
> 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
I like my idea of developing a boot manager or something that could allow
the user to select the OS or even partition, to boot. Just some quick
code. I'd be willing to put some time into this, since I already have it
half-written somewhere in a pile on my desk. The user could even have a
control panel, which sets up the boot manager...
> 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.
Why avoid using Mac tool calls? They're built-in, and they're easy to
use. I don't think we should get rid of those at all...
> 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?
yes.
--Rick C. Petty, aka Snoopy
__________________________________________________________
email: pett0019@gold.tc.umn.edu, pett0019@itlabs.umn.edu
WWW: http://www.itlabs.umn.edu/~pett0019/