VOGONS


First post, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

The Gravis UltraSound SDK states that when doing DMA transfers using a 16 bit DMA channel (regardless of whether 16 bit samples are transferred or not), the DRAM address written to register 0x42 must be adjusted. As I understand it, adjustment means that bits 0-17 (bit values 0-128K) are shifted one bit to the right because of the word transfer, while bits 18 and 19 are kept as they are because they select the 256K bank, which apparently the card addresses separately (sort of like the DMA page register on the PC mainboard).

DOSBox does not seem to take this into account at all. As a result, DOOM exhibits the kinds of problems I expected when selecting GUS as a music/sound device with the DMA set to 5 or above. Changing src/hardware/gus.cpp by adding one line to the beginning of GUS_DMA_Callback:

--- gus.cpp.old	2014-03-26 14:39:42 +0000
+++ gus.cpp.new 2014-10-07 21:40:54 +0000
@@ -712,6 +712,7 @@
static void GUS_DMA_Callback(DmaChannel * chan,DMAEvent event) {
if (event!=DMA_UNMASKED) return;
Bitu dmaaddr = myGUS.dmaAddr << 4;
+ if (myGUS.DMAControl & 0x4) dmaaddr = (((myGUS.dmaAddr & 0x1fff)<<1) | (myGUS.dmaAddr & 0xc000))<<4;
if((myGUS.DMAControl & 0x2) == 0) {
Bitu read=chan->Read(chan->currcnt+1,&GUSRam[dmaaddr]);
//Check for 16 or 8bit channel

fixes DOOM with DMA >= 5 while (as far as I can tell) not breaking anything else.

Theoretically, one could also emulate the fact that DMA transfers may not cross a 256K boundary in the GUS' memory, but since that is unlikely used by any game or demo for effect, one might as well leave it be.