GUS emulation concern: A surprising number of demos apparently need the "force irq enable" hack

[joncampbell123]

A number of demos according to debug output seem to initialize the GUS as expected, but do not set the IRQ enable bit.

"No" by Nooon: Without the hack, the demo starts uploading samples to GUS RAM via DMA, but then hangs because it never set the IRQ enable bit, and it's waiting for a DMA TC interrupt that never arrives.

"Juice" by Psychic Link: Without the hack, music does not play.

The GUS reset register is arranged as follows according to the SDK:

bit 0: master reset (1=run 0=reset)
bit 1: DAC enable. "DACs will not run unless this is set"
bit 2: Master IRQ enable. "This bit MUST be set to get ANY of the GF1-generated IRQs"

In all cases, debug output shows the demos properly reset the GUS, but they never set the IRQ enable bit.

Example 1: JUICE.EXE GUS initialization. Note bit 2 (IRQ enable) is never set.

If it was, the value written would be 0x0700, not 0x0300

LOG:   97384998 DEBUG MISC:GUS reset with 0x0000
LOG:   97385004 WARN  IO:Read from port 0300
LOG:   97385045 DEBUG MISC:GUS reset with 0x0100
LOG:   97386816 DEBUG MISC:GUS reset with 0x0300
LOG:   97388853 DEBUG MISC:GUS reset with 0x0000
LOG:   97388900 DEBUG MISC:GUS reset with 0x0100
LOG:   97390671 DEBUG MISC:GUS reset with 0x0300

Example 2: NO.EXE (by Nooon) GUS initialization.
Note the demo never sets bit 1 (DAC output enable) and bit 2 (IRQ enable).
Theoretically, even if the demo did enable the IRQ, the music wouldn't be audible
because the DAC output is disabled!

LOG:   12187768 DEBUG MISC:GUS reset with 0x0000
LOG:   12187785 DEBUG MISC:GUS reset with 0x0100

The thing is that, if DOSBox-X is correct, these demos should have failed at the demoparty either by hanging or by failing to play music. But they're well known demos in the scene, surely they initialized the GUS properly on real hardware, or music would not have worked.

Theories I have at the moment:

