From:	Shawn Hargreaves <Shawn AT talula DOT demon DOT co DOT uk>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Refresh rates,VESA(30) and scitech
Date:	Thu, 5 Feb 1998 20:43:23 +0000
Organization:	None
Distribution:	world
Message-ID:	<IHRx1nArRi20EwZq@talula.demon.co.uk>
References:	<6bd2ao$hj6$1 AT cadmium DOT aware DOT nl>
NNTP-Posting-Host:	talula.demon.co.uk
MIME-Version:	1.0
Lines:	120
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Rick writes:
>I am sory to bother you with another question, but since allegro
>uses high res modes I was "forced" to look into my  trident cards
>failure for that 600*480( was only working for high color res!), etc.

I presume you mean the 640x480 resolution?

>What I discovered was not to nice: the trident drivers from
>www.tridentmicro need that you reset the refresh rates "blindly",
>so I dare to ask: does somebody know how programmatically reset the
>refresh rate for a vesa mode ?( I am looking at vesa 20 specs but
>didn't find anything useful).

I believe that VESA 3.0 has some functions for controlling the refresh
rate, but I haven't yet seen the spec so I can't give you any details.
This probably won't help you in any case, because you would have to
install UniVBE to get a VESA 3.0 driver (the hardware vendors will
probably take a few years to catch up with the new API). You really
shouldn't have to worry about this kind of crap, though, because when
you ask the VESA driver for a 640x480 resolution, it is in charge of
setting up whatever is required to make this mode work. If it can't do
that properly, the driver is badly broken and should be thrown away in
disgust :-)

>I would like to know how most people fixed this, and also what to 
>expect as a programmer if you find that a graphix card supports a vesa 
>mode. It seems to me that it is not entiraly true to expect the mode to 
>work too!

Sadly, that is all too true. Most hardware manufacturers produce very
poorly written and buggy VESA implementations, fail to test them in any
way, and then seem totally unconcerned about the resulting mess. I don't
know what we can do about this as programmers, other than just to cross
our fingers, hope that things will work correctly, and tell people to
install UniVBE if anything goes wrong :-) Writing register level drivers
for specific hardware can avoid the problem altogether, but it isn't
realistic to write special code for all the cards that are available
today. Despite a great deal of help from many dedicated people, Allegro
still only has hardware drivers for 10 of the more common chipset
families, compared to the 42 that are supported by UniVBE!

<offtopic rant>

A few years ago, the majority of VESA drivers didn't work properly, and
almost none of them supported the nice VBE 2.0 features like linear
framebuffer modes. Then along came a couple of big-name games like Duke
Nukem and then Quake, which used VBE 2.0 as their default graphics mode,
and all of a sudden the hardware vendors woke up and realised that their
drivers didn't work with these games. This was obviously a Bad Thing,
and almost overnight people like ATI and Tseng came out with a new batch
of VBE 2.0 implementations that fixed a lot of their earlier problems.
But they cut a lot of corners, because their brief was to "make this
work properly with Quake", rather than "make this properly conform to
the VESA standard". Unfortunately Quake doesn't use things like the
hicolor and truecolor modes or any kind of retrace synchronisation, so
the driver people never bothered to make those work correctly. The
commercial games industry has now moved across to Windows and DirectX,
so there is no longer any pressure for these problems to be fixed, and
the vendors seem to have just gone back to sleep. I find this immensely
frustrating, and at times I start to fantasise about what I could do if
I got the guy who wrote the S3 driver alone in a room full of medieval
torture implements...

Sorry about that :-) But I get on average four or five mails a week from
people having VESA problems, and I get very tired of explaining that it
probably isn't my bug at all, and the only way they can fix it is to
shell out the $$$ for a copy of UniVBE.

</offtopic rant>

>there is a package from scitech that is by far the best in this arrea, 
>because it allows you to set the refresh rates modewise, because it 
>supports VESA30 and because it supports VESA/AF, but it is timelimited. 

SciTech are the best. UniVBE is pretty much the only thing that is
keeping DOS viable as a platform for high performance graphics, and I
would be totally stumped without them.

Incidentally, you can license the UniVBE code and link it directly into
your program, to make sure that a decent driver will always be
available. I don't know the details of this (I suspect you would have to
pay them a great deal of money!) but that might be a good option if you
are making a commercial game. I seem to remember hearing that Warcraft
used this approach.

>If such a package existed as freeware/shareware then maybe 
>gameprogrammers could assume that all vesamodes would work, so my 
>question is: is anyone doing this, and/or does anyone has intimate 
>knowledge of all kind of graphix cards and the way to put them into 
>vesa30 ??

If you can make such a thing, I will love you forever! But be warned
that it is a _huge_ project. You should expect to spend several years
working on it, and will probably need to buy a couple of hundred
different types of graphics card for testing.

Of course, there are probably a lot of people on the net who would love
to help with such a project. But there aren't all that many who have the
ability to write a really reliable driver, and you will probably find
that almost all of those own either an S3, Cirrus, Tseng, ATI, or
Trident board, so you will have real problems getting support for the
more obscure hardware. I hate to sound so pessimistic and would love to
be proven wrong about this, but my personal experience with Allegro
shows that even given a large userbase full of capable and enthusiastic
contributors, getting robust and comprehensive hardware support is very
difficult, possibly verging on the impossible...

In terms of borrowing code from other places, XFree86 has drivers for a
lot of different hardware. I haven't looked at these in any detail, but
if you are going to start a project like this, that would probably be a
good place to begin. The VGADOC package (on x2ftp) also has a lot of
technical information and Pascal code, which seems to be about 95%
correct although I have encountered a few subtle errors here and there.

Good luck!


--
Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
"Pigs use it for a tambourine" - Frank Zappa

- Raw text -