carlostex wrote:

The games i tried were: Tyrian Raptor: Call of the Shadows Duke Nukem 3D DOOM […]
Show full quote

The games i tried were:
Tyrian
Raptor: Call of the Shadows
Duke Nukem 3D
DOOM

I think all of these use DOS/4GW, but not sure.

Yeah I think so. There may not be many real-mode games out there that support General Midi. GMPlay will work though 😀
I think the primary use case will still be playing MT-32 games.

Hopefully I'll get my retro PC set up soon and I can look into the WC1 issue. Right now I am running it through Bochs and Microsoft Synth on a Win 7 PC so my instruments are already messed up 🤣

Damn i should have tried Dune 2 before reverting into the YMF again. I'm not sure but i don't think it needs protected mode.

Quick report on a CT1330A:

works without /DELAYSYSEX : Dragonsphere
does not work: Wing Commander 1 (all versions) /hanging note at all speeds/, Laser Squad /game starts but no communication with the MT32/, Gateway 2 /game freezes at startup/

I thought that the difficulty with using SB-MIDI to emulate an MPU-401 is that you need to send a DSP command to allow for MIDI transfers. But then you would need to send a different DSP command to allow for digitized sound output. Games using the Sound Blaster for digitized sound output, like Wing Commander II, would not work with this method.

Isn't that exactly what Sierra's MTBLAST.DRV does though?

Granted it may require a particular ordering of the DSP commands.

Sierra's official MTBLAST.DRV isn't used in any of the games that require a true MPU-401. I believe it was first used with Space Quest IV. You should ask NewRisingSun about his driver. All the Sierra games on the list don't have a separate selection for music and digital devices, neither does Ultima VI, Simon the Sorcerer (floppy version at least), A-10 Tank Killer, It Came from the Desert or Wing Commander. Superhero League of Hoboken, Wing Commander II and Might and Magic III all do. I don't know about the other games.

If I understood correctly this trouble I can say too about it. I tested Creative SB16/AWE cards and non-Creative cards. It's interesting that Creative cards can't play digitized sound and LA at the same time if a game has separate settings for SFX and music. Non-Creative cards can do it. If I select with Creative card in game settings Sound Blaster for digitized sound and General MIDI for music together it works perfect. But when I try SB-sound and MT32-music together the system freezes and doesn't respond keys. For UART mode it happens same every time with or without SoftMPU equally. Non-Creative cards play SB-sound and MT-32 together without any problems.

Which game was that PARUS?

Some early Sound Blaster 16s do exhibit a problem in certain games with digital out + MPU-401 MIDI. This is what SBMPU401.EXE and similar utils are meant to fix (by disabling the MPU interrupts). I'm unclear the bug is in the hardware or in the affected games. Also, I can't see why this would affect LA MIDI but not GM, unless it's a game-specific bug.

Great Hierophant wrote:

Sierra's official MTBLAST.DRV isn't used in any of the games that require a true MPU-401

Don't think this is relevant to the question of whether SBMIDI + digital FX are possible. Flashback also supports this btw.

Is it possible to add a CM64 and CM500 switch to SoftMPU?

Would be beneficial to turn the CM-32P parts to "off" so it sounds correctly. Now this has to be done with SysEx messages prior to startup. If mode A could be used and SoftMPU auto sensed if LA or GM synth was going to be used and turned off the correct channels on the CM500 that would be even more awesome as it would eliminate knob switching.

See this post: Wrong notes/instruments in Larry 3 with CM-500?!
and this: http://queststudios.com/smf/index.php?topic=2778.0

Just write two batch files that do it for you. I don't think it's a feature that should be part of SoftMPU, but that's just my take on this of course...

Mau1wurf1977 wrote:

Just write two batch files that do it for you. I don't think it's a feature that should be part of SoftMPU, but that's just my take on this of course...

There is already a feature with the optional /RA50 switch which enables simulated "All Notes Off" commands for compatibility with the Roland RA-50. I don't see how this is any different than turning off notes on the CM500 and CM64.

Hmm didn't know about that switch 😀

Fair enough then.

Muting the CM-32P part via SoftMPU would be very handy. We could then create .BAT files with the proper switches for any specific module you wanted to run at the moment.

For instance, it would be nice to send the SYSEX file to lower the internal volume of the CM-32L to avoid/minimize the clipping issue before running the games.

Just suggesting. 😀

While I can see how these init options would be useful, I'd like to restrict SoftMPU to things that can't be achieved with other tools.

