various dosemu comments and hacks (sound, delays)

various dosemu comments and hacks (sound, delays)

[Ryan Underwood]

Hi,

I've been working with the new dosemu 1.1.4.13 and hacking some stuff.  Here
are my observations and a few questions.

------------------------------------------------------------------------------
1) Ctrl-Alt-F fullscreen crashes dosemu with a X-Shm (Shared memory) error
if I use the key combination for the first time when inside a graphical game.
If I use it when dosemu is sitting at a prompt, it works fine, and I can
then enter a game.  Further, I can window/fullscreen toggle all I want after
that point, and it is fine.  It just can't be in a game when toggling it
for the first time.  Minor problem.

------------------------------------------------------------------------------
2) In order to solve the problem of classic games running too fast, I have
hacked in delays in two select places to take care of specific common cases
without destroying others.

One reason the games run too fast is because
writes to VGA hardware take far less time than they used to, and depending
on the program being blocked for a certain amount of time during display
writes is an assumption that falls through today.  Wing Commander I as a
whole, and Wing Commander II's cinematic sequences suffer from this problem.
Utilities like Moslo do not help because it can only delay software interrupt
routines and not hardware like the VGA.

However, since we have an emulated VGA core now thanks to the X11 code, we
have control over how long VGA writes take to complete.  In essence, I added
the following code in src/env/video/vgaemu.c in vga_emu_fault():

static int bogo = 0;

  if (!bogo) {
        bogo = config.cpu_spd / 8;
        printf("Speed delay in vgaemu.c is %d\n", bogo);
  }

  for (i = 0; i < bogo; i++);

This simulates a slow graphics card/video bus pretty well.  Wing Commander
I is perfectly playable on my machine (800Mhz Celeron).

However, for this code to work, the following config option must be set:
$_X_updfreq = (1)       # time between refreshes (units: 20 == 1 second)

Not setting it, or setting it to any other value causes the game to be as
speedy as it was without my delay inserted.  Why is this?

I also inserted another delay in miscemu.c, Misc_get_input_status_1():

static int vvfreq = 0;

  if (!vvfreq) {
       vvfreq = config.cpu_spd / 120;
       printf("Speed delay in miscemu.c is %d\n", vvfreq);
  }

which causes the code to wait longer before returning that we are in vsync,
depending on how fast the machine speed is.  Now, this may cause more problems
with tearing, but I didn't notice any that weren't already there.  The advantage
to the delay here is that applications that constantly poll for vsync in
a loop can be smoothly slowed by making the app wait for a bit each time.
This helps in some parts of Wing Commander like the intro where it is still
too fast even with the VGA write delay, but polls for vsync.

Combining both of these loops seems to provide a flexible means for slowdown.
I think the divisor should be configurable by the user, perhaps even at runtime
through a stub utility like the other dosemu utilities.

------------------------------------------------------------------------------
3) The Adlib emulation is not working well on my machine.  I am working on an
implementation which will use a separate Adlib sound server to handle the
emulation, so DOSemu isn't constantly being blocked by the Adlib emulation
code.

------------------------------------------------------------------------------
4) SBemu seems not quite working.  On my Aureal AU8830, when a new DMA
buffer is "loaded" and begins playing, I hear a click or pop, but nothing
after that point.  In order to get this far, however, I had to change the
two opens of /dev/dsp from O_RDWR to O_WRONLY.  The AU8830, like some other
cards, only allows one application at a time to open the device for reading.
Subsequent attempts at opening for read causes driver to return -ENOMEM.
It is a broken feature, to be sure, but if open O_RDWR fails, the open should
be retried O_WRONLY to get around this brokenness.

The offending opens are in linux_sb_get_version() and linux_sb_enable_speaker()
in src/arch/linux/dosext/sound/linux_sound.c.

------------------------------------------------------------------------------
5) I'm working on VCPI and "unreal-mode" support.  Someday, it will happen. :)

------------------------------------------------------------------------------
Let me know if you have any comments!

-- 
Ryan Underwood, <nemesis at icequake.net>, icq=10317253

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

[Stas Sergeev]

Hello.

Ryan Underwood wrote:
> 1) Ctrl-Alt-F fullscreen crashes dosemu with a X-Shm (Shared memory)
Searching the google reveals that
many programs have that problem so
I suppose it is not dosemu-related.
It crashes right in a mode-switching
routine of X (if you add an XSync
calls).

