Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!u.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Newsgroups: comp.os.386bsd.misc Subject: Re: FreeBSD 1.0R, XFree-86 2.0, and Diamond Speedstar Date: 30 Dec 1993 02:26:59 GMT Organization: Weber State University, Ogden, UT Lines: 61 Message-ID: <2fte9j$59s@u.cc.utah.edu> References: <2fqcdg$isp@ulowell.uml.edu> <1993Dec29.041309.17997@pool.info.sunyit.edu> <CIt0rC.F49@usenet.ucs.indiana.edu> NNTP-Posting-Host: cs.weber.edu In article <CIt0rC.F49@usenet.ucs.indiana.edu> pitts@mimosa.astro.indiana.edu (Jim Pitts) writes: >>: >I am having trouble with getting XFree-86 2.0 running on my FreeBSD 1.0R >>: >system. I have a Diamond Speedstar ET4000 card. No Plus, no II, no 24, just >>: >Speedstar. The monitor is a ADI MicroScan 3E >> >>: Whoops...correction...it IS a Speedstar Plus... >> >>Diamond video cards suck! [ ... ] >Diamond video cards do not suck. They just don't support the software you >want the way you want it supported. As far as video cards go they are >actually very nice. Your problem is with a lack of free support for the >product, not a technical problem with the card itself. Actually, there is a minor technical problem that is *why* the programming information is not generally available -- Diamond wants to be able to change the PALs, and that implies a change to the BIOS (or the program that is trying to directly program the clocks) at the same time. Diamond can only guarantee a match between the PALs and the BIOS clock setting code; the *CAN'T* guarantee a match between the PALs and your (free and probably older than both the PALs and the BIOS) clock setting code and/or seperate program. Of course, the problem is biting or going to bite the user in NT and OS/2 and probably Chicago, as well... so supporting the alteration of PALs by making the BIOS/PAL interaction hidden is NOT a good thing, unless they go on to make their BIOS work in both protected and non-protected mode (there are some ethernet cards which do this, for instance). This is not likely to happen, since the far instead of near references and the base register reloading and unloading will give a performance hit to their DOS users -- their primary market. I don't know what Diamond plans to do with NT and OS/2, other than either not support them or ship their own drivers and make sure they also match the PALs on the particular card. Ideally, from a free software standpoint, you wouldn't want to let them change their PALs, so that the same clock programming code would work from card to card (same goes for "ideally" from the NT and OS/2 perspectives as well). >Of course as an owner of Diamond products I am hurt by this messy situation, >but those are the breaks. I chose to buy Diamond. I hope that in the >future Diamond will see that guarding the programming of their clock chips >is not necessary. When this happens I also hope the XFree86 team will be >willing to admit when they have won a battle. I am not holding my breath. Definitely don't; even if they provide the information in the future as to *how*, the specific *values* will vary from PAL rev to PAL rev -- a card probe or BIOS is the only consistant way to deal with it. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.