home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!haven.umd.edu!darwin.sura.net!spool.mu.edu!agate!usenet.ins.cwru.edu!news.ysu.edu!psuvm!bjt105
- Organization: Penn State University
- Date: Sat, 19 Dec 1992 09:58:39 EST
- From: <BJT105@psuvm.psu.edu>
- Message-ID: <92354.095839BJT105@psuvm.psu.edu>
- Newsgroups: comp.os.os2.misc
- Subject: Re: Why not standard VESA
- References: <29437.1088.uupcb@satalink.com> <1992Dec19.070020.4266@netcom.com>
- Lines: 36
-
- A couple facts about the Video Electronics Standards Association (VESA):
-
- 1. The chairman is Scott Vouri (sp?), who is also president (and chief
- programmer) of Binar Graphics -- the company which is producing the
- 32-bit SVGA OS/2 drivers under contract. (also the people who produced
- the Winspeed drivers for window ... they get around!)
- If it were possible to utilize the real-mode VESA interface to write OS/2
- drivers, it would have been done.
-
- 2. VESA DOES HAVE a protect mode standard .. (v 0.7), which is called the
- Protect Mode Interface (PMI). This standard has just been updated to
- be completely compatable with OS/2's PMI file. I will admit that the
- utility of this standard has so far been nil, because support for a new
- chipset cannot be added just by writing a .PMI file for it. However,
- hopefully an implementation can be created which will allow this to
- happen for frame buffer boards (it won't ever happen for accelerators,
- unfortunately).
-
- 3. Reasons why real-mode VESA has not been useful for OS/2:
- a. There are time-critical sections of the session-switch code which
- can not rely on the 16-bit BIOS or TSR code. (BVHSVGA)
- b. VESA is useless in facilitating background execution of DOS programs.
- So, with a VESA driver, DOS background execution could not be allowed.
- (VSVGA)
- c. Performance for VESA would likely be unacceptable for PM, because it
- would mean an extra layer, and a thunk layer to 16-bit code at that.
- Also, nothing about refresh rates is included in the standard.
-
- I wish VESA were more useful, and maybe it could be with more thought.
- But, basically, the consumer must stop considering "SVGA" to be one thing,
- and start demanding compatability and responsibility from graphics board
- vendors. The alternative is new OSs like OS/2, linux, etc. will always
- require a hurculean effort to produce a new (and ever growing) set of
- SVGA drivers.
-
- Bernie
-