DarthSun wrote on 2024-01-14, 11:51:

A very good rate of success, it plays on all of them, most of the programs/games.

Glad to hear that. I was just back to SBEMU recently, and there were a lot people helping with it.
Also thanks for you feedback.

guys! excellent it IS working indeed! thank you very much!!!

Thx Doc

Tested on allready working ac97 board same as previous post

Card Soundblaster LS BB0310 pulled from a DELL chip:A0106-DAT

This one did not work, continuous loud buzzing, 🤣

3 lines about starting playback after loading sbemu

crazii wrote on 2024-01-14, 13:58:

I was just back to SBEMU recently, and there were a lot people helping with it.

That's fantastic news! Are we seeing a new beta release anytime soon?

Bruno128 wrote on 2024-01-22, 10:07:

crazii wrote on 2024-01-14, 13:58:

I was just back to SBEMU recently, and there were a lot people helping with it.

That's fantastic news! Are we seeing a new beta release anytime soon?

Releases are coming out regularly. Often more than one per day. 😃

Have a look: https://github.com/crazii/SBEMU/releases

By all means, try it out and please help us with testing, on as many different systems as possible. Thanks! 🙂

digger wrote on 2024-01-22, 15:25:

Often more than one per day.

What I'm saying is that OP can use an update with a version bump.
May I also make a suggestion: by default add more verbose info about the users audio hardware in initialization output. Some people don't specify that clearly in their comments.
The tests link is in my sig.

Yes beta4 is on its way. 😀

Is there a changelog available somewhere? Usually people publishing thru github put that under Release.

Not yet, the change log is over here in the original post, will be added on next version bump. Thanks for reminding.

I've noticed that the problematic Toshiba with the C200 ICH, is being identified as intel ICH with a conexant codec.

I will double check with working linux to make sure sbemu is correctly identifying it.

I'm curious how you got stunts to work with sbemu
In my (limited) testing I get the "reservememory - OUT OF MEMORY RESERVING polyinfo P=28b HW=f02" when trying to load the game.
It seems to happen only after HDPMI32I is loaded and no combination of switches or arguments seem to make any positive difference

wbahnassi wrote on 2023-04-10, 05:11:

Testing some games with the latest exe from this post (Re: SBEMU: Sound Blaster emulation on AC97). […]
Show full quote

Testing some games with the latest exe from this post (Re: SBEMU: Sound Blaster emulation on AC97).

SB16 mode. I used SBPro mixer to change volumes.

* Doom: OK
* Skyroads: Whenever SFX plays, volume of FM increases then decreases when SFX is done playing
* Prince 1: Hangs, used to work perfectly
* Stunts: OK
* Ninja Turtles Manhattan Missions: Stack overflow, used to work
* Mortal Kombat: HDPMI error
* Might & Magic 3: OK, including speech
* Nova 9: Hangs, used to work
* Island of Dr.Brain: Hangs, then stack overflow

Several games have regressed with this stack overflow error. This is on my HP Z400 workstation.

wierd_w wrote on 2024-01-24, 06:05:

I've noticed that the problematic Toshiba with the C200 ICH, is being identified as intel ICH with a conexant codec.

I will double check with working linux to make sure sbemu is correctly identifying it.

Which vendor_id / device_id does this ICH chip have?
Is it one from intel8x0.c?

