From: bert.tyler@satalink.com (Bert Tyler)
Newsgroups: comp.os.os2.misc
Subject: Re: Why not standard VESA
Date: 18 Dec 92 12:14:00 GMT
Reply-To: bert.tyler@satalink.com (Bert Tyler)
Organization: Datamax/Satalink Connection * Ivyland, PA (215) 443-9434

Forgive me for responding to a message here that really has little to
do with OS/2, but as a person who occasionally writes VESA TSRs for
IBM, I just couldn't let this one go by without a response...

 samiam@netcom.com (Scott Moore) writes about VESA:

SM>Since I was one of the folks (desperately) trying to tell VESA that an all
SM>software standard was a big mistake, I believe that I have earned the right
SM>to call that standard as useless as it truly is.

Useless?  You have the "right" to make any claim you want, but this
one is way off the mark.  Virtually every SuperVGA adapter sold today
comes with VESA either on the BIOS or as a TSR.  IBM ships PS/2s with
SuperVGA adapters(*) with MS-DOS SuperVGA modes accessible *only* via a
VESA TSR (the ValuePoints ship with video adapters accessible via both
VESA and chipset-specific methods.)  Many SuperVGA MS-DOS apps
(Links386 Pro is an example, Microsoft C 7.0's graphics libraries are
another) support SuperVGA *only* for VESA-compliant adapters.  Others
check for VESA-compliance first, and chipset-specific implementations
afterwards (the problem with chipset-specific implementations is that
they tend to work with this week's chipsets, but not with the ones that
get released next week).  Hardly a textbook case of the term "useless".

(*) The PS/2 model 25SX, 35, 40, 56, ThinkPad 700C and others, using
the PS/2 25SX VESA driver (available in Compuserve's IBMPRO forum in
Library 12 (VESA), filename IBMVES.ZIP).  There's also a freeware VESA
TSR for the XGA adapter (same Compuserve library, filename XGAVES.ZIP).
I have seen nothing indicating that IBM's commitment to the VESA standard
is dying off.

Maybe you meant to say "Useless in terms of GUIS like OS/2 when those
GUIs aren't running DOS sessions".  That I would agree with at the moment.

SM>    [discussing bank-switching:]
SM>      Now, I could stop right there, and any programmer worth his salt
SM>will tell you that a high speed driver does NOT stop to make an OS call
SM>whenever a change of vga memory location is required. I believe that
SM>this fact alone has kept the VESA standard from spreading even in DOS mode

See above.  Under MS-DOS, VESA bank-switching is just as fast as
chipset-specific bank-switching - in fact, the DOS App just makes a
far call to what is, in effect, the VESA driver's implementation of
a chipset-specific bank-switching routine.  (There's also a VESA BIOS
call supporting bank-switching, but any DOS programmer concerned about
speed and "worth his salt" avoids that overhead and uses the direct call.)

SM>(for instance, why is there no windows driver for VESA ? windows is
SM>perfectly capable of using VESA BIOS calls).

There is no incentive for a chipset manufacturer to write a Windows
(or OS/2) VESA driver, as it would work on his competitors' chipsets
as well.  Not the cleverest marketing move in the world.  A Windows
(or OS/2) VESA driver *is* technically possible.  Realistically, though,
the only vendor with any incentive to build one is the vendor selling
the GUI itself (Microsoft for Windows, IBM for OS/2).  Also, any
protected-mode GUI using the current real-mode VESA standard would
suffer performance penalties due to the need to switch to real mode
to perform any bank-switching (there is a protected-mode VESA standard
in the works, but we're all talking about the real-mode version that's
been around for awhile).

OS/2 (and Windows NT as well) has the additional problem that most VESA
drivers ship today in the form of DOS TSRs, making them unusable for OS/2
video drivers.  If IBM provided a VESA-based OS/2 video driver and
Microsoft provided a VESA-based Windows 3.1 driver, IBM would be in the
embarrassing position of having to explain why their VESA driver didn't
work on systems which worked with Microsoft's VESA driver.  They would
have an excellent technical explanation, but it would still not be a good
image situation - and image is important.

                   Bert Tyler   (bert.tyler@satalink.com)
---
 . DeLuxe./386 1.25 #343sa . Your mileage may vary.  Your car may not run.
     
Xref: sparky comp.os.os2.misc:39674 comp.sys.ibm.ps2.hardware:2249