> I understand how floppy disk emulation works. but what happens when you
> exceed the 2.88MB boundary that floppy disk emulation mode supports?

Oh I misses that bit :-(
The bochs (PC emulater) bios code might support this, so might help.
However I'm not sure whether your 'old' PC will...

> That is the point of this thread. Hard disk emulation mode does 
> not say if it uses any sort of translation or not.

I suspect is does 2k to 512 byte sector translations and little else.

> Do we just have our 
> users boot the install CD and then insert disk 2 into the floppy disk 
> drive that their machine may not have in the future? 

For i386, the 'problem' is that you need to use bios calls to read
more of the CD than just the kernel.  This isn't insurmountable -
provided the system bios has the required features.  It does get a
lot harder (to do bios calls) once the kernel itself has been loaded.

I am looking at the i386 boot code with the intention of being able to
boot from non ffs file systems.

> 	Furthermore, at some point we're going to have to/want to move 
> the ram disks out of the kernel itself and move to stage 2. (e.g. Linux 
> booting: vmlinuz + initrd.img) Currently NetBSD has no forseable way to 
> do this because our kernel doesn't support it. MacPPC is already largely 
> without USB support in the install kernel because otherwise the kernel 
> with ramdisk is too large for old versions of OpenFirmware to grok.

I'm not a macppc expert, but surely a two stage boot would help?
Also I wouldn't have thought there were as many hoops to get through
in order to make OpenFirmare call on macppc as to make 16bit bios
calls on i386.

> 	This would also potentially help solve the inability to boot from 
> RAID devices and/or RAIDframe/ccd on most platforms.

I think that is largely a different issue...

> 	Drive 80 according to the pheonix docs; it replaces the primary 
> hard drive in the BIOS table and bumps everything else up one (in hard 
> disk emulation mode)

In that case, should you manage to build such a beast, and have a BIOS
that supports it, the boot process would be transparent - at least
as far as getting the kernel executing.


	David

-- 
David Laight: david@l8s.co.uk