Subject: Re: Mac m68k booting process?
To: Michael R. Zucca <mrz5149@acm.org>
From: Tony Mantler <nicoya@apia.dhs.org>
List: port-mac68k
Date: 09/05/2000 22:51:44
At 10:36 PM -0500 9/5/2000, Michael R. Zucca wrote:
[...]
>Not turning off video interrupts is OK, though. Only PrimaryInit has been
>run and cards are *supposed* to initialize and then come into a quiessant
>(sp?) state at that point. If cards didn't at least shut up long enough for
>MacOS to boot, they would never have worked at all. The card isn't supposed
>to "start up" until SecondaryInit, which is basically when the System has
>loaded and is running.
[...]

The way I understood it is that the PrimaryInit was originally the only
init call on the cards, but then 32 bit colour quickdraw came along, and
since that code wasn't in the ROMs, video cards couldn't call the functions
to register and initialize themselves with it, and therefore the
SecondaryInit (which is called by routines in the system file itself,
rather than from ROM) was added for this very reason.

This left me with the idea that the semantics of the PrimaryInit and
SecondaryInit were that you did everything you could to get your card up
and functional in PrimaryInit (Think of a netboot ethernet card - not
exactly inert after PrimaryInit), and then if there were some things that
absolutley couldn't be done before the system loaded, you deferred those to
the SecondaryInit (Like 32-bit colour quickdraw calls).

I could be mistaken though, I haven't read the docs in a while.


The MacOS can (in theory) work happily this way, since the PrimaryInit can
install a slot interrupt handler when/if it turns on it's interrupts, which
is really all you need to keep the slots from clogging.


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/