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!news.cse.psu.edu!uwm.edu!lll-winken.llnl.gov!hookup!news.mathworks.com!solaris.cc.vt.edu!not-for-mail From: erik@fenris.campus.vt.edu () 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: 21 Apr 1996 10:11:47 GMT Organization: A random machine somewhere Lines: 339 Message-ID: <4ld1l3$bem@solaris.cc.vt.edu> 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> NNTP-Posting-Host: shadowlands.campus.vt.edu NNTP-Posting-User: erik X-Newsreader: TIN [UNIX 1.3 950824BETA PL0] Xref: euryale.cc.adfa.oz.au comp.os.linux.development.apps:14606 comp.os.linux.development.system:21727 comp.os.linux.x:29687 comp.os.linux.hardware:36703 comp.os.linux.setup:51120 comp.unix.bsd.386bsd.misc:680 comp.unix.bsd.bsdi.misc:3311 comp.unix.bsd.netbsd.misc:3147 comp.unix.bsd.freebsd.misc:17639 Terry Lambert (terry@lambert.org) wrote: : ] Now, in newer video cards, there is a RAMDAC, a graphics : ] Accelerator, and the clock chips for the modes. : : 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? A PAL, or Programmable Logic Array, is a very generic way to refer to a whole class of devices. Also, PALs are seldom, if ever, used in a manufactured design because of their greater cost. RAMDAC is about taking the values from video memory and converting it into a form the monitor can use. A big difference from "latching an input bit pattern and getting an output bit pattern". : 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. That's pretty good. There are many different ways to implement functionality, jump tables, mode tables, written out mode setting code, which enables bits based on the mode bits. There are some similarities in most VESA BIOSes, because of information it has to return, but that's not necessary to use. : 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. There is a finite number of elements in ANY black box. That doesn't enable you to say that you know for sure what the black box consists off. Maybe it just comes with your vast experience that you can tell how a black box was implemented merely by looking at the outside - the whole point of a black box is that there ISN'T an easy way to tell implementation details. YOu could have a person inside handing you values, for all you know. Maybe you learned another definition. : 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. I actually don't recall this. My understanding was that they kept upgrading their card capacities by making cards with newer chipsets, ranging from the ET4000, to the S3C805 to the newer, spiffier S3's. None of the 'magic' was to really do with the firmware. Not to mention that drivers typically don't use the firmware in ANY protected mode system.. but more on that later. : 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). *BLINK* I suppose this must be my penance for something in a past life. A RAMDAC really is NOT similar to an EEPROM. There is a VAST difference in functionality.. And an EEPROM is changeable while in the design, where as based on my understanding of PALs, once you burn in the design, it's there for good -- osmewhat of a dramatic difference, wouldn't you agree. : 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). XFree86 had the means to work on the cards before Diamond released info. The design of recent S3 based ones was a S3 chip - S3 gives out documentation, then a RAMDAC ( the S24 used the SS2410, which I don't know enough about to say where documentationc ould be obtained.. the S64s use another brand of RAMDAC.. all from other manufacturers ) and a clockchip ( the S24 used the ICS ( or ICD? ) 2061 chip, which the documentation was available ). This has nothing to do with their firmware. : 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)? Diamond didn't disclose information because it was POLICY. That's all.. There wasn't anymore more in it. And, their designs were very easy to clone, using off the shelf chips, but... : Simple: because they neglected to engineer a software access : path other than the BIOS to the mode-table-to-clock-setting : circuitry. HUH? The Diamond drivers in other 32bit operating systems didn't use the BIOS. The Diamond driver in Linux sure doesn't use the BIOS. mode-table -> clock setting is a rather straightforward thing.. the only thing you need for each card is HOW to tell the card what clock rate you want it at. : 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. Protected mode software seldom does this. I don't know of any driver which actually does, although I am sure there might be one or two. Having a tabl ein a ROM would be STUPID because different people have monitors with different specs... havne't you ever ran the configuration program with your video card that lets you align the screen to your monitor and specify the frequency? This is either saved onto an EEPROM or a driver at bootup sets these values (ugh!) on cheaper cards. : 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. So what else is new.. that's why we have modelines in the Xfree configuration file. BECAUSE these tables aren't standard, and ebcause there aren't drivers for individual cards, but for chipsets that are in the cards. The common denominator is the hardware, not the design of the ROM. : 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. Huh? Timing values go to the clock chip. RAMDAC output goes to the monitor. And IF you could find the table, and figure out what format it was in, you would have the values.. of course, the drivers don't need to use this, and it is too much trouble. : 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. Diamond cards are identified as S3 based cards. Their RAMDAC is identifiable by similar methods ( i/o to known ports with known results ). Why should they pay more for a software engineer.. they were probably only slightly modifying the BIOS provided ( I am supposing ) by S3.. paying you to overdesign the product would be a needless expense that would have affected the market price of the cards. : 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. A nice way to do it. It's been done by a couple of designs. The thing is, most people don't want to do a specific Diamond Stealth 64 driver, since THE UNDERLYING HARDWARE is different between different Diamond versions. Your hypothetical design assumes that the underlying hardware will stay the same. WRONG. The ports to write the clock values might easily be different. And these table values are WORTHLESS without knowing the ports. So, you have to do a different set of outputs for various clock chips and ramdacs anyway. And the table doesn't shield you from that. So all the table is good for, is once you know ALL the other hardware... then you _could_ theoretically use the timing values,. BUT these timing values might be worthless. What if you want a higher refresh rate for a loewr mode? to align a mode to your screen better? These table values are likely FIXED. What about someone using an interlaced monitor? ( I am... ). They can't use the default table values. : No XFree86 "mode line" crap, no Windows 95 "card type and : monitory type" Display Control Panel crap, etc.. These mode lines are necessary for supporting a wide range of cards with similar hardware and for getting the most out of the cards, using non-standard modes if you are really daring. And, supporting a wide range of monitor types. Something your table can't really handle. : 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. It is nasty because of the existing design of Linux. The GGI project will solve it. X is the way X is.. and it is one solution that is not ideal for this problem. I call it nasty because the hardware doesn't support the existing software design well. Eventually the software will change, but since it is an underlying problem, it will take much time. If you are calling the X programming team incompetent, I'll let others deal with that. : 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. BLINK. Yes, you can potentially overdrive a clock chip., That is bad. Yeah, you can hit your monitor with frequencies that it doesn't support.. That's a risk with ANY card, not just diamond. Firmware upgrade technology? That's better referred to as putting in a better RAMDAC, a better clock chip.. a better main controller.. pretty standard stuff. blah. : 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. : You can fry your hardware with just about any XFree86 driver. What's the big deal -- you are't supposed to mess with the configuration file unless you know what you are doing. : ] 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? Hmm.. It wouldn't have been if you had know what you were talking about :-) The configuration programs that I mentioned above store the monitor specs and the alignment values for a specific mode in an Electronically Eraseable Programmable Read Only Memory ( EEPROM ).. maybe some use a CMOS, but the Diamond's I've seen use an EEPROM ). This is because every monitor, as I have said time and time again, cna be different, likewise, the preferences of the individual users. A really spiffy driver would read these values from the EEPROM. But that'd require it be diamond specific.. it's not worth it. : 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). That's why there is an EEPROM, so the user can configure their own monitor types ( the 'custom' setting ). Replacing a RAMDAC requires a new driver anyway since the programming is different. Replacing the BIOS doesn't affect a protected mode driver, since they don';t use the BIOS anyway. : 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 drivers detect the hardware based on hardware identification.. the new card/old driver case doesn't happen that much, unless the ins/outs are very similar, which is fortunately rare. Most likely, the old driver will say "unrecognized revision id : 0xE3 " or something similar. : 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. This upgrading is done by many compnaies, who put in a newer version of a chipset in their new version. Big deal. It's not a significant economic advantage. : ] Summary - Get a Clue. : Get one yourself. I'm always looking for clues.. somehow I don't think I'd get any from you though..