On Tue, 14 Dec 1999, Ramon van Handel wrote:
> >Disk emulation has potential to be very efficient. We can't
> >do this with standard 640x480x16color VGA mode though, because
> >of those freekin latching modes. Of course, special guest specific
> >drivers will take care of this. (Or I suppose the guest could be
> >allowed to read/write directly to the real VGA ports/memory if
> >we got real spiffy)
>
> My experience with VMWare (I have very little of it, but I do remember this) is
> that graphics programs running in DOS, even in 320x200x256, tend to be
> *EXTREMELY* slow. In one old DOS game that I tried out to test VMWare
> (Gobliins2), I had to wait several minutes for a fade !!! Under windows,
> VMWare uses a specialised driver to achieve fast results -- as I understood
> it, it uses the X DGA extension and directly maps the relevant piece of
> shared memory into the guest address space, so in fact there is direct
> communication between the guest and the host window system. Which is FAST.
>
Yes, running DOS gfx apps under VMware was a real disappointment because I
hoped it would provide a better VDMs than NT. However it was even slower.
Though I wonder what makes the NT VDM's so slow in gfx modes, especially
when the PIT is programmed to higher freqs - probably not a video because
it uses direct access. I thought the problem could be in improper
emulation of PIT, but when I wrote a little dos program to compare the
real freq of PIT in VDM at different latch values with RTC clock (knowing
that RTC is correct in any case), the PIT was generating int's pretty
accurately. Maybe this happens due to lower priority of VDM's?
Unlikely - according to task manager they are taking all of the free CPU
time. Looks like a real enigma to me...
> Though I would still like to have fast "compatibility" modes, if possible,
> things like graphics can be best handled in a specialised manner.
>
> -- Ramon
>
>
>
>
>
Dmitriy