For example, the RA-50 mode is only possible becaused SoftMPU can continuously intercept and modify the MIDI stream.

I think device-specific initialization is best performed by another tool (e.g. GSPlay). This can happen either before or after SoftMPU is installed.

bjt wrote:

While I can see how these init options would be useful, I'd like to restrict SoftMPU to things that can't be achieved with other tools.

For example, the RA-50 mode is only possible becaused SoftMPU can continuously intercept and modify the MIDI stream.

I think device-specific initialization is best performed by another tool (e.g. GSPlay). This can happen either before or after SoftMPU is installed.

Fair enough!

Update on the old Ultimate DOS machine:

EMM386 and QEMM works with SoftMPU, and JEMM386 almost had the job done, but I had an error pop up:

1√ MPU-401 detected at port 330
2√ Sound Blaster detected at port 220 IRQ 9
3i SYSEX delays enabled
4! Error: port trap failed. Please submit a bug report

EMM386 and QEMM works with SoftMPU and JEMM386 (FreeDOS) almost works... except there are software and one dll that need to be loaded in order for JEMM386 to work:

1iotrap.dll
2jload.exe
3testiot
4makefile <-- must be running in probably Linux to make the iotrap.dll and testiot files

According to jwt27:

jwt27 wrote:

JEMM source does include an example of using the port trapping API. That's what this emulator uses right?

JEMM is a bit different in that it requires the driver to be a DLL, as Jemm Loadable Module:

1. About […]
Show full quote

1. About

IOTRAP is a JLM sample which demonstrates how to trap IO port access.

2. How to install and uninstall IOTRAP

IOTRAP can be installed either as a device driver in CONFIG.SYS:

DEVICE=JLOAD.EXE IOTRAP.DLL

or as a TSR from the command line:

JLOAD IOTRAP.DLL

To uninstall, use JLOAD's -u option:

JLOAD -u IOTRAP.DLL

3. How to test IOTRAP

- install IOTRAP: C:\>JLOAD iotrap.dll
- install TESTIOT: C:\>testiot
- start DEBUG: C:\>debug
- read port 100: -i 100

now a colored string '*#!+' should appear on line 25.

4. License

IOTRAP is Public Domain.

Japheth

Source of the readme file:
sdcboot/freedos/source/jemm/jlm/iotrap

We already discussed here that JEMM support would require to fork SoftMPU to a JEMM loadable module or to have a just a stub for port trapping as JEMM dll that talks with the SoftMPU TSR. This is more complicated as you may think since the port trap callback is in protected mode.
So it is not the case that it "almost" works, but the different approach of port trapping implementation by JEMM is not supported at all atm. The error message just comes up since JEMM appears in the memory manager detection as an oldschool manager, so SoftMPU tries the [Q]EMM386 port trapping API which JEMM does not support.
Still, if you take the effort and add a patch to SoftMPU to support JEMM I am confident that bjt includes it in a future release.

elianda wrote:

We already discussed here that JEMM support would require to fork SoftMPU to a JEMM loadable module or to have a just a stub for port trapping as JEMM dll that talks with the SoftMPU TSR. This is more complicated as you may think since the port trap callback is in protected mode.
So it is not the case that it "almost" works, but the different approach of port trapping implementation by JEMM is not supported at all atm. The error message just comes up since JEMM appears in the memory manager detection as an oldschool manager, so SoftMPU tries the [Q]EMM386 port trapping API which JEMM does not support.
Still, if you take the effort and add a patch to SoftMPU to support JEMM I am confident that bjt includes it in a future release.

I have enclosed the files for JEMM for you to look at and test.

If all else fails, I did my best to get the patch to work...

You can change the files for your own testing method in case the files I made don't work out as planned.

Happy testing.

Edit: does anyone know the port the program traps? I tried 100, 220, and 330 with no avail. Must be my lack of knowledge.

Bump - new release, see first post for details.

The new support for SB-MIDI allows SoftMPU to be used with older Creative cards like the Sound Blaster Pro. Games send MIDI data to SoftMPU's virtual MPU port to be piped though the Sound Blaster via SB-MIDI.

There are a couple of gotchas:

- Only real-mode games work (no DOS extenders etc.)
- Games that use MPU interrupts (a handful of intelligent-mode games) are currently not supported

Nevertheless this allows a lot of classic games (Lucasarts adventures etc) to work with a MT-32 connected to a Sound Blaster or SB Pro, something that's not been possible before.

Wow.... thats awesome!

I will give it a try soon.

Are you the only person developing this software bjt or is there a couple of you?