Running SoftMPU together with VSBHDA

[hjnijlunsing]

I am trying to run SoftMPU in parallel with VSBHDA; but cannot get it to work. For SoftMPU I require Qemm, but I cannot seem to get Qemm working with VSBHDA as it directly crashes.

Should Qemm 7.5 be compatible with VSBHDA? And if so how should my config.sys / autoexec.bat look like?

[Baron-von-Riedesel]

but I cannot seem to get Qemm working with VSBHDA as it directly crashes.

I don't know how SoftMPU is working, so I most likely cannot help here.

Should Qemm 7.5 be compatible with VSBHDA?

I guess yes - if the Qemm port trapping API is found ( should be in v7.x ). If the API isn't found, an error will be displayed.

And if so how should my config.sys / autoexec.bat look like?

I'm no Qemm expert, in my config.sys, qemm is installed with:

DEVICE=C:\QEMM97\QEMM386.SYS FRAME=D400 BE:N XBDA:N RAM X=E400-EBFF

but the frame address ( D400 in my case ) might be different for your system.

[volkertb]

Wouldn't it be better if SoftMPU's features were incorporated into VSBHDA? As I understand it, SoftMPU wouldn't work with protected mode games, since it doesn't go through HDPI, like VSBHDA does, correct?

It would be really cool if MIDI devices could be used in more modern machines through either serial ports or USB MIDI adapters, while maintaining (emulated) compatibility with the Roland MPU-401 interface.

[hjnijlunsing]

Yes, I agree indeed Softmpu has a legacy way of port trapping and VSBHDA seems more compatible. Apart from Serial Ports, USB MIdi Adapters (Or USB Serial adapters) also Midi over UTP (packet driver) would be an option (as supported by MT32pi) ;-)

[Baron-von-Riedesel]

I just had a look at SoftMPU. It does indeed use Qemm's QPI for port trapping. To adjust it to also accept JemmEx/QPIEMU, just a handful additional lines are needed in TRANS.ASM.

[hjnijlunsing]

Am I correct that with those changes SoftMPU would actually support protected mode games? Quote from: https://www.vogons.org/viewtopic.php?t=36118&start=320

"Hi, unfortunately SoftMPU will only work with real-mode software. Believe both Settlers II and Sam & Max are protected mode. This is a limitation of the port-trapping tech that SoftMPU uses. It isn't a problem for SoftMPU's primary application (intelligent mode games) as these are all older and real-mode, but it does restrict the serial output mode somewhat."

[Baron-von-Riedesel]

Am I correct that with those changes SoftMPU would actually support protected mode games?

With what changes? Adjusting SoftMPU for Jemm? Definitely no.

[volkertb]

Am I correct that with those changes SoftMPU would actually support protected mode games? Quote from: https://www.vogons.org/viewtopic.php?t=36118&start=320

It's important not to conflate two different things here.

What @Baron-von-Riedesel was talking about was making SoftMPU compatible with Jemm, by leveraging his recently introduced QPI Emulation module, that is bundled with the most recent (pre-release) builds of JEmm. That would not make SoftMPU work with protected mode games, but it would at least allow it to work with Jemm as an alternative to QEMM. Unlike QEMM, Jemm is open source and still being maintained. It's also the standard EMM manager that comes with FreeDOS, which increases the outlook of having SoftMPU included in FreeDOS in the near future.

To make SoftMPU also work with protected mode games, it would have to be enhanced to also make use of the port trapping API that was recently introduced in HDPMI32i.

VSBHDA and SBEMU work with both real mode and protected mode games, because they use both Jemm (with the QPIEMU module) and HDPMI32i, botth of which should be loaded first before loading those sound emulators.

As for how much effort would be needed to have SoftMPU alsy make use of HDPMI32i, so it could also work with protected mode games, I'm curious about that too.

One complication that I hope to see resolved soon is a reconciliation between @Baron-von-Riedesel's (upstream) HDPMI32i and @crazii's HDPMI32i fork. That would benefit both SBEMU and a future version of SoftMPU that would also leverage it.

[crazii]

Yeah that's another way to get midi, we can skip reinventing the wheels for SBEMU and add PM port trapping to SoftMPU - that might be much simpler.

I want drop the HDPMI32i fork and uses the official one, but it needs a little bit investigation.

[Torinde]

I just had a look at SoftMPU. It does indeed use Qemm's QPI for port trapping. To adjust it to also accept JemmEx/QPIEMU, just a handful additional lines are needed in TRANS.ASM.

One outstanding SoftMPU PR seems related, but it changes PORTHAND.ASM.

EDIT: Sorry, it won't do that:

It's just redundant. Your code works fine as it is now.

[bjt42]

Hi all, following this discussion with interest. I've added a comment regarding the suitability of SoftMPU as a general purpose MIDI redirector to bjt42/softmpu/issues/31. The TLDR is that I feel the PM MIDI redirection functionality would be best implemented as a separate TSR/JLM or otherwise integrated into something like VSBHDA.

If someone did want to look at adding HDMPI32i support to SoftMPU for PM MIDI redirection, there are some (possibly major?) conderations. IIRC SoftMPU expects a 16-bit PM call to its port trap handler and on first trap attempts to directly modify the GDT to allow access to the resident TSR code & data. It also reads & writes directly to the MPU I/O port from the trap handler.