home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / os / os2 / misc / 39977 < prev    next >
Encoding:
Text File  |  1992-12-21  |  6.9 KB  |  131 lines
  1. Newsgroups: comp.os.os2.misc
  2. Path: sparky!uunet!spool.mu.edu!umn.edu!csus.edu!netcom.com!samiam
  3. From: samiam@netcom.com (Scott Moore)
  4. Subject: Re: Why not standard VESA
  5. Message-ID: <1992Dec19.070020.4266@netcom.com>
  6. Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
  7. References: <29437.1088.uupcb@satalink.com>
  8. Date: Sat, 19 Dec 1992 07:00:20 GMT
  9. Lines: 120
  10.  
  11. bert.tyler@satalink.com (Bert Tyler) writes:
  12.  
  13. >Forgive me for responding to a message here that really has little to
  14. >do with OS/2, but as a person who occasionally writes VESA TSRs for
  15. >IBM, I just couldn't let this one go by without a response...
  16.  
  17. Teed you off eh ? I'll have to point by point this one as well !
  18.  
  19. >Useless?  You have the "right" to make any claim you want, but this
  20. >one is way off the mark.  Virtually every SuperVGA adapter sold today
  21. >comes with VESA either on the BIOS or as a TSR.  IBM ships PS/2s with
  22. >SuperVGA adapters(*) with MS-DOS SuperVGA modes accessible *only* via a
  23. >VESA TSR (the ValuePoints ship with video adapters accessible via both
  24. >VESA and chipset-specific methods.)  Many SuperVGA MS-DOS apps
  25. >(Links386 Pro is an example, Microsoft C 7.0's graphics libraries are
  26. >another) support SuperVGA *only* for VESA-compliant adapters.  Others
  27. >check for VESA-compliance first, and chipset-specific implementations
  28. >afterwards (the problem with chipset-specific implementations is that
  29. >they tend to work with this week's chipsets, but not with the ones that
  30. >get released next week).  Hardly a textbook case of the term "useless".
  31.  
  32. Yes, adapter support of the VESA standard is basically universal at this point.
  33. Just as univeral is the software writer's avoidance of it. Many cards also
  34. come with a TSR that supports the "8514" standard, which if you remeber was the
  35. all software interface to the 8514 board. Anyone out there using that thing ?
  36. The important programs have virtually bypassed VESA, such as AUTOCAD and 
  37. windows itself.
  38.  
  39. >(*) The PS/2 model 25SX, 35, 40, 56, ThinkPad 700C and others, using
  40. >the PS/2 25SX VESA driver (available in Compuserve's IBMPRO forum in
  41. >Library 12 (VESA), filename IBMVES.ZIP).  There's also a freeware VESA
  42. >TSR for the XGA adapter (same Compuserve library, filename XGAVES.ZIP).
  43. >I have seen nothing indicating that IBM's commitment to the VESA standard
  44. >is dying off.
  45.  
  46. Since IBM claims to be commited to OS/2, and os/2 has nothing to do with VESA,
  47. I have to wonder about that. But I don't remeber saying anything about IBM.
  48.  
  49. >Maybe you meant to say "Useless in terms of GUIS like OS/2 when those
  50. >GUIs aren't running DOS sessions".  That I would agree with at the moment.
  51.  
  52. >SM>    [discussing bank-switching:]
  53. >SM>      Now, I could stop right there, and any programmer worth his salt
  54. >SM>will tell you that a high speed driver does NOT stop to make an OS call
  55. >SM>whenever a change of vga memory location is required. I believe that
  56. >SM>this fact alone has kept the VESA standard from spreading even in DOS mode
  57.  
  58. >See above.  Under MS-DOS, VESA bank-switching is just as fast as
  59. >chipset-specific bank-switching - in fact, the DOS App just makes a
  60. >far call to what is, in effect, the VESA driver's implementation of
  61. >a chipset-specific bank-switching routine.  (There's also a VESA BIOS
  62. >call supporting bank-switching, but any DOS programmer concerned about
  63. >speed and "worth his salt" avoids that overhead and uses the direct call.)
  64.  
  65. And there is the core of the matter. That direct call is useless with anything
  66. but a true blue DOS app. In my 32 bit adapter/extender days (before os/2),
  67. I was able to call all the VESA functions but that one. That, plus the
  68. requirement to pass the driver an address to a parameter buffer (which any
  69. junior os textbook will tell you is trouble) made creating even a SLOW driver
  70. for VESA impossible. I talked at length with VESA about this problem, 
  71. proposing several solutions (such as providing a 32 bit version of the 
  72. direct call), and was basically told that 32 bit programs were not 
  73. representative of the mainstream. VESA is supposed to plan for the future, not
  74. intrench the past.
  75.  
  76. >SM>(for instance, why is there no windows driver for VESA ? windows is
  77. >SM>perfectly capable of using VESA BIOS calls).
  78.  
  79. >There is no incentive for a chipset manufacturer to write a Windows
  80. >(or OS/2) VESA driver, as it would work on his competitors' chipsets
  81. >as well.  Not the cleverest marketing move in the world.  A Windows
  82. >(or OS/2) VESA driver *is* technically possible.  Realistically, though,
  83. >the only vendor with any incentive to build one is the vendor selling
  84. >the GUI itself (Microsoft for Windows, IBM for OS/2).  Also, any
  85. >protected-mode GUI using the current real-mode VESA standard would
  86. >suffer performance penalties due to the need to switch to real mode
  87. >to perform any bank-switching (there is a protected-mode VESA standard
  88. >in the works, but we're all talking about the real-mode version that's
  89. >been around for awhile).
  90.  
  91. Man, you really doged that one. If VESA was so great, microsoft could have
  92. simply output windows with a VESA driver built in, and that would have
  93. been the end of it. They did not because it would have been a DOG.
  94. Do you really think that microsoft would not have avoided the video driver
  95. wars if they could have ? remember that win 3.0 drivers were hard to get
  96. as well.
  97.  
  98. >OS/2 (and Windows NT as well) has the additional problem that most VESA
  99. >drivers ship today in the form of DOS TSRs, making them unusable for OS/2
  100. >video drivers.  If IBM provided a VESA-based OS/2 video driver and
  101. >Microsoft provided a VESA-based Windows 3.1 driver, IBM would be in the
  102. >embarrassing position of having to explain why their VESA driver didn't
  103. >work on systems which worked with Microsoft's VESA driver.  They would
  104. >have an excellent technical explanation, but it would still not be a good
  105. >image situation - and image is important.
  106.  
  107. Your ending wrapup ^^^^^^
  108.  
  109. Mine:
  110.  
  111. VESA could have avoided all this nonsense by simply standardizing a single
  112. bank selection port, that, duuuuhhhhh, selects which video page is active.
  113. They could have issued that along with the software standard. Yea, the chip
  114. makers would have screamed. But if enough programs come out to that standard,
  115. they would have gotten in line rapidly.
  116. The unfortunate result has been that SVGA goes virtually unsupported in the
  117. DOS enviornment. Please don't send me a list of VESA programs. Instead,go
  118. down to your local software store and look at side panels. Then tell me how
  119. many off the shelf applications support SVGA. Further, of those that do, 
  120. how many list each adapter they support individually ?
  121. Compare this to the virtual market sweep of VGA and I think I am justified in
  122. calling the situation sad (but probably not VESA's fault).
  123.  
  124.                                                     [sam]
  125. -- 
  126. Scott A. Moore [SAM]  | "Cash is more 
  127. samiam@netcom.com     | important than your 
  128. Santa Cruz, CA USA    | mother"
  129. 408-423-1624          | Allan Shugart - CEO Segate Corp.
  130. ------------------------------------------------------------------------
  131.