Music playback on the GUS is broken NewRisingSun. I have the Version 2.0 Remix and it does play music on my P166MMX/GUS ACE build; unfortunately, the tempo is wrong, note playback is badly messed up (no pitchbends or proper note duration/sustain at all), some notes go missing at random, and about 50% of the time music playback will stop completely and won't start again until the level changes or restarts. I also have the 1.0 and 1.1 shareware versions; they behave the same way. In DOSBox I have the same problems you have (no music or garbage). Looks like music playback routines are optimized for Sound Blaster cards and compatibles, while the GUS was just an afterthought. Too bad.

Radix uses the GUS base port from its configuration file, but it seems to only use the IRQ and DMA for detection, later forcing IRQ 7 and DMA 1 with register writes. Setting the GUS to port 220, IRQ 7, DMA 1 (the defaults from the setup program) does not get the music to work, but what the game is doing might be significant to the issue.

Epic seems to have been a bit lax with GUS support in some of their games. In the registered version of Zone 66, for example, there is no intro music with GUS because the file ZIM2.Z66 is not included. While it's true that you can get the missing music file from the shareware version GUS music add-on (ZONE66G.ZIP), it is in fact identical to the ZIM02.Z66 that is included in the registered version, so there was apparently some mixup with the filename.

Interesting, thanks for the additional info ripsaw8080.

ripsaw8080 wrote:

Epic seems to have been a bit lax with GUS support in some of their games.

Have to agree with that. First Extreme Pinball needs a 1mb GUS to play all 4 tables, and now this issue with Radix. I wonder if they were trying to rush out games with GUS support.

The game indeed has IRQ 7 hard-coded into its executable, just as ripsaw wrote. This, in and of itself, would not be the biggest problem, as the game also writes to the IRQ configuration register, forcing the UltraSound to use GF1 IRQ7 and MIDI IRQ5 regardless of what the config file says.

What prevents the music from playing is that the game uses the UltraSound's AdLib-compatible timer without ever setting a value for Timer 1. The solution is to write value 0 to GF1 register 0x46 before running the game. I have attached a small program that does just that and makes the game work on my UltraSound MAX.

This does not fix the issue under DOSBox, because DOSBox incorrectly resets the timer values to 0xFF whenever the GF1' reset bit is cleared. Obviously, this is not what a real UltraSound does, otherwise SETTIMER.COM would not work. DOSBox should remove the lines

1		myGUS.timers[0].value = 0xff;
2		myGUS.timers[1].value = 0xff;
3		myGUS.timers[0].delay = 0.080f;
4		myGUS.timers[1].delay = 0.320f;

from GUSReset, and add the following to Module_base or wherever the emulated card is first initialized

1		myGUS.timers[0].value = 0;
2		myGUS.timers[1].value = 0xff;
3		myGUS.timers[0].delay = 20.48f;
4		myGUS.timers[1].delay = 0.320f;

which would fix the game when run immediately after booting DOSBox without having to run SETTIMER.COM. Doing this in GUSReset, on the other hand, would seem to to break Epic Pinball.

And again, as so often before, the question beckons: How the hell could these two bugs (hard-coded IRQ7 and lack of timer initialization) have escaped the programmers? Did anyone do any QA at that joint?

Gravis' ULTRINIT.EXE sets timer 1 to 0xff, so the folks at Epic may have had something else/more in their autoexec...

NewRisingSun wrote:

And again, as so often before, the question beckons: How the hell could these two bugs (hard-coded IRQ7 and lack of timer initialization) have escaped the programmers? Did anyone do any QA at that joint?

Perhaps they outsourced their QA to a cheap outfit that simply said "It works, no major problems" just to save time and money. Maybe no one who played the game realized that there should be full GUS support because, well you know, how iffy GUS support was in games.

At least Epic is in good company here. The North American release of DMA Design's, "Hired Guns" has a number of problems with Ultrasound playback (both with DOSBox, and actual hardware), not the least of which is hanging notes. This is particularly shameful, given that the game was intended to tout the GUS' "3D Holographic Sound" capabilities, via Focal Point's software-based solution.

Your SETTIMER.COM program does fix some of the music playback issues on my GUS ACE NewRisingSun. Unfortunately, two still remain: no note pitchbends, and music playback still cuts off at random.

Here's a sample I recorded from the GUS. It's from the first level on Episode 1 - Theta 2:

https://www.dropbox.com/s/jubtscumaqmrvn6/Rad … ame%29.mp3?dl=0

Here's the same music recorded from my Soundblaster Pro 2. It's lower quality and mono, but at least the notes play properly:

