From: Shawn Hargreaves Newsgroups: comp.os.msdos.djgpp Subject: Re: FreeVBE ? Date: Thu, 26 Mar 1998 21:24:36 +0000 Organization: None Message-ID: References: NNTP-Posting-Host: talula.demon.co.uk MIME-Version: 1.0 Lines: 171 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk 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