> for the first time.  Minor problem.
But rather annoying actually:(

> for (i = 0; i < bogo; i++);
Busy loops?? I guess we have a better
ways to do delays (oh, probably a
precision of that other methods is
bad, but I guess the busy loops is a
bad thing to do).

> 3) The Adlib emulation is not working well on my machine.
What adlib engine are you using? The
one currently inside dosemu is not
intended to work at all.

> emulation, so DOSemu isn't constantly being blocked by the Adlib 
> emulation code.
There is practically no adlib code
in dosemu for the moment (only timers
are implemented so that the progs can
detect the adlib) so where does it go
blocking?

> 4) SBemu seems not quite working.
Really? :)

> On my Aureal AU8830, when a new DMA
> buffer is "loaded" and begins playing, I hear a click or pop, but 
> nothing after that point.
Surely you could find the card with
even buggier third-party drivers, but
at least you could visit the project
page and dig the patches section:)
http://sourceforge.net/tracker/index.php?func=detail&aid=680632&group_id=8109&atid=308109

> In order to get this far, however, I had to change 
> the two opens of /dev/dsp from O_RDWR to O_WRONLY.
In general this is not a solution, it
will break recording (yeah, unlikely
is used under dosemu, but anyway).

> The AU8830, like some other
> cards, only allows one application at a time to open the device for 
> reading.
> Subsequent attempts at opening for read causes driver to return 
> -ENOMEM.
I don't think dosemu opens it more than
once at a time.

> he offending opens are in linux_sb_get_version() and 
> linux_sb_enable_speaker()
> in src/arch/linux/dosext/sound/linux_sound.c.
Note that linux_sb_get_version() closes
/dev/dsp right after opening, so only
the linux_sb_enable_speaker() really
keeps it opened, so there must be no
multiple openings in O_RDWR mode (at
least not intended to be).

> 5) I'm working on VCPI and "unreal-mode" support.  Someday, it will 
> happen. :)
Optimist:)

> Let me know if you have any comments!
You've got it:)

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

[Ryan Underwood]

Hi,

> > for (i = 0; i < bogo; i++);
> Busy loops?? I guess we have a better
> ways to do delays (oh, probably a
> precision of that other methods is
> bad, but I guess the busy loops is a
> bad thing to do).

I know busy loops suck, but I wanted to illustrate that putting delays in
those places (regardless of the nature of the delay) is something that can
be used as a smooth speed throttle. :)  If you can come up with a better
delay, be my guest.

> > 3) The Adlib emulation is not working well on my machine.
> What adlib engine are you using? The
> one currently inside dosemu is not
> intended to work at all.

The patch that is provided on your homepage.  It creates some noise that
sounds vaguely like the intended output, but it causes an extreme slowdown
in execution speed since the emulation code is implemented as extra
procedure inserted within the main program, as opposed to a thread or separate
process.

> detect the adlib) so where does it go
> blocking?

In this case, what I mean by "Blocking" is simply that the adlib code is
executed in sequence and the rest of dosemu is halted until it is finished.

A separately scheduled process would seem to model the behavior of the real
hardware more precisely; instead of the program stopping and waiting for
the synthesizer chip to process the data and play the sound (which is what
the current patch seems to do with respect to the emulated opl), the program
running on real hardware simply writes data to the I/O ports and continues
execution while allowing the synth to process the data as a separate entity.

Does that make sense?

> > On my Aureal AU8830, when a new DMA
> > buffer is "loaded" and begins playing, I hear a click or pop, but 
> > nothing after that point.
> Surely you could find the card with
> even buggier third-party drivers,

Actually, probably not. :)

> but
> at least you could visit the project
> page and dig the patches section:)
> http://sourceforge.net/tracker/index.php?func=detail&aid=680632&group_id=8109&atid=308109

Hmm, Feb 03... Guess I'll check that one out. :)
(This patch wasn't there when I went loooking for fixes at first last month)

> > In order to get this far, however, I had to change 
> > the two opens of /dev/dsp from O_RDWR to O_WRONLY.
> In general this is not a solution, it
> will break recording (yeah, unlikely
> is used under dosemu, but anyway).

No problem, it can be tried to open O_RDWR first, and then O_WRONLY if the
first returns fd=-1.

> > The AU8830, like some other
> > cards, only allows one application at a time to open the device for 
> > reading.
> > Subsequent attempts at opening for read causes driver to return 
> > -ENOMEM.
> I don't think dosemu opens it more than
> once at a time.

Yeah, but it's already opened by another application I am using (liveice).

> > he offending opens are in linux_sb_get_version() and 
> > linux_sb_enable_speaker()
> > in src/arch/linux/dosext/sound/linux_sound.c.
> Note that linux_sb_get_version() closes
> /dev/dsp right after opening, so only
> the linux_sb_enable_speaker() really
> keeps it opened, so there must be no
> multiple openings in O_RDWR mode (at
> least not intended to be).

No, the problem isn't multiple openings by dosemu itself, it's that if something
is already recording on the system, dosemu sound _playback_ won't even work
since the device open will fail.

> > 5) I'm working on VCPI and "unreal-mode" support.  Someday, it will 
> > happen. :)
> Optimist:)

