georgel wrote on 2021-09-02, 08:29:

One can use SoftMPU for such games along with AWEUTIL /EM:MT32 but none of the protected mode games sends SysEX messages as far as I've learned from this forum, doesn't it?

Later protected mode games do not since they do not support the MT-32 at all. Of course you can use an MT-32 soundbank with later protected mode games that support only GM/GS (that's a personal preference) but then they will use wrong instruments. You may actually 'like' the wrong instruments better (I think this can be contributed to the anemic default GM set used by the AWE line) but it does not change the fact that the default instrument map of GM/GS and MT-32 substantially differ.

Default GM/GS (capital tones):

Default MT-32:

What about earlier protected mode games -- do they use SysEX messages; give an example of such game , please?

I've never insisted on using MT32 .sbk instead of GM .sbk where inappropriate, don't get me wrong. Just my testing setup for the DOS32AWE was that and for the project debugging it was irrelevant which .sbk to use. It is just a matter of of the AWEUTIL /EM:xxx option setting.

Did testing with the new version yesterday.

DOS32AWE still crashes after time passes even if I executed BEFORE_A.COM (what tweaks it does to improve stability?) prior starting AWEUTIL as a TSR. Also the actual MPU-401 found on the AWE64 (thru gameport) get messed up that I can't use it (got a I/O channel check error) unless I turn off the computer and turn it on again, I think it may be related to BEFORE_A.COM.

I also used a more fresh CONFIG.SYS this time with STACKS=9,256 loaded at low memory and no EMM to make sure.

Gmlb256 wrote on 2021-09-02, 14:15:

Did testing with the new version yesterday.

DOS32AWE still crashes after time passes even if I executed BEFORE_A.COM (what tweaks it does to improve stability?) prior starting AWEUTIL as a TSR. Also the actual MPU-401 found on the AWE64 (thru gameport) get messed up that I can't use it (got a I/O channel check error) unless I turn off the computer and turn it on again, I think it may be related to BEFORE_A.COM.

I also used a more fresh CONFIG.SYS this time with STACKS=9,256 loaded at low memory and no EMM to make sure.

Thanks for testing. It works for hours without a glitch until I stop it on my p3 1.3 GHz ISA machine which used to be unstable with the initial version. How long does it take on your machine to crash in average? What do you see when it crashes, e.g. is it every time the I/O channel check error? It is time to pull another motherboard for testing since with this one there are no more issues. I am leaving DOOM2 to play its intro , and I also have no DOS mouse driver of any kind installed, and no stacks definition in config.sys at all.

georgel wrote on 2021-09-02, 14:24:

Gmlb256 wrote on 2021-09-02, 14:15:

Did testing with the new version yesterday.

DOS32AWE still crashes after time passes even if I executed BEFORE_A.COM (what tweaks it does to improve stability?) prior starting AWEUTIL as a TSR. Also the actual MPU-401 found on the AWE64 (thru gameport) get messed up that I can't use it (got a I/O channel check error) unless I turn off the computer and turn it on again, I think it may be related to BEFORE_A.COM.

I also used a more fresh CONFIG.SYS this time with STACKS=9,256 loaded at low memory and no EMM to make sure.

Thanks for testing. It works for hours without a glitch until I stop it on my p3 1.3 GHz ISA machine which used to be unstable with the initial version. How long does it take on your machine to crash in average? What do you see when it crashes, e.g. is it every time the I/O channel check error?

About 5-15 minutes in average, even if I leave the demo playing on Doom and do nothing.

The I/O channel check error happens every time when I attempt to run the game without using AWEUTIL for MIDI emulation (after executing BEFORE_A.COM and even doing a reboot without it turning off) before the music starts playing.

The behavior you describe without AWEUTIL installed as TSR (which is a must in our case) is normal. DOS32AWE is meant to be used ONLY with preinstalled as TSR AWEUTIL. Otherwise use the ordinary DOS Extender. If you don't install AWEUTIL there is no program to handle the CPU part of the MIDI emulation in real/v86 mode and system dies like you described.
What about the random error that you get after some arbitrary time, what does such a random crash output on screen?

georgel wrote on 2021-09-02, 14:35:

The behavior you describe without AWEUTIL installed as TSR (which is a must in our case) is normal. DOS32AWE is meant to be used ONLY with preinstalled as TSR AWEUTIL. Otherwise use the ordinary DOS Extender. If you don't install AWEUTIL there is no program to handle the CPU part of the MIDI emulation in real/v86 mode and system dies like you described.
What about the random error that you get after some arbitrary time, what does such a random crash output on screen?

I was running AWEUTIL as TSR prior using DOS32AWE (no ordinary DOS extender used, typing DOS32AWE DOOM.EXE on the command line), not making this up. Wonder if the 4DOS shell has something to do with this, will try later to confirm this using COMMAND.COM.

The "output" screen I get occasionally after some time are black vertical stripes, sometimes it freezes the computer that I had to reboot it.

The I/O channel check error happens every time when I attempt to run the game without using AWEUTIL for MIDI emulation

Doesn't thas mean you are not installing AWEUTIL? Why would you use DOS32AWE if you are not using AWEUTIL for MIDI, there is no reason for this.

Please double check for the other behavior that you run BEFORE_A in your autoexec.bat file as prescribed AND that the version of the DOS32AWE you are starting is the V1.1 and not some old dos32awe.exe file left that is V1.0 but unintentionally executed (in path or otherwise). The stripes were a problem of V1.0.

4DOS shouldn't be related at all. Just for information I use freedos' doskey instead.

georgel wrote on 2021-09-02, 14:52:

Doesn't thas mean you are not installing AWEUTIL? Why would you use DOS32AWE if you are not using AWEUTIL for MIDI, there is no reason for this.

This is after using AWEUTIL as TSR and rebooting the computer after the issue (I do that kind of thing to verify stability), otherwise I won't be testing, reporting and posting here at all. I always delete DOS32AWE after doing the tests to avoid leftovers.

Will double check later with a much emptier CONFIG.SYS and AUTOEXEC.BAT (with BEFORE_A.COM and AWEUTIL as TSR of course).

georgel wrote on 2021-09-02, 06:38:

First, the MT-32 parameter instructs AWEUTIL to load the MT-32 soundbank file which is SYNTHMT.SBK file and is twice the size of […]
Show full quote

The /EM:MT-32 parameter remaps the standard General MIDI (GM) instrument set to the arrangement of the Roland MT-32 (which is not a GM device). However, it cannot emulate the custom sound banks functionality of the MT-32.

First, the MT-32 parameter instructs AWEUTIL to load the MT-32 soundbank file which is SYNTHMT.SBK file and is twice the size of the general MIDI .sbk file. You don't know how to program a soundbank converter to .sbk format but you claim :

The /EM:MT-32 parameter remaps the standard General MIDI (GM) instrument set to the arrangement of the Roland MT-32 (which is not a GM device).

Secondly, which games use custom MT-32 soundbanks?

jesolo's post is 100% accurate - the reason the SBK file for the General MIDI soundfont is smaller is that it maps most of the instruments to existing samples in the card's included ROM

jesolo's desire for alternative 3rd party MIDI softbanks and/or converter from/to other formats is completely offtopic!

Gmlb256 wrote on 2021-09-02, 15:04:

This is after using AWEUTIL as TSR and rebooting the computer after the issue (I do that kind of thing to verify stability), otherwise I won't be testing, reporting and posting here at all.

Thank you for testing but if you remove dependent modules that are meant to be part of one whole set-up you would be expected only to report success here but no additional errors. Right now I have no sufficient strength to add foolproof checks in the modules (they can check if AWEUTIL is installed as TSR, etc, give more console output, etc.). All is still maybe crude, sort of proof-of-concept. But before releasing new version 1.1 I ran overnight tests on my machine without a glitch. Now I am moving to my other two ISA machines capable of running that software. Please try also with JEMMEX LOAD, it is easy to be started even after the DOS is booted, I am starting to like this new memory manager.

georgel wrote on 2021-09-02, 15:11:

jesolo's desire for alternative 3rd party MIDI softbanks and/or converter from/to other formats is completely offtopic!

I wasn't trying to detract from what you are doing here.
Merely trying to encourage someone else from expanding the functionality of the existing Aweutil utility, as you've now come up with a solution to enable someone from playing protected mode DOS games directly under DOS (as opposed to playing those games within a Windows 9x DOS prompt with custom soundfonts loaded).

As I'm hoping you are aware, under DOS, users are basically limited to only the 1 MB ROM sample set that is on an AWE card (and some of those samples sounds horrible). However, the AWE range of sound cards (with additional RAM installed) allows a user to load custom soundfonts with far superior samples than those contained in the 1 MB ROM sample set. Unfortunately, the vast majority of those custom soundfonts are in the soundfont V2 format.

FYI - I wasn't the first user that expressed a desire to be able to load V2 soundfonts under DOS. User Gmlb256 also mentioned this in his first post (2nd paragraph).

I hardly could be the person who can reverse these proprietary .sbk AWEUTIL formats considering the fact that nobody else has done it for the last some 30 years...I think they were meant to be hard to reverse in order to keep the .sbk creators from possible stupid lawsuits for bank copyright issues.

georgel wrote on 2021-09-02, 17:17:

I hardly could be the person who can reverse these proprietary .sbk AWEUTIL formats considering the fact that nobody else has done it for the last some 30 years...I think they were meant to be hard to reverse in order to keep the .sbk creators from possible stupid lawsuits for bank copyright issues.

I never meant that I expect you to be that person.

There are already converters out there to convert *.sbk to *.sf2. To convert the other way around is a bit more tricky (which I won't go into now).
You can load *.sf2 files under Windows - it's just a shame that Creative never bothered to update Aweutil to do the same under DOS.

Gmlb256 wrote on 2021-09-02, 15:04:

georgel wrote on 2021-09-02, 14:52:

Doesn't thas mean you are not installing AWEUTIL? Why would you use DOS32AWE if you are not using AWEUTIL for MIDI, there is no reason for this.

This is after using AWEUTIL as TSR and rebooting the computer after the issue (I do that kind of thing to verify stability), otherwise I won't be testing, reporting and posting here at all. I always delete DOS32AWE after doing the tests to avoid leftovers.

I suspect the cause for your trouble is not related to DOS32AWE. AWEUTIL as TSR places the AWE32 card into a mode where it generates IO Channel Check errors (NMIs) on purpose everytime MIDI is accessed. The TSR part of AWEUTIL catches these errors, and performs the necessary MIDI emulation. When you reboot the machine, AWEUTIL is no longer installed and is no longer able to catch the fake IO Channel Check errors generated by the AWE32 card when MIDI ports are accessed. Something needs to tell the AWE32 card to stop generating the IO Channel Check errors after reboot. As far as I know, AWEUTIL /S (which doesn't install the TSR part) will turn off this feature. Rebooting after you used AWEUTIL as TSR without running AWEUTIL /S from autoexec.bat during the next boot is not supported by Creative Labs.

mkarcher wrote on 2021-09-02, 18:10:

Gmlb256 wrote on 2021-09-02, 15:04:

georgel wrote on 2021-09-02, 14:52:

Doesn't thas mean you are not installing AWEUTIL? Why would you use DOS32AWE if you are not using AWEUTIL for MIDI, there is no reason for this.

This is after using AWEUTIL as TSR and rebooting the computer after the issue (I do that kind of thing to verify stability), otherwise I won't be testing, reporting and posting here at all. I always delete DOS32AWE after doing the tests to avoid leftovers.

I suspect the cause for your trouble is not related to DOS32AWE. AWEUTIL as TSR places the AWE32 card into a mode where it generates IO Channel Check errors (NMIs) on purpose everytime MIDI is accessed. The TSR part of AWEUTIL catches these errors, and performs the necessary MIDI emulation. When you reboot the machine, AWEUTIL is no longer installed and is no longer able to catch the fake IO Channel Check errors generated by the AWE32 card when MIDI ports are accessed. Something needs to tell the AWE32 card to stop generating the IO Channel Check errors after reboot. As far as I know, AWEUTIL /S (which doesn't install the TSR part) will turn off this feature. Rebooting after you used AWEUTIL as TSR without running AWEUTIL /S from autoexec.bat during the next boot is not supported by Creative Labs.

You have a point there. I tried without using BEFORE_A.COM that comes with the 1.1 version of DOS32AWE and the I/O channel check error appears after installing AWEUTIL as a TSR (regardless of the DOS program) and then rebooting, the only difference is that the computer didn't hang after some time passes on a non-protected mode program. When I unloaded properly AWEUTIL with the /U parameter, the actual MPU-401 works correctly without any issues.

Gmlb256, is the BIOS of your Socket 7 motherboard AMI?

georgel wrote on 2021-09-02, 18:30:

Gmlb256, is the BIOS of your Socket 7 motherboard AMI?

Award BIOS.

Cool! A while back, I opened another thread in which I inquired about the possibility of handling sound card emulation in the DOS extender, for protected mode games for which real mode emulators wouldn't work.

But after doing some further research, I thought this wouldn't be possible with DOS/32A, since it runs the game in ring 0 (unrestricted), as opposed to other DOS extenders that run the game in ring 3, allowing hardware access to be intercepted. How did you get around this? Or did I misinterpret the documentation I found about this?

Anyway, I believe the CauseWay DOS extender, which can also be used as a drop-in replacement for DOS/4GW and is now also open source, does run its payload in ring 3, which would perhaps make it more suitable for integrating ISA sound card emulation.