Return to BSD News archive
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 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!qns3.qns.com!imci4!newsfeed.internetmci.com!in1.uu.net!news.new-york.net!ritz.mordor.com!ritz From: ritz@ritz.mordor.com (Chris Mauritz) Subject: Re: Why to not buy Matrox Millennium Followup-To: alt.flame X-Newsreader: TIN [UNIX 1.3 950824BETA PL0] Lines: 256 Organization: Mordor International Message-ID: <Dq810D.qD@ritz.mordor.com> 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> <3179639A.7B782E0E@lambert.org> Date: Sun, 21 Apr 1996 16:41:01 GMT Xref: euryale.cc.adfa.oz.au comp.os.linux.development.apps:14583 comp.os.linux.development.system:21691 comp.os.linux.x:29651 comp.os.linux.hardware:36671 comp.os.linux.setup:51049 comp.unix.bsd.386bsd.misc:670 comp.unix.bsd.bsdi.misc:3300 comp.unix.bsd.netbsd.misc:3132 comp.unix.bsd.freebsd.misc:17609 ENOUGH ALREADY! Don't you people have anything better to do than roach the S/N on 30-odd newsgroups? Follow-ups redirected to alt.flame...where all this tripe belonged in the first place. Chris Terry Lambert (terry@lambert.org) wrote: : 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. -- Christopher Mauritz | For info on internet access: ritz@mordor.com | finger/mail info@ritz.mordor.com OR Mordor International | http://www.mordor.com/ 201/212/718 internet access | Modem: (201)433-7343,(212)843-3451