Garehard wrote on 2025-02-15, 13:07:

great Project, but i got with my SB Live only a high pitched sound. opl3 music is fine.
changed irq from 5 to 7, but that doesnt solve the problem. any ideas?

There might be a fix.

The SB Live/Audigy speed seems to depend on what value has been stored in the TIMER register. During SBEMU's test phase it has been given the value 0x200 ( that was found out just by trial and error ).
For SBEMU, the value has later been changed to 0x1A, for VSBHDA the value is still 0x200.

While fixing vsbhda for FastTracker 2, it has turned out that value 0x200 is problematic and value 0x1A makes the sound "too fast" (high pitched). A good compromise seems value 0x11A - both FastTracker 2 and TheDig sound ok with that.

I attached a little tool that displays SBLive/Audigy's current status, including the TIMER register.

You can experiment on your own, no need to recompile SBEMU/VSBHDA: with FD DEBUG you can change the value on the fly, for example with "OW B81A 11A" (assuming the Emu10kx base port is 0xB800).

Baron von Riedesel wrote on 2025-09-12, 02:26:

There might be a fix. […]
Show full quote

Garehard wrote on 2025-02-15, 13:07:

great Project, but i got with my SB Live only a high pitched sound. opl3 music is fine.
changed irq from 5 to 7, but that doesnt solve the problem. any ideas?

There might be a fix.

The SB Live/Audigy speed seems to depend on what value has been stored in the TIMER register. During SBEMU's test phase it has been given the value 0x200 ( that was found out just by trial and error ).
For SBEMU, the value has later been changed to 0x1A, for VSBHDA the value is still 0x200.

While fixing vsbhda for FastTracker 2, it has turned out that value 0x200 is problematic and value 0x1A makes the sound "too fast" (high pitched). A good compromise seems value 0x11A - both FastTracker 2 and TheDig sound ok with that.

I attached a little tool that displays SBLive/Audigy's current status, including the TIMER register.

You can experiment on your own, no need to recompile SBEMU/VSBHDA: with FD DEBUG you can change the value on the fly, for example with "OW B81A 11A" (assuming the Emu10kx base port is 0xB800).

Thanks, I downloaded it, Audigy2 PPro will be included in X299, just in case I need it.

945G chipset, Realtek codec, Atom CPU desktop mini PC. All works great. Only mutes PC speaker output from speakers. Even SBMIX does not help. Only restart restores PC speaker volume. And interferes with Windows 3.1 HDA sound drivers. And only one of my favorite game crashes with digitized sound: Supaplex. And DooM has a minute delay at the start, but all works fine.

Cyberdyne wrote on Yesterday, 13:41:

945G chipset, Realtek codec, Atom CPU desktop mini PC. All works great. Only mutes PC speaker output from speakers. Even SBMIX does not help. Only restart restores PC speaker volume. And interferes with Windows 3.1 HDA sound drivers. And only one of my favorite game crashes with digitized sound: Supaplex. And DooM has a minute delay at the start, but all works fine.

If PC speaker muting bothers you then try VSBHDA isnstead. In new versions it leaves the PC speaker alone.
https://github.com/Baron-von-Riedesel/VSBHDA/releases

Cyberdyne wrote on Yesterday, 13:41:

And only one of my favorite game crashes with digitized sound: Supaplex.

I had exactly that experience when working on dosemu's SoundBlaster emulator more than 20 years ago. Supaplex uses the original binary code provided by Creative Labs to play back digital samples on SoundBlaster cards. That code uses an arcane feature of the SoundBlaster card to patch two very essential bytes of the driver code, and does not actively check if that arcane feature worked, but blindly crashes the system if it does not. The only reasonable explanation for the presence of that feature and the behaviour of the Creative Labs driver is that this is meant to make producing clone cards harder (possibly even suing them if they clone that arcane feature), so the original Creative Labs DSP firmware inside the SoundBlaster card is used like a copy protection dongle to prevent the Creative Labs driver from working on unlicensed Soundblaster clones.

