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