Yea, we'll see.

Thanks!
-- 
Ryan Underwood, <nemesis at icequake.net>, icq=10317253

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

[Stas Sergeev]

Hello.

Ryan Underwood wrote:
> be used as a smooth speed throttle. :)  If you can come up with a 
> better delay, be my guest.
Well, I've no idea about a
precision you need, but if
the precision of usleep()
and friends is not OK for you,
then the general thing to try
is to do a delays not on every
access, but, say, at each third
access etc. Dosemu already does
the like tricks for hogthreshold
so in general this is feasible.

>> What adlib engine are you using? The
>> one currently inside dosemu is not
>> intended to work at all.
>  The patch that is provided on your homepage.
Ah, OK. Yes, it has problems, lots
of problems.

> It creates some noise that
> sounds vaguely like the intended output,
That varies from program to program.
For example in Wolf3D the sound it
produces is rather OK but in Dune it
is pretty bad.
The one disadvantage is that I have
to drop the already filled buffers
if the tone gen is suddenly reprogrammed,
which produces a distortion. There
might be other issues as well.

> but it causes an extreme slowdown
> in execution speed since the emulation code is implemented as extra
> procedure inserted within the main program,
Yes, this adlib engine is permanently
broken in a polling mode. The problem
is that we never know when some tone
gen will be reprogrammed so we don't
know how many data we can generate per
a polling cycle.

> the current patch seems to do with respect to the emulated opl), the program
> running on real hardware simply writes data to the I/O ports and continues
> execution while allowing the synth to process the data as a separate 
> entity. 
> Does that make sense?
Of course. Threading looks like the
only cure for adlib. Also the DMA can
benefit from threading, but DMA works
quite fine also in a polling mode
because at least the buffer size is
known (but I had to add a lot of
heuristics about a buffer sizes to get
it working acceptably in a polling mode
so it would be better to put it in a
separate thread as well).
The problem is that somehow dosemu
doesn't like pthreads. For example if
I link it with -lpthread, at one point
all the glibc functions starts to raise
SIGSEGV with no apparent reason. On
other machines it doesn't suck that bad
but breaks DPMI, on some machines it
works fine. This looks like a glibc-dependant
problem and we don't know the solution
(any glibc gurus around? :)

I've been recently exploring the power
of the Async IO and found it even more
effective than threading in some particular
cases
http://sourceforge.net/tracker/index.php?func=detail&aid=689297&group_id=49784&atid=457449
but for adlib it doesn't look like a
solution (if at all it can be applied
to /dev/dsp).

>> Surely you could find the card with
>> even buggier third-party drivers,
>  Actually, probably not. :)
OK, their aureal_re project looks
promising, but it seems it advances
with a speed of a turtle.

>> will break recording (yeah, unlikely
>> is used under dosemu, but anyway). 
>  No problem, it can be tried to open O_RDWR first, and then O_WRONLY if 
>  the first returns fd=-1.
It is the problem however if it will
do that silently so that the user will
wonder why recording not always works.
With the appropriate error message that
looks acceptable.

> No, the problem isn't multiple openings by dosemu itself, it's that if something
> is already recording on the system, dosemu sound _playback_ won't even 
> work since the device open will fail.
Yes I see. Most devices doesn't have
the ability of a multiple opening
even for output btw, so doing something
with sound and using a dosemu for playback
at the same time is a rare (but probably a
usefull) thing.

>> > 5) I'm working on VCPI and "unreal-mode" support.  Someday, it will 
>> > happen. :)
>> Optimist:) 
>  Yea, we'll see.
No, we'll not:(
See the EMUfailures.txt:1.1

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

[Ryan Underwood]

hi,

> > be used as a smooth speed throttle. :)  If you can come up with a 
> > better delay, be my guest.
> Well, I've no idea about a
> precision you need, but if
> the precision of usleep()
> and friends is not OK for you,

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.  Try it and see
if you have the same results as me.

> then the general thing to try
> is to do a delays not on every
> access, but, say, at each third
> access etc. Dosemu already does
> the like tricks for hogthreshold
> so in general this is feasible.

