Re: various dosemu comments and hacks (sound, delays)

[Stas Sergeev <stssppnn@yahoo.com>]

Hello.

Ryan Underwood wrote:
> The precision is not the problem as much as having the context switch time
> within every iteration of that loop is really bad for performance. e.g.,
> even nanosleep(0) incurs a way too much performance hit.
Of course that depends on the
frequency of that switching.
That's why it is better do
reduce that freq by doing a
syscall not every time the
access to the register is done.

> Ok.. my implementation is going to be with a separate process because I 
> am developing adlib server for other reasons too, so my code will be 
> re-usable.
Yep, the standalone adlib server
would probably be good to have.
Just wondering where can it be
used besides dosemu?

> The adlib server will either emulate the adlib card or pass through the writes
> to real OPL hardware (e.g., /dev/dmfm*).  Alternately it could be done the
> other way around; have the client program (e.g. dosemu) write to /dev/dmfm,
> and depending on the driver that is installed, either the driver writes to
> real adlib hardware, or an emulation driver stub registers /dev/dmfm and
> forwards the writes to userspace emulation daemon, which then outputs to
> /dev/dsp. 
> Which way do you think is better?
Well, ALSA have everything necessary
for doing it the second way. That's
how the timidity sequencer for ALSA
work it seems. So writing the ALSA
support for that may be better I guess,
but from dosemu's side I think it is
about the same which rules are to follow.

> Hmm, what do you mean by "all the glibc functions"?  There are many glibc
> functions that require re-entrant replacements to be used when threading
> is involved.
Of course, but in the case I am talking
about, the threading was not actually
involved. What I've done is just added
a -lpthread to the linker options and it
was enough to get a non-functional dosemu.
Weird.

>> I've been recently exploring the power
>> of the Async IO
> So, basically, it seems to be a non-blocking form of polling?
No, that's something similar to the
interrupt-driven IO. When IO is possible
you get a SIGIO (or another signal if
you want), you do the IO and get back to
work. I.e. no polling is involved, no
waiting in select(), no threading etc.

> I think #2 is the promising one, but it will be some work.
I think the 2 is the only possibility
for something real but if you can really
get as far as that, then why limiting
yourself with VCPI? If you do your #2,
you'll be able to just execute any
priveleged code, so in that case it
will be possible to just load a VCPI
server of QEMM etc. I.e. no need to
implement a VCPI inside dosemu then.
Yeah, that would be great.
Btw, we have a simx86 CPU emulator
for this. It was rather functional but
currently it is in a bizarre state
due to a lack of a maintainer. So it
might be much easier to resurrect the
simx86 and implement some missing
features to it rather than using a
bochs as a CPU-emu server as you suggested.
Anyway this was a long-standing dream
for dosemu to be able to execute a ring0
code and so far noone had any success
with it, so good luck with that work.
But also it turned out recently that
even a DPMI can do quite a lot if it
is designed properly:)