DP Tool Club 17/CD_ASCQ_17_101194.iso/dos/games/lw2sw/lw2sw.z01/UNIVBE41.ZIP/XGAVES.ZIP/XGAVESA.DOC

Text File | 1991-12-16 | 8KB | 166 lines

             (sort of) VESA-Compliant TSR for the IBM XGA Adapter
                            version 1.2

                Another freeware utility by Bert Tyler
                       Compuserve ID:  73477,433
                           BIX ID:  btyler


WHAT'S NEW IN THIS RELEASE?

(I'm going to answer this question first, because this is the only
question that those of you who are using an earlier release of this
package are gonna ask)

Release 1.2 adds support for the VESA 1.2 spec and its "true-color"
modes - in particular, mode 111h (640x480x65536-color) that seems to
have been designed especially for XGA-like adapters.

Also, this release supports the non-standard (at least as far as IBM is
concerned) 800x600 mode only if you fire it up with the '800' option
('xgavesa 800').  Earlier releases supported that mode unless you
specifically fired them up with a '-800' option, and in retrospect
that was not a good approach.  This version cheerfully ignores any
'-800' option, as that's what is was going to do anyway.


WHAT DOES THIS PROGRAM DO?


XGAVESA is a TSR that (sort of) makes your XGA adapter VESA-compliant
(the "sort of" clause is explained in detail below, and is related
to the fact that the XGA adapter has some basic incompatibilities with
the VGA Video DAC and vertical retrace signals when it is in its
XGA-specific video modes).

The reason for this TSR's existence is simple:  many software packages
out there in the MS-DOS world currently have drivers for VESA-compliant
video adapters but not for IBM's XGA adapter.  This TSR is an attempt
to address that situation, by translating standard VESA calls into
routines that IBM's XGA adapter understands.


WHAT VIDEO MODES AND VESA CALLS DOES THIS PROGRAM SUPPORT?


This TSR supports the following standard VESA modes:

   VESA mode           Description

   109h                132-column by 25-rows text mode
   101h                640x480x256 graphics mode
   103h *              800x600x256 graphics mode (requires a multisynching
                       video monitor)
   105h **             1024x768x256 graphics mode (requires a high-resolution
                       video monitor and 1024K of memory on the adapter)
   111h **             640x480x65536 graphics mode (requires 1024K of
                       memory on the adapter)

   *  (The program reports support for this video mode only if you
      have fired it up with the '800' option.  Note that this is
      different from earlier versions, which supported this mode unless
      you specifically told it not to using the '-800' option.  There
      is no way for the program to auto-detect the presence of a
      multisynching monitor.)

   ** (The program reports support for this video mode only if it detects
      that the appropriate hardware exists for it.)

XGAVESA supports all of the VESA calls defined in version 1.2 of that
spec.  Given that VESA versions are downward-compatible, that means
that XGAVESA also supports all of the VEAS calls defined by earlier
versions of the VESA specs.

This TSR does not currently support any of the XGA adapter's 16-color
SuperVGA modes.  Adding support for the XGA's 800x600x16 and 1024x768x16
modes would have been trivial, but the XGA does *not* use the standard
EGA/VGA style of pixel addressing when it is in those modes (the XGA's
"packed pixel" method of handling 16-color modes is better, IMHO, but in
this case the word "different" has more impact than the word "better").
Furthur, the responses to a query I posted on various VESA forums indicated
that there is no general consensus as to how most VESA drivers would
attempt to handle a "16-color packed-pixel" VESA mode, so I simply
left those modes out of this release.

When it is first fired up, XGAVESA attempts to detect the presence of
your XGA adapter and determine the amount of memory on your adapter and
the type of monitor to which it is connected.  If it can't locate any
XGA adapter, the program errors out - otherwise, it displays a sign-on
banner, sets itself up to support the VESA modes supported by your
particular hardware and goes TSR.


WAIT A MINUTE - THE XGA SUPPORTS 800x600?


Yup - piece of cake.  Maybe your IBM manuals don't mention it, but
that's probably only because IBM doesn't make a monitor that supports
that particular resolution.  This particular resolution *does* require
the presence of a monitor that supports 800x600 resolution, though, such
as a multisynching monitor like the NEC 2A/3A/4A/5A.

One limitation that the program currently has is that there is no way
to automatically detect the presence or absence of a multisynching
monitor attached to an XGA adapter.  For now, the program just assumes
that you do not have a multisynching monitor that supports the 800x600x256
mode unless you fire it up with the '800' option ("xgavesa 800").
Earlier versions of this program supported that mode unless you specifically
disabled it with the '-800' option, and in retrospect that was not a good
approach - A few of the VESA programs I tried this program out on
automatically use the highest resolution the VESA driver supports, and
if your hardware can't handle 1024x768x256 mode, that's going to be
800x600 unless that particular mode is disabled.  The current version
cheerfully ignores any '-800' option, as that's what it was going to
do anyway.


WADDYA MEAN "SORT OF" VESA-COMPLIANT?


Well, actually, the XGA adapter with this TSR is totally VESA-compliant.
The problem is that the current version of the XGA adapter in its
XGA-specific video modes isn't totally VGA-compliant, and many programs
make assumptions about VGA-compliance that don't work with the XGA
adapter.  (The XGA adapter is totally VGA-compatible when it is in
VGA mode, but not even close to it when in its XGA-specific modes.)
The worst-case scenario is total lockup and Big Red Switch time.

The two problems I have run into are both related to programs which
attempt to update the VGA's Video DAC via direct hardware writes
(and yes, my own Fractint program is one of them).

1) The XGA video DAC is completely different from the VGA video DAC,
and any attempt to update the "VGA's" Video DAC via direct hardware
while the XGA is in an XGA-specific mode has no effect.  If a
program goes through the BIOS to update the Video DAC, all is well
(the XGAVESA program traps the INT 10H, AH=10h interrupts and either
translates those BIOS calls and data into information that the XGA
adapter can understand or "eats" them).

2) The XGA does not support the VGA's vertical retrace hardware
signals when it is in its XGA-specific modes, and any program that
attempts to wait for a VGA-style vertical retrace ends up locking
up the system.

Here is a short list of VESA-compliant programs that have been tested
with XGAVESA, and the results:

   VPIC 4.5        works (version 4.5 of VPIC added its VESA drivers)
   MVGAVU 5.0      works
   VUIMG 3.14      works
   PV 0.5          works ("Persistence of Vision" is the successor to the
                   DKB raytracer program)
   CSHOW 8.3       works *if* invoked with the "+V" option that forces it
                   to avoid the vertical retrace wait and go through the BIOS
                   (if you have a registered copy, the CONFIG program supplied
                   with CSHOW lets you hard-wire this option into the program)
                   ((On the other hand, CSHOW 8.3 offers direct XGA support
                   that is far better than using this XGAVESA driver))
   VGAKIT 3.5      works (once I fixed the VESA driver in release 3.5 <grin>.
                   Uncomment out the 'jmp fini' statement just prior to
                   the 'novesa:' label in BANKS.ASM)
   ORSON 3         works (ORSON2 failed because of a bug in that program)
   FRACTINT 16.11  fails  (looks for the vertical retrace)
                   ((On the other hand, Fractint offers direct XGA support
                   that is far better than using this XGAVESA driver))