https://www.dropbox.com/s/7k46r587fjlb05s/Rad … ame%29.mp3?dl=0

And this is how the same music is supposed to play on the GUS (recorded from Open Cubic Player 2.5.1):

https://www.dropbox.com/s/krkqoz7ge9hxohw/Rad … 5.1%29.mp3?dl=0

The GUS ACE settings are currently at base port 260, IRQ 7 and DMA 3. Removing the Soundblaster Pro 2 and changing settings to 220, 7 and 1 does nothing - the issues still remain. Until a permanent fix can be found, I'll have to assume that Radix music playback on the GUS is indeed broken beyond repair.

I guess I could live without pitch bends, but random cutoffs are unacceptable. I suppose it would violate the definition of "random" to ask whether you can reproduce situations that cause music to be cut off?

The easiest way to create a "random" music cutoff is to play the game demos continuously. Go to the main menu, select Demo, press Enter, and just let them run over and over until the music stops playing. Most of the time it happens when the second or third demo is playing; sometimes it doesn't happen at all. During gameplay, it's very likely to happen during fight scenes with lots of enemies and powerups around while firing your weapons continuously.

I can't quite reproduce the problem with my UltraSound MAX. Although I don't know whether this is the sole cause, looking at the IRQ handler and how it signals an End-of-Interrupt before doing anything to actually service the interrupt, I can sort of understand why strange things would happen when there is a lot of activity, and why they would happen seemingly at random. Sadly, DOS4G's LE executables are notoriously difficult to patch, as they relocate not only segment but also offset addresses.

This hack for Radix 1.0 moves the EOI to the end of the ISR, taking advantage of the fact that the game only needs to signal on the master PIC because it forces IRQ 7:

1Comparing files RADIX.EXE and RADEOI.EXE
200058F9C: 76 EB
300058F9D: 08 10
400058FA1: A0 20
500058FA6: B0 07
600058FA7: 20 1F
700058FA8: BA 61
800058FA9: 20 CF
90005908B: 07 E9
100005908C: 1F 0E
110005908D: 61 FF
120005908E: CF FF
130005908F: 90 FF

Maybe I'm not waiting long enough, but I don't notice any difference in DOSBox with this.

Since I've done all of my testing and gameplay of Radix with memory managers (himem.sys/emm386.exe and jemmex.exe), I decided to try a minimal boot without them to see if the game behaved any different. And it did.

I played through the first four levels of Episode 1, and in each one the music would hang/freeze completely (around mid level gameplay). And in level 4, the whole game froze a few seconds afterwards. After a hard reboot I reconfigured Radix to use the Soundblaster Pro 2 instead of the GUS ACE, and played through the same 4 levels again. No music playback problems or freezes.

What in the world is going on here 😕 ?

I have now done the following modifications to version 2.0 (a.k.a. remix):

• Use IRQ from RADIX.CFG, not hard-wired to IRQ7. (I hate the LE format.) 😠
• Send End-of-Interrupt (EOI) signal at end, rather than beginning, of Interrupt Service Routine (ISR). This is a slight modification of ripsaw8080's patch that also (theoretically) supports IRQs >7.
• Do not write anything to the IRQ and DMA configuration register. This means that on a real system, ULTRINIT should be run first, which can be assumed to be done in AUTOEXEC.BAT if the user has properly installed the Gravis software.
• Initialize Timer 1's period to 256. This removes the need for a separate SETTIMER.COM.

These make the game run perfectly on my UltraSound MAX at any IRQ <8. With IRQs 8-15, the game does not work well in DOSBox or a real system, but that may well be a problem of DOS/4GW. Try JayCeeBee64 if the End-of-Interrupt patch also resolves your music break-off issue. Otherwise try a different IRQ than 7, now that you can. 😀 "Perfectly" still means no pitch bends, which apparently the UltraSound .MOD player just has not implemented. Oh well.

Excellent. It works!

No more music cutoffs or hangups/freezes. No more gameplay freezing. And no more broken GUS support in DOSBox. 😁 😁 😁

My hat's off to you both NewRisingSun and ripsaw8080, together you have done what I considered at one time impossible. It's really a shame that Epic did not do more GUS support testing and QA for some of their games; it does appear that their QA people or whatever third party they hired just did a superficial cursory run, gave the final approval and Epic released Radix to the public like this. And the imperfect music playback is indeed a small price to pay, since now the game is fully playable with the GUS both in real hardware and in DOSBox.

Once again, great work! You both truly have my admiration and respect 😀

Apologies for bumping this old thread, but would it be too much to ask for a similar patch for the shareware 2.0 REMIX version of Radix? The download above is registered version only.