1. The Gravis SDK is wrong, and bits 1-2 never existed.
2. The Gravis SDK is right, but bits 1-2 are "sticky" and cannot be cleared (once you enable the DAC and Master IRQ, the hardware doesn't let you turn them off again).
3. The Gravis SDK is right, but fails to document the bits didn't exist until the time the documentation was written i.e. the original Gravis Ultrasound "classic" doesn't have these bits.
4. The Gravis SDK is right, but only the Gravis Ultrasound "classic" has an "IRQ enable" bit and DAC output enable, and therefore have no effect on later revisions of the card.
5. The reset register is readable, DOSBox-X is not emulating read-back properly, and the demo's GUS support routines rely on reading and restoring bits 1-2 while flipping bit 0.

So the task at hand is to pull out the old Pentium with the GUS and see which one of these theories is right (or if they're all wrong). I have on hand a GUS classic and a recently acquired GUS Interwave PnP to test against. Some new Ultrasound test code in DOSLIB would help as well. I'll dig in when spare time is available again.

[ghost]

I replicated your result for JUICE. There were no unhandled accesses logged; also, the init code is not available. :)

[ghost]

I have a dosbox-x build from last June and the gus audio works in the case of JUICE. I assume this is because the emulation was improved since then (and my gus.cpp didn't have 'force enable irq' code). The NO demo shows an error about an unhandled interrupt, but that must be from the same reason. The recent code shows the same as the OP except for NO which doesn't send the reset (probably I'm missing a code bit).

[joncampbell123]

I checked over NO.EXE again, some of the unhandled I/O reported by DOSBox-X makes me think it supports and checks for the Gravis UltraMAX. I'm also seeing I/O writes to supposedly readonly registers. Hm...

I/O ports 0x34C-0x3CF are documented to be UltraMAX registers.

12404726 WARN  IO:Writing 05 to port 034F   <- UltraMAX ??
12404730 WARN  IO:Writing 08 to port 0340   <- MIDI control (DOSBox/DOSBox-X does not emulate GUS MIDI controller)
12404734 WARN  IO:Writing 00 to port 034B   <- ??

It's also writing additional unknown registers

12408254 WARN  IO:Writing 00 to port 024F    <- ??
12408265 WARN  IO:Writing 80 to port 024E    <- ??
12408268 WARN  IO:Writing 39 to port 024D    <- ??

[joncampbell123]

I booted up the Pentium and poked at the GUS Classic with DEBUG.EXE. Here's what I found:

In the reset register (select port 0x4C) bits 0-2 do exist (bits 3-7 do not exist).

Contrary to DOSBox-X emulation, the 8-bit GUS RESET register is accessible from both 3X4 and 3X5 (both halves of the 16-bit register I/O). However, writing to 3X4 has no effect.

I/O port 3X3 (Select) is documented for writing, but undocumented behavior for reading is different. I/O port 3X3 when read back seems to return the last byte value you wrote to ports 3X3-3X5, or the last byte value you read from 3X4-3X5.

If you write register 0x4C (GUS reset), and you transition bit 0 from 0 to 1 (taking the card out of reset), bits 1-2 are ignored. That means, if you select the GUS reset register, write 0x00, then write 0x07, then read it back, you'll get the value 0x01 instead. But once the card is taken out of reset, writing 0x07 sets all three bits as expected and you'll read back 0x07.

That rules out any possibility of merely resetting the card by reading and flipping a bit, because the other two bits are lost coming out of reset.

I also poked at registers 2X8-2XF. Despite lack of documentation on these ports in the GUS SDK, there are definitely ports there. Some of them I understand some of them are for SBOS to fake Sound Blaster ports via NMI, but I'm not sure how yet.

[joncampbell123]

I just noticed the card is apparently an UltraMAX, not a GUS classic. The Ultrasound tools set up a ULTRA16 environment variable and there do exist ports 3XC-3XF.

I just ran JUICE.EXE and NO.EXE on the real hardware, and they seem to initialize the GUS just fine, no problems there.

So the next logical step I can think of is to start developing an Ultrasound test program/library in DOSLIB the same way I did for Sound Blaster, so I can tinker with the card and see what happens when you turn on/off certain bits.

[ghost]

It seems like a card made for the true enthusiast. I recall reading that it even has mt32 emulation in addition to others. Your findings are a very interesting development for expanding the audio emulation.

Edit: I reproduced the above results and I think theory 2 seems very reasonable! Do any demos break where bits 1-2 are "sticky"?

[joncampbell123]

I just confirmed bits 1-2 are not sticky. I poked at the GUS UltraMax in my old Pentium and bits 0-2 are writable, while bits 3-7 are not (stuck at zero). What was not expected is that bits 1-2 are zeroed when bit 0 is changed (either to zero to reset, or 1 to clear reset).

[ghost]

That's surprising since I had guessed that the above remaining options/possibilities weren't as likely (3 and 4), since the demoscene must have a mix of GUS card types where a "bug" would be noticed and possibly commented on at their site.

[joncampbell123]

I have an update on emulation.

I've been doing some poking around with GUS support in DOSLIB all night, and I was able to another theory of mine which turns out to be true:

Bit 2 of the reset register (select 0x4C) is called "Master IRQ Enable", but it's a "Master IRQ enable" for the voice/wave interrupts. The DMA terminal count interrupt is not affected by bit 2.

This is how NO.EXE is able to upload samples to GUS with DMA and an interrupt on completion, despite leaving the DAC disabled and the Master IRQ bit off.

[joncampbell123]

Now we're making progress here. Playing with the GUS on real hardware shows the Adlib timers are also not affected by the Master IRQ Enable. This explains how Juice is able to play music without enabling the Master IRQ Enable.

So, what Gravis means by "Master IRQ Enable" is that it's a master enable for the wavetable/voice IRQs on the chip, not a master enable for ALL functions.

[joncampbell123]

On a related note, I found documentation on the mysterious 2XA-2XF registers. Apparently when AMD acquired Gravis they bothered to document the hardware in a lot more detail than what Gravis alone provided. There's some fun stuff in that range regarding registers that trigger a NMI when written or read so that SBOS can fake a Sound Blaster and an Adlib FM synth.

http://hackipedia.org/Platform/x86/Sound/AMD/Interwave/InterWave%20IC%20Am78C201%20Programmers%20Guide%20v2%2c%20%28SDK%29%201996.pdf

[ghost]

Amazing improvements! Is it feasible to adapt your gus emulation to the SBOS system? Also, do you plan on uploading a youtube video in the near future which highlights some of the enhancements?

[joncampbell123]

Running SBOS within DOSBox-X is a goal, yes. It would also allow the Ultrasound setup program's NMI test to pass. It's one of the reasons I added NMI emulation to the CPU. Then DOSBox-X could preserve for future generations just how horrible SBOS's Sound Blaster emulation really is :) Well, actually, it means DOSLIB might be able to provide an open source implementation of SBOS that doesn't suck so much.

I should really get to uploading some new videos. I just need to pick the "best of". There's not a whole lot of exciting stuff you can draw from a capture of the VGA output while I poke at I/O ports and test the latest compile over and over again.

[ghost]

The SBOS sounds very promising. I look forward to any developments on it.

I think your gus emulation and the dos box developments may be interesting to the community; for example, I assume warcraft2 won't enable gus for both sound and music on real hardware, yet it is now working in dosbox-x. However, the I/O port work is equally interesting to me, perhaps Hollywood teaches us that even a less exciting story can be peppered with a heavy dose of special visual/audio effects. :)

[joncampbell123]

Does Warcraft 2 GUS support work on real hardware?

[ghost]

I don't have the real GUS to confirm whether it can be enabled for both sound and music at the same time (in warcraft 2). I assumed that your fix for that would apply to both emulation and real hardware.

[ghost]

GUS audio works for Juice and NO, even though "force master irq enable=false". NO didn't work until setting xms=true as indicated in your notes. :)

I don't recall the earlier build having with such excellent GUS music in Warcraft 2. With your most recent GUS emulation, I had to verify at least twice that General MIDI wasn't active instead because of the high quality output. Perhaps this is (partly) from the sample rate enhancement just added.

[joncampbell123]

Go into the audio settings, and turn off the CD audio. The game will fall back to using the Gravis Ultrasound.

[ghost]

I don't have a CD loaded. :)

[joncampbell123]

Good. Warcraft II defaulted to playing CD audio in my test setup, and I had to disable it to hear the actual GUS music.