Reply 380 of 419, by Cloudschatze
- Rank
- Oldbie
Another option regarding serial MIDI output for protected-mode titles, and in lieu of SoftMPU, is to modify the MPU driver/routine for a particular game or sound system to natively provide that support.
Another option regarding serial MIDI output for protected-mode titles, and in lieu of SoftMPU, is to modify the MPU driver/routine for a particular game or sound system to natively provide that support.
Cloudschatze wrote on 2021-03-01, 18:00:Another option regarding serial MIDI output for protected-mode titles, and in lieu of SoftMPU, is to modify the MPU driver/routine for a particular game or sound system to natively provide that support.
That's indeed an option, but that would require the development of game-specific patches.
But then again, many protected mode games used standard drivers such as MIDPAK, AIL/32, AIL3, HMI and SCI32 (Sierra games). I guess you'd have to patch each driver type only once, which would be a lot less work to support a large number of games. That would still leave a lot of protected mode games with proprietary drivers or routines that would require individual patches, though.
It would still be more convenient to develop an emulation solution that would work with protected mode games, since such a solution could then perhaps also be used to implement Sound Blaster emulation for systems lacking ISA slots.
I'm curious if there is a comprehensive list somewhere of all protected mode DOS games ever released, along with the sound driver model each one uses, if any.
MobyGames has searchable game database, but not all information in it is accurate. It could perhaps provide a starting point, though.
Just curious - most protected mode games only came out after 1993, when General MIDI was already the standard for games and none required an intelligent mode MPU-401 MIDI interface.
Why do you then need SoftMPU? Just route the MIDI straight from any sound card with an onboard UART mode MIDI interface.
digger wrote on 2021-03-05, 23:30:Cloudschatze wrote on 2021-03-01, 18:00:Another option regarding serial MIDI output for protected-mode titles, and in lieu of SoftMPU, is to modify the MPU driver/routine for a particular game or sound system to natively provide that support.
But then again, many protected mode games used standard drivers such as MIDPAK, AIL/32, AIL3, HMI and SCI32 (Sierra games). I guess you'd have to patch each driver type only once, which would be a lot less work to support a large number of games.
Exactly this. I have some experience modifying routines for serial output, and plan to take a look at some of the later drivers as I have time.
jesolo wrote on 2021-03-05, 23:39:Just curious - most protected mode games only came out after 1993, when General MIDI was already the standard for games and none required an intelligent mode MPU-401 MIDI interface.
Why do you then need SoftMPU? Just route the MIDI straight from any sound card with an onboard UART mode MIDI interface.
The context here isn't intelligent mode support, but rather, MIDI over RS-232, which is useful for systems lacking a discrete MPU solution (laptops, expansion-limited systems, etc.). SoftMPU provides this functionality/redirection, but cannot be used with protected-mode software.
bjt wrote on 2013-05-01, 15:35:MS EMM386 4.46 (MS-DOS 6.0) or later is required. AFAIK no third party EMMs support the MS port trapping API.
JEMM and QEMM do have their own (incompatible) port trapping APIs.
I asked Japeth about possibly implementing the QEMM API (called QPI) in Jemm, but he said it would be complicated and not worth the effort.
So now we have the rather unfortunate situation in which there are three mutually incompatible port trapping APIs (namely Microsoft EMM386, QEMM's QPI and JLM), with JLM being distinctly different, complicating any attempts to port TSRs like SoftMPU and VSB even more.
That makes wonder... If technically possible, wouldn't it make more sense to implement the port trapping APIs from Microsoft and QEMM as Jemm Loadable Modules?
So if for instance you use FreeDOS and Jemm and you want to load a TSR that is dependent on QEMM, you load the JLM that adds QPI compatibility, and then you load the TSR? And then you could have such a JLM for Microsoft EMM386 compatibility as well.
This would have multiple advantages: it would not add a maintenance burden for the Jemm maintainer, you could add compatibility with both APIs this way, and you wouldn't have to port the existing TSRs to JLMs.
(Yeah, I know, I'm quoting a very old post, but the problem remains unsolved to this day.)
I would love SoftMPU to support Jemm386 too. I'm currently using a combination of XMGR and Jemm386 and its too good to ignore.
Hi there! I have an issue with SoftMPU.
With my P166MMX PC, using SetMul, games that require Intelligent Mode take a few minutes to load. Does somebody know why this could happen??
Thank you!
carlostex wrote on 2021-06-12, 18:27:I would love SoftMPU to support Jemm386 too. I'm currently using a combination of XMGR and Jemm386 and its too good to ignore.
What are the advantages? What kind of compatibility problems are there that make it worth keeping this memory manager over another?
Kahenraz wrote on 2021-09-06, 00:18:carlostex wrote on 2021-06-12, 18:27:I would love SoftMPU to support Jemm386 too. I'm currently using a combination of XMGR and Jemm386 and its too good to ignore.
What are the advantages? What kind of compatibility problems are there that make it worth keeping this memory manager over another?
I believe Jemm386 offers some performance advantages, or lower memory requirements, or something like that.
But there's also simply the preference of some users (like me) for a stack that is completely open-source (FreeDOS + Jemm386 + SoftMPU).
As I mentioned in another SoftMPU thread, hopefully 386MAX will be released as open source as well, which would make it an interesting alternative, since it supposedly supports the same I/O port trapping API that Microsoft EMM386 does. Although that is currently disputed and has yet to be tested by someone. (I know, I know, I'll get around to it. 😅)
kolderman wrote on 2019-09-27, 10:45:Can SoftMPU trap one port and redirect to another? I have a Aztech card that has a waveblaster at 530h but I would like to use port 330h.
Re: SoftMPU project needs your help! (game & sound card testing)
georgel wrote on 2021-09-17, 20:32:kolderman wrote on 2019-09-27, 10:45:Can SoftMPU trap one port and redirect to another? I have a Aztech card that has a waveblaster at 530h but I would like to use port 330h.
Re: SoftMPU project needs your help! (game & sound card testing)
Very strange that a MPU-401 device is at 530h. However said version of SoftMPU works without any issues using the virtual MPU ports, you still need to release the source code due to license though. 😉
VIA C3 Nehemiah 1.2A @ 1.46 GHz | ASUS P2-99 | 256 MB PC133 SDRAM | GeForce2 GTS 32 MB | Voodoo2 12 MB | SBLive! | AWE64 | SBPro2 | GUS
Is softmpu specifically known not to work with QEMM 6, or has it simply not been tested on this version?
maxtherabbit wrote on 2021-11-30, 03:37:Is softmpu specifically known not to work with QEMM 6, or has it simply not been tested on this version?
Versions earlier than 7.03 don't work because they lack support for the port trapping API.
bjt wrote on 2021-11-30, 08:03:maxtherabbit wrote on 2021-11-30, 03:37:Is softmpu specifically known not to work with QEMM 6, or has it simply not been tested on this version?
Versions earlier than 7.03 don't work because they lack support for the port trapping API.
Are you sure? The QPI documentation seems to contradict this
maxtherabbit wrote on 2021-11-30, 15:45:bjt wrote on 2021-11-30, 08:03:Versions earlier than 7.03 don't work because they lack support for the port trapping API.
Are you sure? The QPI documentation seems to contradict this
I believe that's the case, yes. Elianda may be able to provide more detail as he wrote the QEMM support.
I went ahead and built a binary that changed the QEMM version check to 6.0. I'll report back later if it works.
BTW - there is an error in your BUILD.BAT
@set LINK=C:\MASM611\BINR\LINK.EXE
There is no 'BINR' directory in a full installation of MASM611, LINK.EXE is in 'BIN'
Port trap failed! Oh well I tried 🤣
Hi
I can't install Microsoft C 6.0A & MASM 6.11 and therefore soft mpu. Will someone share an disc image with installed programs?
maxtherabbit wrote on 2021-12-01, 19:16:There is no 'BINR' directory in a full installation of MASM611, LINK.EXE is in 'BIN'
There is in my install of MASM611 (default install options)
ciamcia wrote on 2022-01-19, 14:07:Hi
I can't install Microsoft C 6.0A & MASM 6.11 and therefore soft mpu. Will someone share an disc image with installed programs?
That's only required if you want to build SoftMPU. There is a precompiled SOFTMPU.EXE in the zip file.