home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / os / os2 / misc / 40050 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  2.3 KB

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