crazii
Does not work with the onboard sound of the ASUS CUV4X-CM / MEDION2001 mainboard (CT5880)
That mainboard uses the Ensoniq 1371 core in an CT5880 DBQ (PCI revision ID is 7). Building a debug version of SBEMU reveals that no IRQs are triggered, and also building debug statements inside sc_e1371 reveals that all transfers to the sample-rate converter and the AC97 codec time out.
The bug is inherited from mpxplay, and merge request 137 contains a fix that has been tested to work on that hardware.
Thanks! Applied your fix to vsbhda's ES1371 driver code. vsbhda works now on my Medion2001 MB. However, there are some quirks, which may be vsbhda or MB issues. That's why I'd like to test sbemu on it, but I'm unable to build it. Could you please upload your fixed sbemu binary?
@Baron-von-Riedesel
Here you are: sbemu.zip. This build has the patch applied and debugging disabled (default configuration).
I had no issue bulding it in a docker/podman container just like the GitHub action in this repository does.
Thanks! Your sbemu binary and vsbhda show similar signs when trying "The Dig"-demo on the Medion 2001 ( P3 with 1 GHz, 512 MB RAM, ES1371 onboard sound ) - there are many crackles and the sound frequency is significantly lower. I had assumed that the SB emulation may overstrain that machine for this game, but when running vsbhda inside 86box, "The Dig" runs flawless - I'm baffled.
EDIT: what actually fixes this issue is to allow 11025 as argument for the /F cmdline option. Using this frequency reduces the interrupts/second to 1/2 ( for ES1371, 22050 is the default ). So it's indeed some kind of cpu overstrain...
I just tested the "The Dig" demo (downloaded from archive.org) on a 900MHz Pentium III in a Medion 2001 mainboard in the native Windows XP DOS box, and the sound was awful similar to what you describe. On the other hand, the sound works perfectly with SBEMU for me, without specifying any specific command line parameters in MS-DOS 6.22. I tested both in SB16 and SB Pro emulation, with just himem loaded, with jemmex + qpiemu or with himem + MS-DOS EMM386. I also tried with and without an UDMA IDE driver.
The BIOS revision I use is called "1009", USB Legcy Support is set to "Auto", but no USB device connected, so USB legacy support is quite likely not active. If you have any ideas what I can try to break the sound, go ahead, and I will test it.
If you have any ideas what I can try to break the sound, go ahead, and I will test it.
No idea how to break the sound, but you could try the preliminary vsbhda v1.7 on your machine. It doesn't have the /F11025 "fix" implemented yet, but this version shows the signs described above on my Medion 2001.
Maybe I am using a different demo of "The Dig" than you use? The one I use doesn't even use OPL3 sound, so I wonder why the OPL3 synthesis frequency matters for you. Your preliminary VSBHDA does not show the signs described on my Medion 2001. OTOH, I encountered an issue: VSBHDA crashes on the first invocation, but works perfectly if I re-run hdpmi32i and vsbhda. The output looks like this (I know the first line is not from VSBHDA, but it might be interesting for context; JHDPMI loaded/not loaded makes no difference).
JLoad: 'd:\vsbhda\qpiemu.dl' loaded successfully.
Found sound card: ENS
Real-mode support: enabled
Protected-mode support: enabled
Exception 10
EAX=00146101 EBX=001461B8 ECX=000000FF EDX=00000000 ESI=00000001
EDI=00000005 EBP=00145EE0 ESP=00145ED8 EFL=00000246 EIP=00123D74
CS=00AF (00000000,FFFFFFFF,CFFB) SS=00B7 (00000000,FFFFFFFF,CFF3)
DS=000B7 (00000000,FFFFFFFF,CFF3) ES=00B7 (00000000,FFFFFFFF,CFF3)
FS=0000 (********,********,****) GS=0000 (********,********,****)
LDTR=0038 (FF811000,00000FFF,0082) TR=0030 (FF80A620,000039E0,008B)
ERRC=0000 (********,********,****) PTE 1. Page LDT=002FD467
GDTR=07FF:FF810000 IDTR=07FF:FF810800 PTE CR2=00000167
CR0=80000011 CR2=00000000 CR3=002EE000 CR4=00000200 TSS:ESP0=000049E0
DR0-3=00000000 00000000 00000000 00000000 DR6=FFFF0FF0 DR7=00000400
LPMS=0087(01) RMS=DEC0:0200 cRMCB=0000 IRQ=000000 ISR=0000
[EIP]=DD 05 20 B9 12 00 89 4C 24 04 DB 44
[ESP]=0005 0000 0001 0000 0001 0000 0005 0000
00145EE8=0001 0000 61B8 0014 3211 0012 60D4 0014
...
If I didn't mess up disassembling by hand, the trapping instruction is FLD [QWORD PTR 12B920h], and the trap is a pending floating point exception reported via the Intel standard "INT 10" error reporting instead of the legacy IRQ13 reporting. I tried running a COM file containing "FCLEX / INT 20" before invoking VSBHDA, which did not solve the issue, so my suspicion that possibly a stale pending FPU exception is recognized on the first FPU instruction is unlikely to be correct.
I am using jhdpmi.dll and qpiemu.dll as provided with VSBHDA pre-release. I am using JEMMEX and JLOAD as provided with the latest SBEMU release.
On my Medion2001, I can report perfect operation with Jazz Jackrabbit (16-Bit VSBHDA + /DIVE) and The Dig. In Wolfenstein 3D, I observe that the title screen is skipped into the episode selection if VSBHDA is loaded. Sound Blaster sound and Adlib Music work fine, though.
Ok, so this "lagging" sound seems restricted to my board. Will be an interesting task to find out what's happening under the hood.
The Exception 10 does also happen on my Medion2001. The BIOS seems to leave the FPU in an unproper state - and it also sets CR0.NE bit, which makes the machine trigger an exception 0x10 instead on an IRQ 13. What should clean the FPU state is an "FNINIT".
I also noted the Wolfenstein 3D peculiarity. Currently I have the suspicion that there's something wrong with the keyboard controller on that board. It's best seen with the Tyrian2k setup.exe, where the machine plays havoc with the menu.
The one I use doesn't even use OPL3 sound, so I wonder why the OPL3 synthesis frequency matters for you.
The /F cmdline option sets the sound hw sampling frequency, so it directly determines how many interrupts/second are generated. It may also influence the OPL3 sound, but I can't remember how exactly.