Gravis Ultrasound Max with HardMPU Issues \ VOGONS

Gravis Ultrasound Max with HardMPU Issues

Topic actions

Post a reply

First post, by figbash

Posted on 2021-07-24, 21:03

figbash Offline

Rank Newbie

Rank: Newbie
Posts: 30
Joined: 2019-10-31, 07:00

I'm pulling my hair out trying to figure this out, I'm wondering if anyone has experience with this or any ideas.

I've been building my ultimate 486 machine. It currently has a Soundblaster 1.5 @ 220 IRQ 5 DMA 1 and a HardMPU @ IRQ2 330. Everything works fine using the HardMPU to run an SC-88 and MT-32 over port 330, which is what I want to use as so many older games are hardcoded to it.

I recently got a Gravis Ultrasound Max 1.8, and no matter what I do I cannot get the HardMPU to continue working @ 330 once the GUS is inserted. It doesn't matter if I run ULTRINIT or not. Changing the GUS to use something other than 330 or just disabling it altogether doesn't seem like an option through jumpers or ULTRINIT.

The GUS just seems to be intercepting everything on port 330 and then doing nothing with it.

I have pulled out the Soundblaster, currently only the GUS, HardMPU, video card, and I/O card are in the system.

I'm not really interested in using MEGAEM, I mainly want to use the GUS for games like Jazz Jackrabbit, and the SoundCanvas/MT-32/SB1.5 for everything else.

It really seems like I should be able to use a card @ 330 before the GUS is inited and without running the MEGAEM TSR, I was under the impression that it was the TSR that captures the port.

I have tried various permutations of these:
1. MEGAEM then MEGAEM -F, to load and unload it (Some people said doing this with SBOS would help with a similar adlib conflict)
2. MEGAEM, EMUSET, MEGAEM -F (Same as above but turning on the emulation with EMUSET)
3. MEGAEM -ROFF, EMUSET (Disable roland emulation)
4. MEGAEM -SBOFF, EMUSET (Disable SB emulation)
5. MEGAEM, EMUSET -CO1 (Coexist with MPU-401)
This one is interesting, I have found in the MEGAEM documentation: "-COn Coexist with real MPU-401 MIDI interface. While Mega-Em will function correctly with a real MPU-401 MIDI interface installed in the system, no software will be able to access the real interface while emulation is active and these options are not used. These options allow Mega-Em to be used together with a real MPU-401 MIDI interface. This can be useful for DOS based MIDI sequencers. Note that when using this option, Mega-Em no longer emulates the MPU-401 interface, however will intercept all data sent to it. -CO1 Allow both input and output to real MPU-401. With this option music will play through both the external MIDI device(s) and the selected Mega-Em output device. -CO2 Only allows input from real MPU-401. Music will only play through the selected Mega-Em output device. Using this option may also increase Mega-Em's compatibility on systems with a real MPU-401."

Occasionally after a cold boot and not running ULTRINIT, I will randomly started getting music on the SC-88 from Doom, but it is very scrambled and wrong sounding, and only occurs maybe 1/10 times.

If anyone can help I'd super appreciate it, this is one of the very last parts to get working!

Reply 1 of 8, by dionb

Posted on 2021-07-25, 13:50

dionb Offline

Rank l33t++

Rank: l33t++
Posts: 5824
Joined: 2017-12-23, 15:35
Location: Amsterdam

Not sure I can help, but reading this explains some of the problems I've been having in a build containing a GUS.

I've utterly failed to get GM to work in that build on:
- Terratec EWS64XL (Dream wavetable onboard)
- Aztech MMSN826 (ICS wavetable onboard)
- AWE64 Gold

All cards are known-good elsewhere. I hadn't linked the issues to the GUS until now, but it's the common factor here. Interestingly, I'd set the AWE64 to 0x300 and it still didn't work.

If I have time this evening I'll remove the GUS from the build (that currently contains the MMSN826 and AWE64 as well) and confirm it it's the cause of these issues.

Edit: nope. See below.

Last edited by dionb on 2021-07-25, 20:01. Edited 1 time in total.

Reply 2 of 8, by darry

Posted on 2021-07-25, 14:32

darry Offline

Rank l33t++

Rank: l33t++
Posts: 5852
Joined: 2014-01-20, 06:27
Location: Canada

@dionb

Is your card a GUS MAX too ?

I have a non MAX, version 3.73 which has no issues cohabitating with

an Orpheus (non PCMIDI) with MPU at 300h
an AWE 64 with MPU at 330h

These UART mode MPU-401 work fine (whether my GUS is initialized or not, AFAICR, but I almost always init the GUS at boot ). Softmpu also works fine on either one .

EDIT: I never run MEGAEM .

Last edited by darry on 2021-07-25, 15:14. Edited 1 time in total.

Reply 3 of 8, by BloodyCactus

Posted on 2021-07-25, 14:56

BloodyCactus Offline

Rank Oldbie

Rank: Oldbie
Posts: 1436
Joined: 2016-02-03, 13:34
Location: Lexington VA

firstly, irq2 is a bad irq to try and put a device on because its slaved to the higher irq's 8-15 so make sure you acpi+apm etc is all disabled. (its a shame a lot of games using midi have hard defaults for irq2)

megaem does indeed capture everything sent to 330.

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 4 of 8, by figbash

Posted on 2021-07-25, 18:11

figbash Offline

Rank Newbie

Rank: Newbie
Posts: 30
Joined: 2019-10-31, 07:00

dionb wrote on 2021-07-25, 13:50:

