on 10/26/00 6:10 PM, Henry B. Hotz at hotz@jpl.nasa.gov wrote something
like:

>> Personally, I'm leaning towards distributing a hybrid CD with the boot
>> floppy image and the MacOS tool to write that to disk.  That way, they've
>> got a boot floppy and a CD with the dist sets, and OF 3 people can just
>> boot it.
> 
> Reasonable if it still covers the beige G3 folks with OF 2.0.  They
> don't have floppy, or floppy booting is broken?

    Beige G3's with OF 2.0f1 are in the clear. However Rev.2 Beige G3's (OFW
2.4 machines with the stock ROM SIMM) cannot boot from floppy; floppy
booting is SLOW, but it's still the easiest way to boot old world PowerMacs.
    I've been up to my ears with other things so I haven't had time to get
all the specifics laid out for Rev 1 G3's. I can't do much here until I get
IDE/ATA booting figured out properly and/or someone posts ofwboot.xcf
compiled at the right address 600000 instead of 6c0000 (requested here three
or four times now with no response).


Highlights/lowlights for Beige G3 Rev.1:    [not guaranteed to be accurate,
                                            but the best I have ATM]

    - TFTP/bootp booting works from an i386 server provided one sets a
static ARP entry for the boot machine and has bootptab setup properly (can
provide a bootptab) Caveat: ofwboot.xcf freezes the whole machine as soon as
it loads because it's compiled at the wrong address from what I'm told. The
only other possibility is that I'm using the wrong syntax. Shouldn't booting
ofwboot.xcf with no command line options bring up a prompt on where to load
the kernel? It never gets that far. I just do boot enet at OFW, what other
options should I have? Haven't tried TFTP booting a full {E/X}COFF Kernel,
do we even have the facilities to convert ELF => {E/X}COFF like pmax does?
Post me one somewhere and I'll try it...

    - Heathrow ATA chip suck: I've spent many hours trying to boot from a
master and/or master/slave and/or slave drive. It only worked twice and the
same exact command did not work the next time I tried it with no real OFW
environment changes. With Rev.B ROM SIMM, attempting to boot from an ATA
channel and then going to MacOS results in an unusable/missing/highly
unstable ATA channel. Even if you skip OFW, every time I try and initialize
an HD in Drive Setup/Anubus/FWB HDT PE it freezes the computer HARD. Booting
from a slave device still does not seem possible in NetBSD, and the latest
System Disk readme seems to indicate that it is just flat out not possible.
The System Disk patches are up in the air, they are needed for Rev A ROM's
in Rev.1 machines, but as for Rev B/C and Rev.2 machines, it seems to be
either redundant code or it actually breaks things. I need much more time
before I can nail down specifics, more time that there is left in the 1.5
Release cycle anyhow. This ATA chip sux, I honestly don't think it can even
do DMA data transfers. The most I've seen NetBSD use is PIO mode 4, then
again maybe DMA is what's causing issues in OFW to start with. *sigh*

    - SCSI: Slow Narrow sux, there's no reason Apple should be using Fast
narrow devices all these years (before 93' even) and still be using the same
slow narrow controllers. Booting from SCSI works in Rev.B ROM with and
without system disk patches (even from non-Apple OEM HD's [imagine that]). I
can't verify Rev A ROM until later.

    - Video: Rev B+ ROM automagically figures out the video address, used my
add in XClaim VR 64 RagePro add in card while still set to the default
"Screen" output device. The devalias seems to automatically update. I would
think that when given the choice of multiple video adapters OFW will choose
to use the lowest slot numbered device with a montior attached (no way to
test that). i.e. it would take $A1(XClaimVR) over $F1(Internal RageII) as it
is in my system. Just food for thought. We need *color* raster console
drivers.