As VSBHDA and SBEMU are both open source, I checked the respective GitHub repositories:

• https://github.com/crazii/SBEMU/blob/main/sbemu/sbemu.c#L240 does not emulate DSP command 0xE2, and it would need to be handled in this switch statement.
• https://github.com/Baron-von-Riedesel/VSBHDA/ … /src/VSB.C#L692 does so.

So Supaplex is likely going to work with VSBHDA.

Yep. Everything works with VSBHDA. No more delays in DOOM. Supaplex works. PC speaker sounds do not mute. And I got a nice 6MB MT-32 SF2 file for the MIDI emulation core. Everything works.

Oh thanks for the Tip, VSBHDA does very well on my Siemens Lifebook.
SBEMU did not work here.

One bonus thing I can say. Ess Solo1 pci does not work in 945G. Not even in Windows 95. It can not configure DMA. So it is just a glorified PCI Adlib card all around.

Report : Both SBEmu and VSBHDASF are fine on X299. Motherboard : X299 Taichi XE.

In my computer (Intel Atom N280, 1 GB RAM, Intel 945 graphics, Intel HDA) I have better results with VSBHDASF: less conventional memory used, sound in more games and PC speaker active. But I'm not able to load the driver for real mode support with VSBHDASF or SBEMU, only the 32 bit/protected mode.

ntalaec wrote on Today, 06:48:

In my computer (Intel Atom N280, 1 GB RAM, Intel 945 graphics, Intel HDA) I have better results with VSBHDASF: less conventional memory used, sound in more games and PC speaker active. But I'm not able to load the driver for real mode support with VSBHDASF or SBEMU, only the 32 bit/protected mode.

So far, both real and protected mode work fine on 7 machines, 5 desktops and 2 laptops.

Should JEMMEX.EXE be used with any parameters? With SBEMU real mode games do not detect the Sound Blaster, with VSBHDASF real mode games detect the Soundblaster but there is no sound at all.

ntalaec wrote on Today, 07:20:

Should JEMMEX.EXE be used with any parameters? With SBEMU real mode games do not detect the Sound Blaster, with VSBHDASF real mode games detect the Soundblaster but there is no sound at all.

For example on X299 machine
UEFI : above 4GB IOOM : disabled
Config :

1DEVICE=C:\CONFIG\LIMITMEM.SYS 256
2SHELL=C:\COMMAND.COM C:\ /E:1024 /P
3LASTDRIVE=Z
4STACKS=9,256
5SWITCHES=/F
6FILES=20
7BUFFERS=20
8DEVICE=C:\SBEMU104\JEMMEX.EXE noems
9DOS=HIGH,UMB,AUTO

Autoexec :

1C:\DOS\SHARE.EXE /l:500 /f:5100
2SET BLASTER=A220 I5 D1 H5 P330
3PATH C:\QEMM;C:\DOS;C:\UTIL;C:\NC;C:\DN
4SET MIDI=SYNTH:1 MAP:E MODE:0
5SET PATH=%PATH%;C:\UTIL\FASTVID;
6C:\DOS\SMARTDRV.EXE /L /X
7SET NC=C:\NC
8SET DN=C:\DN
9SET TMP=C:\TMP
10SET TEMP=%TMP%
11PROMPT [DOS_7.1] $P$G
12LH C:\UTIL\CTMOUSE.EXE
13LH C:\SBEMU104\JLOAD C:\SBEMU104\QPIEMU.DLL
14rem LH C:\SBEMU104\HDPMI32I
15LH C:\SBEMU104\HDPMI32I -R -X2
16LH C:\SBEMU104\SBEMU.EXE
17LH NC

CPU type and SBEmu output :

Memory map :

VSBHDA/VSBHDASF similarly. SBEmu is not started, but startP4 for example, and for the SF version, specify the soundfont to be loaded according to the description.