From: "Mike Nordell" <tamlin@algonet.se>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: Re: OSS audio debugging
Date: Mon, 14 Jun 2004 14:18:07 +0200 [thread overview]
Message-ID: <000301c45209$a77d3340$0401a8c0@putte2k> (raw)
malc wrote:
> Disabling TB chainging helps running DOOM.
And that would be done... how? Patching the call tb_link(tb) from
cpu_exec()?
> Transport Tycoon
[snip]
>
> You can try UNIVBE, Scitech has a free(both senses) download.
Good idea. Cant understand why I didn't think of Kendall immediately. I
didn't find a free as in speech version, but that's of little concern right
now.
While TT still hangs, it did change display mode - and it also found what I
believe to be more emulation bugs! :-)
During univbe's detection phase (runnning uvconfig.exe from sdd653-d.zip
from scitech's ftp) it wanted to switch video modes a number of times. Turns
out that, at least for Windows host (SDL 1.2.7) using cirrusvga, QEMU didn't
switch display mode (or at least resolution) until i clicked its caption. A
few times I _think_ it switched video mode only once for each caption click,
but mostly it flipped through a bunch of modes - but without me clicking the
caption several times it just hung.
There are two (abstract) possibilities as I see it.
1. It needed a user-generated windows message to go through the message
pump. For a simple mode or resolution switch this seems unlikely, since many
other apps as guests can do mode-switches without any problems.
2. The clicks, which can effectively halt emulation due to the way the
Windows message pump works, can bring down host CPU load from 100% to ~0% -
allowing one of the other threads to run (which seems strange too, since the
timer thread is already running at high priority), and had an effect on
delivery of ... something. Interrupts from the timer thread? I did even make
all accesses to env->interrupt_request thread-safe (they are currently not),
but that didn't change anything. Could be timer dependant, or even a bug in
the uvconfig code, making assumptions about relative CPU + timer speed?
It does however reliably and every time display this error for me - both
with and without pci. It would be interesting to know if anyone can repeat
this on *nix (perhaps both with and without softmmu?). I did multiple runs,
deleting the generated config.dat before each test, and every single time I
got this this behaviour.
> Default Win98 sound driver does not work indeed
If that isn't clear proof the emulation is yet incorrect, I don't know what
is. :-)
/Mike
reply other threads:[~2004-06-14 12:19 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000301c45209$a77d3340$0401a8c0@putte2k' \
--to=tamlin@algonet.se \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).