🚀 go-pugleaf

In article <id.QJNW._89@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <C0q94w.48p@NeoSoft.com> karl@NeoSoft.com (Karl Lehenbauer) writes:
>> Hey, how about making the second stage boot, say Julian's loader, an
>> executable DOS program?
>
>This is what Plan 9 does. I was at first repelled and disgusted, but on
>reflection it sounds like a really nice idea. It would resolve the Compaq
>boot problem, it would resolve the problem of video boards that require
>magic DOS configuration programs, it would resolve the "how do I boot
>386BSD on a second controller" problem, and so on.

I'm still repelled and disgusted.  B-).

Actually, this wouldn't resolve the Compaq boot problem, which is the result
of a NOP tromping a register in the second stage boot.  It's actually a
wonder that the boot works on as many machines as it does.  A soloution
based on a DOS first stage boot would still blow up during the second stage.

It would only resolve the video board problem in two ocassions:

1)	When there were unused clocks to be reset by BIOS which had a
	"normal" way for the clocks to be set.
2)	When there is only one mode that will be used, and that mode can
	be selected from the BIOS.

The first might be possible (although it's just as hard as doing it from
386BSD directly, and there's just as much possible variance by which PAL
the particular board uses), but is probably not applicable to the Diamond
problem.

The second is applicable to the Diamond problem, but drastically limits
the available resoloutions.

The "boot on a second controller" problem is resolved with Julian's boot
blocks.

What's needed for either of the video soloutions is the ability to make
BIOS calls from 386BSD.  This can be accomplished fairly easily without
resort to DOS by providing a virtual 8086.  This also has the advantage
of allowing us to run DOS or Windows under 386BSD without having to resort
to actually running DOS to make BIOS calls (an 8086 assembly program is
sufficient; therefore one need not buy DOS with their machine for another
$60 just to set video modes).

>Plus, it'd make it easier to hack around with the boot sequence. You could
>build a new boot program without worrying about making your system non-
>bootable. You could give it arguments
>
>	bootbsd boot-options where init-options
>
>	bootbsd as1a:386bsd.old
>	bootbsd -large wd0a
>	bootbsd -debug fd0a

The boot arguments are pretty well supported by Julian's boot blocks; you
can build a new boot block without making the machine unbootable already
(by mounting/writing/unmounting/syncing/booting a fixit.fs/dist.fs disk).

The only additional problem I see this resolving that isn't already solved
is the video modes problem for some unsupported cards (Diamond, in
particular), and this is resolvable by using the posted Diamond clock code
from articles past, or, to great additional advantage, the use of a
virtual machine to make the BIOS calls (since this also buys us DOS under
386BSD with very little additional work).


On the other hand, a DOS utility to cause it to boot to 386BSD when DOS
is the default partition could be handy, since to keep DOS the default
involves fdisking 386BSD active, rebooting, and fdisking (in 386BSD) the
DOS partition active.  Plus you could quickly type it and pretend you
were rebooting if any of your friends caught you using DOS  ;-).


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------