yup.

I was not discounting it being basically a gimmick.

I still point out that it would give you plenty of mixer space for layering OPL with FM. (Or, maybe one day, software Wavetable)

crazii wrote on 2024-04-26, 03:49:

analog_programmer wrote on 2024-04-25, 08:49:

I read about the problems with port trapping with addresses lower than 100h with EMM386.EXE and maybe the best solution for compatibility will be some patched EMM386, but this is forbidden topic here.

I don't see why it's forbidden, to modify a proprietorial program? It's not necessary to modify the program or it's image in RAM.
I'm not a lawyer but It MIGHT BE OK if only the IO permission bitmap be patched at runtime, without modifying the executable binary in RAM. That's what SoftMPU did, modifying the GDT only.

The issue, is that MS 'got wise' in their EULA saying 'no, you are forbidden to do that.' [Reverse engineer, modify, etc...]

So doing that is a property right violation.

A foible about just modifying the permissions and then hooking functions is likely (or would have been at the time, MS has essentially abandoned 9x, but still owns it) to get lawyers bristling.

analog_programmer wrote on 2024-04-25, 08:20:

Has anyone managed to successfully use SBEMU in combination with M$ HIMEM.SYS + JEMM386.EXE instead of JEMMEX.EXE?

I remember did some simple tests with HIMEM.SYS + EMM386.EXE (without real mode support), it basically work, like doom. duke3d. but I didn't test much.

crazii wrote on 2024-04-26, 03:49:

I don't see why it's forbidden, to modify a proprietorial program? It's not necessary to modify the program or it's image in RAM.
I'm not a lawyer but It MIGHT BE OK if only the IO permission bitmap be patched at runtime, without modifying the executable binary in RAM. That's what SoftMPU did, modifying the GDT only.

Thanks for your suggestion, crazii!
Actually not modifying the executable itself, but this I/O address permission map seems like very good idea. Unfortunately I don't have enough low level programming skills (I have very basic and limited experience with assembly) and knowledge on how this memory management parts of M$-DOS works "under the hood" to achieve it.

I tried SBEMU.EXE with CMI8738 and JEMMEX + HDPMI32I.EXE + QPIEMU.DLL on M$-DOS 7.1 and upon SBEMU's initialization it reports that assigns the right SB interrupt and DMA channel according to BLASTER variable values (SET BLASTER = A220 I5 D1 H5 T6 P330), but in the end it turns out that some sound setup programs detect different values. For example on first run of TR1's SETUP.EXE it determines interrupt = 10 and DMA = 0, the sound test passes and the game has sound with these "unproper" settings, but after second run (in row) of SETUP.EXE it determines the "right" values according to BLASTER variable - interrupt = 5 and DMA = 1 and sound test crashes with system hang. Overall the situation with CMI8738 is not very different from the mess when used available C-Media DOS drivers (initializers), but slightly better - at least in some rare cases the sound works 😀 There's something very wrong with SB emulation initialization for these C-Media chips.

If you're interested in this strange and buggy behavior with CMI8738 soundcard, I can provide some pictures with explanations later.

P.S. Also I found that the combination of JEMMEX + HDPMI32I.EXE + QPIEMU.DLL in most cases works fine with DOS/4GW extender dependent executables, but not with DOS/32A. I know that this is not related to SBEMU code, but it still relies on Jemm project to function properly and that's why I'm thinking of some solution for EMM386.EXE limited I/O port trapping problem.

wierd_w wrote on 2024-04-26, 03:51:

The issue, is that MS 'got wise' in their EULA saying 'no, you are forbidden to do that.' [Reverse engineer, modify, etc...]

So doing that is a property right violation.

A foible about just modifying the permissions and then hooking functions is likely (or would have been at the time, MS has essentially abandoned 9x, but still owns it) to get lawyers bristling.

Right. But rloew's win9x patches are circulating all over the internet and as far as I know some of them was paid in the past. And it seems like M$ does nothing against this.

And anything to do with so called piracy, intellectual property violation, "abandoned software" and corporate double standards is a very broad topic and far beyond the scope of this thread. M$ are welcome to forbid me to use Ghidra for educational purposes, whether they can 😀

analog_programmer wrote on 2024-04-26, 07:01:

Actually not modifying the executable itself, but this I/O address permission map seems like very good idea. Unfortunately I don't have enough low level programming skills (I have very basic and limited experience with assembly) and knowledge on how this memory management parts of M$-DOS works "under the hood" to achieve it.

It also needs to modify the porttrap handler table.

analog_programmer wrote on 2024-04-26, 07:01:

For example on first run of TR1's SETUP.EXE it determines interrupt = 10 and DMA = 0, the sound test passes and the game has sound with these "unproper" settings

Very interesting. I it's like TR installs multiple interrupt handlers to detect sound card IRQ, like doom does. I thought I have fixed that, by not sending the real IRQ (or any PCI IRQ) to clients, normal dos programs are not gonna do anything with them anyway. Are you using the latest release? if not you can try a more recent one.

