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
