various dosemu comments and hacks (sound, delays)
Hello.
Quoted 3 lines · Ryan Underwood
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.
Quoted 1 line
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?
Quoted 7 lines
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/dmfmand 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.
Quoted 3 lines
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.
Quoted 3 lines
Quoted 2 lines
I've been recently exploring the power
of the Async IOSo, 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.
Quoted 1 line
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:)
Hi,
Quoted 7 lines
Quoted 1 line
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.
Quoted 4 lines
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.
Quoted 7 lines
Quoted 7 lines
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/dmfmand forwards the writes to userspace emulation daemon, which then outputs to/dev/dsp.
Which way do you think is better?
Quoted 5 lines
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. :(
Quoted 6 lines
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.
Quoted 5 lines
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. :)
Quoted 8 lines
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.
Quoted 7 lines
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. :)
Signature · 1 line
Ryan Underwood, <nemesis at icequake.net>, icq=10317253