Perhaps "special" ports for relatively standard high-performance display
interfaces, such as SDL and OpenGL would be good secondary targets to aim
for: Many GUI OSes already have extensive support for these interfaces,
so even a basic OS-specific video driver wouldn't be a huge impediment.
What if Plex86 had an X driver interface built in, that would make use of
an X server running on the host? Lots of overhead, but it would be able
to take advantage of the powerful native X drivers, and again would be
able to take advantage of X support in the client OS. Perhaps some of the
WINE code would help get this up and running relatively quickly, even if
only on a temporary basis. It seems to work well for Win4Lin too.
Sure, the communications overhead alone could be staggering. But all of
the above would certainly be faster than VNC, though VNC may well be the
simplest interface of all to bring up initially (just to get something up
and running), at least for platforms with VNC support.
Let's see... Start Windows (with no display driver) under Plex86, but
with the VNC server running. Then connect to the Plex86 Windows session
using the Linux VNC client. You would see enough of the boot via
non-accelerated VESA emulation alone to (hopefully) get the client OS up
and running.
-BobC
"Timothy J. Massey" wrote:
> On Tue, 29 May 2001 18:17:26 -0400, Kevin Lawton wrote:
>
> >Ideally, emulating a real video card would be the way to go.
>
> IMHO, this is more than ideal: it's a minimum requirement. You're
> either going to have to decide that A)Plex86 will only run Linux and
> Windows as guest OS's, or B)those OS's other than Linux and Windows are
> stuck with VGA or Text-mode only.
>
> Neither of these are a great tradeoff. At least emulating an early
> model S3 chipset (or even a Tseng Labs ET4000, or something else very
> simple) gives you the possibility of >640x480 and >16 colors.
> Performance is not going to be stellar no matter what, so designing
> something to play Quake probably isn't a realistic goal anyway! :)
