Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!spool.mu.edu!sdd.hp.com!usc!cs.utexas.edu!hellgate.utah.edu!fcom.cc.utah.edu!park.uvcc.edu!ns.novell.com!gateway.novell.com!thisbe.Eng.Sandy.Novell.COM!terry From: terry@thisbe.Eng.Sandy.Novell.COM (Terry Lambert) Subject: Re: 386bsd: Doesn't use BIOS? Message-ID: <1992Sep4.000109.19556@gateway.novell.com> Sender: news@gateway.novell.com (NetNews) Nntp-Posting-Host: thisbe.eng.sandy.novell.com Organization: Novell NPD -- Sandy, UT References: <1992Sep3.194427.14251@engage.pko.dec.com> Date: Fri, 4 Sep 1992 00:01:09 GMT Lines: 77 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.