home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.95 / text4699.txt < prev    next >
Encoding:
Internet Message Format  |  1996-03-31  |  2.8 KB
  1. Received: from sloth.swcp.com (sloth.swcp.com [198.59.115.25]) by nacm.com (8.6.10/8.6.9) with ESMTP id JAA19462 for <executor@nacm.com>; Wed, 13 Sep 1995 09:56:49 -0700
  2. Received: from iclone.UUCP (uucp@localhost) by sloth.swcp.com (8.6.9/8.6.9) with UUCP id KAA12811; Wed, 13 Sep 1995 10:56:44 -0600
  3. Received: from gwar.ardi.com by mailhost  with smtp
  4.     (nextstep Smail3.1.29.0 #11) id m0ssv4y-000YdaC; Wed, 13 Sep 95 10:54 MDT
  5. Received: by gwar.ardi.com (linux Smail3.1.28.1 #5)
  6.     id m0ssv4y-000GVEC; Wed, 13 Sep 95 10:54 MDT
  7. Message-Id: <m0ssv4y-000GVEC@gwar.ardi.com>
  8. Date: Wed, 13 Sep 95 10:54 MDT
  9. From: mat@ardi.com (Mat Hostetter)
  10. To: Alan Shutko <ats@hurd193.wustl.edu>
  11. Cc: executor@nacm.com
  12. Subject: Re: Success w/ SVGAlib Executor
  13. In-Reply-To: <199509131627.LAA00865@hubert.wustl.edu>
  14. References: <199509131627.LAA00865@hubert.wustl.edu>
  15. Sender: owner-paper@nacm.com
  16. Precedence: bulk
  17.  
  18. >>>>> "Alan" == Alan Shutko <ats@hurd193.wustl.edu> writes:
  19.  
  20.     Alan> * When using speedometer, running through the graphics
  21.     Alan> tests, some screen modes are garbage.  It looks like there
  22.     Alan> is some kind of memory mismatch between what Executor or
  23.     Alan> SVGAlib expects, and what it actually gets.  After running
  24.     Alan> the graphics tests, Executor wouldn't accept clicks and I
  25.     Alan> ^C'd out.
  26.  
  27. SVGAlib doesn't give us any way to set the base address of the linear
  28. frame buffer, and Macintosh semantics demand that the base address of
  29. the screen can never change.  Furthermore, most SVGA boards don't
  30. support 2 bpp and 4 bpp "packed" modes.  This forces us to do one of
  31. two things:
  32.  
  33.     1) Always present a RAM frame buffer to the Mac at the same
  34.        address in memory, and periodically update the SVGA board
  35.        with it.  This will support all bits per pixel, but
  36.        double-buffers the screen so it's slow.
  37.  
  38.     2) Present SVGAlib's 8bpp linear frame buffer directly to the
  39.        emulated apps, and disallow setting the screen depth to
  40.        anything other than 8bpp.  This is fast, but only allows
  41.        8bpp.
  42.  
  43. By default we do (2), which is the fastest mode and really good for
  44. certain Mac games.  However, if you specify a bits per pixel other
  45. than 8 on the command line, e.g.  "executor -bpp 4", we do (1).  (1)
  46. should be compatible with Speedometer (albeit slow).
  47.  
  48. When in mode (2), Executor should tell Speedometer that the only
  49. possible bits per pixel is 8, and disallow depth sets to any other
  50. bpp.  The fact that Speedometer tries to switch to those other
  51. (illegal) screen depths sounds like a bug, either in our code or in
  52. Speedometer.  I'll look into it.
  53.  
  54. What we *really* want is SVGAlib support for re-mmap'ing the frame
  55. buffer *after* SVGAlib initialization time to an address that we
  56. specify.  Then we can have super-fast 8bpp graphics *and* support all
  57. screen depths.
  58.  
  59. -Mat
  60.  
  61.