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!newsfeed.internetmci.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: 20 Apr 1996 06:34:24 GMT Organization: A random machine somewhere Lines: 74 Message-ID: <4la0hg$j6h@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> 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:14684 comp.os.linux.development.system:21939 comp.os.linux.x:29892 comp.os.linux.hardware:36890 comp.os.linux.setup:51451 comp.unix.bsd.386bsd.misc:749 comp.unix.bsd.bsdi.misc:3392 comp.unix.bsd.netbsd.misc:3235 comp.unix.bsd.freebsd.misc:17832 Terry Lambert (terry@lambert.org) wrote: : The reason Diamond cards didn't have a documented interface : is well known: their BIOS programmer didn't do the mode select : through a table lookup because he was an EE, not an SE, and : EE's typically do not think of things like that, since the : software is there for the benefit of the card. If they had : hired a software engineer in the first place, then they would : never have had the problem. You should back up this statement better. First of all, unless you disassembled Diamond's BIOS, you would not know this, and judging from how VGA BIOS has to be implemented to follow documented interfaces, you NEED to use at least one accessable table. The format isn't completely followed, but you must use a table that is standard for modes up to decimal 29. While I cannot speak for Diamond, I do know that it is very typical for BIOS writers to continue using this table. Somehow I have the feeling this is going to turn into a Get A Clue post. : And now they release drivers on their web site, and still don't : use table lookups, so bowing to pressure from the likes of you : has destroyed their ability to change PAL's and BIOS to allow : them to add capabilities to their cards without redesigning : them. The reason for the proprietary interface on Diamond, : as any idiot *should* know, is that the only way to latch : good input values on their clock chip input was to give their : PAL appropriate inputs, since it's the PAL output that latches : the values. And the PAL inputs were looked up from a table : in their BIOS when you made an INT 10 mode select call, and : their EE programmer stupidly didn't make their table a standard : format or location, so protected mode drivers could find it : and latch the right PAL inputs. *DUH*... the hazards of the : wrong person for the job. 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. 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". 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. 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. 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. Summary - Get a Clue.