> The usual story... for L*nux, all the world's an i386. The big difference
> between the "Industry Standard Architecture" and the Macintosh is that the
> Intel machines have the bare metal in common whereas the Macintosh unifies
> a heterogenous hardware with a firmware layer.

Both these approaches have their advantages and disadvantages. It's all
about tradeoffs. And in actuality the "firmware" in pre-OpenFirmware
machines is really only of particular use to MacOS engineers. If you
want to write another OS you have to effectively emulate a small
portion of MacOS to gain any benefit from the code in the ROMs.

> Working around the ROMs as a principle is merely a religious issue, and
> frankly, those who are the most excited about this idea usually rant and

Glad you asked ;-)

Well, I'd say it's less of a religious issue and more of practical issue
and to a lesser degree a "fun" issue.

The fact that the ROMs we have to work with were specifically designed for
MacOS is one large problem. The way MacOS handles interrupts, function
calls, traps, and just about everything else is different from how things
are done under UNIX. Using ROM code requires writing and maintaining
very strange code (like MRG). Of course that also means execution
overhead every time you call something, or the ROM code calls something,
in ROMs.

Part of writing an OS is deciding and enforcing policy issues. How can
we enforce our policies when we have to deal with some other OS's policy?

If you code your own device drivers you have your own code that you can
modify, inspect, and debug. The number of bugs in the ROMs is innumerable.
That's why you'll see big hunks of code in the MacOS system files that
are ROM patches. ROM patches we can't benefit from.

There's also the issue of the completeness of implementaiton of the ROMs.
This is an especially bad issue with NuBus vidoe cards. Usually, you get
cards that have "just enough" code to get by until they load a more
complete set of drivers from an extension. The Toby card is a great
example of this. If we coded our own driver for the Toby we could enable
stuff that even the "full" MacOS drivers don't even use such as
hardware panning/zooming, overscan modes, page flipping, etc.

Then there's the "fun" issue. Writing drivers is actually a little fun
(see "Joys of the craft" in the Mythical Man Month) and it's one of the
reasons I consider writing drivers for NetBSD a hobby. It's challenging
to write drivers for hardware with nearly no documentation.

> then go elsewhere without having contributed anything.  I must have seen
> about four or five longish threads on direct booting to BSD that never got
> to any results; the efforts and stamina needed could be used elsewhere with
> much greater effect.

The problem is "all the world's not interested in operating systems" and
thus the set of people with energy isn't equal to the set of people
with ability which isn't equal to the set of people with an interest
in NetBSD and have time and hardware on their hands.

An independant booter is a project I'd love to write, a project I have
the skill to write, a project I have the information to write, but
alas it's a project I don't have the *time* to write.

> "Performance" -- what performance do you expect to gain by "direct"
> hardware access? 

Well, not hitting code located in the ROMs is a good start. The ROMs
are notoriously slow devices compared to normal RAM. There's a program
for AV macs that lets you shadow the ROMs into RAM for better
performance. This is also a reason why Linux ix86 avoids using the
PC BIOS like the plague.

> e.g. for NuBus cards. If you don't have the specs for all the hardware out
> there, how can you expect to do better than the card manufacturer or Apple
> itself?
[snip]
> ratio, the Mac has never been too bad. I am pretty sure the low level stuff
> in the ROMs is highly optimized.

The folks at Apple are only mortals like the rest of us (albeit with slightly
more information). They had particular goals in mind. Speed may not have
been one of them while writing the ROMs. I'd be willing to bet that
the ROM code writers were instructed to write code that was correct
and tolerant while system software writers were instructed to patch and
override the ROM code for speed when necessary. A good example of this
would be A/UX on the IIfx. I'd be willing to bet the ROM code is
slow-mode code that just accesses enough of the IOPs to work right.
(just like the MacOS code for that machine).

Also, keep in mind when the ROMs in a machine like the IIsi were written:
Pre system 7, pre-SCSI Manager 4.3, pre 100 other advances. Trust me, there's
plenty of room to improve performance over the code in the ROMs.

Whew! Well, that's the schpiel about ROMs vs direct code. :-)
Thanks for listening.