Executor 2.0/executorv2.0.iso/pc/linux/extra/docs/maillist/text/archive.95/text2366.txt

Text File | 1996-04-02 | 8.2 KB | 172 lines

>>>>> "Colin" == Colin Irwin <[e-mail]> writes:

    Colin> However, when I ran Maelstrom (I know, I'm still trying to
    Colin> get it to work :-)) it started fine but was extremely
    Colin> jerking in gameplay. Now my question is this: Is there
    Colin> something worng with my general setup, or is it a graphics
    Colin> based problem (as I don't have an accelerated graphics
    Colin> card).

If you're running under DOS, the short answer is "download and install
UniVBE 5.1a, and run Executor under plain DOS" for your best chance of
making Maelstrom run fast.  UniVBE is widely available; you may want
to download it directly from the authors at ftp.scitechsoft.com.

The rest of this letter is a detailed explanation of what's going on.
It's probably far more detail than you ever wanted, but others on this
list may be interested.

The problem is that Maelstrom bypasses Quickdraw and writes directly
to screen memory, which can force many Executor setups to run in a
slower compatibility mode.

There are two graphics modes in which Executor can run:

   1) The "screen" presented to the app being emulated (e.g. Maelstrom)
      is in fact the real hardware screen.  Pixels written to this
      memory will instantly appear on the screen.

   2) The "screen" presented to the app is actually just normal RAM.
      Special Executor code periodically copies rectangles from this
      RAM to the real display.

(1) is *MUCH* faster than (2), so of course we always try to use mode
(1) when possible.  Of course, it's often not possible.  For example,
under X11 we are not able to get direct access to screen memory, and
instead have to use X11 calls to copy rectangles to the screen.

In your case, your machine is running Maelstrom in mode (2), so it's
really slow.  To make it run in mode (1) you need a VBE 2.0-compatible
video driver, such as UniVBE 5.1a.  Of course, it's possible that
UniVBE doesn't support your video card, in which case you won't be
able to get mode (2) until we port to Win32/DirectDraw (assuming
DirectDraw does what we want).

For normal programs that use Quickdraw (i.e. make toolbox calls to
draw to the screen), Executor notes what parts of the screen have
changed.  When it comes time to update the "real" screen, Executor
knows how what changed so it only copies some minimal "dirty
rectangles" from its internal screen to the real screen.

When programs bypass Quickdraw and write directly to screen memory,
Executor has no easy way of knowing which pixels on the "real" screen
are outdated.  Executor switches into a slow "refresh mode" where it
does one of two things:

   A) Periodically compare the current internal screen to the last one
      displayed, identify the smallest rectangle that encloses all
      changed pixels, and copy that rectangle to the screen.

   B) Periodically copy the entire internal screen to the real screen,
      and don't bother trying to figure out which pixels have changed.

Both will be fairly slow and lurchy.

So right now you're in mode (2) and you'd really like to be in mode
(1).  Maelstrom blazes when it gets to write directly to your SVGA
card's VRAM.  Unfortunately, DOS makes supporting this mode extremely
difficult.

Many games originally written for the Macintosh expect that screen
memory is a contiguous sequence of bytes, and that they can plot
pixels at any location on the screen by writing to the appropriate
memory location.  Unfortunately, because of the infamous 640K
limitation on the 80286, the original SVGA boards could only make a
64K "window" into screen memory available at any given time.  This
window could be "repositioned" to correspond to various places on the
screen, but could not be enlarged.

Of course, most 256 color screens take much more than 64K.  For
example, a 640x480x256 screen takes 300K.  DOOM uses a 320x200x256
screen, which takes less than 64K and thus avoids many of the
headaches that Executor encounters.

Anyway, back to our story.  Some programs originally written for the
Mac expect a big block of memory to correspond to the screen.  Under
the old svga model, there is no such block of memory for screens that
take more than 64K.

