At 4:59 AM -0500 11/14/99, Miles Nordin wrote:

>Remember, if you switch to 32-bit mode without using Mode32, ROM routines
>are no longer your friend.

Mode32 isn't magic. We can reproduce its behavior. The fact is, that only
three machines really need Mode32 so even if we can't reproduce Mode32
behavior in the first cut of such a booter, we can still boot most mac68k
boxes without the need for MacOS.

>For what my own small opinion is worth, i don't mind booting via MacOS.
>Given the path it sounds like Apple has taken, the MacOS is really part of
>the firmware.

It seems to me the design idea was to put a "nanokernel" in hardware. That
is, all of the really machine specific calls go into the ROMs. The system
just rests on top of that with a minimal amount of info that is hardware
specific.

>There is code in MacOS that fits this description.  And, if you consider
>as some have mentioned that, on pre-OF Mac's, Apple doesn't ever release
>firmware upgrades but rather patches the ROM with MacOS code, the line
>between firmware and MacOS becomes even blurrier.

The fact is, though, that the ROMS are usually bug free enough to
accomplish what you need to do at boot time. For instance, we already know
the ROM keyboard and mouse routines are pretty much bug free. The NuBus
code must also work to a greater degree because it is called by cards
during Primary Init before MacOS is even loaded. The SCSI and floppy block
routines must work because MacOS is able to load....etc.

>For another example the microcode that runs on the Power Management CPU in
>PowerBooks is linked into MacOS, not the ROM.  When you remove the clock
>battery, the power manager loses its code and must be loaded, primed,
>bootstrapped--all by the MacOS, not the so-called firmware.

Again, we can do this too. It takes more work but it's possible.

Undoubtably, booting from MacOS makes life easier but it also takes away
some freedom to fix and optimize ourselves. A good example are the IOPs in
the IIfx/Q9xx machines. The IOPs are really 6502's which are programmable
from a shared memory segment. Under Linux (and NetBSD?) the code they are
using now is simply the code provided by MacOS but there's nothing to stop
folks from rolling their own, potentially better and more bug free, 6502
code for the IOPs.

>I'd much rather go through the mess of booting MacOS than have odd
>inexplicable problems show up that eventually get traced back to an
>unfixed ROM bug caused by not booting MacOS.  And i'd rather what little
>developer time mac68k warrants be spent on fixing real bugs than
>notBootingMacOS-related problems.

I disagree. By not relying on MacOS we must become more familiar with the
hardware. That means we have more information at our disposal when
diagnosing "more important" problems.

>Even if some feel it's worth writing first- and second-stage loaders, i
>don't see how it's worth the long-term fiasco.  There has to be something
>more attention-worthy, like ELF or sound or slotman or IDE.  We fall into
>talking about these things because there's so much to say without actually
>writing any code.

Of course, we must prioritize what we do but that doesn't mean we shouldn't
brainstorm ideas. That way, folks with the time on their hands might be
able to take the ideas and make them a reality.


____________________________________________________________________
 Michael Zucca - mrz5149@acm.org - http://www.mdc.net/~mrz5149/
 "I will choose a path that's clear. I will choose Freewill. "
  --Rush, Freewill
____________________________________________________________________