On Tue, 16 Nov 2004, jegunn wrote:
Thanks. I tried this a little while before I got your reply; the
performance is *very* sensitive to the setting; 3 is more-or-less
OK, but better with zero. I was using 1 before with 1.0.2.1. Did
the priority code change between these versions?
yes,
On Wed, 17 Nov 2004, Bart Oldeman wrote:
Thanks, Bart.
The other problem I alluded to still remains. The following line in
.dosemurc
$_X_vesamode = 1024,740
elicits no response to a query which lists the available VESA modes.
Changing the $_X_vgaemu_memsize has the expected result; going
from
Many apologies--I thought the debugging output came on stdout/stderr, but
it is clearly put into boot.log. Running with -D9+c elicits the output
X_fullscreen 0
vgaemu_memsize 0x600
vesamode_list (nil)
X_lfb 1
X_pm_interface 1
when parsing the .dosemurc lines in the vicinity of
# size (in
On Wed, 17 Nov 2004, jegunn wrote:
in .dosemurc. So the memory size is recognized, but the vesamode line is
not. Has the syntax changed? The documentation has not.
No, it's a typo.
in dosemu's etc/global.conf replace
foreach $yyy ( , $X_vesamode)
by
foreach $yyy ( , $_X_vesamode)
Thanks much, Bart. I am running from the binary
distribution, so I took the chicken's way out and changed
dosemu.users to read the fixed global.conf file.
Ok, that's fine, it just overrides the builtin one then.
quilla:SDSSPrettypicsxdosemu
[1] 3541
quilla:SDSSPrettypicsERROR: Unable to
I may have missed messages on this issue on the mailing list, and if so
apologies. I have used dosemu 1.0.2.1 for a couple of years under RH7.3 on
a dual 1.6GHz Athlon machine, running Generic CADD 6.0 under xdosemu with
wonderful results. I recently upgraded to FC2, (2.6.8) and discovered that
On Tue, 16 Nov 2004, Stas Sergeev wrote:
Hello.
jegunn wrote:
fine, but the cadd program now generates its screen a full factor of 50
more slowly than it did before.
Set $_hogthreshold=(0) in your dosemu.conf.
Thanks. I tried this a little while before I got your reply; the
