Ryan Underwood wrote:
Yes. But I was wondering will they be able to use dmixUnfortunately not without the wrapper. The dmix is done
both. Is it available via the OSS emulation layer at all?
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.
- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
