[Prev][Next][Index][Thread]

Re: Success w/ SVGAlib Executor



>>>>> "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


Follow-Ups: References: