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 log to find out whether the prog uses DPMI. I wonder if it is a problem to figure out under NT whether an app uses DPMI or not? NT is known for a poor logging (and poor DPMI) though:) - 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
