[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: