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.