Alright I have some interesting findings for you.
I just found out that on a GUS MAX card I obtained from ebay, the Ultrainit software will give you the same result. Obviously it can see the card and initialize it to some degree (enough to make a slight "pop" sound in the speakers) but it gives the same error message. But playing with the SETUP program showed me why: The program will not init a GUS MAX unless ULTRA16 is also set to point at the onboard "codec" on the GUS MAX. Only then did ultrinit work (on real hardware). I had to look at what SETUP.EXE was adding to AUTOEXEC.BAT.
Test machine is a 133MHz Pentium MMX with 32MB of RAM on a motherboard I bought back in 1996. Just to clarify that the motherboard originally had a 100MHz Pentium that I later replaced with the MMX version. The GUS is connected to one of 3 ISA slots and the BIOS is configured so the PCI-ISA bridge passes through IRQ 5 and DMA channels 1 & 5. The ultrasound PLAYMIDI program works perfectly, as do several mid-1990's MS-DOS demos including 2nd Reality (with GUS) and Dope. The "hard drive" is a 2GB compact flash card connected through an IDE-CF adapter because the original hard drive died a few years ago and the BIOS (dated sometime 1995) seems to max out at 2GB anyway.
Why Gravis didn't write ultrinit to detect a GUS MAX, but init as GUS classic if ULTRA16 wasn't set, is beyond me. Going 'round and 'round with SETUP.EXE reporting the card OK and ULTRINIT.EXE whining is definitely a sanity test. I have a PDF of the Interwave (GUS ACE and higher) chipset that shows the MAX/ACE and later cards faithfully reproduce the legacy register set and behavior until "enhanced" bits are set, then you can remove the sample rate limit beyond 14 voices, program the voices beyond the 1MB boundary and do GUS DMA transfers with finer accuracy to onboard RAM.
Now apparently you're running a newer version of DOSBox from SVN that has new emulation code for gus classic, max, ace, etc. I'm not using the latest SVN copy but I would definitely try setting gus=max and then manually adding in ULTRA16=34C,0,0,1,0. I would say that if DOSBox truely wants to emulate a GUS MAX it needs to automatically add that for you, just as it does the ULTRASND variable.
I also toyed with SBOS and MEGAEM on real hardware. They absolutely suck donkey balls and I can't believe Gravis would even ship such utter crap with their excellent software. SBOS pretends to be a SoundBlaster 2.0 (DSP v2.1, not even a Pro) but doesn't support auto-init DMA like a real one does, which probably choked quite a few DOS games I'm sure. It also responds to the DSP copyright string command with ASCII byte 0x01 for some weird reason. MEGA-EM is even more downlevel, pretending to be a Sound Blaster with DSP v1.3 and an extremely limited DSP command set complete with hanging with system and crashing with an error message if the program dares to use any unsupported DSP commands.
And when MEGA-EM is resident, don't run anything that depends on DOS 4/GW or other DOS extenders unless you want your system to immediately crash and reset. Especially if SMARTDRV is resident, and running a system spawned from a Windows 95 boot floppy. I don't know if MS-DOS 6.22 has this problem. If SMARTDRV is not loaded, you can unload MEGA-EM and use DOS extenders again without crashing.
I also noticed neither attempts to correctly emulate Sound Blaster DMA timing. In a SoundBlaster test program I wrote you normally see the program play a sound block, and the DMA counter moves right along with the sound, with the IRQ firing off the minute terminal count finishes. With Gravis SBOS/MEGA-EM, the program starts a block and DMA transfers *way* too fast, sits at terminal count for 3/4 of the time, then the IRQ fires at the proper time. If anyone here has memories of DOS games skipping and stuttering horribly with SBOS/MEGA-EM, well, now you know why, considering there were plenty that relied on the DMA counter for timing. Also, SBOX ignores ADPCM playback while MEGA-EM emulates it but decodes the packed bits wrong, giving staticky distorted audio.... I mean more staticky and distorted than when decoded correctly by DOSBox or an actual SB.
I'm starting to wonder if perhaps Gravis failed not necessarily because Creative had stronger marketing, but because Gravis apparently had such poor code and design in emulating a Sound Blaster. It's sketchy enough the card re-uses some GUS registers to fake via NMI the SoundBlaster DSP, the least they could've done is have the card respond to an adjacent port range (like 220-22F if the card sat at 240-24F) and write some better NMI code to fake the whole card. They could've had proper DMA timing emulated by allowing SBOS, MEGA-EM, or the driver to have finer control over the DMA transfer rate (instead of a 2-bit register to select between 650KHz divided by 1, 2, 3, or 4). Frankly if their emulation sucks this bad I think it would have been better to not do SB emulation at all.
I also wrote a test program to run the GUS through it's paces and I found a few differences from DOSBox' emulation.
1. DMA status/terminal count register. There is a DMA terminal count IRQ bit pending and a bit to enable the actual IRQ when DMA finishes. DOSBox does not set the pending bit if IRQ is not enabled. A real GUS MAX will always set the bit on DMA transfer complete, though it doesn't fire the IRQ unless enabled.
2. DMA terminal count clearing and starting a new transfer. DOSBox: you can always start a new transfer by writing a new transfer into place and unmasking the DMA. Real GUS hardware: you must write 0x00 to the register to shut off DMA, then read the register to clear the DMA terminal count event, and THEN program a new DMA transfer. The card won't do any DMA transfers until the terminal count event is cleared.
3. DMA reliability issues. DOSBox: DMA transfers are always 100% reliable and all sound data makes it through. Real GUS MAX hardware: If you set up a DMA transfer, unmask the channel, then program the DMA transfer, the GUS MAX will sometimes carry out the DMA but randomly NOT write the acquired bytes to DRAM (about once every 100th sample or so). If your program uploads samples and they sound staticky or buzzy, and bits of the previous DRAM data are audible, then your program is suffering from this hardware bug. You have to set up the DMA controller channel, leave the channel masked while setting up the GUS DMA transfer, and then finally start the transfer unmasking the channel on the DMA controller. Final note: writing your code to do block DMA transfer mode does NOT help, the GUS can't seem to keep up in that scenario and it will miss about every other byte. You have to use single or demand DMA transfers.
4. GF1 chip reset procedure. DOSBox: writing 0x00 to the reset control, then writing 0x03 to end reset and enable line-out, will read back 0x03 from the same register. Real GUS hardware: Writing the register as described above seems to read back 0x01 instead, indicating that for some reason the DAC wasn't turned on by the write, pehaps the leading edge of the RESET signal triggered by your I/O turns it off. Writing 0x03 and reading back again then yields 0x03.
5. Voices: bidirectional looping. DOSBox: Programming a start value of 0 and an end value of the last sample, and setting current position to 0 will cause the sample to play forwards, then backwards, then forwards again. Real GUS MAX hardware: The sample will play forwards, then play backwards, then completely miss the starting point and wrap around to 0xFFFFF and beyond still going backwards and playing whatever junk was left there (the last used MIDI patches if you recently ran PLAYMIDI.EXE, for example). If you made the mistake I did, writing the mode byte first, the card will immediately start at 0 and play backwards down from 0xFFFFF. Workaround: write the voice "mode" byte last. Program the starting position at sample offset 1 (or 2 if 16-bit) and the current position at the start position.
I hope this information is useful for making the GUS emulation more accurate in case any DOS program relies on it.
