First post, by aquishix
- Rank
- Member
I've been in vintage computing Hell for the last few weeks, and it turned out to be due to high DMA problems on my 486DX2-66 System.
I'll intersperse the rundown of what's been going on with related questions:
I have a Gravis Ultrasound Classic (rev 3.74) that I was trying to get to play nice with SOME true Creative SB16 era card -- preferably ViBRA (for maximum SnR). I was having an outrageously frustrating time because the malfunctioning of both cards was utterly inconsistent. Any troubleshooter knows that intermittent problems are the absolute worst ones to deal with, because it's almost impossible to tell when making a change if the change has a real effect or not. Sometimes the GUS and the SB16 would both work, sometimes the GUS would work and not the SB16, sometimes the other way around, and sometimes the results would depend entirely on which program I used to test one or the other.
(It reminds me of testing one of my Z100IDE ZIP drives and experiencing read errors ...but not consistently. I'd copy the same file from the ZIP drive to my hard drive 10 times in a row, get md5 hash inconsistencies on about 30% of the attempts , and then I'd wait a few minutes, do it again, and all 10 attempts would be perfect. Similar Hell to figure out.)
Most people seem to prefer 240,7,7,7,7 as the GUS hardware resources, so I kept trying to follow suit and also use the "standard" A220 I5 D1 H5 for my SB16 card(s). Sometimes the 16 bit testing in the DIAGNOSE.EXE file for the SB16 would fail, and sometimes it would work. Similar with the sound card testing in Duke Nukem 3D's SETUP.EXE program, as well as live tests in One Must Fall 2097, Wolfenstein 3D, and two different versions of Doom. One of the things of note, re: Wolfenstein is that the Adlib would work correctly and then the game would instantly freeze upon firing a gun, because it was using the PCM functionality of the SB16.
If I recall correctly, it was when I set the GUS to 240,3,3,3,3, which made the GUS start working consistently, that I set that aside and hammered hard on the SB16 resources until I got something to work correctly and consistently for it. That ONLY happened when I gave up on high DMA entirely for the SB16 and set it to A220 I5 D1 H1. Then it worked perfectly when attempting to use it as an SB16 instead of using its quasi-Sound Blaster Pro, original Sound Blaster, or Adlib functionality. NB: My ViBRA CT2890 (which is PnP) and my ViBRA 2260 (which is not PnP) behave exactly the same way, re: high DMA.
Now, if my understanding is correct, when doing that, it means that a game(or other program) emits 16 bit PCM samples to the card, but they get downgraded to 8 bit waveforms before mixing and subsequent output through the line-out and/or spkr-out ports. It seems like a simple hack to get a SB16 card to work in a system that can't properly use high DMA -- and the DIAGNOSE.EXE tool says as much in its text dialogs -- but it's not absolutely clear what the end result is.
1) Is that correct? / Thoughts?
On the GUS front, I'm worried about the same thing -- using DMA channel 3 instead of 7. I ended up using 240,3,3,7,7 for the GUS because it works consistently with IRQ 7 and I'd prefer to leave IRQ 3 freed up so my ATi Mach32 VLB video card can use it. (Its options are IRQ 2, 3, and 5, but I want IRQ 5 for the SB16 and IRQ 2 for my MIF-IPC-B.) I noticed that with the Duke Nukem 3D SETUP.EXE app, setting the GUS to DMA 3 like that causes static/clicking to come out of the speakers when testing it. That problem doesn't seem to manifest when running Doom, OMF2097, or Quake(which I tested on my PII, not my 486 😉).
2) Is the GUS similar to the SB16 in this regard? Does it only function as a true 16-bit audio card when using high DMA?
3) Is it a foregone conclusion that my motherboard (specifically the secondary Intel 8237 or equivalent DMA controller used for high DMA) is at fault for this?
4) If so, can anything be done about it, or should I just get a different 486 motherboard?
5) If I have to get a different 486 motherboard, does anyone have any recommendations for ensuring that high DMA actually works correctly? If so, I'm only interested in boards that have either PCI slots (that work CORRECTLY...*grumble*), or at least 2 VLB slots so I can continue using my Mach32 video card and also slap in a high(er) performance VLB multi I/O card for the drives.
I'd pay money at this point just for the information (which does not seem to be easy to scour from the web), but it's probably only proper to give gratitude. 😉
I anxiously await expert advice/opinions. This roadblock is stalling everything else in my project.
