Who knows if the compiled executable will be compatible with P1 non-MMX, PPro or non-P1 MMX (for example AMD K6) CPUs when "march=pentium-mmx" flag is used.

It won't, most likely. Could just split it into multiple binary releases.

megatog615 wrote on 2024-04-26, 16:06:

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

Then it's worth a try with MMX enabled. BTW I remember some flags in control register needs to be set to enable it - maybe that's already done by HDPMI. otherwise the CPU will generate an exception. Also, if SBEMU is planned to work in win9x, it has to save the MMX context too.
and, if the newly written DPMI is used, I'm concerned that it won't perform as good as HDPMI for your Pentium MMX. 😁 It's written in C and for ease of development, some codes are not well optimized, especially the most frequently used - mode switching and interrupt handling.

BTW have you try the recent builds? it enables LTO and use O2 optimization, which might perform a little better than before.

crazii wrote on 2024-04-26, 18:17:

megatog615 wrote on 2024-04-26, 16:06:

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

Then it's worth a try with MMX enabled. BTW I remember some flags in control register needs to be set to enable it - maybe that's already done by HDPMI. otherwise the CPU will generate an exception. Also, if SBEMU is planned to work in win9x, it has to save the MMX context too.

You do not have to enable MMX by control registers. It's only true for SSE (and above). It's because SSE uses new registers (XMM) but MMX does not. MMX registers are mapped to the x87 FPU registers. That's why MMX (and also 3dnow!) does not require explicit OS support either. If an OS can save x87 FPU register state then it automatically also can save MMX state. Win95 and even DOS/Win3.1 is MMX/3dnow! compatible. So SBEMU does not have to save "MMX context" explicitly on Win9x either. The OS does this when it saves FPU state.

In a couple of years, we might have the DOS 6.22 source code, and then it can be modified and compiled for the ultimate SBEMU and gaming compatibility 😎

https://github.com/microsoft/MS-DOS

crazii wrote on 2024-04-26, 12:35:

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 po […]
Show full quote

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.
SBEMU_fix1.zip

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. 😁

Thanks for the fix. Unfortunately, it didn't work on either laptop, even with /P0 option. On my i5-8250u laptop, it detects soundcard, using /SCL parameter (cap1.png), but has wrong IDs: This should not be max 0 khz,0 bit, 8 ch, but instead detect as max: 192khz, 24 bit, 8ch)
Upon executing my batchfile sb.bat, which loads HDPMI32i and executes SBEMU, it hangs the system (cap2.png).

On my other laptop with Apollolake chipset, SBEMU runs and detect IRQ25 but fails to assign a valid IRQ. (cap3.png). This is on my SoC Netbook with N3350 / ApolloLake chipset. (Realtek ALC269, device vendor ID=8086: devid=5a98)

The last version of SBEMU which worked on my Intel SKL Kabylake Intel HDA card is from 09-Feb-2024, where it's properly dectected as Realtek ALC259, max:192khz, 24 bit, 8ch).

Falcosoft wrote on 2024-04-26, 19:17:

crazii wrote on 2024-04-26, 18:17:

megatog615 wrote on 2024-04-26, 16:06:

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

Then it's worth a try with MMX enabled. BTW I remember some flags in control register needs to be set to enable it - maybe that's already done by HDPMI. otherwise the CPU will generate an exception. Also, if SBEMU is planned to work in win9x, it has to save the MMX context too.

You do not have to enable MMX by control registers. It's only true for SSE (and above). It's because SSE uses new registers (XMM) but MMX does not. MMX registers are mapped to the x87 FPU registers. That's why MMX (and also 3dnow!) does not require explicit OS support either. If an OS can save x87 FPU register state then it automatically also can save MMX state. Win95 and even DOS/Win3.1 is MMX/3dnow! compatible. So SBEMU does not have to save "MMX context" explicitly on Win9x either. The OS does this when it saves FPU state.

Cool, thanks for the correction. 😁

zyzzle wrote on 2024-04-27, 01:36:

Thanks for the fix. Unfortunately, it didn't work on either laptop, even with /P0 option. On my i5-8250u laptop, it detects soun […]
Show full quote

crazii wrote on 2024-04-26, 12:35:

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 po […]
Show full quote

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.
SBEMU_fix1.zip

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. 😁

