RE: DMA-Sound support in dosemu
Hi. Vlad Romascanu (LMC) wrote: However, even if the transfer was block it will still pause on terminal-count if DREQ is deasserted, no? From manual: The difference between Block and Demand is that once a Block transfer is started, it runs until the transfer count reaches zero. DRQ only needs to be asserted until -DACK is asserted. So I don't think DSP have something to stop it. But also I am not sure whether it is possible to use block mode for sound transfers at all: how then DSP can control a transfer speed (sampling rate)? So, if it is not possible, then pausing DRQ == pausing DMA. Seriously, though -- trackers will want 16-bit stereo sound. Is this why FastTracker2 plays twice as slow with my code? How good does it work with yours? 16-bit DMA is very easy to implement. I don't know exactly how easy it is to implement, but I suspect this will require an implementation of DMAC cascading/cascade mode, which what I don't currently know how it works (probably in need of a good specs). No: starting DMA transfers from the inthandler, relying at the same time on the execution outside of inthadler seems to be stupidity in any case. Why? I was merely suggesting using Pause as a non-reentrancy/guarding technique (other than cli) -- called from *within* the int handler, of course. Because int is mostly an async event. Yes, you can pause DMA and safely leave the handler, but how can you know *where* will you be after iret? Where is to put an unpause? You will have to do some synchronisation probably with global volatile variables and waitpoints in the main code. But then it is better to start transfer from the main code and do only ACKing from the handler. This is all about that 5-byte xfers that ST3 does for SB detecting. If you are going to do real transfers, than you may not worry about recurseing into inthandler and it is OK. But doing *short* test transfers from within inthandler seems unreliable to me. ST3 sets a transfer with disabled speaker. This produces an interrupt. One moment -- Disable Speaker (0xD3) is not supposed to generate IRQs, no? I didn't say that. ST3 *sets a transfer* with disabled speaker is what I said. Interrupt is produced by the transfer (when it is over), not by the disabling speaker, of course. It theoretically only acts as a mute (and, according to my docs, it Maybe. But I have a feeling that when you do a transfer with a speaker being disabled, DSP keeps DRQ asserted during the whole transfer, ignoring the sampling rate. So it is possible that the transfer with the disabled speaker is going much faster than with enabled. But this is nothing more than my internal feeling:) There is nothing in my docs about it. What I do: If (speaker_is_disabled transfer_started_from_inthandler) wait_for_a_several_cpu_cycles; Start_the_transfer; Tzk, tzk, tzk, you cheated -- the SB is not supposed to know that the CPU is in an interrupt handler. ;) Long before I started doing sound stuff, I wanted to implement a safeguard for PIC that will prevent the inthandler for an int with the equal or lower prio to be executed without giving some CPU cycles to a main code. This would solve the aforementioned as well as many other problems. But my PIC patches are still kept away from dosemu:) That is why I am introducing such a dirty hacks:( Interesting, though -- I assume ST3 sets up such a small DMA block size that the IRQ occurs while the ISR is pre-empted. ... only at a detection phase, of course. This is a pain, though, because other games (e.g. Rex Nebular) will actually fail SB detection if the IRQ does not come soon (they set the DMA block size to a few bytes, e.g. 4 bytes, and time-out/fail detection if an IRQ is not emulated within 5-10ms). This is exactly what I have with IPlay (Inertia Player), but fortunately it is clever enough to not set such a short transfers from within an inthandler so no problems with it. I wonder if it is possible to figure out under NT is the process currently inside an inthandler or not? I can feel like ST3 doesn't work under your emulator, right?:) And differences between DMA DMA block size and DSP DMA block size are not an issue for me, all cases (less, equal, greater) work fine with other apps. :) This means that you are doing a smoother transfers, probably you even have another thread for DMA? Dosemu is single-threaded (threading support was removed not so long ago for the reasons unknown to me) so I have to do a very large xfers (I can't be sure that I will have a control within the next few seconds or not). This produces a nasty bursts and some programs stuttering. That is why I have some heuristic code about a transfer sizes, but unfortunately this doesn't work very well. I don't know what to do with it:( I suspected DPMI before I saw your message a But ST3 doesn't use DPMI! Dosemu have a global variable in_dpmi that allows to figure out easily are we using dpmi or not. From outside dosemu you can do a
RE: DMA-Sound support in dosemu
Hello. Vlad Romascanu (LMC) wrote: you (the SB) can always deassert DRQ and the DMAC will actually check DRQ when reaching terminal-count, no? Yes (even in auto-init I think, my docs are incomplete though), but how to stop block DMA xfer when TC is not yet? I mean I can issue a Pause command to DSP at any moment, and what DSP can do? Buffer the end of the block? So even if you are in auto-init, the SB would still be able to insert transfer pauses (until its internal buffer is almost empty) during auto-init DMA. Of course, all this assuming that pre-SB16 cards did have buffering (which is not so obvious). I think (again, only my internal feeling:) that DSP simply asserts DRQ with frequency equal to its sampling rate, so buffering is not necessary (8-bit DMA transfers 1byte/request). That is why I assume that block mode transfers are not possible here - DRQ freq doesn't matter in this case and buffering the entire block is not possible as you already mentioned. I have a good data-sheet from Intel from the DMAC -- I think I grabbed it on ALSA (or was it Bochs?) I can also e-mail it to you if you want. This would be nice:) No, you pause DMA, do all the time-consuming double-buffer memory xfer, then resume DMA and IRET. But here you are probably talking about auto-init (for DSP), while ST3 uses single-cycle. Once the memory xfer is done (i.e. DMA has been resumed), the ISR doesn't really care about re-entrance anymore unless If we are talking about single-cycle (and atleast I am talking about it:) then DMA will not start anyway until you have done everything so what is the use of pausing it? or it's doing 10-byte long transfers between IRQs :) ... which is exactly what it does:) I'be been hacking away at NTVDM.EXE for quite a while. Hmm... Do you have a sources for it or whatever?? Yes, I have another thread for DMA. But I guess you have the advantage of being notified by the emulated DMAC whenever data is to be transferred... or are you not? No. Emulated DMAC doesn't control the transfer at all. Transfer function is called ocasionally (on timer tick or on fault) and trying to fill up an OSS buffer. So it is Linux driver who controls the transfer. If there is some free space in linux buffer, I am transferring, if no - I am waiting (actually it is simply a non-blocking write()). It's been one year since I peeked at DosEmu, I guess many things have changed in that interval too. :) The short answer is... No, not at all:( Almost nothing (except for the current devcycle). I grab data every T milliseconds, where T self-adjusts between user-define bounds (default 5 and 15ms). I would expect this T to actually depend of a sampling rate:) And how many data you are transferring at once? OSS manual recommends to transfer a one full fragment per one write() call, so I am very limited here... I am ignoring this recommendation, of course, but this makes some drivers to work unreliably:( I wonder if I can steal some OPL code from your emulator? Does it produce a digital sound, or it uses a midi capabilities for output? - 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
RE: DMA-Sound support in dosemu
Yes (even in auto-init I think, my docs are incomplete though), but how to stop block DMA xfer when TC is not yet? I mean I can issue a Pause command to DSP at any moment, and what DSP can do? Buffer the end of the block? Yes, that would be a sensible thing to do (buffer the end of the block) provided that buffering existed on pre-SB16 machines (of which I am not very sure, i.e. I don't think buffering existed). So it would just lose data and produce silence/garbage/repeat, depending on the internal implementation of the SB. :) I think (again, only my internal feeling:) that DSP simply asserts DRQ with frequency equal to its sampling rate, so buffering is not necessary I agree with you (at least on pre-SB16 models). Block transfers would not be feasible (I mean you could program the DMAC for block transfer, but pre-SB16 -- and even SB16's, if the block is very large -- would screw up, or maybe even lock up depending on how well they were designed). or it's doing 10-byte long transfers between IRQs :) ... which is exactly what it does:) Oh... :) I'be been hacking away at NTVDM.EXE for quite a while. Hmm... Do you have a sources for it or whatever?? Not quite... but MS was, well, how should I put this, kind enough to provide the symbols, he he he... ;) I grab data every T milliseconds, where T self-adjusts between user-define bounds (default 5 and 15ms). I would expect this T to actually depend of a sampling rate:) Yes, it partially depends on the sampling rate. Also the module responsible for the output (disk or sound) sends a feedback value that shapes the DMA traffic depending on the data needs (e.g. if the sound buffer is too full then it will tell the DMAC thread to slow down, and if the buffer is below a certain threshold then it will speed up the xfer; this adjustment is made on top of the ideal rate which is a function of the sample rate). And how many data you are transferring at once? OSS manual recommends to transfer a one full fragment per one write() call, so I am very limited here... I am ignoring this recommendation, of course, but this makes some drivers to work unreliably:( I always round up to 1 or 2 samples, depending on whether it's mono or stereo sound. That's about the only limitation, though. I wonder if I can steal some OPL code from your emulator? Does it produce a digital sound, or it uses a midi capabilities for output? Produces digital sound. Go ahead and steal it, it actually was in turn stolen from MAME (GPL'd as well). I may look into making further modifications for OPL3, but that remains to be seen (time is a very sought after commodity). :) You will need to mix the sounds though (DSP+OPL), and moreover you may find it difficult to do in a single-threaded app. (i.e. the end reult may sound weird, with a broken tempo) :( V. - 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
RE: DMA-Sound support in dosemu
Hi, Stas, From manual: 0xD0: After receiving this command, the DSP will cease to send out DMA requests. So, it seems that Pause also only pauses DRQ, which doesn't mean a pause for block mode (BTW, are there any progs that uses DMA block mode for sound? I know Doom uses demand mode, but I've never seen someone using block). I haven't encountered a program that does block-mode xfers yet. However, even if the transfer was block it will still pause on terminal-count if DREQ is deasserted, no? I don't suspect DSP to be able to pause DMA by something more than just stop DRQs. Yes, the SB deasserts DRQ. Sorry, I have a tendency to talk of the SB and DMAC more or less interchangeably when DMA is concerned. :) And I don't see any reasons for implementing SB16: all programs have a support for SBPro/classic SB. And implementing SB16 is an additional headache: I have to implement 16bit-DMA. Is 16-bit, 48kHz stereo sound a good reason?! May not make a difference on pc-speaker drivers, I agree... ;) Seriously, though -- trackers will want 16-bit stereo sound. 16-bit DMA is very easy to implement. No: starting DMA transfers from the inthandler, relying at the same time on the execution outside of inthadler seems to be stupidity in any case. Why? I was merely suggesting using Pause as a non-reentrancy/guarding technique (other than cli) -- called from *within* the int handler, of course. I assume that even when speaker is disabled, DMA transfer still goes and takes some time. BTW, is this correct? Or, when speaker is disabled, there is no transfer and the interrupt is generated immediately? I have no idea really, since my main documentation source only says that it pauses DMA only for SB1.x (I can take a look at the Creative Developer Kit docs again, assuming they give more details than my main documentation). So in other words you halt DMA xfers until the DMAC is reprogrammed? Is No. The scenario is this: ST3 sets a transfer with disabled speaker. This produces an interrupt. One moment -- Disable Speaker (0xD3) is not supposed to generate IRQs, no? It theoretically only acts as a mute (and, according to my docs, it actually has no effect on the speaker on the SB-16). Interrupt handler ACKs and starts a new transfer with speaker still off. This produces an int before inhandler's IRET, so, after an EOI, the handler is executed again immediately, without any chance of executing the main code. It starts the transfer again... and again. Deadloop. What I do: If (speaker_is_disabled transfer_started_from_inthandler) wait_for_a_several_cpu_cycles; Start_the_transfer; Tzk, tzk, tzk, you cheated -- the SB is not supposed to know that the CPU is in an interrupt handler. ;) Interesting, though -- I assume ST3 sets up such a small DMA block size that the IRQ occurs while the ISR is pre-empted. This is a pain, though, because other games (e.g. Rex Nebular) will actually fail SB detection if the IRQ does not come soon (they set the DMA block size to a few bytes, e.g. 4 bytes, and time-out/fail detection if an IRQ is not emulated within 5-10ms). ST3 using single-cycle or auto-init? I can feel like ST3 doesn't work under your emulator, right?:) It uses single-cycle with the transfer size for DSP being much larger than for DMA. You guessed: no, it does not work. And differences between DMA DMA block size and DSP DMA block size are not an issue for me, all cases (less, equal, greater) work fine with other apps. :) Also, auto-init DMA works fine with single-cycle DSP commands, and single-cycle DMA works fine with auto-init DSP commands. I suspected DPMI before I saw your message a couple of days ago, which is why my interest surged like that. :) 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
Re: DMA-Sound support in dosemu
On Tue, 15 Jan 2002 12:03, Stas Sergeev wrote: [snipped] Hello. pesarif wrote: I've had mixed results with your new patches. In general, the code seems to have gotten slower but works better. What do you mean by code seems to have gotten slower? Slow execution or slow sound? Or somethig else? Liero and OMF2097 sound stutters a bit (the kind of sound stuttering you hear when a system is under a heavy load). Here are some results of testing: You have done a very good work actually, thank you for such a detailed testing (esp. for the comparision with the old code!) Program no sound patchesoriginal sound patches new sound patches (sb pro)(sb pro)(sb or sb clone) Jill of the Jungle no sounddistorted perfect (even better than win98!#) Scream Tracker 3 locks uplocks upperfect Wolfanstine 3D no soundno soundperfect # Seems strange: Wolf used to work for me previously. And the detection problems are Adlib-related I think. Swiv3D no soundintro works perfect Descent perfect stuttersperfect Warcraft 2 stutters horribly works perfect Spitwad Willy no sound? perfect What is ? :) I forgot to test it :) This all looks very good. Detection problems are deferred, as I mentioned above. Count Down initial sound, lock up stutters,clicking perfect,clicking Clicking is generally caused by an OSS limitations (buffer must be empty if I want to change speed, I have to reopen (!!!) the device if I want to change fragment size) or by direct DAC writes (which I can't improve - pc-speaker problems). So this is also deferred (see below). One Must Fall 2097 perfect music is too fast music skips stutters * Fixed: http://www.dosemu.org/~stas/snd-patch1-1.1.2.diff.gz This game uses an undocumented ability of a command 0x1C to set a transfer length. Previously none of my programs does this, so I didn't implemented this, while now I can see it was implemented in the old code. Thanks for pointing this anomaly. Actually I was thinking that my test suit is rather large, but apparently it was not. Good! I'll try out your patch. Liero no soundperfect sound stutters * I can only hope that it is the same problem as above. And if it is not, I need this game (link) or the debugging output. I was given version 1.33 (freeware) by a friend. http://www.freewaregaming.com/aa/liero.html Clyde's Adventure no soundpartial partial What is partial? The music (not MIDI or adlib) cannot be heard. Normal sound effects can't be heard. But the Arrh!! sound of Clyde dying is about the only thing that can be heard. Need for Speed no soundno soundno sound Shell Shock perfect no soundno sound * Not good. Link or debugging output needed. I can't find a link. Perhaps I could send it to you OL (it's shareware after all)? Monster Bashno soundno soundno sound Kiloblaster no soundno soundno sound Clyde's Revenge no soundno soundbombs out Mugen no sounddos4gw exceptiondos4gw exception What??? Give me a link to this one, please! Oh, I beleive it is DMA problems again:((( http://www.elecbyte.com It was written in DJGPP/Allegro (and most games that use this combo don't work and cause a dos4gw exception). Commander Keen 4no soundno soundlocks up :( * I guess this game is not very large for download?:) http://www.apogee1.com/downloads.html 2.4keen.zip - Goodbye Galaxy v1.4 shareware episode (712k) Cosmo locks uplocks uplocks up Not now... (for Oliver Ob: with Stas' latest patches, Scream Tracker 3 works perfectly if you use SET BLASTER=A220 I7 D1 T1 and it plays MODs very nicely) ST3 was a troublesome beast. I added a support for it only after you have mentioned it here:) It sets a DMA transfer from an interrupt handler when speaker is disabled, so retriggering the interrupt immediately causes a deadlock. And also it sets a transfer size for DSP *much* larger than for DMA, while the sane way is opposite. So it required some dirty hacks:( Just wondering...but how can you write and test sound code without a sound card? I mean, you're doing a very good job without one! I can't hear the music in any of the games above (except for OMF 2097 and
Re: DMA-Sound support in dosemu
Hello. pesarif wrote: I did all your patches at that URL (sound + serial) and got: i.e. the serial patches required fuzzing and the DPMI patch failed. Using dosemu 1.0.2.1. What I am doing wrong? At least one thing: serial patches have nothing to do with sound stuff, so it is not necessary to apply at all (testing them is a good idea anyway:). And DPMI patch was diffed against dosemu-1.1.2 and it is necessary only for better SB detection, but there were some more patches for this, which I am currently submitting, so detection will be available later. I am excluding DPMI and PIC fixes from my sound patch to prevent any further confusion. Don't forget to reinstall your sources after you got rejects. And, btw, what do the serial patches do (do they make null-modem games work?)? Maybe, but I was solving a problem that prevented me from transferring files more that 10Kb size via modem. With that patch I am no longer limited in a transfer size. I would be glad to hear that it also fixes something else (which is rather possible). Note2: you have to select Sound Blaster clone or Sound Blaster or 100% compatible in your games, but not Sound Blaster Pro and of course not Sound Blaster 16 or AWE32. Why not? I used to be able to select Sound Blaster Pro, but I can't anymore in any of my games and this is reducing the sound quality in some games. This is not a mandatory, at least I hope that all the programs that used to work with SB Pro before, will work with it also now. I just want to warn you that some programs will not work if you specify SB Pro, and will work with SB. I don't want to drop any functionality of course. My original goal was to completely outperform the old code. But your tests indicates that this goal will require some more work than I expected. I've had mixed results with your new patches. In general, the code seems to have gotten slower but works better. What do you mean by code seems to have gotten slower? Slow execution or slow sound? Or somethig else? Here are some results of testing: You have done a very good work actually, thank you for such a detailed testing (esp. for the comparision with the old code!) Program no sound patchesoriginal sound patches new sound patches (sb pro)(sb pro)(sb or sb clone) Jill of the Jungleno sounddistorted perfect (even better than win98!#) Scream Tracker 3 locks uplocks upperfect Wolfanstine 3Dno soundno soundperfect # Seems strange: Wolf used to work for me previously. And the detection problems are Adlib-related I think. Swiv3Dno soundintro works perfect Descent perfect stuttersperfect Warcraft 2stutters horribly works perfect Spitwad Willy no sound? perfect What is ? :) This all looks very good. Detection problems are deferred, as I mentioned above. Count Downinitial sound, lock up stutters,clicking perfect,clicking Clicking is generally caused by an OSS limitations (buffer must be empty if I want to change speed, I have to reopen (!!!) the device if I want to change fragment size) or by direct DAC writes (which I can't improve - pc-speaker problems). So this is also deferred (see below). One Must Fall 2097perfect music is too fast music skips stutters * Fixed: http://www.dosemu.org/~stas/snd-patch1-1.1.2.diff.gz This game uses an undocumented ability of a command 0x1C to set a transfer length. Previously none of my programs does this, so I didn't implemented this, while now I can see it was implemented in the old code. Thanks for pointing this anomaly. Actually I was thinking that my test suit is rather large, but apparently it was not. Liero no soundperfect sound stutters * I can only hope that it is the same problem as above. And if it is not, I need this game (link) or the debugging output. Clyde's Adventure no soundpartial partial What is partial? Need for Speedno soundno soundno sound Shell Shock perfect no soundno sound * Not good. Link or debugging output needed. Monster Bash no soundno soundno sound Kiloblaster no soundno soundno sound Clyde's Revenge no soundno soundbombs out Mugen no sounddos4gw exceptiondos4gw exception What??? Give me a link to this one, please! Oh, I beleive it is DMA problems again:((( Commander Keen 4 no soundno
Re: DMA-Sound support in dosemu
Hello. pesarif wrote: I got dropped from the list for a while (don't know why so I rejoined), did I miss any other of your patches? If so, please send them to me. No, I haven't posted any more due to a complete lack of interest. But I have just uploaded a latest version to http://www.dosemu.org/~stas/snd-patches0-1.1.2.tar.gz so give it a try. There is a sound patch and 2 additional small fixes that will improve an SB usage for some DPMI programs. Note: some features mostly related to a detection of soundblaster's presence are disabled because it requires a changes to PIC, which are not yet merged to a mainstream. But this is not very noticeable, I hope. Note2: you have to select Sound Blaster clone or Sound Blaster or 100% compatible in your games, but not Sound Blaster Pro and of course not Sound Blaster 16 or AWE32. The particular patch that you sent with the email I'm replying to is really great. Now Liero works perfectly (it didn't before) and so does Warcraft II Thanks for a good feedback:) (without MIDI, of course). Have you tried to select General MIDI or MT32 or something MPU401 for midi? It must work perfectly if you have /dev/midi working (your sound card must support this feature) and dosemu is properly configured. And Adlib midi is a sad story: it doesn't work currently and I can't help it due to a lack of the sound card (actually I don't have a free slot for it, maybe I have to by an USB-ISA converter, but it is still *very* expensive). But I am working on porting my pc-speaker driver to a newer OSS api to make it compatible with SoftOSS, that will hopefully allow me to use midi with it... Trouble is, a game that worked perfectly before (One Must Fall 2097 - go to Oops, I was not aware of some games that used to work before :) War International in the links section of www.omf.com to download - the game is now freeware), now has abnormally fast music. Please fix this. OK, the patch you have tested was produced within a few hours and it was mostly a set of workarounds for the problems I noticed at a first look. So it was not very good and it had some bugs inside. Later I have convinced myself that fixing the current code is a wrong way to go, so I mostly rewrote it. That said, my current patch doesn't share any bugs with previous (maybe it have enough of its own however:), so I hope this problem is fixed. Please continue producing more excellent code (esp. sound code)! I'll try. The current TODO for the sound code is very small: - move the actual I/O from dma.c to linux_sound.c - merge additional fixes and interfaces to the mainstream - find any bugs remaining - convince myself that the code works not only with pc-speaker - try all of the proposed workarounds for doom's problem (deferred) I really hope to complete this all within a month or two, but currently things are getting very slowly for several reasons (mostly because I have to submit other things at first, but also due to my lack of a free time). - 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
Re: DMA-Sound support in dosemu
On Tue, 1 Jan 2002 04:57, Oliver Ob wrote: Stas Sergeev schrieb: Oliver Ob wrote: Hi Bart, please be so kind as to What do you need? Sound support is incomplete anyway so not only Doom is silent. Enjoy Wolf for now:) What I need? I would like to have some easy MOD player under dosemu. that'S all. I haven't followed this thread but Scream Tracker 3 is what I think you want. - 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
Re: DMA-Sound support in dosemu
Stas Sergeev schrieb: Oliver Ob wrote: Hi Bart, please be so kind as to What do you need? Sound support is incomplete anyway so not only Doom is silent. Enjoy Wolf for now:) What I need? I would like to have some easy MOD player under dosemu. that'S all. -- *º¤., ¸¸,.¤º*¨¨¨*¤=Oliver@home= *º¤., ¸¸,.¤º*¨¨*¤ I http://www.bmw-roadster.de/Friends/Olli/olli.html I I http://www.bmw-roadster.de/Friends/friends.html I I http://groups.yahoo.com/group/VGAP-93 I I http://home.t-online.de/home/spacecraft.portal I Telek0ma iBBMS - soon back online +49.4503.TRSi1/TRSi2 - 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
Re: DMA-Sound support in dosemu
Bart Oldeman schrieb: Yes. But you don't need DOSEMU. It's nice to see that DOOM runs in DOSEMU (even though without sound), but it's more of theoretical than of practical value as native versions of DOOM have existed for Linux since (at least) 1995. Indeed I went through all levels of Doom 1 shareware on my 386SX 20Mhz with Slackware in 1995 (made the screen a bit smaller though ;-). Hi Bart, please do the bart man and be so kind as to technically exlpain why no sound with DOS-DOOM thank you :-) -- *º¤., ¸¸,.¤º*¨¨¨*¤=Oliver@home= *º¤., ¸¸,.¤º*¨¨*¤ I http://www.bmw-roadster.de/Friends/Olli/olli.html I I http://www.bmw-roadster.de/Friends/friends.html I I http://groups.yahoo.com/group/VGAP-93 I I http://home.t-online.de/home/spacecraft.portal I Telek0ma iBBMS - soon back online +49.4503.TRSi1/TRSi2 - 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
Re: DMA-Sound support in dosemu
Oliver Ob wrote: Hi Bart, please be so kind as to What do you need? Sound support is incomplete anyway so not only Doom is silent. Enjoy Wolf for now:) technically exlpain why no sound with DOS-DOOM Quoting http://www.jsiinc.com/dl/SoundFX.txt: --- Execution of an CLI or STI instruction causes a trap to the emulator which then updates the virtual interrupt state. Many programs save the interrupt state before disabling them by executing a pushf instruction. Unfortunately due to a limitation in the Intel architecture when running a process in protected mode at a privilege level above 0 the popf instruction that would normally restore the interrupt state does not cause a trap and hence the virtual interrupt state in the VDM gets out of step with what the program expects and further virtual interrupts such as timer, mouse or sound card are not delivered to the program. The only solution is to fix the application. --- There are still some workarounds to try so all is not lost. - 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
RE: DMA-Sound support in dosemu
Hi, [...] independently of the CPU's frequency). If the program reads several times Yes, 4 times. Typical delay technique. If you disassemble the DOS program you will almost certainly see that it doesn't do anything with the values it reads from the port. :) It needs this delay because the reset signal (in the reset register, accessible by writing to 0x226) must be kept asserted for a minimum time of I don't remember how many microseconds, so games assert the reset signal, read a few times from the reset port to achieve the delay (4 to 6 consecutive reads), then deassert the reset line. Command 0xe2 was a pain to reverse-engineer. Are 0x06 and 0x6b actual commands, or arguments to a command (e.g. 0xe2)? Exactly, that were arguments to 0xe2:) Anyway, until 0xe2 is unknown, this Millenium game doesn't produce any sound under dosemu. But atleast it doesn't lock now, when arguents are handled correctly, i.e. known what is to ignore. Command 0xe2 is a sort of challenge/response command. Whatever value is output to this port modifies some internal (hidden) registers, and the contents of these registers (the response to the challenge) is transferred into memory via DMA (!), one byte at a time. See the code I pointed to in the first message. I know at least one game (Wing Commander: Rebel Alliance) that locks if command 0xe2 is not implemented completely (it actually checks the data returned via DMA, and locks if it's not correct). Get a sound card! Or are you out of ISA/PCI slots? :) Exactly, you guessed also this. How are you doing it?:) Damn this engineers who put only 1 ISA (or even 0!) to the MB! I know... I only have one ISA slot on my mobo, but I'm keeping it for my LAPC1 card. :) There is a PC-speaker driver for Windows, but it is fully synchronous (i.e. I knew it was for win95 but never seen it for NT. I know I had it on my machine for a while before I got a soundcard (quite a while ago), and I'm pretty sure I was running NT4 at the time. :) But anyway the driver is worthless because it blocks the entire machine while it's playing. I wouldn't be surprised if someone wrote a Disney SoundSource (or parallel-port soundblaster) driver for NT, some people really have nothing to do with their time. ;) 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
RE: DMA-Sound support in dosemu
Hi, Stas, For Doom and the like it should be easy to incorporate a workaround into DosEmu (it's tougher to do in WinNT because NT's NTVDM.EXE does not expose a proper interface for what is needed, but anyway). If interrupts have been disabled for more than a certain amount of time (easy to detect from within the emulated IRQ0 generator, maybe coupled with the CLI/STI trap handler), DosEmu could force the enabling of interrupts. Then Doom should then get past the Initializing timer... lockup and work properly. Can someone test that? Thx, Vlad. -Original Message- From: Stas Sergeev [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 20, 2001 8:17 AM To: [EMAIL PROTECTED] Subject: Re: DMA-Sound support in dosemu Oliver Ob wrote: Now I already made some programs to work with sound: pv (mp3 player), iplay (stm player) some other utilities and some games. The fact that I don't have a sound card appears to be not a big problem: I have pc-speaker, and that just required some more hacks. what games? The complete list is too long:) But it is worth to mention SimCity2000, Settlers2, Dune, ThemeHospital, Grand Thief Auto and some other games that use DMA transfer as well as some older games that use direct DAC writes. Doom and other famous ID games doesn't work (and probably never will), the reason was pointed out by Vlad Romascanu (it just locks dosemu, and if it was suid-root under console, it locks the whole linux box when sound is enabled). and what have you changed? The patch was attached to my letter, didn't you notice it? Anyway, it was mostly a hacks and workarounds. The only purpose I posted it here was to enshure whether it works for the real soundcards, since the only sound device I have is pc-speaker and I had to make some tricks to adjust the code for that device. There were several people complaining the sound support in dosemu. As they are unwilling to test the patch, they'll have to complain further, until someone with a soundcard will fix their problems:) - 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
Re: DMA-Sound support in dosemu
Stas Sergeev schrieb: Oliver Ob wrote: Now I already made some programs to work with sound: pv (mp3 player), iplay (stm player) some other utilities and some games. The fact that I don't have a sound card appears to be not a big problem: I have pc-speaker, and that just required some more hacks. what games? The complete list is too long:) But it is worth to mention SimCity2000, Settlers2, Dune, ThemeHospital, Grand Thief Auto and some other games that use DMA transfer as well as some older games that use direct DAC writes. Doom and other famous ID games doesn't work (and probably never will), the reason was pointed out by Vlad Romascanu (it just locks dosemu, and if it was suid-root under console, it locks the whole linux box when sound is enabled). i was told doom i+ii _do_ work under linux. sure? and what have you changed? The patch was attached to my letter, didn't you notice it? SORRY deleted it, please attach again - if you like in PM Anyway, it was mostly a hacks and workarounds. The only purpose I posted it here was to ensure whether it works for the real soundcards, since the only sound device I have is pc-speaker and I had to make some tricks to adjust the code for that device. There were several people complaining the sound support in dosemu. As they are unwilling to test the patch, they'll have to complain further, until someone with a soundcard will fix their problems:) ha.. -- *º¤., ¸¸,.¤º*¨¨¨*¤=Oliver@home= *º¤., ¸¸,.¤º*¨¨*¤ I http://www.bmw-roadster.de/Friends/Olli/olli.html I I http://www.bmw-roadster.de/Friends/friends.html I I http://groups.yahoo.com/group/VGAP-93 I I http://home.t-online.de/home/spacecraft.portal I Telek0ma iBBMS - soon back online +49.4503.TRSi1/TRSi2 - 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
