Mail Archives: djgpp/1998/03/27/22:43:59
Bjorn De Meyer writes:
>That is why I'm wondering if anybody is working on a free VESA 2 driver
>which replaces Univbe?
Replacing UniVBE is a huge task, because it supports a lot of different
chipsets! But this is a laudable task, and I would love to see such a
project take shape.
>If there's no-one working on this, I might be interested in programming
>such a driver myself, with the intention of making it work with
>Allegro. (When i find some time :|) The question is then: where can I
>find the required documentation (without having to pay tons of money to
>the VESA organisation)?
From the VESA end, all the information you need can be found in the
official VBE 2.0 specification (available from www.scitechsoft.com).
When it comes to programming your specific hardware, the best reference
is VGADOC (ftp://x2ftp.oulu.fi/pub/msdos/programming/docs/vgadoc4b.zip).
I think you will find it very hard to write a VESA driver with djgpp,
because VESA is a 16 bit real mode API. You could perhaps do it with
djasm, or the 16 bit gcc from DJ's site, but that would be making life
extremely difficult for yourself. IMHO it would be much more sensible to
find a real mode compiler like Borland C.
But there is another possibility. I've recently been working on a VBE/AF
driver for Allegro (preliminary version on my website), and this seems
like something that would be much less complex to implement with djgpp.
A VBE/AF driver is a disk file containing a block of relocatable 32 bit
code, and it provides all the same features as VESA 3.0 plus support for
a range of hardware accelerated drawing routines.
As it happens (isn't it is odd the way related things always seem to
show up at the same time?) I've just written a long message about this
exact topic to the Allegro mailing list, so I will repeat it here. My
apologies if you end up seeing this rather long message twice, but it
seems like an appropriate response to this question...
----------------------------------------------------------------------
[forwarded message from allegro AT mail DOT canvaslink DOT com: this was in
response to Ove Kaaven mentioning the possibility of writing an
accelerated Mach64 driver]
Periodically someone raises the idea of a loadable driver structure,
which so far I have resisted on the grounds that it would be too
complex, more files to distribute along with the program, and a waste of
time because most of the current drivers are very small (look at
something like s3.c: it is only a few lines of code). Once we start to
add hardware accelerator support, though, an external driver system
starts to look much more attractive. I'm sure I don't need to list all
the advantages here: it is patently the Right Thing for any large and
complex hardware support module.
Designing a good interface is a huge task, but in this case we have an
existing one staring us right in the face: VBE/AF. I have been very
impressed with this system, and think it could be very effective to
provide accelerated drivers in the form of vbeaf.drv files, supporting
multiple cards via the single internal /AF driver.
Advantages of using VBE/AF
--------------------------
- As an external standard, it would be possible to use these drivers
with other programs than just Allegro. At present not many things
support /AF, but hopefully this will change in the near future. Most
interesting, an /AF driver has the potential to be binary compatible
across multiple operating systems, and I have heard some talk about
it being supported by the XFree86 and Linux GGI projects.
- It is a clean and efficient design, easy to use, and almost
certainly just as good if not better than anything I could come up
with myself.
- Since it was designed by SciTech, VBE/AF provides is a good
abstraction of the capabilities of a wide range of different
hardware. We don't have information about nearly so many chips, so
if we were to make an interface of our own, we would run the risk of
it being slanted towards the particular cards that we knew about at
the time, and less easily scalable to future hardware.
Disadvantages of using VBE/AF
-----------------------------
- The official specification is only available by paying large sums of
money to the VESA people. This is incredibly stupid of them, because
it has effectively prevented the standard from being supported by
most developers, but I don't think it will be a problem for us. The
MGL source is freely available, and I found their /AF code very easy
to understand, so I didn't have much problem combining that with
info from a very early copy of the VBE/AF 1.0 spec to come up with a
working driver. Armed with my current knowledge, I think I can write
a framework that will let other people implement /AF systems without
needing to refer to any official specs.
Note: this ridiculous situation is likely to change in the future.
SciTech are working on a replacement API called Inertia, which will
be very similar to VBE/AF (it will be trivial to convert existing
/AF code to use Inertia), but it will be their property rather than
belonging to the VESA association, so they will be able to freely
document it.
- A VBE/AF driver would be less specific to the needs of Allegro, so
there may be some things that we could do more easily with a custom
driver format. But overall I'm not sure this is such a bad thing:
given a choice between the general and the specific, it may be
easier to use the latter, but the former is usually a better
solution in the long run...
- VBE/AF is quite a bit more complex than what we would really need.
But to start with at least, we wouldn't need to implement a full
version of the standard, just the parts that are actually used by
Allegro (for example the page flipping functions are redundant,
because Allegro uses the scroll routine to access this
functionality.
How to make a VBE/AF driver
---------------------------
Step 1: find a way to link code into a suitable binary format
Step 2: implement a VBE/AF compatible driver interface
Step 3: add hardware support for specific chipsets
If someone else will tackle the first step, I will undertake to do the
second. This can then be released as a stub driver implementation, at
which point anyone who feels so inclined will be able to fill in the
dummy functions to make it support a particular card.
A VBE/AF implementation consists of a single binary file called
vbeaf.drv. This will be written mainly in C, but some portions will
require a small amount of asm. It cannot call any library functions (not
that it would need to), and any static data must be output explicitly
(if you declare a global "char pad[200]", this should produce 200 zeros
in the binary file, rather than just being allocated at runtime). A
specific structure must be placed at the beginning of the file, which
contains a few ID flags and some pointers to initialisation routines
(stored as offsets from the start of the file). The first step in
loading the driver is to call the first of these functions (the user
must manually add the offset from the header to the address at which
they loaded the driver), passing it a pointer to the driver base address
as a parameter. This init routine then has a chance to perform any
relocation that is required, after which various other functions from
the header may be called using normal C syntax.
I have no idea how to implement this in djgpp: possibly some tweaking of
the linker script, or perhaps by modifying the DXE code? (the two things
seem very similar).
If anyone can set such a thing for me (a way to produce a binary file
with header structure, and an init routine which will relocate the rest
of the C code in the driver), I will turn it into a framework for a
VBE/AF implementation. I can't promise to make it fully compliant with
the official specification, but I can at least implement all the
routines which are used by Allegro, and provide a few basic video modes
(say 640x480, 800x600, and 1024x768) by calling VESA functions to do the
actual work. I'll provide stub routines for all the other accelerated
functions, so anyone who is interested can then fill these in with
chipset specific code for particular cards.
Does this seem like a useful or workable idea? I'm game for it if you
are...
--
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 -