analog_programmer wrote on 2024-04-26, 07:01:

P.S. Also I found that the combination of JEMMEX + HDPMI32I.EXE + QPIEMU.DLL in most cases works fine with DOS/4GW extender dependent executables, but not with DOS/32A. I know that this is not related to SBEMU code, but it still relies on Jemm project to function properly and that's why I'm thinking of some solution for EMM386.EXE limited I/O port trapping problem.

It's DOS32A, not JEMMEX. Although it's not mandatory, the DPMI spec 'suggest' to detect & use DPMI first, then VCPI, then raw mode switches. DOS32A just use VCPI even DPMI is present. I think a tiny change with DOS32A code will make it work. it'll be better if it switches stack too - to eliminate the problem faced by FastDoom.
BTW VCPI cannot be port trapped because it gives high privilege (Ring0) to a VCPI client.

crazii wrote on 2024-04-26, 09:10:

Very interesting. I it's like TR installs multiple interrupt handlers to detect sound card IRQ, like doom does. I thought I have fixed that, by not sending the real IRQ (or any PCI IRQ) to clients, normal dos programs are not gonna do anything with them anyway. Are you using the latest release? if not you can try a more recent one.

I'm using the latest SBEMU version 1.0 Beta3 which is linked in your first post in this thread. Which version should I try?

Thank you for all the detailed explanations.

crazii wrote on 2024-04-26, 09:10:

It's DOS32A, not JEMMEX. Although it's not mandatory, the DPMI spec 'suggest' to detect & use DPMI first, then VCPI, then raw mode switches. DOS32A just use VCPI even DPMI is present. I think a tiny change with DOS32A code will make it work.

DOS32A can be configured via command line switch or by other means too (its configuration utility) to use DPMI first.

analog_programmer wrote on 2024-04-26, 09:35:

crazii wrote on 2024-04-26, 09:10:

Very interesting. I it's like TR installs multiple interrupt handlers to detect sound card IRQ, like doom does. I thought I have fixed that, by not sending the real IRQ (or any PCI IRQ) to clients, normal dos programs are not gonna do anything with them anyway. Are you using the latest release? if not you can try a more recent one.

I'm using the latest SBEMU version 1.0 Beta3 which is linked in your first post in this thread. Which version should I try?

Thank you for all the detailed explanations.

You can try this one:
https://github.com/crazii/SBEMU/releases/tag/ … 024.04.11_09-01
There's a SBEMU.zip containing files needed.

georgel wrote on 2024-04-26, 09:45:

crazii wrote on 2024-04-26, 09:10:

It's DOS32A, not JEMMEX. Although it's not mandatory, the DPMI spec 'suggest' to detect & use DPMI first, then VCPI, then raw mode switches. DOS32A just use VCPI even DPMI is present. I think a tiny change with DOS32A code will make it work.

DOS32A can be configured via command line switch or by other means too (its configuration utility) to use DPMI first.

Thanks for the tip. 😁

EDIT: I checked doc before but didn't remember much. so I checked again just now after your tip. The config utility of dos32a can change the order of VCPI/DPMI.

VCPI/DPMI Detection Mode Default: VCPI/DPMI
Controls the order of VCPI/DPMI detection. When set to VCPI/DPMI, the DOS Extender will look for a VCPI server first, and if found, initialize and use it, even though a DPMI host may be present in the system. The advantage of doing so is that the VCPI servers are usually faster than DPMI hosts. On the other hand, a DPMI host may always deny the presence of VCPI, and in that case the DPMI will be detected and initialized instead.

georgel wrote on 2024-04-26, 09:45:

DOS32A can be configured via command line switch or by other means too (its configuration utility) to use DPMI first.

You're right. There is configuration utility in DOS/32A package - "ss.exe". I have to try it again as I don't remember exactly what kind of settings it sets.

crazii wrote on 2024-04-26, 09:52:

You can try this one:
https://github.com/crazii/SBEMU/releases/tag/ … 024.04.11_09-01
There's a SBEMU.zip containing files needed.

Thanks for the link. I'll try it as soon as possible and will report back if it makes any difference for the CMI8738 cards compared to 1.0 beta3 version.

zyzzle wrote on 2024-04-22, 23:48:

Also, I'm experiencing a freeze on all the userbuilds of SBEMU past February or so (since General Midi at port 0x330 was added). The SBEMU program detects all the usual settings, and then just freezes the system. All versions (even back to the first betas posted in Feb / March 2023) previously worked very well for me on Intel HDA and the same laptop - before the new MIDI / port 0x330 code was added to the program.

Are there commandline options to specificially disable this detection. I can't even run SBEMU to get a list of the commandline options, as it crashes my system immediately. Strange, indeed.

Can you test this temporary build to see if it works?
And if it doesn't, you can try /P0 (zero not oh) option to disable MPU port trap to confirm again.

