Hello. "Vlad Romascanu (LMC)" wrote: >> Just to be more specific: I am only pausing DRQs, which doesn't always >> mean pausing DMA, but for single mode it does. > OK. On SB-16 DMA *transfers* will pause What exactly it does to pause DMA? OK, atleast my code must be correct for SBPro (which is what is emulated) regarding the workaround that finally forces DRQ.
>> but is the real DSP have some >> intermediate buffering to allow DMA pauses? > Yes. Actually in the "Generic DAC/ADC DMA commands", in the "Command > byte", you will see there is a bit field for "FIFO" -- setting it enables > internal buffering Yes, I see it. So, the default state for it is enabled, right? It is good because I can't avoid OSS buffering anyway. > Good point about sound looping when program crashes -- I observed this > behaviour on my old SB-Pro (consistent); has anyone observed this on a > real SB16? Yes. > ISR may dutifully ACK every IRQ (thus the sound would loop on forever), This is possible because even warm reboot with QEMM's quick boot used to stop this, but unlikely by resetting DSP (it could reset DMA though). BTW, I observed this after crashes from dos4gw so it is unlikely that there was an old handler alive. But I don't have SB handy and it was long ago so I can confuse something... > Is there such a thing as a USB<->ISA > "bridge"? It sounds like such a Frankenstein -- imagine all the > hacking going behind the scenes needed to trap I/O and translate > IRQ's (from actual > "made-for-ISA" drivers) into something that can be pushed around on a > USB interface. That is why it costs way too much:( Initially it required the rewriting of the drivers. But recently they made something that allows to work with ISA drivers. For more info visit www.arstech.com > BTW, about the Scream Tracker 3 problem that needs DMA to be halted What do you mean? I am not halting it, just delaying it's start. > during "disabled speaker" periods -- is that documented somewhere, or > is it also an empirical observation? :) It was a logical conclusion:) ST3 sets a DMA transfer from the int handler. If you request the int immediately, this handler will be called again and will set the same transfer again - infinite loop. It just wants to execute some commands after a return from handler - this is all what it demands. I assume that even when speaker is disabled, DMA transfer still goes and takes some time. I am not going to emulate any timings, instead I just detect if the transfer was set from inthandler, in which case I delay it for some CPU cycles. That works just fine. - 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
