...also make sure that you have installed the CPU usage reduction fix
for Windows 98, se manual: 3.11.2.2
(The link in the manual seems to be dead, but working ones can be found
using Google.)
/Dan
Mikhail Ramendik wrote:
On Tuesday 02 January 2007 12:54, Dan Sandberg wrote:
On the
the other hand, if for instance VMware is able to run Windows 98 much
faster (I do not have it so I can't test this) then my guess is that
kqemu is the guilty part and does something wrong with 16-bit code.
Regards
Dan Sandberg
Mikhail Ramendik wrote:
Hello,
Some time ago I reported
s performance on any machine having decent OpenGL drivers
(which will be the common case soon with more OpenGL-friendly X-window
implementations being introduced).
Regards
Dan Sandberg
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://
patch seems to solve this, but I can't say that I understand
how (not having looked into the SDL source code).
Regards
Dan Sandberg
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Mikhail Ramendik wrote:
Hello,
There seems to be an issue with guest Windows 98 SE on qemu 0.8.1 and kqemu
1.3.0pre7, on a Linux host.
Windows 98 SE is visibly very slow; and when qemu is run with -no-kqemu, it is
actually faster.
I have this issue on two different systems:
- Intel Celer
Jamie Lokier wrote:
Dan Sandberg wrote:
When the screen is "painted" the DAC's read from the host video buffer
(1600x1200) and interpret it as RGB. Somewhere they "hit" the left
boundary of the separate viewport that you have set up and bang, on the
fly they
Jamie Lokier wrote:
Dan Sandberg wrote:
Creating a rectangular direct output area in OpenGL is actually like
vitualizing a graphics card.
That is what X's XF86DGA ("Direct Graphics Adapter") feature does.
And I believe SDL already supports XF86DGA when in full screen m
Fabrice Bellard wrote:
Dan Sandberg wrote:
Just curious...
Are you using an OpenGL directdraw surface for the graphics emulation
in Qemu?
If not, then consider the benefits:
1. It is much faster than any native graphics 2D/3D primitives like
Windows GDI
2: It gives full control over
Paul Brook wrote:
On Wednesday 10 May 2006 23:05, Fabrice Bellard wrote:
In order to stop the release of incomplete BGR patches, I am
implementing a more complete patch. I am just adding depth = 32 with BGR
instead of RGB. If other pixel formats are wanted, you should signal it
now.
I
n sync and
everything seems to be OK.
I haven´t been looking at the source-code, but my suggestion is that in
the Click-event-handler where Mousegrab is entered the guest-OS pointer
coordinates should be passed rather than the host's coordinates
(simulating a click at the exakt right position).
Regards
Dan Sandberg
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Dan Sandberg wrote:
Brad Campbell wrote:
Troy Benjegerdes wrote:
On Thu, Feb 09, 2006 at 04:01:34PM -0600, Anthony Liguori wrote:
Jim C. Brown wrote:
-kernel-kqemu virtualizes ring 0 code.
So it basically makes qemu do what VMware does.
IIRC someone reported a 33% speedup with the new
test line was:
qemu.exe -kernel-kqemu -m 384 -L ./bios -boot c -hda c.img
Best regards,
Dan Sandberg
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
12 matches
Mail list logo
