From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Ryan Underwood" Subject: Re: various dosemu comments and hacks (sound, delays) Date: Mon, 24 Feb 2003 23:14:24 +0000 Sender: linux-msdos-owner@vger.kernel.org Message-ID: <20030224231428.3B02A75372@mail.icequake.net> References: <3E5A78CA.8070603@yahoo.com> Mime-Version: 1.0 Return-path: List-Id: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Stas Sergeev Cc: linux-msdos@vger.kernel.org Hi, > > 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. > 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. > > 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? > 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. :( > 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. > 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. :) > 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. > 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. :) -- Ryan Underwood, , icq=10317253