App database, libsynth
Hello.
Quoted 8 lines · Ryan Underwood
Quoted 3 lines
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/dspkernel 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.
Quoted 1 line
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
Quoted 4 lines
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.
Quoted 1 line
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.
Quoted 1 line
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.
Quoted 1 line
So the "compatibility mode" is only good for running the 32-bit applications while in longmode. Correct?
No: 16 bit is also OK.
Quoted 1 line
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:)
Quoted 3 lines
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.
Hi Stas,
Quoted 11 lines · Stas Sergeev
Hello.
Quoted 8 lines · Ryan Underwood
Quoted 3 lines
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/dspkernel device would bypass it. The aoss wrapper intercepts those writes and puts them through alsalib instead, allowing dmix to be used.
Quoted 10 lines
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.
Just tried aoss. It didn't work too horribly on the ones I tried (Duke3D, Hardball III). The sound warbles and there are lots of clicking, but overall it could be a lot worse. Also some sound is repeated, like there is a buffer underrun and the buffer gets wraped around, or something like that. Duke3D sounds pretty good which surprised me a lot, considering it is hard on the sound card, and my Vortex driver is still in pre-alpha for ALSA. :)
Quoted 10 lines
Quoted 2 lines
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 thePCM->PDMconversion and not the vice-versa (no recording via speaker:), and also the code there is complicated by a software amplification tricks.
Just to make sure, the PC speaker needs no programming besides writing to the two hardware ports, correct?
Quoted 4 lines
Quoted 4 lines
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?
Quoted 9 lines
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.
I see that now. Very nice. I wonder if there is an easier way to set the MIDI up than making the user manually connect pipes with MIDI devices. Perhaps dosemu could use a launcher program of some sort?
Quoted 9 lines
Quoted 2 lines
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.
Hmm, so what's the best way to use a OPL3-emulated sequencer from dosemu? If I make it an ALSA client, people using midid will not be able to use it. If I make it a server application that midid talks to, it is less flexible for the people who could use it through ALSA applications.
I could do both but that takes a lot of time. :)
Quoted 6 lines
Quoted 2 lines
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...
What does wine use it for? I think XFree86 uses it for Int10 support too.
Quoted 3 lines
Quoted 2 lines
So the "compatibility mode" is only good for running the 32-bit applications while in longmode. Correct?
No: 16 bit is also OK.
But not 16-bit realmode applications or 32-bit ring0 applications either?
Quoted 8 lines
Quoted 3 lines
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:)
:)
Quoted 6 lines
Quoted 3 lines
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->win95might also be possible.
Those VCPI-games should be taken care of like that too, Privateer, Strike Commander et.al.
Signature · 1 line
Ryan Underwood, <nemesis at icequake.net>, icq=10317253