Crossposted-To: comp.unix.sysv386,comp.windows.x,comp.unix.bsd,
comp.os.mach,comp.graphics,comp.sys.ibm.pc,comp.sys.ibm.pc.hardware
From: dwex@cbnewsj.cb.att.com (david.e.wexelblat)
Subject: Free software and the future of support for Diamond products
Date: Thu, 3 Sep 1992 16:24:13 GMT
[ This is a personal statement and does not represent any position being
taken by my employer. My affiliation is only listed so that those who
wish to reply to this statement may do so. ]
Diamond, makers of the SpeedStar and Stealth series of SVGA cards, have
developed a new hardware technology for video dot-clock selection. The
current boards that have this new technology are the SpeedStar 24, the
SpeedStar 24X, and the Steath boards. Diamond considers this hardware
technology proprietary, and feel that giving out information on how to
program this hardware will yield a competetive advantage to their
competitors.
This position makes it impossible to support these boards on operating
systems that do not use the BIOS (e.g. Unix), unless one is willing
to sign a non-disclosure agreement with Diamond. Obviously, this is
impossible for software for which the source code is freely available.
In particular, these newer Diamond boards will not be supported by the
free X Window System packages (in particular XFree86, previously known
as X386 1.2E) that are available for a number of x86 operating systems
(SVR3, SVR4, 386BSD, Mach386, Linux). There are commercial packages that
do support these boards.
It is the contention of the authors of XFree86, the free enhancement
package for X11R5 on x86, that Diamond is will be losing customers
based on this policy. We are aware that many people will only buy
boards that work with this software, and that there are boards available
from Diamond's competitors that fill this need. We are also certain that
there are other software packages that fall into the same category.
We have been in contact with a representative of Diamond about this policy.
He indicated to me that there are currently no plans to change the
proprietary nature of this information, but they are willing to hear
our arguments for such a change. To that end, we would like to collect
some statistics that we can give to Diamond. We have set up a mail
drop to collect this information. If you have not bought, will not
in the future buy, or have in fact returned Diamond hardware because
of this policy, please send a short note to <diamond@physics.su.oz.au>
Any mail sent to this address will be deposited in a file, and will
only be looked at occasionally, so don't expect a reply. If you
want a reply on this issue, mail to <xfree86@physics.su.oz.au>. Please
indicate the amount to Diamond product impacted by your decision (e.g.
if you are a VAR, an estimate of the number of systems shipped per
month that will not contain Diamond boards will be useful).
We do not know what impact, if any, this data will have on Diamond.
As long as this policy remains in effect, XFree86 will not support new
Diamond products. We choose to make this stand for reasons of liability
avoidance. So if someone publishes the technical information required,
we will not use it, nor will we accept code that uses it, until we
know that Diamond's policy has changed. Be aware that if you disassemble
their BIOS, you are risking a lawsuit. We will not assume that liability,
so don't even ask!
The XFree86 Core Team:
David Dawes <dawes@physics.su.oz.au
Glenn Lai <glenn@cs.utexas.edu>
Jim Tsillas <jtsilla@damon.ccs.northeastern.edu>
David Wexelblat <dwex@mtgzfs3.att.com>
Mail drop for Diamond sales loss data:
diamond@physics.su.oz.au
To contact the Core Team:
xfree86@physics.su.oz.au
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Wexelblat | dwex@mtgzfs3.att.com | Somebody get me a
AT&T Bell Laboratories | ...!att!mtgzfs3!dwex | cheeseburger!
200 Laurel Ave - 4B-421 | |
Middletown, NJ 07748 | (908) 957-5871 | --Steve Miller Band
Crossposted-To: comp.unix.sysv386,comp.windows.x,comp.os.mach,
comp.unix.bsd,comp.sys.ibm.pc,comp.sys.ibm.pc.hardware
From: dwex@cbnewsj.cb.att.com (david.e.wexelblat)
Subject: Re: Free software and the future of support for Diamond products
Date: Sun, 6 Sep 1992 21:01:59 GMT
In article <eaVY02MJ20P.01@JUTS.ccc.amdahl.com>
gab10@griffincd.amdahl.com (Gary A Browning) writes:
> What is XFree86's feeling about negotiating the distribution of a very
> small binary library with their release that contains just the
> Diamond Configuration routines. This would not be any more reverse
> engineerable than the ROM supplied with the video cards, it allows the
> server to still be distributed in source form, and it keeps a lot of
> Diamond's current and future customers happy.
>
> For those users that do not have one of these cards, they get complete
> source code. For those that do have the cards, they get complete source
> code except for the Video Card Clock Configuration routine.
>
> It the longer term, my guess is that the Diamond policy will change when
> its competators release their cards. At this point the source could be
> included.
> --
> Gary Browning | Exhilaration is that feeling you get just after a
> | great idea hits you, and just before you realize
> | what is wrong with it.
I should have covered this topic in the initial posting.
We discussed this possibility and decided that we have no desire to
enter the legal tangle involved in signing the non-disclosures that would
be involved. I, for one, could not sign such an agreement, given my
current employment status. And the others are not willing to take
on the responsibility. So this will not happen.
We are sorry if there are people who can't use our software, but we are
not in business. We are a bunch of hackers putting something together
in our spare time, using our own financial resources to do it. We can't
be all things to all people.
So until Diamond changes their policies, we will not go to any effort
to support them. We are already expending more effort to try to get
data to use to get them to change their policy than some of us think
should be expended.
That's the way it is, and that's the way it will remain.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Wexelblat | dwex@mtgzfs3.att.com | Somebody get me a
AT&T Bell Laboratories | ...!att!mtgzfs3!dwex | cheeseburger!
200 Laurel Ave - 4B-421 | |
Middletown, NJ 07748 | (908) 957-5871 | --Steve Miller Band
From: jrowland@cs.utexas.edu (John Richards Rowland)
Crossposted-To: comp.unix.sysv386,comp.windows.x,comp.os.mach,comp.unix.bsd
Subject: Re: Free software and the future of support for Diamond products
Date: 7 Sep 1992 00:38:24 -0500
I dont see the problem here. I use bios calls to set the clocks.
By observation, I can determine what clock settings each bios call
sets the PLL to. Just before Xfree86 starts, I take it apon myself
to make that bios call, and the bios sets the clock values to what I need.
For example:
When I boot my linux system I always remember to choose the text mode
100x40 in the selection list because I know that setting that text mode also
sets the clocks to what I want for my chosen resolution. This type of
trickery is uncomfortable, but it does allow me to use X on my Diamond
Speedstar24 using bios 5.X.
--
=======================================================================
primary: jrowland@cs.utexas.edu (UT CS Department)
secondary: jrowland@csdfx8a.arlut.utexas.edu (Applied Research Laboratory)
=======================================================================
Crossposted-To: comp.unix.sysv386,comp.windows.x,comp.os.mach,comp.unix.bsd
From: dwex@cbnewsj.cb.att.com (david.e.wexelblat)
Subject: Re: Free software and the future of support for Diamond products
Date: Mon, 7 Sep 1992 13:33:47 GMT
In article <lalqmgINNa96@needmore.cs.utexas.edu>
jrowland@cs.utexas.edu (John Richards Rowland) writes:
>
> I dont see the problem here. I use bios calls to set the clocks.
> By observation, I can determine what clock settings each bios call
> sets the PLL to. Just before Xfree86 starts, I take it apon myself
> to make that bios call, and the bios sets the clock values to what I need.
>
> For example:
> When I boot my linux system I always remember to choose the text mode
> 100x40 in the selection list because I know that setting that text mode also
> sets the clocks to what I want for my chosen resolution. This type of
> trickery is uncomfortable, but it does allow me to use X on my Diamond
> Speedstar24 using bios 5.X.
> --
> -----------------------------------------------------------------------
> primary: jrowland@cs.utexas.edu (UT CS Department)
> secondary: jrowland@csdfx8a.arlut.utexas.edu (Applied Research Laboratory)
> -----------------------------------------------------------------------
1) Calling BIOS from a multitasking OS is trick, dangerous, and impossible
for those of us running SVR3/4
2) One of the nice features of XFree86 (and X386) is the ability to switch
resolutions via hot-key. Kiss that goodby without the clock-select
logic
3) Some of us are such Unix snobs that DOS will never touch our machine.
Having to boot DOS, then boot Unix, is an unnacceptable crock. If you
want to do it, fine. But don't suggest that as a rational alternative.
4) No other manufacturer is trying to make us jump through hoops, so we just
plain won't support the one that is.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Wexelblat | dwex@mtgzfs3.att.com | Somebody get me a
AT&T Bell Laboratories | ...!att!mtgzfs3!dwex | cheeseburger!
200 Laurel Ave - 4B-421 | |
Middletown, NJ 07748 | (908) 957-5871 | --Steve Miller Band
Crossposted-To: comp.unix.sysv386,comp.windows.x,comp.os.mach,comp.unix.bsd
From: sef@kithrup.COM (Sean Eric Fagan)
Subject: Re: Free software and the future of support for Diamond products
Date: Tue, 08 Sep 1992 09:33:00 GMT
In article < 1992Sep7.133347.4433@cbnewsj.cb.att.com>
dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:
>1) Calling BIOS from a multitasking OS is trick, dangerous, and impossible
> for those of us running SVR3/4
An interesting way to get around all of those: set up a v86 process that
calls the BIOS routines for you. It can be done, and I've seen it (not for
the card in question, however), although I don't recall enough to make any
claims about performance.
It probably requires some kernel help, however.
There's more than one way to skin a cat, remember!
--
Sean Eric Fagan | "You can't get lost in one room, no matter how
sef@kithrup.COM | little effort you make to learn your way around."
=================+ == William E Davidsen (william@crd.GE.COM)
Any opinions expressed are my own, and generally unpopular with others.
Crossposted-To: comp.unix.sysv386,comp.windows.x,comp.os.mach,comp.unix.bsd
From: harp@netcom.com (Gregory O. Harp)
Subject: Re: Free software and the future of support for Diamond products
Date: Thu, 10 Sep 92 02:03:32 GMT
sef@kithrup.COM (Sean Eric Fagan) writes:
>In article < 1992Sep7.133347.4433@cbnewsj.cb.att.com>
dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:
>>1) Calling BIOS from a multitasking OS is trick, dangerous, and impossible
>> for those of us running SVR3/4
>An interesting way to get around all of those: set up a v86 process that
>calls the BIOS routines for you. It can be done, and I've seen it (not for
>the card in question, however), although I don't recall enough to make any
>claims about performance.
Yuck. ;)
However, that does allow for compatibility with several boards. For
example, a VESA version of the X server could be released (I think.
Perhaps that's pushing it a bit far...).
So, how's the hate-mail campaign going with Diamond? ;)
--
=================Greg=Harp================harp@netcom.com==================
Love me, love my ferrets. "Break out of the mold before
Or at least love my ferrets. ;) the mold sets in" -- B52's
Crossposted-To: comp.unix.sysv386,comp.windows.x,comp.unix.bsd,
comp.os.mach,comp.sys.ibm.pc,comp.sys.ibm.pc.hardware
From: dwex@cbnewsj.cb.att.com (david.e.wexelblat)
Subject: Re: Free software and the future of support for Diamond products
Date: Thu, 10 Sep 1992 13:03:59 GMT
In article <1992Sep09.203305.18082@digibd.com>
rick@digibd.com (Rick Richardson) writes:
> dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:
>
> >Diamond, makers of the SpeedStar and Stealth series of SVGA cards, have
> >developed a new hardware technology for video dot-clock selection. The
> >current boards that have this new technology are the SpeedStar 24, the
> >SpeedStar 24X, and the Steath boards. Diamond considers this hardware
> >technology proprietary, and feel that giving out information on how to
> >program this hardware will yield a competetive advantage to their
> >competitors.
>
> OK, so they are trying to protect this as a "trade secret". If
> you discover a trade secret in legal ways, you are free to blab.
>
Of course. But how do you PROVE that that trade secret was discovered
in a legal way?
> >This position makes it impossible to support these boards on operating
> >systems that do not use the BIOS (e.g. Unix), unless one is willing
> >to sign a non-disclosure agreement with Diamond. Obviously, this is
> >impossible for software for which the source code is freely available.
>
> Or, unless someone discovers the secret and blabs.
>
> >know that Diamond's policy has changed. Be aware that if you disassemble
> >their BIOS, you are risking a lawsuit. We will not assume that liability,
> >so don't even ask!
>
> One can discover the trade secret without disassembling the BIOS.
> [disassembling the BIOS is probably legal, too, since this comes
> under the fair use provisions of the Copyright laws; I've never
> yet seen a shrink-wrap license wrapped around a VGA board which
> would put additional limits on fair use like software licenses.]
>
> One can put an emulator into a PC (or just a logic analyzer will do),
> run the BIOS, and see what I/O's are going out to the board to set the
> clocks.
>
There are any number of ways to determine the information we need. But
the bottom line is that (in this country, anyway) anyone can be sued for
just about anything, with or without justification. Now take a look at
my .signature, and think about what would happen if Diamond decided that
they didn't like what we were doing. Right or wrong, I would almost
definitely be out of a job. I'm not going to risk that for a piece
of hackerware. My cohorts, who are in a less intractable position on
this matter, have agreed with the position I am required to take.
So the bottom line for me is that I don't want to know about any of this
stuff, unless I am convinced that there's no way that any litigation will
be brought. I don't care about win or lose. The issue is will the action
be brought at all.
> The Diamond 24X is likely to be fairly ubiquitous in the cheap clones
> (I think Zeos ships it, for example), and these are, of course,
> exactly the type of people who'll be wanting XFree386. I think
> Computer City is selling them for $175.
>
Well, one of the responses to our Diamond mail survey was from Rick Kemp
at SCO. I quote:
We have no plans on supporting their cards at anything but
640x480 resolution. They have refused to tell us how their
cards work, and we have told all of our distributors to
discontinue carrying them (Gateway 2000 and Zeos).
So we'll see. The fact that SCO is having trouble doesn't bode well
for our winning this battle.
> -Rick
> --
> Rick Richardson Email: rick@digibd.com This space intentionally
> Senior Staff Engineer Fax: (612) 943-0803 blank until 1996 elections.
> DigiBoard, Inc. Tel: (612) 943-5383
> Eden Prairie, MN Radio: N0NMY
People may think I'm being selfish, or overly cautious. Well, I am. I'm
the most visible of the people involved in this, and the one employed
by the biggest corporation. We're doing this for fun. Going to court
and/or losing my job is NOT my idea of fun (1/2 :->).
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Wexelblat | dwex@mtgzfs3.att.com | Somebody get me a
AT&T Bell Laboratories | ...!att!mtgzfs3!dwex | cheeseburger!
200 Laurel Ave - 4B-421 | |
Middletown, NJ 07748 | (908) 957-5871 | --Steve Miller Band
Crossposted-To: comp.unix.sysv386,comp.windows.x,comp.os.mach,
comp.unix.bsd,comp.sys.ibm.pc,comp.sys.ibm.pc.hardware
From: dwex@cbnewsj.cb.att.com (david.e.wexelblat)
Subject: Re: Free software and the future of support for Diamond products
Date: Thu, 10 Sep 1992 13:15:35 GMT
In article < d0sncm+.harp@netcom.com>
harp@netcom.com (Gregory O. Harp) writes:
> sef@kithrup.COM (Sean Eric Fagan) writes:
>
> >In article <1992Sep7.133347.4433@cbnewsj.cb.att.com>
> >dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:
> >>1) Calling BIOS from a multitasking OS is trick, dangerous, and impossible
> >> for those of us running SVR3/4
>
> >An interesting way to get around all of those: set up a v86 process that
> >calls the BIOS routines for you. It can be done, and I've seen it (not for
> >the card in question, however), although I don't recall enough to make any
> >claims about performance.
>
> Yuck. ;)
>
> However, that does allow for compatibility with several boards. For
> example, a VESA version of the X server could be released (I think.
> Perhaps that's pushing it a bit far...).
>
If somebody wants to write that and contribute it, fine. We will NOT
be examining that alternative.
> So, how's the hate-mail campaign going with Diamond? ;)
It's not a hate-mail campaign (yes, I see the smiley). Some people seem
to think it is. I see it as data collection to be used as evidence to
support our contention that Diamond is cutting themselves out of a
significant market.
That said, thing are going well. Our mailbox is over 170kb long. We
have reports of several thousand board sales lost (pushing 10000). We
have been contacted by several universities and several consulting
firms of varying size. We have been contacted by SCO and by S3.
I'll be on vacation next week. When I get back (after wading though
a huge mailbox), I will tabulate the results and send them to Diamond.
Then we wait and see.
> --
> -----------------Greg-Harp----------------harp@netcom.com------------------
> Love me, love my ferrets. "Break out of the mold before
> Or at least love my ferrets. ;) the mold sets in" -- B52's
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Wexelblat | dwex@mtgzfs3.att.com | Somebody get me a
AT&T Bell Laboratories | ...!att!mtgzfs3!dwex | cheeseburger!
200 Laurel Ave - 4B-421 | |
Middletown, NJ 07748 | (908) 957-5871 | --Steve Miller Band
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Crossposted-To: comp.unix.sysv386,comp.windows.x,comp.unix.bsd,
comp.os.mach,comp.sys.ibm.pc.misc,comp.sys.ibm.pc.hardware
Subject: Re: Free software and the future of support for Diamond products
Date: 11 Sep 92 12:48:31 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
In article <1992Sep10.130359.24767@cbnewsj.cb.att.com>,
dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:
| Well, one of the responses to our Diamond mail survey was from Rick Kemp
| at SCO. I quote:
|
| We have no plans on supporting their cards at anything but
| 640x480 resolution. They have refused to tell us how their
| cards work, and we have told all of our distributors to
| discontinue carrying them (Gateway 2000 and Zeos).
|
| So we'll see. The fact that SCO is having trouble doesn't bode well
| for our winning this battle.
Interesting, since SCO has a stealth X driver in their directory on
uunet. I have very little information about it beyond that.
--
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
I admit that when I was in school I wrote COBOL. But I didn't compile.
From: kgermann@zeos.com (Ken Germann)
Crossposted-To: comp.unix.sysv386,comp.windows.x,comp.unix.bsd,
comp.os.mach,comp.sys.ibm.pc.misc,comp.sys.ibm.pc.hardware
Subject: Re: Free software and the future of support for Diamond products
Date: 12 Sep 92 03:55:49 GMT
In article <1992Sep11.124831.10108@crd.ge.com>
davidsen@crd.ge.com (bill davidsen) writes:
>In article <1992Sep10.130359.24767@cbnewsj.cb.att.com>,
>dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:
>
>| Well, one of the responses to our Diamond mail survey was from Rick Kemp
>| at SCO. I quote:
>|
>| We have no plans on supporting their cards at anything but
>| 640x480 resolution. They have refused to tell us how their
>| cards work, and we have told all of our distributors to
>| discontinue carrying them (Gateway 2000 and Zeos).
>|
>| So we'll see. The fact that SCO is having trouble doesn't bode well
>| for our winning this battle.
>
> Interesting, since SCO has a stealth X driver in their directory on
>uunet. I have very little information about it beyond that.
>--
The solution for the support of X/Windows in the Freeware arena or
any other arena would be to design a VESA based driver for these
software packages. It would greatly simplify the need to design
specific drivers for specific cards. Granted the VESA drivers may not
take advantage of the hardware specific to the card; but, there would
still be a driver available until someone changes their minds.
How difficult would it be to support a VESA based driver under Unix?
This would be a place to start.
The problems with the support arose with the Speedstar 24X and Diamonds
proprietary technology used on the card. The Speedstar and Stealth
are both supported by ODT 1.x and 2.x now. The generic TSENG drivers
, I am told should work for the Speedstar (ET4000) based card.
--
Ken Germann ZZZZ EEEE OO SSS ZEOS International, Ltd.
support@zeos.com INET Z E O O S Technical Support Dept.
uunet!zeos!support UUCP Z EE O O SS 530 5th Ave N.W.
800-228-5390 VOICE Z E O O S St. Paul, MN 55112
612-633-7337 ZZZZ EEEE OO SSS FAX 612-633-4607
Crossposted-To: comp.unix.sysv386,comp.windows.x,comp.unix.bsd,
comp.os.mach,comp.sys.ibm.pc.misc,comp.sys.ibm.pc.hardware
From: dwex@cbnewsj.cb.att.com (david.e.wexelblat)
Subject: Re: Free software and the future of support for Diamond products
Date: Sun, 20 Sep 1992 00:08:51 GMT
In article <1992Sep12.035549.4743@zeos.com>
kgermann@zeos.com (Ken Germann) writes:
> In article <1992Sep11.124831.10108@crd.ge.com>
> davidsen@crd.ge.com (bill davidsen) writes:
> >In article <1992Sep10.130359.24767@cbnewsj.cb.att.com>,
> >dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:
> >
> >| Well, one of the responses to our Diamond mail survey was from Rick Kemp
> >| at SCO. I quote:
> >|
> >| We have no plans on supporting their cards at anything but
> >| 640x480 resolution. They have refused to tell us how their
> >| cards work, and we have told all of our distributors to
> >| discontinue carrying them (Gateway 2000 and Zeos).
> >|
> >| So we'll see. The fact that SCO is having trouble doesn't bode well
> >| for our winning this battle.
> >
> > Interesting, since SCO has a stealth X driver in their directory on
> >uunet. I have very little information about it beyond that.
> >--
> The solution for the support of X/Windows in the Freeware arena or
> any other arena would be to design a VESA based driver for these
> software packages. It would greatly simplify the need to design
> specific drivers for specific cards. Granted the VESA drivers may not
> take advantage of the hardware specific to the card; but, there would
> still be a driver available until someone changes their minds.
> How difficult would it be to support a VESA based driver under Unix?
> This would be a place to start.
>
>
> The problems with the support arose with the Speedstar 24X and Diamonds
> proprietary technology used on the card. The Speedstar and Stealth
> are both supported by ODT 1.x and 2.x now. The generic TSENG drivers
> , I am told should work for the Speedstar (ET4000) based card.
>
>
>
> --
> Ken Germann ZZZZ EEEE OO SSS ZEOS International, Ltd.
> support@zeos.com INET Z E O O S Technical Support Dept.
> uunet!zeos!support UUCP Z EE O O SS 530 5th Ave N.W.
> 800-228-5390 VOICE Z E O O S St. Paul, MN 55112
> 612-633-7337 ZZZZ EEEE OO SSS FAX 612-633-4607
[Sorry it took me so long to get back into the fray - I've been on vacation]
Unless I've missed something, a VESA compliant board supports a BIOS standard,
not a register-level standard. Unix, like other protected-mode operating
systems, does not use the BIOS at all, except during boot. So there's
no such thing as a VESA-compliant driver under Unix, unless someone hacks
the kernel to allow this to work.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Wexelblat | dwex@mtgzfs3.att.com | Somebody get me a
AT&T Bell Laboratories | ...!att!mtgzfs3!dwex | cheeseburger!
200 Laurel Ave - 4B-421 | |
Middletown, NJ 07748 | (908) 957-5871 | --Steve Miller Band
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Crossposted-To: comp.unix.sysv386,comp.windows.x,comp.unix.bsd,comp.os.mach,
comp.sys.ibm.pc.misc,comp.sys.ibm.pc.hardware
Subject: Re: Free software and the future of support for Diamond products
Date: 21 Sep 92 15:08:21 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
In article <1992Sep20.000851.2641@cbnewsj.cb.att.com>,
dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:
| Unless I've missed something, a VESA compliant board supports a BIOS standard,
| not a register-level standard. Unix, like other protected-mode operating
| systems, does not use the BIOS at all, except during boot. So there's
| no such thing as a VESA-compliant driver under Unix, unless someone hacks
| the kernel to allow this to work.
Youu've missed something. The kernel supports vm86 operation, and it
is possible to drop into real mode, allow access to the i/o ports
needed, and run the BIOS in real mode, then exit back to protected mode.
I am not suggesting this, I'm just saying it can be done.
--
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
I admit that when I was in school I wrote COBOL. But I didn't compile.
Crossposted-To: comp.unix.sysv386,comp.windows.x,comp.unix.bsd,
comp.os.mach,comp.sys.ibm.pc.misc,comp.sys.ibm.pc.hardware
From: dwex@cbnewsj.cb.att.com (david.e.wexelblat)
Subject: Re: Free software and the future of support for Diamond products
Date: Mon, 21 Sep 1992 15:44:51 GMT
In article <1992Sep21.150821.9472@crd.ge.com>
davidsen@crd.ge.com (bill davidsen) writes:
> In article <1992Sep20.000851.2641@cbnewsj.cb.att.com>,
> dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:
>
> | Unless I've missed something, a VESA compliant board supports a BIOS
> | standard, not a register-level standard. Unix, like other protected-mode
> | operating systems, does not use the BIOS at all, except during boot. So
> | there's no such thing as a VESA-compliant driver under Unix, unless
> | someone hacks the kernel to allow this to work.
>
> Youu've missed something. The kernel supports vm86 operation, and it
> is possible to drop into real mode, allow access to the i/o ports
> needed, and run the BIOS in real mode, then exit back to protected mode.
> I am not suggesting this, I'm just saying it can be done.
> --
> bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
> I admit that when I was in school I wrote COBOL. But I didn't compile.
Well. Learn something new every day. Does anyone have a code sample that
shows how this may be done?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Wexelblat | dwex@mtgzfs3.att.com | Somebody get me a
AT&T Bell Laboratories | ...!att!mtgzfs3!dwex | cheeseburger!
200 Laurel Ave - 4B-421 | |
Middletown, NJ 07748 | (908) 957-5871 | --Steve Miller Band
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Crossposted-To: comp.unix.sysv386,comp.windows.x,comp.unix.bsd,
comp.os.mach,comp.sys.ibm.pc.misc,comp.sys.ibm.pc.hardware
Subject: Re: Free software and the future of support for Diamond products
Date: 21 Sep 92 16:48:16 GMT
In article <1992Sep21.154451.10085@cbnewsj.cb.att.com>
dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:
>In article <1992Sep21.150821.9472@crd.ge.com>
>davidsen@crd.ge.com (bill davidsen) writes:
>>
>> Youu've missed something. The kernel supports vm86 operation, and it
>> is possible to drop into real mode, allow access to the i/o ports
>> needed, and run the BIOS in real mode, then exit back to protected mode.
>> I am not suggesting this, I'm just saying it can be done.
>
>Well. Learn something new every day. Does anyone have a code sample that
>shows how this may be done?
Hmm. The linux alpha DOS-emulator might be able to do it with some
minor tweaking: you'd have to get the initial 'int 0x10' address from
somewhere (as it's normally over-written by the kernel), and the process
should do a mmap("/dev/mem") the put the bios/screen memory into the
normal address space. Additionally, you can use the iopl() system call
to give the process IO priviledges before switching to vm86 mode - that
way you don't even have to emulate any IO instructions. Some additional
setup to initialize the normal BIOS data areas, and off you go. The
only thing that doesn't work with the current linux setup is to get the
original offset to the 'int 0x10' call: a minor kernel diff to look it
up at bootup would be possible.
I don't know how other systems would do it, but it should certainly be
possible - but I do not think it's a good idea. It's ugly, and it's not
guaranteed to be safe: the BIOS call might do something nasty while it
has IO priviledges if it assumes a normal DOS setup and the vm86 setup
is incomplete. Besides, that way you can only set modes that the BIOS
knows about - the X386 (XFree86) driver has already proven that
programming the chipset directly can lead to much better results (ie
nonstandard resolutions etc).
Linus