home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.95 / text1776.txt < prev    next >
Encoding:
Text File  |  1996-04-02  |  1.9 KB  |  44 lines

  1. >>>>> "Alan" == Alan Shutko <ats@hurd193.wustl.edu> writes:
  2.  
  3.     Alan> * When using speedometer, running through the graphics
  4.     Alan> tests, some screen modes are garbage.  It looks like there
  5.     Alan> is some kind of memory mismatch between what Executor or
  6.     Alan> SVGAlib expects, and what it actually gets.  After running
  7.     Alan> the graphics tests, Executor wouldn't accept clicks and I
  8.     Alan> ^C'd out.
  9.  
  10. SVGAlib doesn't give us any way to set the base address of the linear
  11. frame buffer, and Macintosh semantics demand that the base address of
  12. the screen can never change.  Furthermore, most SVGA boards don't
  13. support 2 bpp and 4 bpp "packed" modes.  This forces us to do one of
  14. two things:
  15.  
  16.     1) Always present a RAM frame buffer to the Mac at the same
  17.        address in memory, and periodically update the SVGA board
  18.        with it.  This will support all bits per pixel, but
  19.        double-buffers the screen so it's slow.
  20.  
  21.     2) Present SVGAlib's 8bpp linear frame buffer directly to the
  22.        emulated apps, and disallow setting the screen depth to
  23.        anything other than 8bpp.  This is fast, but only allows
  24.        8bpp.
  25.  
  26. By default we do (2), which is the fastest mode and really good for
  27. certain Mac games.  However, if you specify a bits per pixel other
  28. than 8 on the command line, e.g.  "executor -bpp 4", we do (1).  (1)
  29. should be compatible with Speedometer (albeit slow).
  30.  
  31. When in mode (2), Executor should tell Speedometer that the only
  32. possible bits per pixel is 8, and disallow depth sets to any other
  33. bpp.  The fact that Speedometer tries to switch to those other
  34. (illegal) screen depths sounds like a bug, either in our code or in
  35. Speedometer.  I'll look into it.
  36.  
  37. What we *really* want is SVGAlib support for re-mmap'ing the frame
  38. buffer *after* SVGAlib initialization time to an address that we
  39. specify.  Then we can have super-fast 8bpp graphics *and* support all
  40. screen depths.
  41.  
  42. -Mat
  43.  
  44.