Thanks for the fix. Unfortunately, it didn't work on either laptop, even with /P0 option. On my i5-8250u laptop, it detects soundcard, using /SCL parameter (cap1.png), but has wrong IDs: This should not be max 0 khz,0 bit, 8 ch, but instead detect as max: 192khz, 24 bit, 8ch)
Upon executing my batchfile sb.bat, which loads HDPMI32i and executes SBEMU, it hangs the system (cap2.png).

On my other laptop with Apollolake chipset, SBEMU runs and detect IRQ25 but fails to assign a valid IRQ. (cap3.png). This is on my SoC Netbook with N3350 / ApolloLake chipset. (Realtek ALC269, device vendor ID=8086: devid=5a98)

The last version of SBEMU which worked on my Intel SKL Kabylake Intel HDA card is from 09-Feb-2024, where it's properly dectected as Realtek ALC259, max:192khz, 24 bit, 8ch).

OK, then I have to check the commit log the see what's wrong. Thanks for the testing.

EDIT: does the 11-Feb build work? there seems no big changes from 09-Feb.
After that the O2 and LTO is on, probably causing problems, but are fixed on the 2024.02.18_00-37.

EDIT2: I see that SETPVI is used. you can try again without it. SETPVI may be needed by VSBHDA but not needed by SEBEMU, and it might cause problem especially code runs fast with O2 optimization, the bug exposed by O2 is fixed (interrupt related), however if setpvi is used, it is still not gonna work properly.

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 SB emulation in CMI8738 soundcard are same.

I just debugged with TR1, it assumes the card is SB16/AWE and read IRQ/DMA from the mixer registers (80h&81h), but mixer reset code doesn't set those two.
You can try this build with the problem fixed: https://github.com/crazii/SBEMU/releases/tag/ … 024.04.27_03-42

analog_programmer wrote on 2024-04-26, 14:45:

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.