Ok, I'll try to make it a little better.

> > the current patch seems to do with respect to the emulated opl), the program
> > running on real hardware simply writes data to the I/O ports and continues
> > execution while allowing the synth to process the data as a separate 
> > entity. 
> > Does that make sense?
> Of course. Threading looks like the
> only cure for adlib. Also the DMA can
> benefit from threading, but DMA works
> quite fine also in a polling mode
> because at least the buffer size is
> known (but I had to add a lot of
> heuristics about a buffer sizes to get
> it working acceptably in a polling mode
> so it would be better to put it in a
> separate thread as well).

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.

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?

> The problem is that somehow dosemu
> doesn't like pthreads. For example if
> I link it with -lpthread, at one point
> all the glibc functions starts to raise
> SIGSEGV with no apparent reason.

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.  Such as localtime()=>localtime_r() and the rest of the _r()
functions.  I'm sure you probably already know this, but it may have
slipped past you.

> I've been recently exploring the power
> of the Async IO

Interesting, will take a look at it.

> and found it even more
> effective than threading in some particular
> cases
> http://sourceforge.net/tracker/index.php?func=detail&aid=689297&group_id=49784&atid=457449
> but for adlib it doesn't look like a
> solution (if at all it can be applied
> to /dev/dsp).
 
So, basically, it seems to be a non-blocking form of polling?

> >> Surely you could find the card with
> >> even buggier third-party drivers,
> >  Actually, probably not. :)
> OK, their aureal_re project looks
> promising, but it seems it advances
> with a speed of a turtle.

Yeah, that's what happens when the company disappears without leaving us
documentation.  Well, they left documentation, but Creative has it at the
bottom of a locked filing cabinet in a rarely used lavatory, it seems.

> >> will break recording (yeah, unlikely
> >> is used under dosemu, but anyway). 
> >  No problem, it can be tried to open O_RDWR first, and then O_WRONLY if 
> >  the first returns fd=-1.
> It is the problem however if it will
> do that silently so that the user will
> wonder why recording not always works.
> With the appropriate error message that
> looks acceptable.

Yeah, just S_printf("User with buggy sound driver, please let go of the sound
device before running dosemu\n") or something similar :)

> Yes I see. Most devices doesn't have
> the ability of a multiple opening
> even for output btw, so doing something
> with sound and using a dosemu for playback
> at the same time is a rare (but probably a
> usefull) thing.

Many PCI cards will support multiple opens, not the same for ISA
unfortunately, you are correct.

> >> > 5) I'm working on VCPI and "unreal-mode" support.  Someday, it will 
> >> > happen. :)
> >> Optimist:) 
> >  Yea, we'll see.
> No, we'll not:(
> See the EMUfailures.txt:1.1

There are a few strategies I am exploring:
1) Search-and-destroy in the program image before execution, according to
heuristics, or a provided lookup table.  Relocate the bad memory writes and
nop out unnecessary privileged instructions.  This won't work in a variety
of cases:  program self-modifies, program depends on privileged instructions,
etc.  Un-realmode can be easily handled this way though because many of those
programs don't use privileged instructions besides the initial switch in
and out of protected mode.  This is the way the U7-win9x patch works.

2) When supervisor instruction is encountered, trap the fault and sent the
machine state to Bochs or other x86-emu.  Let it run the privileged
instruction(s) and/or priveleged state, and upon the program's return to
v86, return the machine state to dosemu.

3) Translate VCPI calls to DPMI equivalents?  Not sure how this would work,
and again would only be valid if the program didn't run 386 ring 0 instructions
at all.

I think #2 is the promising one, but it will be some work.

-- 
Ryan Underwood, <nemesis at icequake.net>, icq=10317253

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

[Ryan Underwood]

Hi,

> > 4) SBemu seems not quite working.
> Really? :)
> 
> > On my Aureal AU8830, when a new DMA
> > buffer is "loaded" and begins playing, I hear a click or pop, but 
> > nothing after that point.
> Surely you could find the card with
> even buggier third-party drivers, but
> at least you could visit the project
> page and dig the patches section:)
> http://sourceforge.net/tracker/index.php?func=detail&aid=680632&group_id=8109&atid=308109

I patched this patch, and SBemu is working well on Aureal Vortex
AU8830! :)  Thanks for the heads up...

-- 
Ryan Underwood, <nemesis at icequake.net>, icq=10317253

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

[Stas Sergeev]

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:)

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

[Ryan Underwood]

Hi,

> > 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.

Aha, I understand.  I will play around with it.

