Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.ecn.uoknor.edu!paladin.american.edu!gatech!swrinde!newsfeed.internetmci.com!in1.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
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
Date: Sat, 20 Apr 1996 15:22:18 -0700
Organization: Me
Lines: 246
Message-ID: <3179639A.7B782E0E@lambert.org>
References: <3170348D.4496D9F1@lambert.org> <stephenkDq2BCK.B40@netcom.com> <3176AFE0.28146F7@lambert.org> <stephenkDq3B99.FDq@netcom.com> <31785BB6.99F81FD@lambert.org> <4la0hg$j6h@solaris.cc.vt.edu>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.apps:14565 comp.os.linux.development.system:21657 comp.os.linux.x:29626 comp.os.linux.hardware:36645 comp.os.linux.setup:51000 comp.unix.bsd.386bsd.misc:659 comp.unix.bsd.bsdi.misc:3284 comp.unix.bsd.netbsd.misc:3117 comp.unix.bsd.freebsd.misc:17585
erik@fenris.campus.vt.edu wrote:
] Somehow I have the feeling this is going to turn into a
] Get A Clue post.
You're right; it is. Prepare to acquire one.
] I wonder why I often get depressed reading newsgroups... because
] of worthless misinformation posted here.
]
] PAL values? What are you referring to as a PAL?
]
] First, you say in the paragraph above, "didn't use a table
] lookup", then you say "PAL inputs were looked up from a
] table". It's either one or the other.
]
] Now, Diamond did some stupid things, but this doesn't seem
] likely.. As a former owner of a Diamond Stealth 24, I feel
] qualified to say a little about the support for that.
]
] Now, in newer video cards, there is a RAMDAC, a graphics
] Accelerator, and the clock chips for the modes.
]
] I don't see any of those referred to as a "pal".. the closest
] thing would be the palette values, called 'pel's typically,
] but that's a whole different story.
RAMDAC, not PAL. Sorry. The two are so electrically different,
what with you latching an input bit pattern and getting an output
bit pattern on both... note the similar screwup in toyr own post
(below). I guess there is a dual semantic perfection standard?
First, let me point out that any software engineer with half a
brain would immediately know, from observation of the card
behaviour, exactly how they implemented their INT 10 BIOS.
This does not require, as you accused me of doing, the engineer
to disassemble their BIOS implementation. There is a finite
set of elements which could fit in their little "black box"
and make it do what it apparently does.
Now let's look at what their supposedly "magic" card design
does for them: it lets them use firmware to upgrade their
card capabilities without changing component layouts or
redoing artwork.
The firmware consists of a BIOS ROM and a RAMDAC (or an
EEPROM, as you suggest, and a PAL, as I suggested, would work
to provide the same design results).
Their "intellectual property" consists of the ability to
crank out card upgrades in a vastly shortened design and
fabrication cycle. I am sure it is protected by patent;
it's not a "trade secret" (they cease to offer protection
after disclosure, and this one was instantly on the net
the first time someone competent looked into making XFree86
work on their cards) and it's not an issue of copyrighted
code (or the disassembly thereof).
Now why didn't Diamond disclose protected mode programming
information for the cards if they were not actively
protecting intellectual property through their non-disclosure
(which is what most net.idiots thought they were doing:
simply keeping secrets)?
Simple: because they neglected to engineer a software access
path other than the BIOS to the mode-table-to-clock-setting
circuitry.
Which is to say, that internally, the BIOS ROM's could do a
table lookup, but since the table was not formally specified
as to location, size, and content, protected mode software
could not.
In other words, as far as protected mode software is concerned,
the table effectively does not exist... and even if it could
find the damn thing, it's incomplete because of information
implied in the INT 10 mode select interface. Like where the
damn thing ends.
Even if you could get at the table, this would not give you
the ability to latch RAMDAC values for input to the clock
chip.
A correct design (which Diamond should pay me for, since
they should have hired a software engineer to do it in the
first place, and I would have been happy to see their product
be more usable while still meeting the fabrication/upgrade
design goals) would have a card identification tag at a
known location.
The easiest method of accomplishing this would be to do
the following:
INT 10 entry ,-------
| JMP | -.
|-------| |
Card Identification | | |
| | |
|-------| |
| | |
BIOS Mode to RAMDAC | | |
input description table | | |
| | |
... |
| | |
| | |
|-------| |
Real INT 10 entry | |<-'
| |
...
Obviously, then, to locate the table, a protected mode driver
would be able to look at the low core INT 10 entry point for
the card, verify the card identity, and access the table
directly.
If our hypothetical "video BIOS engineer who knows what he
is doing" is really smart, then he would leave table space
for future expansion and terminate the table with an abnormal
record that both the INT 10 mode select calls and the
protected mode driver could recognize (because he documents
what the termination looks like).
Finally, if he were truly gifted, he would include flags
so that extended mode values above and beyond the ones
defined by the standards were knowable from the table.
For instance, a flag to indicate a text vs. a graphic mode,
a flag to indicate mapping of a graphic mode as a linear
frame buffer, and 16 bit X and Y resoloution values for
all modes, etc..
No XFree86 "mode line" crap, no Windows 95 "card type and
monitory type" Display Control Panel crap, etc..
This is how a real software engineer would have solved the
problem, if Diamond wouldn't let them make the INT 10
interface callable from protected mode (which they probably
wouldn't because it would impact DOS-mode benchmarks -- note
that Windows NT and even Windows 95 are using protect mode
video drivers, so handicapping INT 10 for a DOS benchmark is
just more bogus marketing crap with zero technical merit).
Even if it were callable from protected mode, the table
would need to be accessable to document the extended
modes (which are stupidly documented only in accompanying
printed materials and must currently be hard-coded in
drivers... cv: the Windows 95 "card type" selection box).
] now, some of Diamond's cards used clockchips with a nasty
] misfeature - you couldn't read from them. This makes
] RESTORING the previous mode a bit nasty, but it has nothing
] to do with knowing "good input values".
Irrelevant. If a write-only register exists, a competent
driver writer will shadow it in the driver so that the state
is always knowable. This is why having the DDX mode setting
code in XFree86 instead of in the kernel is a stupid idea.
A competent software engineer would have immediately arrived
at this soloution and not called the problem "nasty" in the
first place.
] The clock chips were mostly standard ( on the Stealth 24,
] it was an ICS 2061a, which the specs for were posted, even
] before official Diamond support ). So, knowing the
] right input values wasn't difficult at all.
]
] Your ignorance seems to be showing.
Your ignorance is showing. This is again, irrelevant because
of allowable variations in design based on RAMDAC inputs. The
information was not disclosed because a good setting for a
protected mode driver for one card could overdrive the card
or the monitor and fry it for another (apparently identical
because of the firmware upgrade technology) Diamond card.
If you had truly followed the unsupported Diamond drivers and
the accompanying notes in the Sunsite Linux FTP archives, as
you claim, then this would have been known to you already.
The first thing in the README was a disclaimer that it might
fry your hardware.
] Protect mode drivers seldom,if ever, get anything from the BIOS.
] If the chip contains mode settings, it's typical for the driver
] to read it from the EEPROM and use that to program the clock chip,
] and the ramdac, and whatever other spiffy features your card has.
Some semantic bit twiddling as a means of "discrediting" you
(turnabout is fair play -- obviously if I must be infallable
when referring to the RAMDAC, it's reasonable to expect you
to be infallable when referring to the ROM):
[ I don't see any of those referred to as an "EEPROM".. the closest
thing would be the mask-programmed BIOS ROM, called a 'ROM'
typically, but that's a whole different story. ]
Not as pleasent on the other foot?
] And finally, pressure from developers did NOT damage Diamond's
] ability to add enhancements - look at the s3D stuff that they
] have.. and diamond had been redesigning their cards every
] generation anyway, looking over the chipsets in diamond's
] boards is like a who's who in the SVGA chipset market.
Disclosure of programming information for existing cards
damaged their ability to replace BIOS/RAMDAC pairs in card
designs to safely upgrade the card without a physical design
change (for instance, when a new monitor came out, or for an
OEM product).
Upgrade after drivers had been written on the basis of the
diclosure risked "new card/old driver" card and/or monitor
damage, as described in the SunSite documents.
The ability to upgrade their cards without significant
redesign *WAS* a competitive advantage for Diamond, and
you are an idiot with no understanding of the economics
involved to argue that it wasn't.
] Summary - Get a Clue.
Get one yourself.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.