home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.96 / text2188.txt < prev    next >
Encoding:
Text File  |  1996-07-25  |  2.6 KB  |  62 lines
  1.     id m0tv4ID-0007q4a; Fri, 8 Mar 96 08:41 MST
  2. Sender: owner-executor
  3. Received: from gwar.ardi.com by ftp.ardi.com with bsmtp
  4.     (Smail3.1.29.1 #3) id m0tv4Hc-0007q2C; Fri, 8 Mar 96 08:40 MST
  5. Received: by gwar.ardi.com (Smail3.1.29.1 #3)
  6.     id m0tv4Gf-000GOKC; Fri, 8 Mar 96 08:39 MST
  7. Message-Id: <m0tv4Gf-000GOKC@gwar.ardi.com>
  8. Date: Fri, 8 Mar 96 08:39 MST
  9. From: mat@ardi.com (Mat Hostetter)
  10. To: Georg_Bauer@ms3.maus.westfalen.de (Georg Bauer)
  11. Cc: executor@ardi.com
  12. Subject: Re: executor & windows95
  13. Newsgroups: comp.emulators.mac.executor
  14. In-Reply-To: <199603060842.a60491@ms3.maus.de>
  15. References: <m0ttbTz-000GOKC@gwar.ardi.com>
  16.     <199603060842.a60491@ms3.maus.de>
  17. Sender: owner-executor@ardi.com
  18. Precedence: bulk
  19.  
  20. >>>>> "Georg" == Georg Bauer <Georg_Bauer@ms3.maus.westfalen.de> writes:
  21.  
  22.     Georg> Hi!
  23.     >> Video should be faster (if you've got UniVBE) because we can
  24.     >> directly access the linear frame buffer under DOS.  Still, I
  25.     >> wouldn't think that the CPU number should slow down.
  26.  
  27.     Georg> Actually the Win95 does give you the same sort of penalty
  28.     Georg> that EMM386 gives you, but worse. Every memory access runs
  29.     Georg> through their paging code, so that is slowed down. Ok, most
  30.     Georg> code is in the internal cache, but it's slow nonetheless. I
  31.     Georg> found that I could even gain some more speed in the CPU
  32.     Georg> benchmarks by just removing EMM386 and let the extender of
  33.     Georg> Executor handle all the memory.
  34.  
  35. What's happening is that CWSDPMI implements the DPMI 1.0 extension
  36. that lets us map physical memory into our address space.  Nearly all
  37. other DPMI providers (Windows, Warp, EMM386) only implement DPMI 0.9,
  38. and so they don't support this feature.  This requires us to use the
  39. equivalent of a "far" pointer to access video memory.
  40.  
  41. Since Macs have no notion of "far" pointers, we can only let Mac apps
  42. *directly* access the real video memory under CWSDPMI.  On nearly all
  43. other setups they access a RAM frame buffer from which we periodically
  44. transfer rectangles to the real screen.
  45.  
  46. There is actually a way around this in Win3.1, Win95, and Warp if
  47. UniVBE is giving you a linear frame buffer but we haven't implemented
  48. it as an option.  There are two big drawbacks:
  49.  
  50. 1) You'd be stuck at 8 bpp graphics, unable to switch depths.
  51.  
  52. 2) You'd lose memory protection, so a misbehaving Mac program could
  53.    screw up your system, potentially corrupting other memory and even
  54.    causing a reboot.
  55.  
  56. Reason (2) is the main reason we haven't added this option.  It might
  57. be worth adding anyway.  Certain arcade games (those that bypass
  58. QuickDraw) would be *much* faster under Win95 and Warp.
  59.  
  60. -Mat
  61.  
  62.