VOGONS

Common searches


Reply 380 of 388, by elianda

User metadata
Rank l33t
Rank
l33t

I have currently no setup with 386MAX, though if you try then change the memory manager detection part to be skipped and default to the EMM386 way. If it is fully compatible then this should do.
If that works we have to adapt the memory manager detection a bit. It would also helpful to know which version of 386MAX was the first to support the port trapping API.

Retronn.de - Vintage Hardware Gallery, Drivers, Guides, Videos. Now with file search
Youtube Channel
FTP Server - Driver Archive and more
DVI2PCIe alignment and 2D image quality measurement tool

Reply 381 of 388, by georgel

User metadata
Rank Member
Rank
Member
digger wrote on 2021-09-02, 20:34:
georgel wrote on 2021-09-02, 10:10:
digger wrote on 2021-08-08, 20:24:

Question: has anybody tried using SoftMPU with the 386MAX memory manager? And if so, did it work? 386MAX is supposed to be compatible with the I/O port trapping API of Microsoft EMM386.

I'm asking this, since 386MAX might eventually be made open source, and bundled with FreeDOS. See https://sourceforge.net/p/freedos/mailman/message/28740668/ (point 4)

The 386MAX API is absolutely different than that of QEMM and I doubt it offers port trapping to V86 clients despite it uses exactly that mechanism for its very own API interface.

If you read my quote again, you'll see that I mentioned compatibility with Microsoft's port trapping API, not QPI (QEMM). From what I found on-line, 386MAX is compatible with the Microsoft API, including the port trapping stuff, and can even be considered a superset of it. To be fair, though: I haven't actually tried that myself yet. It'll be fun to experiment with this in the weekend. I was just wondering if someone here had already tried SoftMPU with 386MAX already, and if so, what the results were.

I am aware of the misleading info that you quote. A rumor is a weak word for it -- it is 100% lie.

I have a question of my own -- what is that catch of the motherboards that have the ability in their CMOS SETUPs to set the COM ports to be of MIDI type? Is it just that thus they allow the MIDI bitrate to be set on that COM port or is it more?

Reply 383 of 388, by digger

User metadata
Rank Oldbie
Rank
Oldbie
georgel wrote on 2021-09-03, 18:53:
digger wrote on 2021-09-02, 20:34:

If you read my quote again, you'll see that I mentioned compatibility with Microsoft's port trapping API, not QPI (QEMM). From what I found on-line, 386MAX is compatible with the Microsoft API, including the port trapping stuff, and can even be considered a superset of it. To be fair, though: I haven't actually tried that myself yet. It'll be fun to experiment with this in the weekend. I was just wondering if someone here had already tried SoftMPU with 386MAX already, and if so, what the results were.

I am aware of the misleading info that you quote. A rumor is a weak word for it -- it is 100% lie.

If you are referring to this article on Programmer's Heaven, I would consider it a bit harsh to call it flat-out "misleading" or a "100% lie", since the writer does clarify that he hasn't tried it himself and doesn't know for sure.

You seem quite sure that it doesn't work, though. Have you confirmed this by trying this out yourself?

Also, through some more googling/duckduckgoing on this topic, I stumbled upon the source code of usbjstik, a DOS legacy joystick driver/emulator for USB joysticks, which uses the same "INT 2Fh, Function 4A15h" API and contains multiple references to 386MAX support in the code. Also, in this forum post, Bret Johnson implies that 386MAX is supported by (and verified to work with) the usbjstik TSR.

@elianda Do you think the usbjstik source code that I linked to above would also provide a nice reference for the SoftMPU developers to add 386MAX support to SoftMPU, if that doesn't yet work out of the box (other than the EMM manager detection routine not yet taking 386MAX into account)?

Reply 384 of 388, by georgel

User metadata
Rank Member
Rank
Member

My first impression from SoftMPU (1.91) is too bad -- it is not compatible with the AWEUTIL (when loaded as TSR with /EM:xxx) - the Creative's semi-software MIDI emulator for AWE sound blasters under DOS.

Reply 385 of 388, by jesolo

User metadata
Rank Oldbie
Rank
Oldbie
georgel wrote on 2021-09-07, 20:53:

My first impression from SoftMPU (1.91) is too bad -- it is not compatible with the AWEUTIL (when loaded as TSR with /EM:xxx) - the Creative's semi-software MIDI emulator for AWE sound blasters under DOS.

SoftMPU's main purpose is to emulate an intelligent mode MPU-401 MIDI interface (using a supported sound card's UART mode MIDI interface) so that you can use it in conjunction with a real Roland MT-32 /CM-32L and also RA-50.

Reply 386 of 388, by Gmlb256

User metadata
Rank Member
Rank
Member
georgel wrote on 2021-09-07, 20:53:

My first impression from SoftMPU (1.91) is too bad -- it is not compatible with the AWEUTIL (when loaded as TSR with /EM:xxx) - the Creative's semi-software MIDI emulator for AWE sound blasters under DOS.

I'm surprised that you didn't know about this. 😜

SoftMPU needs to use a dumb MPU-401 interface and SB IRQ (doesn't use the MPU-401 IRQ) to emulate the intelligent mode and the only way to use this on AWE cards is through the actual MPU-401 interface. The EMU8K synth doesn't even have a MIDI interpreter there and is more akin to the GUS GF1 and AMD InterWave chips there in programmability.

This program can also be used with serial ports and SB-MIDI interface but the latter one decreases compatibility.

Reply 387 of 388, by georgel

User metadata
Rank Member
Rank
Member

Here is my preliminary build of SoftMPU that under QEMM (QEMM V9 tested only, EMM386 fails with AWEUTIL /EM:xxx but otherwise is usable to some extent) supports separate I/O ports for virtual and physical MPU-401's thus allowing usage of AWEUTIL /EM:xxx with your favorite soundbanks . Apart from utilizing AWEUTIL this allows you to have very flexible sound setups. If you specify on the command line same (overlapping) ports for virtual and physical MPUs then this works exactly like conventional SoftMPU 1.91 but such setup prohibits AWEUTIL from operating.

Attachments

Last edited by georgel on 2021-09-15, 22:14. Edited 1 time in total.

Reply 388 of 388, by igna78

User metadata
Rank Newbie
Rank
Newbie
georgel wrote on 2021-09-15, 21:26:

Here is my temporary build of SoftMPU that under QEMM (V9 tested only, EMM386 fails with AWEUTIL /EM:xxx) supports separate I/O ports for virtual and physical MPU-401's thus allowing usage of AWEUTIL /EM:xxx with your favorite soundbanks . Apart from utilizing AWEUTIL this allows you to have very flexible sound setups. If you specify on the command line same ports for virtual and physical MPUs then this works exactly like conventional SoftMPU 1.91 but this setup prohibits AWEUTIL from operating.

Really congratulations for what has been done! I am amazed, you have succeeded where the dreams of others were shattered 👍