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

["Ryan Underwood" <nemesis-lists@icequake.net>]

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