At 18:45 Uhr +0100 18.12.1997, Michael R Zucca wrote:
>> 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.

Sure. In the end you take what is more easily accessible: Hardware specs or
API docs.

>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.

Which has apparently been a sensible approach wrt. NuBus config 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

Proving my point. "Practical issue" is usually no matter of principle.

>and to a lesser degree a "fun" issue.

It was for the iwm driver. Looking back, I think building a slim "device
manager" framework around the .Sony driver might actually have been faster.
But hacking the hardware and "boldly tread where no man dared before" was
fun.

Michael, you are working on actual projects and draw your conclusions from
there -- the pragmatic approach.
The MacLinux guys are making "we use no steenkin' ROM code" a PR &
marketing point -- the religious approach.

>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?

That, on the other hand, _is_ a religious point.  =8)

>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.

"The number of bugs in NetBSD is innumerable." -- Your point is?

I can smell "NIH"... I strongly doubt the majority of these patches are bug
fixes. There may be a lot of adapters and wrappers among them.

>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.

How many cards are out there? How many custom chip sets in how many
different applications? And how many people are actually working on the
mac68k kernel - is half a dozen too optimistic?

>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.

Ahhh... (see above ;)

>> "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.

That's what they claim. The cdev for my Quadra's Radius 2nd level cache
card has such an option, but I cannot even see any performance effect of
the cache itself. (One of these days, I'm going to hack a Unix benchmark
for the MacOS and check. 8)
And, while the effect may even be measurable for '040 machines, I strongly
doubt you will see any difference in access speed for '030 Macs. There,
it's something like 100ns access time for RAMs vs. 150ns for ROMs (IIcx
class), and you still have to give the RAMs additional refresh time.

>This is also a reason why Linux ix86 avoids using the
>PC BIOS like the plague.

Careful here. PC Bioses are usually 8Bit "wide" and written for 8088
compatibility Real Mode. That's a horse of an entirely different colour -
nah, it's not even a horse.  ;)

>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 nice guess, but still, a guess.

"The MacOS disk drivers are faster than the MacBSD ones, and they are far
more stable. And, contrary to custom Apple chipsets, we _do_ have the specs
for the 53c80 and 53c96."

>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.

What you listed has added bells and whistles on top of the low level stuff.
".Sony", for instance, hasn't changed much at all from the SE/30 to the
Quadra 700 and (presumably) the Duo 280. The SCSI manager 4.3 does not have
much for the 53c80 equipped machines.

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

You're welcome. Thanks for entering the discussion.  ;)

	hauke


--
"It's never straight up and down"     (DEVO)