home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.96 / text2006.txt < prev    next >
Encoding:
Text File  |  1996-07-25  |  3.5 KB  |  73 lines
  1.     id m0tuhUw-0007r2a; Thu, 7 Mar 96 08:20 MST
  2. Sender: owner-executor
  3. Received: from gwar.ardi.com by ftp.ardi.com with bsmtp
  4.     (Smail3.1.29.1 #3) id m0tuhUF-0007qtC; Thu, 7 Mar 96 08:20 MST
  5. Received: by gwar.ardi.com (Smail3.1.29.1 #3)
  6.     id m0tuhTU-000GOKC; Thu, 7 Mar 96 08:19 MST
  7. Message-Id: <m0tuhTU-000GOKC@gwar.ardi.com>
  8. Date: Thu, 7 Mar 96 08:19 MST
  9. From: mat@ardi.com (Mat Hostetter)
  10. To: gmangen@aol.com (GMangen)
  11. Cc: executor@ardi.com
  12. Subject: Re: Executor & UniVBE 5.1?
  13. Newsgroups: comp.emulators.mac.executor
  14. In-Reply-To: <4hllj0$q21@newsbf02.news.aol.com>
  15. References: <4hllj0$q21@newsbf02.news.aol.com>
  16. Sender: owner-executor@ardi.com
  17. Precedence: bulk
  18.  
  19. >>>>> "GMangen" == GMangen  <gmangen@aol.com> writes:
  20.  
  21.     GMangen> Am I correct to assume that while UniVBE provides
  22.     GMangen> emulation of 2.0 BIOS extensions, it gives no access at
  23.     GMangen> all the the hardware acceleration features of the #9
  24.     GMangen> Video card?  If this is so, would a Win32 version using
  25.     GMangen> DirectDraw when available work with drivers that DO use
  26.     GMangen> all the hardware acceleration available, and would this
  27.     GMangen> in turn lead to even greater graphics performance?
  28.  
  29. VESA's VBE 2.0 standard, which is what UniVBE 5.1a implements, does
  30. not offer any way to access hardware acceleration features.  VESA
  31. recently came out with a new video driver standard, VBE/AF, which
  32. allows programs to use hardware acceleration.  I have not yet seen
  33. this standard, and a version of UniVBE that supports it has not yet
  34. been released.  Consequently, Executor does not yet use VBE/AF and we
  35. do no hardware accelerated graphics under DOS.
  36.  
  37. I have not seen the DirectDraw API, but it seems plausible that it
  38. would provide access to hardware acceleration features.  If it does,
  39. we'll use it.  Executor/svgalib already uses hardware acceleration for
  40. solid rectangle fills, and under X11 we use X calls to fill solid
  41. rectangles in some situations.  Adding hardware acceleration for
  42. bitblts and scrolling wouldn't be hard.  Using hardware acceleration
  43. for diagonal line drawing is a little tricky because we need the
  44. screen result to be pixel-for-pixel identical with what Executor would
  45. draw "by hand".
  46.  
  47.     GMangen> Furthermore (and I know this gets kinda murky) would the
  48.     GMangen> lessened time Executor spends doing graphics overhead
  49.     GMangen> lead to increased performance in other quarters of the
  50.     GMangen> emulations, ie enhanced CPU and math throughput maybe?
  51.  
  52. It depends what Executor is doing.  During the normal CPU and math
  53. Speedometer tests, there aren't really any graphics going on to speak
  54. of so it wouldn't make a difference.  Using hardware acceleration to
  55. support "refresh" mode would help performance across the board when
  56. running in "refresh" mode.
  57.  
  58.     GMangen> Also, the docs, and the mailinglist a while ago, got on
  59.     GMangen> the subject of the rough instruction ratio Executor
  60.     GMangen> encounters going from 68k to x86 code.  I have seen
  61.     GMangen> stated that it is pretty consistently 3:1 but that it was
  62.     GMangen> hoped in going to a certain new kind of dynamic
  63.     GMangen> compilation we could get to maybe 2:1 and I was wondering
  64.     GMangen> if anything more is known about such lofty prospects at
  65.     GMangen> this time.
  66.  
  67. I've been too busy working on Executor 2 related things to go back to
  68. hacking on CPU emulation.  It's a bit of a shame; once Executor 2 is
  69. out I should be able to adjust my priorities.
  70.  
  71. -Mat
  72.  
  73.