Return to BSD News archive
Xref: sserve comp.os.386bsd.misc:2420 comp.os.linux.misc:13908 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!yeshua.marcam.com!news.kei.com!news.byu.edu!cwis.isu.edu!u.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (Terry Lambert) Newsgroups: comp.os.386bsd.misc,comp.os.linux.misc Subject: Re: Impressions: FreeBSD vs Linux Date: 27 Apr 1994 23:47:41 GMT Organization: Weber State University, Ogden, UT Lines: 78 Message-ID: <2pmtit$rs4@u.cc.utah.edu> References: <2p6jqn$9b2@acme.gatech.edu> <2pfjmi$3j9@u.cc.utah.edu> <2ph0ut$2nc@acme.gatech.edu> NNTP-Posting-Host: cs.weber.edu In article <2ph0ut$2nc@acme.gatech.edu> gt8134b@prism.gatech.edu (Robert Sanders) writes: ]terry@cs.weber.edu (Terry Lambert) writes: ] ]>In article <2p6jqn$9b2@acme.gatech.edu> gt8134b@prism.gatech.edu (Robert Sanders) writes: ] ]>]No, what he's saying isn't ridiculous at all. Having a way to run the ]>]vendor-supplied VGA BIOS to initialize the cards with proprietary and ] ]>Actually, a better plan is a protected mode vm86() call so anything ]>anyone wants to write in kernel space could make a BIOS call if it ]>needed one. ] ]Okay, someone explain to me the difference between those two proposals. ]I seem to be having a problem lately with people reading what's not in ]my messages and not seeing what is, and if I can find the cause, I'd ]like to fix it. ] ]Or is this just another case of Terry going the world one better? The first proposal, using a DOS emulator to run the code to init the card using BIOS calls, requires: 1) A DOS emulator that works 2) The ability to stuff input to the initial COMMAND.COM as if typed on the keyboard -- a bit hairy, if you ask me -- to wit: VGASETUP.EXE EXIT Where VGASETUP.EXE is a program to do the setup (and may need argumets to it stuffed as well) and EXIT exits the top level COMMAND.COM, thus exiting the emulator back to BSD to let the command run only once. 3) The VGASETUP.EXE program, whatever it is, probably having to be written on a per card basis, and probably not the manufacturer's setup progam in any case (likely a full screen thing). 4) A copy of DOS. 5) COMMAND.COM and a number of other things generally agreed as hard drive pollution to make the thing work. 6) In keeping with the source code philosophy, either a DOS cross compilation environment under BSD or some type of DOS development environment to build VGASETUP.EXE (note: the second option kills the ability to do a top level make as an automated process). On the other hand, the option I presented, using vm86() calls, requires: 1) The vm86() call facility (this is a prerequisite for a working DOS emulator in the first case). 2) A vgasetup program that runs under BSD to make BIOS calls using the vm86() facility. Far from "one-upping" the previous suggestion, I'm simplifying it greatly; since it includes part of the necessary infrastructure for a DOS emulator, it can't be said to be more work. A general vm86() mechanism is also a step toward being able to make *ALL* DOS hardware for which there are existing BIOS interfaces "just work". In particular, it would also be possible to write a disk driver that used the vm86() facility to make INT-13 calls instead of having a controller specific driver... might be a little slower, but *ALL* DOS usable disks would be BSD usable disks, and it would be possbile to support *ANY* SuperVGA card under X. If you were a total masochist, you could even make a DDX for X that would use Windows video drivers. Of course, that *would* be "one-upping"... 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.