From: terry@thisbe.Eng.Sandy.Novell.COM (Terry Lambert)
Subject: Re: 386bsd: Doesn't use BIOS?
Organization: Novell NPD -- Sandy, UT
Date: Fri, 4 Sep 1992 00:01:09 GMT

In article <1992Sep3.194427.14251@engage.pko.dec.com> ewanco@kalvin.enet.dec.com writes:
>
>I saw mentioned in the thread on the Diamond Speedstar 24[X] interface problems
>that said that 386bsd does not use BIOS and hence needs the code for the
>Speedstar.  This struck me as odd; I can understand skipping the BIOS for the
>sake of speed on certain devices, but why can't 386bsd use BIOS for proprietary
>devices like the Speedstar?  Is it an all-or-nothing thing, that is, either we
>forgo using BIOS at all or incur horrible disadvantages?  I'd like to
>understand why exactly 386bsd cannot use the BIOS at all.  I guess I could
>understand Diamond's hesitance to give us direct access to their hardware,
>especially when everyone else probably goes the standard way and uses the BIOS
>to access it.  (Then again, it is news to me that you could take advantage of
>hi-res accelerated boards through the BIOS, but that's another issue.)

Why 386BSD doesn't use BIOS:

o	Most BIOS code doesn't function correctly in protected mode on
	386/486 hardware, since the implementors were interested in the
	DOS market for the most part.  UNIX is a protected mode OS, and
	so is Linux, 386BSD, and MACH.

o	BIOS interfaces have classically taken the easy way out of the
	"sparklie" problem by disabling interrupts during writes to memory.
	What this means to you and me is that we don't get serial, disk,
	ethernet, or keyboard interrupts while executing the video BIOS
	code.  This can be a serious bummer.  Those cards which have the
	capability of issuing a vertical retrace interrupt generally do so
	on IRQ 2.  This tends to bugger most low end ethernet boards, and
	can not be relied on to be supported in any case.  In any case,
	support for external driver code by vertical retrace still doesn't
	mean protected mode BIOS.

o	Standard BIOS code interface does text, and some simple line and
	pixel operations.  Extensions to "get the most" out of the board
	are either non-standard calls (no way to make it portable) or simply
	non-existant (you have to implement them as main CPU code anyway).

Is it an all-or-nothing thing?

	No, but it may as well be.  The problems and peculiarities of
various video BIOS code are almost as numerous as the number of adapter
cards.  Paradise and Hercules cards disable interrupts during INT 10 calls;
Epson Equity laptops can't scroll lest than the full screen without scrolling
garbage into the scrolled on line using BIOS (ie: insert line and delete line
on the top and bottom 2 lines of the screen can fail).

Diamond's hesitance:

	Diamond may be hesitant for several reasons, only one of which is
giving information to the competition (ie: they must be protecting a non-
patentable interface or process as a trade secret).  Other reasons include
making it impossible to duplicate/emulate a Diamond board without violating
ROM copyright, or to give themselves sufficient time on the market prior to
an "improved clone" being released by another vendor.

Everyone else uses BIOS:

	This is *not* true.  As stated by another poster, Diamond is willing
to realese the information under non-disclosure.  This means no source code
to users (ala 386BSD), since source code using an interface is tacitly a
document describing the interface.  People like Interactive, SCO, and Dell
can sign non-disclosure on the information and distribute *binary* drivers
based on the information, no problem.  The problem is that the 386BSD/Linux
community wants to allow anyone to hack on any piece without restriction...
they would also like to avoid generating binaries for every hardware/software
configuration when distributing XFree.

Hope this clarifies the issue.


					Terry Lambert
					terry_lambert@gateway.novell.com
					terry@icarus.weber.edu

---
Disclaimer:  Any opinions in this posting are my own and not those of
my present or previous employers.