I'm the author of JemmEx. Errors for JemmEx can be posted on GitHub. I understand that not everyone wants to have a GitHub account, so it's acceptable if you post any bug reports here ( with "here" I DO NOT MEAN this thread, which is already long enough, but perhaps a new thread in the "Release Anouncement" sub-forum?

Note that MS EMM386 probably had good reasons NOT to allow port trapping of ports < 0x100 - it might severely affect system stability, escpecially if the DMA ports 0x00-0x1F and 0xC0-0xDF are concerned. It's allowed in JemmEx, to make it work with SoundBlaster emulation software, but it's a little trade-off.

I admit that floppy controller DMA channel testing ( channel 2 ) in JemmEx has decreased in priority, because the floppy controller is somewhat "obsolete" these days and JemmEx is primarily meant to run on "modern" systems ( it's not - and never was - intended to be a "MS EMM386 clone" ). Nevertheless, it's still regarded as a bug if garbage is written to the FAT due to DMA not handled properly by the v86-monitor.

For the record, It was abundantly clear to me that JEMM is not aiming to be an EMM386 clone. It does not report the same EMS handler name, and does things quite a bit differently than EMM386, presumably with an emphasis on "Doing things better, and not being constrained by legacy behavior"

If you want "maximal compatibility", you have to fall victim to the "Legacy behavior backward compatibility" trap.

These are mutually exclusive goals, and I recognize that. This is why I suggested that a different project would be needed, and would be appreciated.

(In which JEMM supplies the current use of modern DOS on Modern Systems, used for industrial settings-- which is why it pairs well with FreeDos project-- and in which the hypothetical EMM386 clone would be intended for use on legacy hardware, with legacy-licenced MS-DOS, for use with legacy software, that expects things done the legacy way, with legacy behaviors.)

crazii wrote on 2024-04-27, 03:45:

I just debugged with TR1, it assumes the card is SB16/AWE and read IRQ/DMA from the mixer registers (80h&81h), but mixer reset code doesn't set those two.
You can try this build with the problem fixed: https://github.com/crazii/SBEMU/releases/tag/ … 024.04.27_03-42

I'll try this build today and will give feedback. Thank you.

I just managed to take some pictures from the test with previous build (UserBuild_2024.04.11_09-01), but if the newer one works fine, then detailed explanation with pictures will be unnecessary.

Baron von Riedesel wrote on 2024-04-27, 06:22:

I'm the author of JemmEx. Errors for JemmEx can be posted on GitHub. I understand that not everyone wants to have a GitHub account, so it's acceptable if you post any bug reports here ( with "here" I DO NOT MEAN this thread, which is already long enough, but perhaps a new thread in the "Release Anouncement" sub-forum?

Note that MS EMM386 probably had good reasons NOT to allow port trapping of ports < 0x100 - it might severely affect system stability, escpecially if the DMA ports 0x00-0x1F and 0xC0-0xDF are concerned. It's allowed in JemmEx, to make it work with SoundBlaster emulation software, but it's a little trade-off.

I admit that floppy controller DMA channel testing ( channel 2 ) in JemmEx has decreased in priority, because the floppy controller is somewhat "obsolete" these days and JemmEx is primarily meant to run on "modern" systems ( it's not - and never was - intended to be a "MS EMM386 clone" ). Nevertheless, it's still regarded as a bug if garbage is written to the FAT due to DMA not handled properly by the v86-monitor.

Hi, and thank you for the input. I just noticed this problem with Jemm, because right now I'm trying to make some CMI8738 PCI soundcards to work properly under pure DOS on PII system with attached real floppy drive and the only partially working solution is this SBEMU project which relies on your Jemm project. If there's a special topic/thread dedicated to your Jemm project I may give some Jemm related feedback there.

I have one suggestion (and maybe it's stupid). Why don't you try to allow only sound related ports addressess (or some limited range) lower than ox100 in JEMMEX? Maybe this will minimize the chances something else to get messy. And yes, maybe M$ did have some reasons to restrict port trapping under 0x100 in EMM386, but on the other hand it seems that Quarterdeck does not (their QEMM seems to work differently since it is not 100% compatible with M$-DOS software).

crazii, so far no good news. And I'm too confused now. It seems like this last build got worse in terms of sound quality with CMI8738. Still no proper autodetection from TR1's SETUP.EXE - seems like there's improvement with interrupt detecting, but sill autodetects HighDMA (3) instead of DMA (0 or 1) number. Otherwise the sound test and game sound works fine only if I set manually interrupt and DMA according to BLASTER variable values, but it's more choppy and quieter now. C-Media test program CMTEST.EXE version 1.1 also seems like detects proper interrupt a little faster, but as always fails on DMA detection (with all SBEMUU builds I've tested).

I think I'll just start the testing over with the two builds you've recommended me - UserBuild_2024.04.11_09-01 and latest UserBuild_2024.04.27_03-42. I'll use these values for BLASTER variable: BLASTER=A220 I5 D1 H3 T6 P330 as it seems like with my test PII system DMA 1 is handled somehow worse than DMA 0 for the C-Media SB emulation and I don't want the best scenario. I5 is fine for interrupt 5. H3 is fine for HighDMA 3. T6 is fine for SB16 emulation. I can't force the BIOS to hook interrupt lower than 11 (usually it's 12) on the CMI8738 PCI card, but I think this is not the root of the problem with its SB emulation. The strangest thing for me is that TR1 sound also works with interrupt 10 which is hooked to some PCI USB hub in some occasions (I don't remember with what setting for DMA 0 or 1 - have to test this again, but it happens with older build too).

What do you think about this?

That's really strange, I tested the auto detection and it works as expected, and manual config also works.
Do you set BLASTER env before running SBEMU? or after it? if so, what the settings?
if no, what the BLASTER env set by SBEMU after it installs?
FYI I didn't set BLASTER env before SBEMU, nor additional options (no /A /H), just defaults to A220 I7 D1 T5

crazii wrote on 2024-04-27, 09:57:

That's really strange, I tested the auto detection and it works as expected, and manual config also works. Do you set BLASTER en […]
Show full quote

That's really strange, I tested the auto detection and it works as expected, and manual config also works.
Do you set BLASTER env before running SBEMU? or after it? if so, what the settings?
if no, what the BLASTER env set by SBEMU after it installs?
FYI I didn't set BLASTER env before SBEMU, nor additional options (no /A /H), just defaults to A220 I7 D1 T5

I set BLASTER values in AUTOEXEC.BAT just before the line with SBEMU.EXE:

1@ECHO OFF
2VERIFY ON
3LH /L:3,23568 C:\WINDOWS\COMMAND\MSCDEX /D:MSCD0001 /M:32 /E /V /L:D
4LH /L:0;2,45488 /S C:\WINDOWS\SMARTDRV.EXE /X /V 3072 256
5LH C:\DOSDRVRS\MOUSE.COM
6
7REM :AC'97 SB Emulation
8C:\DOSDRVRS\SBEMU\JLOAD C:\DOSDRVRS\SBEMU\QPIEMU.DLL
9C:\DOSDRVRS\SBEMU\HDPMI32I -R -X
10SET BLASTER=A220 I5 D1 H3 T6 P330
11C:\DOSDRVRS\SBEMU\SBEMU
12
13SET CLIPPER=F35
14PATH C:\WINDOWS;C:\WINDOWS\COMMAND;C:\;C:\DOSDRVRS;C:\UTILS

The SBEMU always reports correct values according to BLASTER values:

I think I also tested 1.0 beta3 build with no BLASTER variable at all, just default A220 I7 D1 T5 from SBEMU, but then I decided that there are some conflicts and started to use BLASTER variable in AUTOEXEC.BAT.

Also with all the tested builds no matter what BLASTER values I set, CMTEST.EXE always gives me this DMA error:

Ok, write me down what strategy to apply when testing these CMI8738 cards.

OK, H3 is 16bit data through 8bit channel. usually you should use 5,6,7 only for high dma.
and it seems TR1 only recognize 8bit low DMA, when you set H5/H6/H7 it will detect D1 properly.

if H3 (other than 5,6,7) is used, TR1 won't detect it as high dma H3, but low dma D3 and cause problem, so I don't recommend setting H3, use H5 will be OK.
Also H0/1/3 is not well tested, and the SB guide doesn't allow setting more than 1 low bits (in your case DMA 1 & 3), that needs improvement too.

EDIT: additional checks added if HDMA is less than 5, then Dx and Hx must be the same, in your case SBEMU will set H3 to H1. (or set D1 to D3 will work too).

CMTEST might be another bug in the SBEMU dma code, I found some missing cases in the dma code too, it was fixed in another branch but not committed yet.

While testing SBEMU on different FSC-Computers I recognized that there is no "SBEMU" that includes every patch ever made?
To be clear the newer and patched working AD1980 (E600/D1534) supported sbemu-version breaks support on a former working (C610/D1644) AC97 and i865gv.
If this is the way it is, the main/first post should link more versions of SBEMU that are patched for different chipsets/audiochips.

crazii wrote on 2024-04-27, 10:32:

OK, H3 is 16bit data through 8bit channel. usually you should use 5,6,7 only for high dma. and it seems TR1 only recognize 8bit […]
Show full quote

OK, H3 is 16bit data through 8bit channel. usually you should use 5,6,7 only for high dma.
and it seems TR1 only recognize 8bit low DMA, when you set H5/H6/H7 it will detect D1 properly.

if H3 (other than 5,6,7) is used, TR1 won't detect it as high dma H3, but low dma D3 and cause problem, so I don't recommend setting H3, use H5 will be OK.
Also H0/1/3 is not well tested, and the SB guide doesn't allow setting more than 1 low bits (in your case DMA 1 & 3), that needs improvement too.

Well, then this explains why is TR1 SETUP.EXE always messess DMA with HighDMA number in my current configuration. I don't remember well what BLASTER values are more suitable for SB cards and the other soundcards capable of emulating SB. Maybe we have to make some more detailed "readme" documentation.

I suspect this DMA messing happens with CMTEST.EXE, but I have to test again with more proper BLASTER settings.

Can you recommend some other DOS sound test tool instead of C-Media's CMTEST.EXE for CMI8738 cards?

Ok, I'll test again the latest UserBuild_2024.04.27_03-42 with this line in AUTOEXEC.BAT: "SET BLASTER=A220 I5 D1 H5 T6 P330" and give feedback later today.

crazii wrote on 2024-04-27, 10:35:

CMTEST might be another bug in the SBEMU dma code, I found some missing cases in the dma code too, it was fixed in another branch but not committed yet.

Or maybe CMTEST is also buggy as the C-Media'a DOS driver/initializer and mixer. We'll see...

Iirc, 'normal' low dma is 1 or 3, and High dma is 5 or 7.

Irq 5 or 7.

It has been awhile though.