From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Ryan Underwood" Subject: various dosemu comments and hacks (sound, delays) Date: Mon, 24 Feb 2003 03:35:05 +0000 Sender: linux-msdos-owner@vger.kernel.org Message-ID: <20030224033507.84BBA75370@mail.icequake.net> Mime-Version: 1.0 Return-path: List-Id: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-msdos@vger.kernel.org Hi, I've been working with the new dosemu 1.1.4.13 and hacking some stuff. Here are my observations and a few questions. ------------------------------------------------------------------------------ 1) Ctrl-Alt-F fullscreen crashes dosemu with a X-Shm (Shared memory) error if I use the key combination for the first time when inside a graphical game. If I use it when dosemu is sitting at a prompt, it works fine, and I can then enter a game. Further, I can window/fullscreen toggle all I want after that point, and it is fine. It just can't be in a game when toggling it for the first time. Minor problem. ------------------------------------------------------------------------------ 2) In order to solve the problem of classic games running too fast, I have hacked in delays in two select places to take care of specific common cases without destroying others. One reason the games run too fast is because writes to VGA hardware take far less time than they used to, and depending on the program being blocked for a certain amount of time during display writes is an assumption that falls through today. Wing Commander I as a whole, and Wing Commander II's cinematic sequences suffer from this problem. Utilities like Moslo do not help because it can only delay software interrupt routines and not hardware like the VGA. However, since we have an emulated VGA core now thanks to the X11 code, we have control over how long VGA writes take to complete. In essence, I added the following code in src/env/video/vgaemu.c in vga_emu_fault(): static int bogo = 0; if (!bogo) { bogo = config.cpu_spd / 8; printf("Speed delay in vgaemu.c is %d\n", bogo); } for (i = 0; i < bogo; i++); This simulates a slow graphics card/video bus pretty well. Wing Commander I is perfectly playable on my machine (800Mhz Celeron). However, for this code to work, the following config option must be set: $_X_updfreq = (1) # time between refreshes (units: 20 == 1 second) Not setting it, or setting it to any other value causes the game to be as speedy as it was without my delay inserted. Why is this? I also inserted another delay in miscemu.c, Misc_get_input_status_1(): static int vvfreq = 0; if (!vvfreq) { vvfreq = config.cpu_spd / 120; printf("Speed delay in miscemu.c is %d\n", vvfreq); } which causes the code to wait longer before returning that we are in vsync, depending on how fast the machine speed is. Now, this may cause more problems with tearing, but I didn't notice any that weren't already there. The advantage to the delay here is that applications that constantly poll for vsync in a loop can be smoothly slowed by making the app wait for a bit each time. This helps in some parts of Wing Commander like the intro where it is still too fast even with the VGA write delay, but polls for vsync. Combining both of these loops seems to provide a flexible means for slowdown. I think the divisor should be configurable by the user, perhaps even at runtime through a stub utility like the other dosemu utilities. ------------------------------------------------------------------------------ 3) The Adlib emulation is not working well on my machine. I am working on an implementation which will use a separate Adlib sound server to handle the emulation, so DOSemu isn't constantly being blocked by the Adlib emulation code. ------------------------------------------------------------------------------ 4) SBemu seems not quite working. On my Aureal AU8830, when a new DMA buffer is "loaded" and begins playing, I hear a click or pop, but nothing after that point. In order to get this far, however, I had to change the two opens of /dev/dsp from O_RDWR to O_WRONLY. The AU8830, like some other cards, only allows one application at a time to open the device for reading. Subsequent attempts at opening for read causes driver to return -ENOMEM. It is a broken feature, to be sure, but if open O_RDWR fails, the open should be retried O_WRONLY to get around this brokenness. The offending opens are in linux_sb_get_version() and linux_sb_enable_speaker() in src/arch/linux/dosext/sound/linux_sound.c. ------------------------------------------------------------------------------ 5) I'm working on VCPI and "unreal-mode" support. Someday, it will happen. :) ------------------------------------------------------------------------------ Let me know if you have any comments! -- Ryan Underwood, , icq=10317253