*BSD News Article 29985


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.