Fortunately, with the advent of the 32-bit 80386, most svga boards
gained a "linear frame buffer" option, which can give programs a
single contiguous block of memory for the entire screen.  Yay.  This
is exactly what we want.

The specifics of how to turn on "linear mode" vary by SVGA chipset.
In general, these board-specific differences are handled by the video
driver, so programs need not concern themselves with the details of
every board ever made.

Unfortunately, the ROMs on most boards only support the "VBE 1.2"
standard (VESA BIOS Extensions 1.2), which predates the widespread use
of linear frame buffers and provides no way for programs to use them.
VESA addressed this with the VBE 2.0 standard, which also allows
programmers to take advantage of 8-bit DACs and do certain things more
quickly in protected mode programs.

VBE 2.0 isn't built in to many boards, but UniVBE 5.1a knows how to
provide a VBE 2.0 driver interface for most boards.  When UniVBE is
installed on a well-supported board that actually has the hardware
capability for linear frame buffers, Executor can enable linear frame
buffer mode for faster graphics.

You hoped my explanation was complete and this letter was coming to an
end, but nay.  There's more.

I'm sure you've stayed awake nights wondering how protected mode
programs allocate memory from the system, patch into hardware
interrupts, etc.  These days the standard way to do it is for the
program to talk to a "DPMI server" which manages those resources.
Windows, Warp, and DOSEMU all provide DPMI servers.  DOS does not,
although several are available.  Executor/DOS comes with cwsdpmi.exe,
a free DPMI server written by Charles Sandmann.  It only gets used
when no other DPMI server is present.

The original DPMI standard was DPMI 0.9.  It provided enough basic
mechanisms for unsophisticated programs to run well.  However, its
limitations eventually resulted in the DPMI 1.0 standard.  DPMI 1.0
provides programs with powerful new ways to manipulate virtual memory.

One important thing that DPMI 1.0 lets programs do is map physical
memory into their address space.  Executor uses this feature, when
available, to map a linear frame buffer into our address space.
Without this feature, Executor needs a "far pointer" to reference even
a linear screen, and so that memory cannot be made available to the
application being emulated.

However, VBE 2.0 + DPMI 0.9 is still fast for programs that don't
bypass Quickdraw, since our blitter knows how to draw directly to
screen that requires a far pointer (a segment override).  On this
setup, we don't keep a RAM virtual screen lying around in some
graphics modes.  Our blitter just draws directly to the SVGA board.

Amazingly, Windows 3.1 and Windows '95 only provide DPMI 0.9!  I'm not
sure about WinNT, but I'd guess it also provides 0.9.  OS/2 Warp
provides something they call DPMI "0.95", but I haven't been able to
get the DPMI 1.0 features I need (mostly DPMI function 0x508) to work
under Warp.

In fact, there are very few DPMI 1.0 servers out there.  Fortunately,
after ARDI and Id Software begged the author we were able to get
cwsdpmi.exe to provide the DPMI 1.0 features we need to map the frame
buffer into our address space.  Games like Maelstrom, Apeiron,
Solarian, Space Madness, etc. *blaze* under DOS + UniVBE 5.1a.  But if
you run under Windows or Warp, or you don't have a VBE 2.0 compatible
driver, or your svga board doesn't support linear frame buffers, these
games will be slow and lurchy.

After Executor 2 comes out, we plan to port Executor to Win32.  I have
not yet read the documentation for Microsoft's "DirectDraw" package,
but it sounds like it may give us the best of all worlds for Windows
users.  Warp has something called DIVE which may provide similar
functionality.  NEXTSTEP has Interceptor.  And then there's SciTech's
"WinDirect" package, which allows Windows programs to shut down the
Windows GDI and take over the entire screen.  That, combined with
SciTech's UniVBE 5.2 (which will support the VBE/AF hardware
acceleration video driver standard on some boards) might also make for
a blazing Executor.

If you've read this far, I'm impressed.  :-)

-Mat