{ PCI_VDEVICE(INTEL, 0x2415), DEVICE_INTEL }, /* 82801AA */
{ PCI_VDEVICE(INTEL, 0x2425), DEVICE_INTEL }, /* 82901AB */
{ PCI_VDEVICE(INTEL, 0x2445), DEVICE_INTEL }, /* 82801BA */
{ PCI_VDEVICE(INTEL, 0x2485), DEVICE_INTEL }, /* ICH3 */
{ PCI_VDEVICE(INTEL, 0x24c5), DEVICE_INTEL_ICH4 }, /* ICH4 */
{ PCI_VDEVICE(INTEL, 0x24d5), DEVICE_INTEL_ICH4 }, /* ICH5 */
{ PCI_VDEVICE(INTEL, 0x25a6), DEVICE_INTEL_ICH4 }, /* ESB */
{ PCI_VDEVICE(INTEL, 0x266e), DEVICE_INTEL_ICH4 }, /* ICH6 */
{ PCI_VDEVICE(INTEL, 0x27de), DEVICE_INTEL_ICH4 }, /* ICH7 */
{ PCI_VDEVICE(INTEL, 0x2698), DEVICE_INTEL_ICH4 }, /* ESB2 */
{ PCI_VDEVICE(INTEL, 0x7195), DEVICE_INTEL }, /* 440MX */
{ PCI_VDEVICE(SI, 0x7012), DEVICE_SIS }, /* SI7012 */
{ PCI_VDEVICE(NVIDIA, 0x01b1), DEVICE_NFORCE }, /* NFORCE */
{ PCI_VDEVICE(NVIDIA, 0x003a), DEVICE_NFORCE }, /* MCP04 */
{ PCI_VDEVICE(NVIDIA, 0x006a), DEVICE_NFORCE }, /* NFORCE2 */
{ PCI_VDEVICE(NVIDIA, 0x0059), DEVICE_NFORCE }, /* CK804 */
{ PCI_VDEVICE(NVIDIA, 0x008a), DEVICE_NFORCE }, /* CK8 */
{ PCI_VDEVICE(NVIDIA, 0x00da), DEVICE_NFORCE }, /* NFORCE3 */
{ PCI_VDEVICE(NVIDIA, 0x00ea), DEVICE_NFORCE }, /* CK8S */
{ PCI_VDEVICE(NVIDIA, 0x026b), DEVICE_NFORCE }, /* MCP51 */
{ PCI_VDEVICE(AMD, 0x746d), DEVICE_INTEL }, /* AMD8111 */
{ PCI_VDEVICE(AMD, 0x7445), DEVICE_INTEL }, /* AMD768 */
{ PCI_VDEVICE(AL, 0x5455), DEVICE_ALI }, /* Ali5455 */

are there any plans to offer a sbemu win9x edition to get sound working in a dos-environment within win9x?

dr.zeissler wrote on 2024-01-26, 12:49:

are there any plans to offer a sbemu win9x edition to get sound working in a dos-environment within win9x?

From: https://github.com/crazii/SBEMU/issues/59

SBEMU won't work on any windows system by its nature - windows has its own DPMI host and it have no port trapping, and windows won't launch if there's a DPMI installed under DOS (e.g. HDPMI32i),

thank you.

Maybe if Win98 sources will leak (not yet? NT4 and XP srcs are out there for a long time) then it would be possible to patch win9x DPMI 😀

I was under the impression sound card drivers can install their own DOS Sound Blaster emulation?

rasz_pl wrote on 2024-01-26, 17:57:

I was under the impression sound card drivers can install their own DOS Sound Blaster emulation?

The problem, is that we are implementing a dirty hack here, not implementing a VXD, which traps all interrupts in protected mode using a totally different mechanism that integrates with the NTVDM and WoW subsystems.

We are instead, utilizing a niche private API from quarterdeck, to trap real mode interrupts in protected mode, using a far call handler-- handle the interrupt-- then return to realmode execution as if nothing happened. We handle that interrupt using a DPMI provider that windows does not like.

If we could get Crazii to use the Quarterdeck DPMI provider (or write a suitable surrogate that fakes it good enough), we could maybe get around it, but windows would NOT like having stuff done behind its back. I would say that they don't use that approach for important reasons.

veelstekel wrote on 2024-01-26, 09:06:

Which vendor_id / device_id does this ICH chip have? Is it one from intel8x0.c? […]
Show full quote

wierd_w wrote on 2024-01-24, 06:05:

I've noticed that the problematic Toshiba with the C200 ICH, is being identified as intel ICH with a conexant codec.

I will double check with working linux to make sure sbemu is correctly identifying it.

Which vendor_id / device_id does this ICH chip have?
Is it one from intel8x0.c?

