VOGONS

Common searches


Reply 380 of 390, by Cloudschatze

User metadata
Rank Oldbie
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.

Reply 381 of 390, by digger

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 382 of 390, by jesolo

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 383 of 390, by Cloudschatze

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 384 of 390, by digger

User metadata
Rank Oldbie
Rank
Oldbie
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.)

Reply 386 of 390, by AndalusianRG

User metadata
Rank Newbie
Rank
Newbie

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!

Reply 387 of 390, by Kahenraz

User metadata
Rank Oldbie
Rank
Oldbie
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?

Reply 388 of 390, by digger

User metadata
Rank Oldbie
Rank
Oldbie
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. 😅)

Reply 389 of 390, by georgel

User metadata
Rank Member
Rank
Member
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)

Reply 390 of 390, by Gmlb256

User metadata
Rank Oldbie
Rank
Oldbie
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. 😉