EDIT: I also tried to fix the IRQ assignment issue, by just changing the PCI configuration space register only, you can also test with your laptop that with a IRQ>15. I guess it won't work, but worth a try anyway. 😁

georgel wrote on 2024-04-26, 09:45:

DOS32A can be configured via command line switch or by other means too (its configuration utility) to use DPMI first.

Unfortunately in DOS/32A version package which I have (one of the latest if not the last) ss.exe's option for selecting DPMI detection over VCPI is deprecated and non-functional:

analog_programmer wrote on 2024-04-26, 12:58:

Unfortunately in DOS/32A version package which I have (one of the latest if not the last) ss.exe's option for selecting DPMI det […]
Show full quote

georgel wrote on 2024-04-26, 09:45:

DOS32A can be configured via command line switch or by other means too (its configuration utility) to use DPMI first.

Unfortunately in DOS/32A version package which I have (one of the latest if not the last) ss.exe's option for selecting DPMI detection over VCPI is deprecated and non-functional:

dos32a-conf.jpg
dos32a-conf-deprecated.jpg

Then I guess you can try another version of dos32a, or run `JEMMEX NOVCPI` after installing SBEMU.

crazii, I tried the SBEMU version form the github-link you gave me and unfortunately the problems with proper initialization of SB emulation in CMI8738 soundcard are same.

Later I'll upload pictures with some explanations, but I'm thinking there are mainly problems with DMA channel and interrupt assignment as these problems reminds the ones with the DOS "driver" from C-Media.

crazii wrote on 2024-04-26, 13:06:

Then I guess you can try another version of dos32a, or run `JEMMEX NOVCPI` after installing SBEMU.

Thanks for this JEMMEX hint. I can try this. But it is more important to me to find out why CMI8738's SB emulation does not initialize properly in DOS.

EDIT: Just tried JEMMEX NOVCPI in CONFIG.SYS and the result is that JLOAD.EXE complains that it can not allocate 4k page block, HDPMI32I.EXE reports that CPU is in V86 mode and missing VCPI/DPMI host and (as expected) SBEMU does not work at all. Let's leave aside DOS/32A extender problem for now.

analog_programmer wrote on 2024-04-26, 13:08:

crazii, I tried the SBEMU version form the github-link you gave me and unfortunately the problems with proper initialization of […]
Show full quote

crazii, I tried the SBEMU version form the github-link you gave me and unfortunately the problems with proper initialization of SB emulation in CMI8738 soundcard are same.

Later I'll upload pictures with some explanations, but I'm thinking there are mainly problems with DMA channel and interrupt assignment as these problems reminds the ones with the DOS "driver" from C-Media.

crazii wrote on 2024-04-26, 13:06:

Then I guess you can try another version of dos32a, or run `JEMMEX NOVCPI` after installing SBEMU.

Thanks for this JEMMEX hint. I can try this. But it is more important to me to find out why CMI8738's SB emulation does not initialize properly in DOS.

EDIT: Just tried JEMMEX NOVCPI in CONFIG.SYS and the result is that JLOAD.EXE complains that it can not allocate 4k page block, HDPMI32I.EXE reports that CPU is in V86 mode and missing VCPI/DPMI host and (as expected) SBEMU does not work at all. Let's leave aside DOS/32A extender problem for now.

`JEMMEX NOVCPI` is needed AFTER installing SBEMU, probably set in autoexec.bat

I'll investigate the problem with my CMI cards with TR1.

crazii wrote on 2024-04-26, 14:26:

`JEMMEX NOVCPI` is needed AFTER installing SBEMU, probably set in autoexec.bat

I'll investigate the problem with my CMI cards with TR1.

Ok, I'll try with JEMMEX NOVCPI in the command prompt after all the DOS boot initializations, just before I run DOS/32A modified SETUP.EXE.

I just found another problem related to Jemm on my test system. M$-DOS FORMAT and even NFORMAT produces garbage FAT on floppy drives. When I reverted back to HIMEM + EMM386 this problem has gone.

Unfortunately, until now the only partially working pure DOS solution for using my PCI CMI8738 soundcards is yours SBEMU.EXE, but I really don't like all these Jemm related problems. Those C-Media DOS drivers can't even set SB emulation to use DMA 0 or something different than IRQ "A" (maybe "10" in hex).

EDIT: Ok, the trick with JEMMEX.EXE NOVCPI in command prompt worked, but I'll just remember to not use DOS/32A modified executables with Jemm. I don't like to overcomplicate things 😀

is compiling in MMX support as simple as -mmmx like with GCC?

Currently SBEMU uses i386 instruction set, changing it to 'pentium-mmx' will get general optimization using MMX.
manual asm/intrinsic code of mmx for some functions may get the most out of mmx power I guess.
I think it's OK to use pentium-mmx because a real 386 doesn't need SBEMU and SBEMU cannot work on the low power CPUs. I only tested it with P3 and it works fine.

Yeah, it struggles on Pentium MMX 233 with my SBLive, last time I tried it. It was almost there in terms of performance.