Hi, > According to this, it would be easier to patch doom itself: > http://www.jsiinc.com/dl/SoundFX.txt
No good; most of the games patched using cli2nop crash after a few seconds; with the patch there is the risk it replaces what it is not supposed to replace, and/or not replace cli sequences that it should. Plus always keeping interrupts enabled could be asking for trouble (and random crashes) -- if the game uses sti/cli for mutual exclusion then keeping interrupts enabled all the time won't guarantee any mutual exclusion. If DosEmu *does* disable interrupts but forcefully re-enables them later (as opposed to always keeping them enabled), then you're somewhat safer. > Wait for a certain period and reenable ints could probably be > a good workaround, > but there are seem to be some problems: this cli/popf > sequence really *locks* > dosemu, it's timer stops, it eats 100% CPU, it doesn't > receive signals anymore, > nothing, only kill -9. Haven't looked in the IRQ0 emulation code of DosEmu, but I'd imagine the emulated PIT either continues to try to generate IRQ0's from a Linux timer (but they are not delivered), or DosEmu tries to be smart and pauses its Linux timer. All the rest (i.e. keyboard) should be dead except for magic key combinations, this is normal. The CPU is at 100% probably because of Doom being stuck in a busy-wait on some flag (supposed to be set from the iNT8 handler, I guess) that never gets modified. Now, if the Linux timer continues to run then it should be easy to implement the CLI workaround I outlined in my previous mail (e.g. if more than a second has elapsed since the last CLI then force a STI). > BTW, you suggested me to visit your page to find out undocumented DSP > commands. One very old game called Millenium writes to DSP > the following > commands: 0x06, 0x6b and 0xe2. Then it reads from a Reset > address, while > Creative's manuals claims that it is Write-only. I failed to > find in your > code something that could give me a hint such as what this > program expects > from DSP... Programs usually read from the reset port, but they read garbage and AFAIK they only do it for timing purpose (i.e. they assume the ISA bus frequency is whatever MHz, so they do a couple of INB's to get a microsecond-delay independently of the CPU's frequency). If the program reads several times in a row from port 0x226 (I think that's the reset one) then it's just a delay trick. Command 0xe2 was a pain to reverse-engineer. Are 0x06 and 0x6b actual commands, or arguments to a command (e.g. 0xe2)? 0xe2 was used in Creative's drivers for Lucas Arts games like Wing Commander, but I've never seen commands 0x06 or 0x6b. > How bad the fact that there is no a pc-speaker driver for NT > so that I could > try your code out. :) Get a sound card! Or are you out of ISA/PCI slots? :) There is a PC-speaker driver for Windows, but it is fully synchronous (i.e. your machine is blocked until the sound finishes playing), so it's only good for UI sound effects (no good for listening to MP3's or use for DOS emulation). Cheers, Vlad. - 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
