Date:	Mon, 25 Jan 93 14:00:52 CST
From:	(csaba AT vuse DOT vanderbilt DOT edu) <csaba AT vuse DOT vanderbilt DOT edu>
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Re: VESA driver development

On ,
  <> writes:

[ Sorry -- our mailer somehow lost the sender's address]

>
>After getting some messages I assume that:
>1. No VESA driver exists
>2. I will get your blessings to create one with any >=256 capability.
>
>If above is true, here is a short summary of what I know and what
>I am planning to do. HELP and COMMENTS INVITED.
>
>  Most of todays VGAs are VESA compatible - this includes new Tsengs,
>Trident 8900 with BIOS v >=3.00, and really NEW boards, like the one
>I am currently falling in love with, Cirrus AVGA3 (CL-GD5422). For all
>older boards you can get a software VESA driver, so it really looks
>like a standard. VESA supports any direct color modes, including
>32K, 64K, 16M (currently implemented) and anything one can imagine.
>Mode numbers are standarized as well as mode switching and bank switching.
>
>  After analyzing GO32 and driver code I found two problems:
>1.(this can be false) The variable holding no. of colors inside graphics
>driver is 16 bits long, and cannot express neither 64K nor 16M. It would
>be much nicer if its meaning was "bits per pixel" - single byte would be
>enough (even for Silicon Graphics systems with >120 bits :-) ).


The 16 bit number in the driver header actually encodes
various driver features on bitfields. There are still a couple unused bit 
combinations in the bitfield which describes the number of colors.


>2.(The REAL problem) Bank switching can be done in one of two ways:
>- by invoking int 10h,
>- by calling real mode function with 16 bit far return (faster),
>under current circumstances (the architecture of go32 and its graphics
>interface) none of these methods can be used.
>It seems to me that the simplest method would be as follows:
>- use new graphics driver interface,
>- create extended real mode init function, getting all the necessary VESA
>  parameters,
>- create special bank switching code segment descriptor in GDT during
>  graphics driver init - this would be possible if we can slightly extend
>  the extended graphics driver interface (.grn),
>- call the function in paging routine, depending on flag set by init
>  (either old-style, simple one or the new, with its own descriptor).
>The bank switching routines in VESA BIOSes I examined so far are
>very well-behaved and can work in protected mode. This is not a VESA
>feature, but it seems to be dependable. Anyway, we are hackers...
>
>The first thing I tried was to call int 10h from graphics driver's 
>bank switching routine. I wasn't surprised with the result (or rather
>no result), but let me ask a question: Why not allow "int xx" passing
>from any context to DOS?


I also looked at this problem when I tried to create a VESA driver for GRX. 
I think GO32 could easily be modified to allow the graphics driver's 
(protected mode) page switching function to invoke the proper VESA int 10h 
function. The real problem with this approach is performance. Imagine the 
cost of two (or possibly four if you have to make two VESA calls to remap 
both the read and write page) real/protected mode switches per 64K boundary 
crossing in your graphics code. DJ must have had some pretty good reasons 
to include a protected mode "shortcut" in GO32 for graphics page faults!

HERE COMES THE BIG QUESTION:

Does anyone know if the far call version of the VESA page mapping function 
can be used in protected mode? My VESA doc does not say anything about 
this. However, I can confirm the statement made by the previous poster. I 
have traced the far call versions of the page switching code in three 
different VESA BIOS-es. (TSR-s for Tseng ET4000 and Trident 8900, and 
one ROM BIOS for the Diamond Stealth.) Typically, the VESA BIOS page 
switching code is very small. (as expected) I did not see anything in the 
code which would make it incompatible with 16-bit protected mode. The only 
requirement seems to be to set up the following 16-bit protected mode 
segment descriptors: 

   one for CS => mapping the segment part of the far pointer returned by 
                 the VESA BIOS as the entry point of the far call page
                 mapping function.

   the protected mode selector 0x40 has to be mapped to the BIOS data
                 segment at 0x400. This is necessary because some
                 VESA page switching functions seem to access data in this
                 area. (This mapping is automatically performed
                 in most of the commercial DOS extenders)

If someone with a more recent/detailed VESA documentation could provide 
info about the protected mode usability of the VESA paging function I could 
try to come up with a "universal" VESA driver and with the code to provide 
the necessary additional segment mappings in GO32. 

Conversely, if our theory about protected mode VESA paging gets disproven, 
at least we can put the matter to rest. [8-(] I find it hard to believe 
that the creators of such a recent standard as the VESA BIOS did not think 
about the protected mode usage of the most performance-critical part of 
their interface....

>
>That's all for today... I wait for your comments.
>If anyone is interested, I can post my vesa graphics C module,
>containing mode switching, putpixel and putimage functions.
>It works with Watcom C 386 and Borland, and sometimes with DJGPP, using
>any mode to 1024x768x256, 800x600x32/64K & 640x480x16M.


Csaba Biegl
csaba AT vuse DOT vanderbilt DOT edu

- Raw text -