Another thing to note here is that at this moment the MPU emulation code is entirely homegrown, so bugs can exist.

The IRQ emulation code is also kind of hardcoded to only push out sound related interrupts so it's unfortunately looking difficult to meaningfully add MT-32 emulation given the need to also implement Intelligent Mode.

Cacodemon345 wrote on 2025-02-05, 14:09:

Another thing to note here is that at this moment the MPU emulation code is entirely homegrown, so bugs can exist.

The IRQ emulation code is also kind of hardcoded to only push out sound related interrupts so it's unfortunately looking difficult to meaningfully add MT-32 emulation given the need to also implement Intelligent Mode.

Not necessarily! Quite a few pre-GM era games that sound best on an MT-32 work in UART mode. Probably even the vast majority of them.

From what I've read in other threads, the list of games that really require Intelligent Mode for MPU-401 MIDI support is actually surprisingly short.

There's definitely a whole range of games that would benefit from MT-32 emulation without Intelligent Mode support.

In the longer term, you could look into adopting more code from the SoftMPU project, since that project had already worked out all the Intelligent Mode stuff years ago.

On the other hand, I also recall a SoftMPU developer somewhere here on Vogons suggesting us not to bother with Intelligent Mode support in newer emulators such as SBEMU and VSBHDA(SF), since those very few games that truly need it are so old, that they easily run at full speed in DOSBox on modern machines anyway. Especially since it's apparently very tricky to emulate in terms of timing and such.

I attempted to add MT-32 emulation via Munt.

Safe to say, I couldn't get it to work properly. First thing is that it is C++-based, and is impossible to compile without RTTI due to reliance on dynamic_cast. It also has no provisions for custom allocators unlike TinySoundFont, which makes it very hard to support.

Which may lead to the question "how did I get TSF working then?". It was not easy (but not too hard either) to make it work; it used to rely on C standard library functions originally, which would fail hard after the TSR relocation given its usage nature, and it had to be made to pre-allocate the channels manually since it didn't even do that properly. Making it rely on DPMI allocation and revising FPU save/restore functions to not make the compiler wreck up the final executable was very much needed, since it'd otherwise crash programs left-and-right (and even freeze the system!) for mysterious reasons. Munt being C++ is not very usable for TSR programs, and is relying on new/delete memory allocation pairs for itself. The very-small 4KiB stack for protected-mode interrupts also very much does not help at all.

I apologize to everyone that wanted MT-32 emulation on VSBHDASF. Any PRs that can add MT-32 emulation without wrecking up programs (or the system) is very much appreciated, but I have to pass on Munt for now.

I reported this: https://github.com/Baron-von-Riedesel/VSBHDA/issues/32 for VSBHDA but VSBHDASF also inherits this issue.
Do you think it can be fixed?

I don't have any machines with the codec in question so I can't fix it myself. It's also better that this gets fixed upstream.

Hello,
I tested this with my Libretto U100 (AC97), and when I run the program it completely crashes the system. Not even Ctrl+Alt+Del works.
By the way, I tested it with several versions, and this problem occurs in all of them. With the Baron-von-Riedesel fork it works perfectly.
Has this problem occurred with anyone else? Any tips?

sergio_prado wrote on 2025-03-21, 22:47:

Hello, I tested this with my Libretto U100 (AC97), and when I run the program it completely crashes the system. Not even Ctrl+A […]
Show full quote

Hello,
I tested this with my Libretto U100 (AC97), and when I run the program it completely crashes the system. Not even Ctrl+Alt+Del works.
By the way, I tested it with several versions, and this problem occurs in all of them. With the Baron-von-Riedesel fork it works perfectly.
Has this problem occurred with anyone else? Any tips?

Well, laptops like these are blatantly incompatible with almost anything, these special drivers are only worth using with regular desktop computers.

DarthSun wrote on 2025-03-21, 23:03:

sergio_prado wrote on 2025-03-21, 22:47:

Hello, I tested this with my Libretto U100 (AC97), and when I run the program it completely crashes the system. Not even Ctrl+A […]
Show full quote

Hello,
I tested this with my Libretto U100 (AC97), and when I run the program it completely crashes the system. Not even Ctrl+Alt+Del works.
By the way, I tested it with several versions, and this problem occurs in all of them. With the Baron-von-Riedesel fork it works perfectly.
Has this problem occurred with anyone else? Any tips?

Well, laptops like these are blatantly incompatible with almost anything, these special drivers are only worth using with regular desktop computers.

My laptop works fine with all SBEMU forks, including Baron-von-Riedesel's VSBHDA. Only with this one does the mentioned problem occur.

sergio_prado wrote on 2025-03-22, 12:53:

DarthSun wrote on 2025-03-21, 23:03:

sergio_prado wrote on 2025-03-21, 22:47:

Hello, I tested this with my Libretto U100 (AC97), and when I run the program it completely crashes the system. Not even Ctrl+A […]
Show full quote

Hello,
I tested this with my Libretto U100 (AC97), and when I run the program it completely crashes the system. Not even Ctrl+Alt+Del works.
By the way, I tested it with several versions, and this problem occurs in all of them. With the Baron-von-Riedesel fork it works perfectly.
Has this problem occurred with anyone else? Any tips?

Well, laptops like these are blatantly incompatible with almost anything, these special drivers are only worth using with regular desktop computers.

My laptop works fine with all SBEMU forks, including Baron-von-Riedesel's VSBHDA. Only with this one does the mentioned problem occur.

I see, I didn't exactly follow the problem then.

sergio_prado wrote on 2025-03-22, 12:53:

DarthSun wrote on 2025-03-21, 23:03:

sergio_prado wrote on 2025-03-21, 22:47:

Hello, I tested this with my Libretto U100 (AC97), and when I run the program it completely crashes the system. Not even Ctrl+A […]
Show full quote

Hello,
I tested this with my Libretto U100 (AC97), and when I run the program it completely crashes the system. Not even Ctrl+Alt+Del works.
By the way, I tested it with several versions, and this problem occurs in all of them. With the Baron-von-Riedesel fork it works perfectly.
Has this problem occurred with anyone else? Any tips?

Well, laptops like these are blatantly incompatible with almost anything, these special drivers are only worth using with regular desktop computers.

My laptop works fine with all SBEMU forks, including Baron-von-Riedesel's VSBHDA. Only with this one does the mentioned problem occur.

Have you tried both the P4/SSE2 optimized and the normal/x87 version of the driver (VSBHDAP4 vs. VSBHDA)?

Reminder that all VSBHDASF releases are compiled with DJGPP, and it has the potential to mis-compile the program due to it heavily using assembly code to perform its functions, so while it may work for many people, I can't guarantee that it will work on each and every system upstream VSBHDA and SBEMU will work on.

This does not mean that majority of the systems will not run VSBHDASF; a lot of them will do (even the more finicky Skylake/Kabylake desktops and laptops), more than what one will think.