Are you getting game messages on the MT-32? That will indicate whether the data is reaching it properly.

Are you positive your gameport is working/enabled? Can you test it with a joystick?

Also, did you check the volume settings of your card? The line-in could be muted.

P.s.: SoundBlasters and their clones aren't 100% MPU401-compatible because there is a thing called "intelligent mode". Only Roland's own dedicated MPU401 controllers and their clones support this. This is why people use SoftMPU. However, some games should work without it — AFAIK, Secret of Monkey Island is one of them.

I think you need to note that most cards are only compatible with 'dumb'/UART mode of the MPU401. Some older games (early Sierra for example, so probably Colonel's Bequest) need a fully 'intelligent' mode compatible MPU401 interface.
I think you should first try with software that is guaranteed to run correctly on dumb mode MPU401, that is what the PAS16 should be able to do.
Then you can at least verify that the PAS16 and MT-32 are communicating correctly.

You could use SoftMPU to 'promote' it to a full MPU401 if the basic port works. Note however that SoftMPU also supports older Sound Blaster cards, so if you use SoftMPU anyway, then an MPU401-compatible Sound Blaster may not be required, should you want to look for a replacement of the PAS16.

Well, in this particular case, Ultima Underworld and Monkey Island are both compatible with dumb UART ports, so they should be suitable test candidates.

Sorry I don't have any actual suggestions for you. Maybe confirm the MIDI shows up on port 330?

Also test it in Windows, where it should be an explicit MIDI output device that you can switch to in the midi mapper. Canyon.mid will sound strange on an MT32, but it should still play.

For what it's worth, I'm using an AWE64 and have had no problems with compatibility. Lots of people here recommend the Audician 32+, and I've got one on order for another machine that should hopefully arrive around the same time as the card.

I suspect that the MPU-401 is disabled by default on the PAS16 - re run the config tool in DOS and check that ( I can't remember the name of the tool I'm sorry). If it is then you can enable it via the tool, and check that it's set to port 330 while you're there.

If this information is correct, then it is possible to configure the CD-ROM interface to use port 330 as well: http://nsd.dyndns.org/pas16/
So you may want to check and make sure that the CD-ROM is not using the same port.

badmojo wrote:

I suspect that the MPU-401 is disabled by default on the PAS16 - re run the config tool in DOS and check that ( I can't remember the name of the tool I'm sorry). If it is then you can enable it via the tool, and check that it's set to port 330 while you're there.

Yes, it seems that the install tool can enable the MPU401 and set the base address: http://www.vogonsdrivers.com/getfile.php?fileid=198
I assume that just sets up the mvsound.sys driver with the correct flags.

Atom wrote:

Hi there, […]
Show full quote

Hi there,

I'm trying to connect my Roland MT32 to a 486 PC. My soundcard is a Pro Audio Spectrum 16. According to my research the gameport is MPU401-compatible.
I've got a midi-cable connected to the gameport and the midi in/out of the midi-cable to the MT32. I tried plugging in a headphone into the L-Port for getting at least a mono-sound for checking. Later I also tried connecting the MT32 to the Line-In of the Soundcard. Problem in both cases: I get no sound, no matter which old game I configure for MT32. I tried it for example with Ultima Underworld, The Colonels's Bequest, Monkey Island and I know how to configure the MT32 there, but no sound at all. Any hints what I'm doing wrong? And question 2: What soundcard can you recommend for this, because I stumbled upon some comments that said you should not use a Soundblaster card older than the Soundblaster 16, because of the 100% guaranteed MPU401-compatibility. Can anyone confirm this?

Cheers

The fact that joystick works or not has almost nothing to do with MIDI working or not.
When MIDI was added to joystick port some power supply pins were replaced for MIDI pins so older joysticks may not work if they expect power supplies to be there.

If the MPU port address is settable, it must be at 330h. If some games require IRQ for MPU operation (they should not), MPU interrupt should be IRQ2/IRQ9 (same hardware pin on ISA bus, on XT it will be hardware IRQ2, on AT it will be hardware IRQ9 and BIOS revectors that to IRQ2 handler).

Also, PC MIDI OUT connector goes to MT-32 MIDI IN connector, just in case you connected them wrong.
There is no need to connect PC MIDI IN plug to anywhere, it might even confuse things if PC receives MIDI data.

What kind of MIDI adapter box or adapter cable you have there to convert the 15-pin joystick connector to DIN plug?

Yes if you want to try Sound Blaster as MPU401 interface, only SB16 and newer will have MPU401 register compatibility, but again it only implements dumb uart mode, it does not have intelligent mode, so it is not 100% MPU401 compatible. Sound Blasters older than that don't any kind of MPU401 compatibility so games wanting to send MIDI to MT-32 must know how to send MIDI through the SB DSP.

Monkey Island is a good game to try MT-32, it should just work by starting it with "MONKEY R", more help with "MONKEY ?".

I would also check the setup in another system if possible.
I had trouble when first getting into external midi devices, and it was all down to the midi cable in the end

I'll just add too that the PAS16 has a flawed MPU401, so it might not be worth your while to get it working anyway! The details of the issue will be around this forum somewhere - something to do with a buffer not being big enough maybe?

Lots of options for MPU401 these days - any old clone + SoftMPU and you're in business.

True. And it was an early card also. At the time of release, its competitors had no MPU-401 at all.

badmojo wrote:

something to do with a buffer not being big enough maybe?

I don't think you'd really need a buffer.
The dumb interface for the MPU401 is like this:
1) Poll the status register to wait until the MPU401 is ready to receive a byte
2) When ready, send a single byte
3) Go back to to 1)

