> > 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."
I have the DMAC .pdf at home so I can check more thoroughly later, but correct me if I'm wrong: you (the SB) can always deassert DRQ and the DMAC will actually check DRQ when reaching terminal-count, no? > 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. 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. I do not know how large their internal buffer is, probably less than 64k :) but still I'd expect a few kB (so it may not be able to buffer an entire "block" transfer). Of course, all this assuming that pre-SB16 cards did have buffering (which is not so obvious). > > 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? Doesn't play at all IIRC. Again, I suspect Windows. Is it attempting to play stereo by any chance (see mixer command to switch from mono to stereo and back on SB-Pros)? > > 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). 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. > 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? No, you pause DMA, do all the time-consuming double-buffer memory xfer, then resume DMA and IRET. Once the memory xfer is done (i.e. DMA has been resumed), the ISR doesn't really care about re-entrance anymore unless it runs out of stack, which is impossible unless your CPU is reeeeeeeeeeeelly slow or it's doing 10-byte long transfers between IRQs :) > >> 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. Sounds like a good argument. The "reasonable" explanation for Disable Speaker would be, of course, to "mute" the annoying pop that would occur after a 4-byte transfer (especially since many apps don't even bother to transfer 4 0-bytes, but transfer 4 random bytes). I would expect the SB to maintain timing, though, even if the speaker is muted (especially since on SB16s apparently Disable Speaker does not mute, so you'd expect to hear the sound, which in terms of backwards compatibility would mean that the timing *was* right all the time since SB1.x). So I don't really know what to say -- I can try to test it at some point in the future (my old SB-16 equipped machine does not have a display and there is no VNC for DOS ;)... I still have a SB-Pro equipped machine pretty functional, though). > 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? Big pain. I'be been hacking away at NTVDM.EXE for quite a while. Of course, all the v86 core is buried deep inside the kernel (and not NTVDM.EXE). I would have expected the "emulated" machine to be just another thread, switching between v86 and p-mode depending on whether a real-mode or a p-mode DOS app was running (would have been great for trapping faults and doing custom processing on stuff like STI/CLI's), but it doesn't look that simple. Still hacking, though. :) > This means that you are doing a smoother transfers, probably you even > have another thread for DMA? 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? It's been one year since I peeked at DosEmu, I guess many things have changed in that interval too. :) I grab data every T milliseconds, where T self-adjusts between user-define bounds (default 5 and 15ms). > 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:) Ooops, I must have been too rash there with blaming DPMI. Actually I have a way of not loading the DPMI host, so I can check that. But I wouldn't be surprised if it were yet another Windows bug, since a commercial SB emulator has the exact same trouble with ST3 (and FT2 for that matter). 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
