Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!news.kei.com!uhog.mit.edu!news.mathworks.com!newsfeed.internetmci.com!howland.reston.ans.net!cs.utexas.edu!not-for-mail
From: pmcdermo@cs.utexas.edu (Peter F. McDermott)
Newsgroups: comp.os.linux.development.apps,comp.os.linux.development.system,comp.os.linux.x,comp.os.linux.hardware,comp.os.linux.setup,comp.unix.bsd.386bsd.misc,comp.unix.bsd.bsdi.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc
Subject: Re: Why to not buy Matrox Millennium
Followup-To: comp.os.linux.development.apps,comp.os.linux.development.system,comp.os.linux.x,comp.os.linux.hardware,comp.os.linux.setup,comp.unix.bsd.386bsd.misc,comp.unix.bsd.bsdi.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc
Date: 26 Mar 1996 16:53:40 -0600
Organization: CS Dept, University of Texas at Austin
Lines: 83
Distribution: world
Message-ID: <4j9shk$odt@slappy.cs.utexas.edu>
References: <4j21ph$crr@slappy.cs.utexas.edu>
NNTP-Posting-Host: slappy.cs.utexas.edu
X-Newsreader: TIN [version 1.2 PL2]
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.apps:13787 comp.os.linux.development.system:20206 comp.os.linux.x:27883 comp.os.linux.hardware:34657 comp.os.linux.setup:47713 comp.unix.bsd.386bsd.misc:337 comp.unix.bsd.bsdi.misc:2836 comp.unix.bsd.netbsd.misc:2616 comp.unix.bsd.freebsd.misc:16192
I'm glad that this thread has aroused so much discussion, but am even
happier that it appears to have aroused even more awareness of Matrox's
policies. Let me go over my reasons for originally posting the message:
o To raise awareness within the Linux/*BSD* community that Matrox's
hardware will not work on XFree86 any time in the forseeable future.
o To make the public understand how arrogant the tech support people
are at Matrox.
o To bring about discussion that will hopefully get back to the powers
that be at Matrox and somehow convince them that releasing documentation
on their chipset is a good thing.
I think the first two have been successful, the third, I don't know. I
certainly have received no e-mail from Matrox.
I'm glad that the Xinside people are following this thread. And there
have certainly been quite a few thoughtful posts regarding the matter.
Now let me get a few words in.
The XFree86 team is a very dedicated group of individuals. David
Wexelblat's (sp?) comments aside, they are pretty nice people. Maybe
David was having a bad day. I can certainly understand his frustration
with people suggesting that the solution is reverse engineering, when
the real solution is convincing the manufacturers to release documentation.
As has been pointed out by a number of people reverse engineering something
as complicated as an accelerated graphics chipset is going to be quite
painful. If I had a Matrox Millennium, I could probably reverse engineer
it. I estimate that if I dedicated all of my time to the project, I could
do it in 9 months. I am by no means the best programmer, so ymmv. But I'm
certainly not going to be spending the next 9 months of my life porting
Mesa to a card that will be obselete when I'm done. I have better things
to do with my time. [Mesa is a free OpenGL clone]
Now, as far as the reverse engineering stuff goes, let me relate a conversation
I was having with a programmer who used to work for a company that reverse
engineered the IBM VGA when it was new.
Oh, when I talk about legality here it is US law -- after all, we are
talking about US companies.
Apparently, reverse engineering the gates on a chip is not illegal. They
sent the actual VGA chip to Japan where a company stripped the silicon
one layer at a time and mapped out the chip. From this they had basically
the programming equivallent of a binary bump of the VGA logic. This was
all perfectly legal. Now, the BIOS was a different story all together.
The BIOS for the card is actual code and as such is protected under US
copyright law, much like a book. So, they couldn't so much as look at
the code and consider it clean-roomed. They ended up putting a tektronix
logic analyzer on the bus, sending an outp(..) to one of the printer lines
to trigger the logic analyzer to start recording, and then calling an
int 10h (video) function to do something (say a mode set) and recording
all of the bus transitions, and then sending an outp(..) to the same
printer port to tell the logic analyzer to stop recording. It went like
this:
outp(...) -- tell logic analyzer to start recording
mov ax, something -- setup the function number for the interrupt call
int 10h -- call the video BIOS to execute the function
(logic analyzer records all bus transactions)
outp(...) -- tell the logic analyzer to stop recording
So, they ended up with address and data information which they could then
look at to determine what registers on the VGA chip were being programmed
for a given int 10h function call.
In a nutshell, they black-boxed the BIOS chip.
All perfectly legal, none of it particularly easy.
I hope this gives some of you an idea of just what's involved in a
reverse-engineering effort.
Oh, BTW, the Matrox 3-D solution is okay for now, but come Comdex time
you'll be seeing a whole slew of 3-D chipsets. Most of them better
than Matrox's current offering. And I know of at least one that will
be making their documentation publicly available. Who's do you think
I'll be using?
-Peter McDermott
pmcdermo@cs.utexas.edu