VOGONS


SBEMU: Sound Blaster emulation on AC97

Topic actions

Reply 1300 of 1493, by analog_programmer

User metadata
Rank Oldbie
Rank
Oldbie

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.

from СМ630 to Ryzen gen. 3
engineer's five pennies: this world goes south since everything's run by financiers and economists
this isn't voice chat, yet some people, overusing online communications, "talk" and "hear voices"

Reply 1302 of 1493, by crazii

User metadata
Rank Oldbie
Rank
Oldbie
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.

Toshiba Satellite Pro 4300 - YMF744, Savage IX
Toshiba Satellite 2805-S501 - YMF754, GeForce 2Go
IBM Thinkpad A21p - CS4624, Mobility Radeon 128
main: Intel NUC11PHKi7C Phantom Canyon: i7-1165G7 RTX2060 64G 2T760PSDD

Reply 1303 of 1493, by Falcosoft

User metadata
Rank l33t
Rank
l33t
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.

Website, Facebook, Youtube
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
VST Midi Driver Midi Mapper

Reply 1305 of 1493, by zyzzle

User metadata
Rank Member
Rank
Member
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).

Attachments

  • cap1.png
    Filename
    cap1.png
    File size
    3.89 KiB
    Views
    748 views
    File license
    Fair use/fair dealing exception
  • cap2.png
    Filename
    cap2.png
    File size
    4.46 KiB
    Views
    748 views
    File license
    Fair use/fair dealing exception
  • cap3.png
    Filename
    cap3.png
    File size
    4.51 KiB
    Views
    748 views
    File license
    Fair use/fair dealing exception

Reply 1306 of 1493, by crazii

User metadata
Rank Oldbie
Rank
Oldbie
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. 😁

Toshiba Satellite Pro 4300 - YMF744, Savage IX
Toshiba Satellite 2805-S501 - YMF754, GeForce 2Go
IBM Thinkpad A21p - CS4624, Mobility Radeon 128
main: Intel NUC11PHKi7C Phantom Canyon: i7-1165G7 RTX2060 64G 2T760PSDD

Reply 1307 of 1493, by crazii

User metadata
Rank Oldbie
Rank
Oldbie
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.

Last edited by crazii on 2024-04-27, 07:31. Edited 1 time in total.

Toshiba Satellite Pro 4300 - YMF744, Savage IX
Toshiba Satellite 2805-S501 - YMF754, GeForce 2Go
IBM Thinkpad A21p - CS4624, Mobility Radeon 128
main: Intel NUC11PHKi7C Phantom Canyon: i7-1165G7 RTX2060 64G 2T760PSDD

Reply 1308 of 1493, by crazii

User metadata
Rank Oldbie
Rank
Oldbie
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

Toshiba Satellite Pro 4300 - YMF744, Savage IX
Toshiba Satellite 2805-S501 - YMF754, GeForce 2Go
IBM Thinkpad A21p - CS4624, Mobility Radeon 128
main: Intel NUC11PHKi7C Phantom Canyon: i7-1165G7 RTX2060 64G 2T760PSDD

Reply 1309 of 1493, by Baron von Riedesel

User metadata
Rank Member
Rank
Member
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.

Reply 1310 of 1493, by wierd_w

User metadata
Rank Oldbie
Rank
Oldbie

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

Reply 1311 of 1493, by analog_programmer

User metadata
Rank Oldbie
Rank
Oldbie
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).

from СМ630 to Ryzen gen. 3
engineer's five pennies: this world goes south since everything's run by financiers and economists
this isn't voice chat, yet some people, overusing online communications, "talk" and "hear voices"

Reply 1312 of 1493, by analog_programmer

User metadata
Rank Oldbie
Rank
Oldbie

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?

from СМ630 to Ryzen gen. 3
engineer's five pennies: this world goes south since everything's run by financiers and economists
this isn't voice chat, yet some people, overusing online communications, "talk" and "hear voices"

Reply 1313 of 1493, by crazii

User metadata
Rank Oldbie
Rank
Oldbie

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

Toshiba Satellite Pro 4300 - YMF744, Savage IX
Toshiba Satellite 2805-S501 - YMF754, GeForce 2Go
IBM Thinkpad A21p - CS4624, Mobility Radeon 128
main: Intel NUC11PHKi7C Phantom Canyon: i7-1165G7 RTX2060 64G 2T760PSDD

Reply 1314 of 1493, by analog_programmer

User metadata
Rank Oldbie
Rank
Oldbie
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:

@ECHO OFF
VERIFY ON
LH /L:3,23568 C:\WINDOWS\COMMAND\MSCDEX /D:MSCD0001 /M:32 /E /V /L:D
LH /L:0;2,45488 /S C:\WINDOWS\SMARTDRV.EXE /X /V 3072 256
LH C:\DOSDRVRS\MOUSE.COM

REM :AC'97 SB Emulation
C:\DOSDRVRS\SBEMU\JLOAD C:\DOSDRVRS\SBEMU\QPIEMU.DLL
C:\DOSDRVRS\SBEMU\HDPMI32I -R -X
SET BLASTER=A220 I5 D1 H3 T6 P330
C:\DOSDRVRS\SBEMU\SBEMU

SET CLIPPER=F35
PATH C:\WINDOWS;C:\WINDOWS\COMMAND;C:\;C:\DOSDRVRS;C:\UTILS

The SBEMU always reports correct values according to BLASTER values:

SBEMU_init.JPG
Filename
SBEMU_init.JPG
File size
74.43 KiB
Views
599 views
File license
Fair use/fair dealing exception

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:

non-working_CMTEST.JPG
Filename
non-working_CMTEST.JPG
File size
68.79 KiB
Views
591 views
File license
Fair use/fair dealing exception

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

from СМ630 to Ryzen gen. 3
engineer's five pennies: this world goes south since everything's run by financiers and economists
this isn't voice chat, yet some people, overusing online communications, "talk" and "hear voices"

Reply 1315 of 1493, by crazii

User metadata
Rank Oldbie
Rank
Oldbie

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

Last edited by crazii on 2024-04-27, 10:58. Edited 1 time in total.

Toshiba Satellite Pro 4300 - YMF744, Savage IX
Toshiba Satellite 2805-S501 - YMF754, GeForce 2Go
IBM Thinkpad A21p - CS4624, Mobility Radeon 128
main: Intel NUC11PHKi7C Phantom Canyon: i7-1165G7 RTX2060 64G 2T760PSDD

Reply 1316 of 1493, by crazii

User metadata
Rank Oldbie
Rank
Oldbie

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.

Toshiba Satellite Pro 4300 - YMF744, Savage IX
Toshiba Satellite 2805-S501 - YMF754, GeForce 2Go
IBM Thinkpad A21p - CS4624, Mobility Radeon 128
main: Intel NUC11PHKi7C Phantom Canyon: i7-1165G7 RTX2060 64G 2T760PSDD

Reply 1317 of 1493, by dr.zeissler

User metadata
Rank l33t
Rank
l33t

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.

Retro-Gamer 😀 ...on different machines

Reply 1318 of 1493, by analog_programmer

User metadata
Rank Oldbie
Rank
Oldbie
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...

from СМ630 to Ryzen gen. 3
engineer's five pennies: this world goes south since everything's run by financiers and economists
this isn't voice chat, yet some people, overusing online communications, "talk" and "hear voices"