So you can only send a single byte at a time, and as long as the interface throttles your code properly by not flagging that it's ready for the next byte until it is, things should work fine.
Sure, you could make it more complex by buffering the bytes internally, so you can signal that you're ready as long as you have buffer space. But I don't think most dumb MPU401 clones even go that far.
The real MPU401 probably does, then again, it has a whole microprocessor running an internal sequencer for intelligent mode, so buffering a few bytes is the least it can do.

It's possible that they screwed this up on the PAS16, as simple as it is... but I don't know.

Scali wrote:

It's possible that they screwed this up on the PAS16, as simple as it is... but I don't know.

This guy does know: PAS16 sounds distorted

badmojo wrote:

This guy does know: PAS16 sounds distorted

Well, I'd like to know what size FIFO buffer it has then, and what it uses it for.
In theory you'd only need a one-byte buffer. Just some place to store the data between receiving it from the application until you've sent it out via the MIDI port.
So I don't really see how buffer size has any effect on the working of the MIDI port.
Only the state management can screw things up (bytes being overwritten before they were sent out to the MIDI port, which means it has told the application that it's ready to send data, while it isn't).

Jo22 wrote:

True. And it was an early card also. At the time of release, its competitors had no MPU-401 at all.

MPU-401 (UART-mode) compatibility was a later addition to the Pro AudioSpectrum 16, introduced with the MVD101D bus-interface chip sometime in 1993. It's possible that the OP has an earlier, non-MPU-compatible PAS16 card. Would be nice to determine that, as well as the MVSOUND.SYS parameters being used.

For what it's worth, Creative Labs was first-to-market with an MPU-401 (UART-mode) compatible card - the Sound Blaster 16.

Scali wrote:

Well, I'd like to know what size FIFO buffer it has then, and what it uses it for.
Only the state management can screw things up (bytes being overwritten before they were sent out to the MIDI port, which means it has told the application that it's ready to send data, while it isn't).

Several anecdotal references about the PAS16's MIDI issues mention inadequate buffering. I've certainly experienced dropped/hung notes myself. It could very well be something more complicated than a FIFO issue, but perhaps less-approachable in explanation. Where the MVD101D chipset is documented as having a 16-byte transmit buffer, which ought to be sufficient, the problem could be with the state management, as you suggest. I'm not aware of any means of determining this through testing though.

It's also worth mentioning that not all software/drivers wait indefinitely for MPU readiness; some will retry for a specified number of cycles, and then send the byte of data regardless.

Cloudschatze wrote:

It's also worth mentioning that not all software/drivers wait indefinitely for MPU readiness; some will retry for a specified number of cycles, and then send the byte of data regardless.

That could certainly be an issue.
When developers assume certain things about the hardware... eg "I'm sending a 3-byte MIDI command, and I know on a Roland MPU401 the buffer is empty at the start, and the buffer is large enough, so I only wait for ready once, and then send all 3 bytes immediately".
Then MPU401-compatibility suddenly takes on an entirely different meaning.
I suppose on a 386+ system that could be solved by a SoftMPU-like solution: You could virtualize the port, and perform the waiting for every byte that is sent. I wonder how many problems with hanging notes etc that would solve 😀
Also, do SB16 and newer still support the legacy SB DSP MIDI as well? That doesn't have hanging note issues afaik. I wonder if rerouting data via SoftMPU to the SB DSP would solve anything 😀

Scali wrote:

Also, do SB16 and newer still support the legacy SB DSP MIDI as well? [..]

I think so. At least I can confirm that I once checked a "SoundBlaster-16 MPU" option and it worked, apparently.
Port "330" looks dubious, but MPU-401 was listed separately.. See pictures here: Re: emagic micrologic demo (1993)

Another test bed would be that´old Sierra patch for SB/Pro and MT-32. It uses native SB MIDI, I believe.
http://www.sierrahelp.com/Utilities/SoundUtilities.html

I have my own MIDI player with support for MPU401, IBM Music Feature Card and SB DSP MIDI.
Could try that out on an SB16 or newer to see if it works 😀

The SB16 chipset does indeed support SB MIDI.

The bigger "hanging-note" issue plaguing many SB16s isn't so much related to inadequate buffering, but is instead the "spurious-byte," DMA-interrupt-related bug affecting MPU-401 playback. SB MIDI is not affected by this bug, as you mention. Still, NewRisingSun devised a pretty effective workaround for this issue, while another means of mitigation might be to patch the sound drivers of known affected titles to do DMA block-size transfers of ~2K or larger.

That said, the SB16's MPU buffering does yet remain something of an issue, even with the cards that don't exhibit the aforementioned, "spurious-byte" problem. Virtualizing the port to provide both software buffering, as well as permanent DRR ready status, could be a nice solution, but precludes use with protected-mode titles. Ensoniq managed to get around the whole protected-mode issue though (https://www.google.com/patents/US5790837). Has anyone ever looked into whether this method could be used for SoftMPU or otherwise?