Return to BSD News archive
Xref: sserve comp.unix.sysv386:23925 comp.windows.x:45394 comp.os.linux:10443 comp.unix.bsd:5364 comp.os.mach:2175 comp.sys.ibm.pc.misc:21747 comp.sys.ibm.pc.hardware:31566
Newsgroups: comp.unix.sysv386,comp.windows.x,comp.os.linux,comp.unix.bsd,comp.os.mach,comp.sys.ibm.pc.misc,comp.sys.ibm.pc.hardware
Path: sserve!manuel!munnari.oz.au!spool.mu.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Free software and the future of support for Diamond products
Message-ID: <1992Sep20.110805.12124@fcom.cc.utah.edu>
Keywords: Diamond, free-software
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1992Sep12.035549.4743@zeos.com> <1992Sep20.000851.2641@cbnewsj.cb.att.com> <1992Sep20.085358.25938@zeos.com>
Date: Sun, 20 Sep 92 11:08:05 GMT
Lines: 112
In article <1992Sep20.085358.25938@zeos.com> kgermann@zeos.com (Ken Germann) writes:
>I would think that making a VESA compliant kernel/drivers for video would help
>cut down on development time for video drivers and help end users determine
>whether their newly purchased video card will work with X. I know as an
>end user I am always concerned about compatiblity issues. VESA support
>in Unix/X Windows would be a step in the right direction for graphics support
>and it would definitely solve some of the problems that Unix developers have
>with getting specs on the video cards from video card manufacturers. The only
>question that would need to be asked is : Is your card VESA compliant? If the
>answer to the questions is YES, XYZ's product will work with that video card.
>If it isn't compliant with VESA, a special driver would need to be written.
>The trend in the PC arena is most video cards are being designed to be VESA
>compliant. Diamond supports VESA on the 24x card in the VIDEO BIOS on the card.
>The biggest reason I am making this proposal is there is more of a trend in
>the industry to support MS Windows than there is with X and Unix. This
>trend will change over the coming years with the release of new processors
>and operating systems that will take advantage of these new processors.
>Where ever support for VESA Video Standards needs to start, now would be
>a good time to start it. AT&T, SCO , etc. should do some research into
>the feasibility of supporting the VESA Video standards.
This has been reiterated many times in may way, so I won't harp on
it too long -- but I will harp on it:
1) VESA is a BIOS standard.
2) BIOS code frequently does not operate in protected mode. This is
because their primary market is DOS, and they could care less about
UNIX or other protected mode OS's (like Windows NT)... this will
change, but not because of UNIX.
3) UNIX is a protected mode operating system, as is Windows NT;
Microsoft doesn't have a problem with this, since Bill Gates can
personally afford to literally buy a Space shuttle for cash and
fly it every 6 months for the next 10 years. When he asks for
documentation, it is provided, even if some poor geek in Redmond
Washington has to disassemble and document ROMs. More frequently,
card builders wet themselves during the frenzy caused in deciding
if FedEx, Desk-To-Desk, or having the company predisent personally
fly up and hand some peon the documentation would be faster. The
UNIX community as a whole doesn't have this luxury or clout. To
think that 386BSD does by itself is ridiculous. The amount of
hardware that would be sold catering to the UNIX community is
miniscule. That's why small UNIX-niche hardware companies survive.
4) BIOS code for video cards frequently fails when the "Gate A20 defeat"
is used. This is because the defeat prevents the ROMs from showing
up over and over, and programmers not considering environments other
than DOS program as if this is a given.
5) UNIX fails if the "Gate A20 defeat" is not used. This is required
for modern memory management techniques (like virtual addressing and
paging).
6) DOS is neither modern, nor does it do memory management; DOS memory
management code, such as it is, is over 20 years old, given only
trivial updates when it didn't break program that run OK on DOS 1.0.
What it would require to run a VESA standard under UNIX:
1) A virtual 8086 without Gate A20 Defeat to run the driver on behalf
of a 386 virtual 8086 VESA interface driver.
2) A message control mechanism for the virtual 8086 to driver interface.
3) Pretend "interrupt driven" code for the "8086" to actually implement
the BIOS calls for VESA.
Now this would be slow -- so slow, in fact, that standard VGA programming
would probably be faster, despite the *very* DOS-centric advantages of VESA.
Consider the fact that the virtual 8086 will have to communicate with hardware
through a virtual implementation of hardware or a physical reallocation of
386BSD resources (like a video card) to the "8086". Consider also that the
"8086" can't be allowed to monopolize cpu time because of things like serial
and ethernet interupt service routines. And consider the most damning thing
of all: Many cards, such as Hercules and Paradise and a lot of "VESA" cards
disable all interrupts during running of their on-board BIOS code (so you
don't need to handle the vertical retrace interrupt on IRQ 2) to avoid "the
sparklies" if the code is interrupted and thus allows the scan to catch up
to the area of memory being altered. Say "goodbye" to any packets, serial
port, or disk interrupts which come in during this time. DOS, of course,
doesn't do things like predictive read ahead in it's disk "drivers" and polls
for serial input, so this is generally not a problem. The primitive
"client/server" rather than the more sophisticated "peer/server" model of
networking makes it so any "interrupt ignored" lost packets from a network
will either be repeated by the server or re-requested by DOS.
Admittedly, a virtual 8086 mechanism would be interesting for an Intel centric
mechanism for a (hopefully) non-Intel centric OS to emulate a DOS box on
the minority of the eventual list of platforms we expect it to run on; but
this also would require a great deal of additional work with little chance
for any real pay-off.
I, for one, really don't think that is a bigger win than, say, loadable
drivers to allow loading of card-specific drivers into the kernel for
different video cards as they become available. I probably won't work on
it unless I feel a burning need to write a hardware dependant VP/IX clone,
and I'm betting that others feel the same way.
VESA, like QIS-40/QIC-80, is just one more DOS-generated esthetically
pleasing but practically unusable hardware interface "standard".
Terry Lambert
terry_lambert@gateway.novell.com
terry@icarus.weber.edu
---
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
-------------------------------------------------------------------------------