> Yep, the standalone adlib server
> would probably be good to have.
> Just wondering where can it be
> used besides dosemu?

Various other adlib-related things, like Sierra AGI/SCI interpreters that
are ported, plugins for sequencer software, etc.  Of course one could always
link in AdPlug or the mame opl2, but the server would simply be a
concurrent-execution method of accessing the same functionality so the
adlib-client program can simply forward the writes and worry no more after
that.

> > 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,

Yep, I think it would be a good idea to model it after how timidity works.
I need to learn how to program ALSA though. :(

> 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.

Very strange, I'll see what happens on my end when trying that.

> 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?

Well, I'm worrying mainly about the common cases -- VCPI, unrealmode, and
Win32S programs are the ones people always run into (any others you know
that people complain about?)

You are correct that it would seem reasonable to expect arbitrary supervisor
code to work as well if any of these works.  A caveat would be memory access,
since not all supervisor code is reasonable with regards to its memory usage.

VCPI programs (at least ones that don't have bugs) request memory pages before
switching to ring 0 and do not use pages besides those requested, even though
being in ring 0, they _could_ write to arbitrary memory.  We can easily serve
out malloced memory to a VCPI program and be generally assured that it won't
try to write elsewhere.  Unrealmode and other flat memory model programs
is not so nice because we don't have any way to confine its memory accesses,
that I can see.  So either the program itself will have to be patched, or
else somehow trap the memory fault and handle it in there when the program
tries to write to 0x0 ?

WFWG3.11 is a VCPI client, and Win95 seems to be a VCPI client as well. 
I wonder if we could run win95 in dosemu eventually?

I copied over my Win-OS2 install, which is a hacked WFWG3.11 from IBM for
use with OS/2, that is a DPMI client instead of VCPI.  But, I couldn't get
it to run yet. :(

I have implemented a VCPI server, mostly, per the VCPI spec (in emm.c), so
most VCPI programs get as far as the ring 0 switch before crashing.  It'll
take some work to get to the next part.

Its weird though.  It seems like doing this is turning dosemu into what plex86
tried to be. :)

> 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.

Interesting, I will take a look at it.

> 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:)

Yep, my long-standing dream is to run Privateer (a VCPI client) under dosemu.
Once I can do that, we'll be in good shape. :)

-- 
Ryan Underwood, <nemesis at icequake.net>, icq=10317253

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

[Stas Sergeev]

Hello.

Ryan Underwood wrote:
>> Just wondering where can it be
>> used besides dosemu? 
>  Various other adlib-related things, like Sierra AGI/SCI interpreters that
>  are ported, plugins for sequencer software, etc.  Of course one could 
>  always link in AdPlug or the mame opl2, but the server would simply be a
>  concurrent-execution method of accessing the same functionality so the
>  adlib-client program can simply forward the writes and worry no more 
>  after that.
Yes, that can be usefull. The
downside of that approach is
that the program can itself keep
the /dev/dsp busy (like dosemu does)
and your adlib server will conflict
with an app trying to output the
sound. Of course for the cards that
allows multiple streams this is not
a problem, but for others (like the
pc-speaker:) this can be troublesome.
Perhaps the only solution would be
to make dosemu to use some sound server
and to make your adlib server to use
the same. By linking dosemu with mame
opl emu and implementing the mixing
(which is necessary for dosemu anyway)
doesn't have the aforementioned problem.
The alternative could be to implement
the entire SB in a separate server.
DMA needs to be in another thread/process
anyway, so nuking the SB out of dosemu
and to a separate server process can
be great I think.

> I copied over my Win-OS2 install, which is a hacked WFWG3.11 from IBM for
> use with OS/2, that is a DPMI client instead of VCPI.  But, I couldn't 
> get it to run yet. :(
Probably you have to try 3.1
instead of 3.11.

> Its weird though.  It seems like doing this is turning dosemu into what 
> plex86 tried to be. :)
I don't know much about plex86, but
the power of dosemu is in its great
integration in a linux environment,
i.e. ability to work with the mounted
filesystems, networking etc. Also
dosemu has a good speed due to running
the progs natively rather than emulating
the CPU (emulating only the privileged
instructions is not a big slowdown).
Does the plex86 have all that?

>> simx86 and implement some missing
>> features to it rather than using a
>> bochs as a CPU-emu server as you suggested.
>  Interesting, I will take a look at it.
To make your life easier here is a
patch that resurrects a real-mode part
of simx86 (prot mode is still broken but
it was functional in the past)
https://sourceforge.net/mailarchive/forum.php?thread_id=1662943&forum_id=8386