Re: App database, libsynth

[Stas Sergeev <stsp@aknet.ru>]

Hello.

Ryan Underwood wrote:
>> Yes. But I was wondering will they be able to use dmix
>>  both. Is it available via the OSS emulation layer at 
>> all?
> Unfortunately not without the wrapper.  The dmix is done
>  in userspace, so writing to /dev/dsp kernel device would
>  bypass it.  The aoss wrapper intercepts those writes and
>  puts them through alsalib instead, allowing dmix to be 
> used.
That practically means using dosemu's OSS output
plugin will not be possible that way. It does all
the possible things to make it not compatible
with any redirectors. Leaving apart the nonblocking
I/O, it also writes a partial fragments, demands
the precise quering of a current buffer load and
all the other weird things, so it is not compatible
even with most of the third-party OSS drivers.
But have you tried it with aoss? I have to port my
pcsp driver to ALSA before I can do that.

> The PC speaker would seem to fit that model, so if you 
> have some emulation code, I should be able to include it.
Unfortunately I don't have anything like that.
The program I was referring to, was written in
Pascal.
You can also have a look in my pcsp driver, but
it does only the PCM->PDM conversion and not
the vice-versa (no recording via speaker:),
and also the code there is complicated by a
software amplification tricks.
Finally you may want to steal the code from a
dosbox, but it is in C++.
There are some explanation about PDM (aka PWM)
on the net in case you are wondering:
http://www.wikipedia.org/wiki/Pulse-width_modulation
http://www.powerdesigners.com/InfoWeb/design_center/articles/PWM/pwm.shtm
http://www.netrino.com/Publications/Glossary/PWM.html

> If the timidity/mt-32 emulator becomes an ALSA sequencer
>  client (which is the optimal situation so it can be used
>  in any ALSA application), how would dosemu/midid support
>  it?
No modifications at all. See sound-usage.txt
about how to use dosemu->ALSA->timidity. This
is quite fundamental and doesn't require midid.
But to keep the midid up-to-date, probably some
small modification to the midid's timidity
frontend will be required, as currently it
assumes that only GM is supported. That is for
the OSS users, as ALSA users doesn't need midid
at all.

> Interesting.  What about making the ALSA sequencer a 
> backend for midid?
No, actually there is an overlap of a functionality.
midid is also a kind of a sequencer. It receives the
same data on input the alsa sequencer receives. It
can't work after/before the ALSA sequencer because
they are doing the similar job. Only the output is
different: midid talks to timidity's server interface,
while alsa talks to timidity's alsaseq interface.

> So under longmode there will be no more vm86() and we 
> will definitely need to use QEMU.
Unless someone will finally implement it, which
is unlikely but not impossible: after all also X vesa
driver uses it, and so does wine, so there might be
some motivation after all...
The syscall will have to switch the CPU between the
longmode and the legacy mode, which is possible, as
per the link in a previous posting.

> So the "compatibility mode" is only good for running the 
> 32-bit applications while in longmode. Correct?
No: 16 bit is also OK.

> I think most people will be using longmode on AMD-64 
> anyhow, so we should get the fast CPU emulation going as 
> soon as possible.
The speed is not a problem on that CPUs I
guess. The problem is to make a relatively bug-free
CPU emulator. Lets see if the qemu people can do
that, otherwise qemu will add bugs to dosemu, while
dosemu has plenty of its ows ones:)

> Side effect of the CPU emulation : can we do things with
> it like run Win95 or other VCPI program underneath
> DOSEMU?
I think it will be possible. Right now qemu can
run Linux kernel itself, so running
linux->dosemu->qemu->win95 might also be possible.