If I have time this evening I'll remove the GUS from the build (that currently contains the MMSN826 and AWE64 as well) and confirm it it's the cause of these issues.

I'd be interested to know what happens with you, I can't be the only one experiencing this surely 😀

BloodyCactus wrote on 2021-07-25, 14:56:
firstly, irq2 is a bad irq to try and put a device on because its slaved to the higher irq's 8-15 so make sure you acpi+apm etc is all disabled. (its a shame a lot of games using midi have hard defaults for irq2)

megaem does indeed capture everything sent to 330.

I've tried different IRQs just in case and it doesn't seem to be the issue, I'm guessing only intelligent mode requires it though?
My issue is that the united card itself seems to be capturing 330 before megaem is even run.

darry wrote on 2021-07-25, 14:32:
@dionb […]
Show full quote
@dionb

Is your card a GUS MAX too ?

I have a non MAX, version 3.73 which has no issues cohabitating with

an Orpheus (non PCMIDI) with MPU at 300h
an AWE 64 with MPU at 330h

Definitely wishing I bought a classic now if it's the Max causing it! I have an AWE64, maybe it would be worth trying the MIDI on that rather than the HardMPU.

When I get time today I'm going to try the cards in another motherboard and see if the same issue occurs to try to narrow it down.

Reply 5 of 8, by dionb

Posted on 2021-07-25, 20:08

dionb Offline

Rank l33t++

Rank: l33t++
Posts: 5824
Joined: 2017-12-23, 15:35
Location: Amsterdam

darry wrote on 2021-07-25, 14:32:

@dionb

Is your card a GUS MAX too ?

No, non-MAX.

But have been checking and I did not have my facts straight. The Aztech card was in fact not an MMSN826 but an MMSN824 without onboard wavetable. So no surprise there that it didn't play anything on its own... I hooked up my SC-55ST to it and it played fine with the GUS present and initialized. That leaves the AWE64 and EWS64 issues, but in both cases it's looking more like non-GUS related issues. In any event the AWE64 fails to play MIDI just as badly when I remove the GUS.

So apologies, my issues clearly aren't the same as OPs.

Reply 6 of 8, by aitotat

Posted on 2021-07-26, 04:21

aitotat Offline

Rank Member

Rank: Member
Posts: 389
Joined: 2008-03-13, 09:14
Location: Finland

I haven't had GUS MAX for a long time so I can't test this anymore but GUS MAX has codec that requires ports of its own. I remember having some configuring problems as well. If I remember correctly setting the GUS MAX to 2x0h requires 3x0h to be available as well so if you have GUS MAX port set to 230h it might actually be problematic. I always set GUS to 240h or 250h. I think those are OK for GUS MAX also.

Then the GUS MAX has CD-ROM controller that can be configured to 330h and IRQ2. Make sure CD-ROM jumpers are at safe settings (both port and IRQ) and then disable the CD-ROM controller completely if you don't need it.

Reply 7 of 8, by figbash

Posted on 2021-07-26, 04:59

figbash Offline

Rank Newbie

Rank: Newbie
Posts: 30
Joined: 2019-10-31, 07:00

Some more info:

I tried the GUS and HardMPU in a Pentium-120 system, and they had the same issue where the HardMPU won't work when the GUS is inserted.

I then removed the HardMPU and tried my Awe64 Gold with the GUS Max, with these results:
Doom works with the Awe64, without even initing the GUS
Descent doesn't work with the Awe64 unless I call ULTRINIT, then it works as well

So it looks like the GUS and HardMPU card are having some kind of conflict... I'm very curious why I would need to init the GUS for Descent to start outputting MIDI over the Awe64 gameport, but not Doom.

dionb wrote on 2021-07-25, 20:08:

So apologies, my issues clearly aren't the same as OPs.

Thank you for checking anyway, appreciated.

aitotat wrote on 2021-07-26, 04:21:

I haven't had GUS MAX for a long time so I can't test this anymore but GUS MAX has codec that requires ports of its own. I remember having some configuring problems as well. If I remember correctly setting the GUS MAX to 2x0h requires 3x0h to be available as well so if you have GUS MAX port set to 230h it might actually be problematic. I always set GUS to 240h or 250h. I think those are OK for GUS MAX also.

Then the GUS MAX has CD-ROM controller that can be configured to 330h and IRQ2. Make sure CD-ROM jumpers are at safe settings (both port and IRQ) and then disable the CD-ROM controller completely if you don't need it.

Interesting, I am actually running the GUS at 230, I hope that is all it is! Is it the CS4231 chip that requires these resources?
I will try changing the baseport as soon as I have a minute.
I have the CD-ROM disabled but I will double check the port/IRQ jumpers just in case.

Reply 8 of 8, by figbash

Posted on 2021-07-26, 05:20

figbash Offline

Rank Newbie

Rank: Newbie
Posts: 30
Joined: 2019-10-31, 07:00

aitotat wrote on 2021-07-26, 04:21:

I haven't had GUS MAX for a long time so I can't test this anymore but GUS MAX has codec that requires ports of its own. I remember having some configuring problems as well. If I remember correctly setting the GUS MAX to 2x0h requires 3x0h to be available as well so if you have GUS MAX port set to 230h it might actually be problematic. I always set GUS to 240h or 250h. I think those are OK for GUS MAX also.

Thank you so much! That was it the whole time. I had no idea it took the same 3x0 along with with the 2x0 setting, and of course I had picked 230 since the SB is on 220. That is basically the only jumpered setting too, so it makes sense that it was breaking without even using any TSRs.

Go to top of page Go to top of page

Back to Sound

Main menu

Common searches