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!paladin.american.edu!gatech!swrinde!newsfeed.internetmci.com!in2.uu.net!mail2news.alias.net!myriad!mylinuxbox!suck!netcom.com!stephenk From: stephenk@netcom.com (Stephen Knilans) Subject: Re: Why to not buy Matrox Millennium Message-ID: <stephenkDq8tt9.DDJ@netcom.com> Organization: Netcom Online Communications Services (408-241-9760 login: guest) References: <3179639A.7B782E0E@lambert.org> <4ld1l3$bem@solaris.cc.vt.edu> <317AD930.2088AE6D@lambert.org> Date: Mon, 22 Apr 1996 03:03:09 GMT Lines: 250 Sender: stephenk@netcom21.netcom.com Xref: euryale.cc.adfa.oz.au comp.os.linux.development.apps:14744 comp.os.linux.development.system:22040 comp.os.linux.x:29959 comp.os.linux.hardware:36967 comp.os.linux.setup:51620 comp.unix.bsd.386bsd.misc:779 comp.unix.bsd.bsdi.misc:3428 comp.unix.bsd.netbsd.misc:3279 comp.unix.bsd.freebsd.misc:17932 In article <317AD930.2088AE6D@lambert.org> Terry Lambert <terry@lambert.org> writes: >erik@fenris.campus.vt.edu wrote: >] 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. > >Then you were wrong, and I *did* mean PAL. I really don't give a >damn what get's changed at the same time the BIOS gets changed, >it's that the data in the BIOS describing the change is not >available to the protected mode driver (because it does not use >the BIOS) which is the important fact. I thought you were going to DROP this thread? I thought PALS were common in commercial deisgn, due to simplicity and flexibility(though some are later hard coded). Gee, you don't sound like a programmer here. ANY data in the BIOS is available from ANY mode! It just appears at a different address, that's all. >] : 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. Just like any of several 100s of thousands of such designs. I have seen LARGE companies build an ENTIRE product line of seemingly totally different radios(for example) on ONE PC board! >] 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. Obviously, a change in chipsets generally means a change in the PCB design. >] XFree86 had the means to work on the cards before Diamond >] released info. > >No, it did not. The XFree86 group specifically *refused* to >integrate the Sunsite patches into the XFree86 source base, >much in the same way David's posting starting this thread >stated that they would refuse to integrate patches based on >a reverse engineering of the Matrox card. They, as I, had/have the means, but chose for certain reasons not to use it. As you later admitted above. >Screw that. Companies make policy for economic reasons. There >was an economic reason for the policy. It wasn't an arbitrary >decision to intentionally decrease their potential market. It >was an economic trade-off, since the benefit of the policy >exceeded the benfit of the (slightly) larger potential market. You think THOUSANDS of cards in a given month is negligable! Incredible! As for economic reasons? If HP wasn't so popular, and the owner of one of the most popular command sets, I would have not bought, and recommended against, their printers. This would have, from me and DIRECT response, amounted to a loss of about $3000 in sales. Sidenote. Cannon didn't properly support me in the writting of software for their 4100, so I used the EPSON command set. The 4100 and the 200ex ARE, as advertised and to the degree I tried them, EPSON compatible. The BJC-210 is NOT! They gave me some song and dance about how there is NO base command set for epson, though I have used the NEC P5xl and Epson printers from the LX-80 to the DFX-5000(?), and several LQs, and ALL were compatible. Had they properly supported it, I might have used their BJ command set, and things might have worked everywhere. SO, I would have to recommend against that. I don't like 3 color printers anyway! If you want a color printer, go for FOUR color! BTW, this is ONE example of how the documentation was NOT correct! BTW Providing a basic command set would have reduced their support time, and a LOT of other expenses. This cost them probably over $15 for ME(just ONE person)! Companies are NOT filled with omniscient omnipotent beings. Some policies are just stupidity. >The Matrox policy that started this thread is based on the >assumption -- false, as it turns out -- that non-disclosure >will allow them legal remedy for reverse engineering. It will >not; reverse engineering is specifically allowed in EU countries, >even under the Berne Convention, for the purposes of documenting >interfaces to allow interoperability. This includes the >interoperability of drivers for the card with cards of other >manufacturers. Wouldn't it be funny if they sued a company for writing software that works with their card? Conversly, how could they find out if another companies card was compatible with theirs without doing what they don't want others to do? >You mean you need to code a card-specific table somewhere, and >you think that the place to do this is in the driver instead >of in memory that is already specific to the card. This is only needed in non standard modes, and by convention is NOT in the BIOS. It WOULD be nice if all provided 32 bit code there, but few, if ANY, do. Such code would have to be relocatable, provide for register based addressing, and likely support only ONE other mode. >That makes for a driver per card revision, doesn't it. Actually, setting the clock is done on intialization, along with a few character generator settings, and is a minor part. Also, there are many standards. >How bloody inefficient to require an OS to have 50 drivers >for 50 slight variations on the same card. Or an X Server >running on an OS. >I think you mean an EAROM, unless there is an over-voltage supply >for the erase that I don't know about. > >In both cases, the problem can be remedied in software by >identification of the offending card. Identification of an >ATI Mach 32 card can be accomplished, per the documentation >in the file: > > http://www.atitech.ca/dr/AP_NT_03.DOC > > >] 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. > >Whereas the fire-storm on the net resulting from their policy, >which resulted from the original *underdesign*, had no economic >impact on them whatsoever, you claim? > > >If I know I have a Diamond card (put the card probe recognition >code into a one-time run program that picks which card_driver.o >to link into the S3 server using "dlopen()"), then I can already >optimize. > >How do you thing X Inside, Thomas Roell's comapny, avoids making >users bang mode-lines? How about Windows 95, which assigns the >right card driver during install in the vast majority of cases. And makes the system almost USELESS in others. >It's a poor design that has to ask a human a question to get an >answer about itself. Sidenote. No programmer should assume that s/he can provide for EVERYTHING. Some "intelligence" built into VMS and win95 LIMITS its compatibility and flexibility! Further, as you had stated earlier, there is NO universal standard for identifying cards. Sadly, this creates a lot of problems. PNP is a good attempt, and hopefully WILL be universally adopted within the next decade. >Peeople can bum their own drivers, at that point, if they are >trying to steal an additional 8 pixels out of the monitor >overscan areas. For various reasons, companies often UNDERdrive their hardware. It is nice to be able to get it to work at full bore. >The Diamond problem was technical, and they've solved it (in >a different way than I would have solved the same problem, and >they lost out on flexibility I would not have lost out on as >a result, but they solved it). What flexibility? >The Adaptec AIC 7770 problem is probably much more analogous >the the Matrox problem that started this thread. Adaptec had >their software interface ripped off by competitors for the >154x/174x family of porducts and had their products commoditized >as a result. I thought they licensed it, like HP and EPSON. Anyway, they enjoyed a PRESTIGE position for quite a while because of it! MANY bought their card BECAUSE it was considered to be so compatible, etc.... I did that only about 2-2.5 years ago! >Similarly, the need to violate Matrox's patents to provide the >same programming interface (interface and physical contraints >dictate design) protects Matrox sufficiently that NDA is not >necessary to prevent their product from being commoditized >(which I think is their real worry; not that people will >be able to steal their design). GEE, OPEC seems to LOVE the idea that crude OIL is a "commodity"! XEROX and INTEL seem to like it ALSO. I don't know whether XEROX allowed xerography (the technique that almost ALL LED and LASER printers and copiers today use) to become PD or what, but they got a LOT out of it! If I sold a product that was a commodity, and I was the ONLY one that sold it, I would be sitting pretty in the catbird seat! >I'd argue that if I were a competitor, it's less expensive >for me to clean-room the interface than it is for me to come >up with my own, in any case, so you do not protect yourself >from hardware competitors, only from software. And thus >you limit your market. Actually, I could come up with a MUCH better interface than that used by any card I have EVER seen or heard of in just a few minutes! The hardware interface could be setup the SAME way as others, and could use an S3, say, with a programmable character generator connected to a "small" memory bank controlled through another register. VOILA, a card with ALL modes documented in the BIOS, compatible with others, capable of practically any character set(eight bit for simplicity sake though 8-( ), and you could have flat memory and real memory mode routines. Of course, the base real mode interface couldn't be extended for other capabilities, as industries tend to change it. Just the idea of a table in bios that has the mode, x max, y max, color, freq, i/ni,valid code would be a MAJOR improvement! Had that existed, I wouldn't have had to make ANY of these stupid calls. FURTHER, software could QUICKLY provide compatibility with all these cards. Have you looked at LINUX? It has a routine that has HUNDREDS of bytes to work with a FEW cards! That ONE SIMPLE idea, listed above would have reduced that to a few dozen bytes to support ALL cards! NOPE, I think this is ALWAYS easier to do yourself, ESPECIALLY when you have a base standard to build on! The protected mode interface could be done through a vector system, made to be VERY similar to the interrupt system! >] 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. > >The "big deal" it that this impacts your ability to sell to >people who "don't know what they are doing". MOST people that don't know what they are doing buy software that already works, and have another setup the system! >Exactly the problem for protected mode driver writers like the >XFree86 team... a problem which does not occur for people using >the BIOS interface, which, because the BIOS interface is badly >designed and VM86() facilities in free OS's are primitive, the >XFree86 team can not do. What is it with you and VM86? ESPECIALLY since you spoke of how this card was built for SPEED! >Other than the "I must take you down a peg to prove my unrelated >point", this has been an enjoyable discussion. 8-). Do you take an arrogant pill, or what?