{ PCI_VDEVICE(INTEL, 0x2415), DEVICE_INTEL }, /* 82801AA */
{ PCI_VDEVICE(INTEL, 0x2425), DEVICE_INTEL }, /* 82901AB */
{ PCI_VDEVICE(INTEL, 0x2445), DEVICE_INTEL }, /* 82801BA */
{ PCI_VDEVICE(INTEL, 0x2485), DEVICE_INTEL }, /* ICH3 */
{ PCI_VDEVICE(INTEL, 0x24c5), DEVICE_INTEL_ICH4 }, /* ICH4 */
{ PCI_VDEVICE(INTEL, 0x24d5), DEVICE_INTEL_ICH4 }, /* ICH5 */
{ PCI_VDEVICE(INTEL, 0x25a6), DEVICE_INTEL_ICH4 }, /* ESB */
{ PCI_VDEVICE(INTEL, 0x266e), DEVICE_INTEL_ICH4 }, /* ICH6 */
{ PCI_VDEVICE(INTEL, 0x27de), DEVICE_INTEL_ICH4 }, /* ICH7 */
{ PCI_VDEVICE(INTEL, 0x2698), DEVICE_INTEL_ICH4 }, /* ESB2 */
{ PCI_VDEVICE(INTEL, 0x7195), DEVICE_INTEL }, /* 440MX */
{ PCI_VDEVICE(SI, 0x7012), DEVICE_SIS }, /* SI7012 */
{ PCI_VDEVICE(NVIDIA, 0x01b1), DEVICE_NFORCE }, /* NFORCE */
{ PCI_VDEVICE(NVIDIA, 0x003a), DEVICE_NFORCE }, /* MCP04 */
{ PCI_VDEVICE(NVIDIA, 0x006a), DEVICE_NFORCE }, /* NFORCE2 */
{ PCI_VDEVICE(NVIDIA, 0x0059), DEVICE_NFORCE }, /* CK804 */
{ PCI_VDEVICE(NVIDIA, 0x008a), DEVICE_NFORCE }, /* CK8 */
{ PCI_VDEVICE(NVIDIA, 0x00da), DEVICE_NFORCE }, /* NFORCE3 */
{ PCI_VDEVICE(NVIDIA, 0x00ea), DEVICE_NFORCE }, /* CK8S */
{ PCI_VDEVICE(NVIDIA, 0x026b), DEVICE_NFORCE }, /* MCP51 */
{ PCI_VDEVICE(AMD, 0x746d), DEVICE_INTEL }, /* AMD8111 */
{ PCI_VDEVICE(AMD, 0x7445), DEVICE_INTEL }, /* AMD768 */
{ PCI_VDEVICE(AL, 0x5455), DEVICE_ALI }, /* Ali5455 */

A quick and dirty PCI ID probe says it is intel, with PCI ID of 8086:1C20 (class 403)
[6 Series/C200 Series Chipset Family High Definition Audio Controller]

I am bastardizing a bootable linux live usb, to get a "Known working" identification on its codec. Give me a bit.

linux identifies (and sets up) the device as Intel HDA i915 audio, with conexant CX20585. (HDAudioC0D0)

let me get exact line from sbemu...

"Intel HDA: Intel CPT6 (80861c20)->Conexant (14f15069)"

Seeing prior posts about that conexant audio codec, and HDAPLAY, I decided to try it.

Some of the time, it "halfass plays" my sample wave, infinitely looping, with lots of static.
Some of the time, it plays a lot of nasty static, and no discernable wav audio.

Invoking SBEMU after using hdastat -r to reset the codec, it still crashes.

hdaplay says it cannot find any pins to do playback with afterward, until issued an hdastat -r. (note, the system is in an unsafe/unreliable/insane state after sbemu crashes)
After being reset in this way, hdaplay is able to reliably* (see above) play wave files, suggesting that SBEMU is indeed setting up the codec correctly.

Running sbemu twice, results in one crash, and then it claiming it installed and activated.

The system is very unstable afterward, and either plays silence, or hangs, when SB audio is attempted.

I can use hdastat to grab the hda register data, if you guys want.