I cant seem to find a thread for OG VSBHDA-- But I thought I would mention that I tried Emulators Inc FusionPC 3 for DOS with it, and it seems to work.

Have MacOS 8.1 running in it. Audio works.

Cacodemon345 wrote on 2025-01-22, 18:31:

GitHub repository: https://github.com/Cacodemon345/VSBHDASF […]
Show full quote

GitHub repository: https://github.com/Cacodemon345/VSBHDASF

This is a fork of VSBHDA that is equipped with the open-source TinySoundFont software synthesizer (with a few fixes incorporated from two PRs (one with dealing centibels-to-decibels conversion and other supporting the MIDI sustain command) and my own modifications to account for over-attenuation) in conjunction with MPU-401 support.

One could ask the question "Why did I make this?" or "Why the need when SBEMU's MPU-401 passthrough to real hardware is sufficient?".

I made this because:

1. My system (motherboard Gigabyte B150M-WIND) has no PCI slots on-board.
2. The case I'm using has no space for a PCIe-to-PCI adapter so it'd become a hassle I don't want to be dealing with.
3. Although I could theoretically get the PCIe C-Media sound cards, I don't want to deal with the hassle of setting up the TSRs and the potential compatibility issues thereafter.
4. Baron Von Riedesel has indicated no plans in the future for VSBHDA (not even AWE32 support, which would allow soundfonts to be loaded, and which I don't plan on, to be honest), and SBEMU development is seemingly halted at the moment outside the sound drivers.
5. Most systems with onboard AC97/HD Audio since 2001 does not provide MPU-401 emulation (unless redirecting it to one of serial ports like SBEMU), and many desktop systems released today with CSM support does not come with the serial port on the backside, instead requiring the pins to be manually wired up to a real one which can be a hassle to deal with.
6. Many laptops even before the Skylake/Kaby Lake era have no serial port outside for obvious reasons, making MPU-401 redirection impossible.
7. Paying for real SC-55 units on eBay in my country is too expensive for me, and doing a smartphone setup with MIDI on one side and serial port on the other would be too much effort for too little gain anyways.
8. I also wanted to make this for fun purposes and also to save money since I have no working PCs with PCI slots proper.

There are three executables to use. One is optimized for SSE2 instructions (named vsbhdap4.exe) and one is targeted at all x86 CPUs with FPU (named vsbhda.exe). There's also a zip attached for easy setup.

MPU-401 emulation is UART-only. There's also no support for 16-bit HDPMI hosts and it does not compile with Open Watcom at the moment, only with DJGPP makefiles.

Set environment variable SOUNDFONT to the path of the soundfont you want to load, and then launch any one of either vsbhda.exe, vsbhdamx.exe or vsbhdap4.exe with the appropriate arguments.

Tested with Duke Nukem 3D Atomic Edition, Vanilla DOOM 2, MBF source port and the DOSMID MIDI playback program. Tested on Gigabyte B150M-WIND motherboard with FreeDOS 1.4 RC1 installation using Intel i5-6500 (not virtualization). It also works on VirtualBox (although make sure to run Duke Nukem 3D on VESA 2.0 modes to avoid severe slowdown and audio glitches). I don't know if it will work very well with Pentium 4s (although TinySoundFont is said to work well for ARM systems) but it should work well on Pentium Dual-Core systems at the very least.

Note that bug reports from non-HD Audio systems (and especially AC97-related ones from certain SiS chipsets) are given lower priority due to my inability to maintain them.

Contributions are welcome.

Has anyone seen and know how to resolve this error?
Intel ICH detection: no IRQ set in PCI config space, try to set it to 11
Found Sound Card: ICH AC97

The sound doesn't seem to want to function.

It's an Anolog Devices AD1886 using the SoundMAX digital audio compatible codec driver on the TriGem Lomita for HP and runs great with a 1400MHz Tualatin Pentium III-S CPU.

https://theretroweb.com/motherboards/12150
the photo here shows the AD1886A chip. I have the AD1886 chip. I wonder if they are similar.

The audio sets to IRQ 9 with two input/output ranges: 1200-12FF and 1300-133F . IRQ 9 cannot be changed and the HP BIOS is no help either is there a way to manually specify AC97 resources? if not, can it be added as some additional parameters when running such as a force setting? I wonder if it would help get this one going.

jkammueller wrote on Today, 15:31:

Cacodemon345 wrote on 2025-01-22, 18:31:

GitHub repository: https://github.com/Cacodemon345/VSBHDASF […]
Show full quote

GitHub repository: https://github.com/Cacodemon345/VSBHDASF

This is a fork of VSBHDA that is equipped with the open-source TinySoundFont software synthesizer (with a few fixes incorporated from two PRs (one with dealing centibels-to-decibels conversion and other supporting the MIDI sustain command) and my own modifications to account for over-attenuation) in conjunction with MPU-401 support.

One could ask the question "Why did I make this?" or "Why the need when SBEMU's MPU-401 passthrough to real hardware is sufficient?".

I made this because:

1. My system (motherboard Gigabyte B150M-WIND) has no PCI slots on-board.
2. The case I'm using has no space for a PCIe-to-PCI adapter so it'd become a hassle I don't want to be dealing with.
3. Although I could theoretically get the PCIe C-Media sound cards, I don't want to deal with the hassle of setting up the TSRs and the potential compatibility issues thereafter.
4. Baron Von Riedesel has indicated no plans in the future for VSBHDA (not even AWE32 support, which would allow soundfonts to be loaded, and which I don't plan on, to be honest), and SBEMU development is seemingly halted at the moment outside the sound drivers.
5. Most systems with onboard AC97/HD Audio since 2001 does not provide MPU-401 emulation (unless redirecting it to one of serial ports like SBEMU), and many desktop systems released today with CSM support does not come with the serial port on the backside, instead requiring the pins to be manually wired up to a real one which can be a hassle to deal with.
6. Many laptops even before the Skylake/Kaby Lake era have no serial port outside for obvious reasons, making MPU-401 redirection impossible.
7. Paying for real SC-55 units on eBay in my country is too expensive for me, and doing a smartphone setup with MIDI on one side and serial port on the other would be too much effort for too little gain anyways.
8. I also wanted to make this for fun purposes and also to save money since I have no working PCs with PCI slots proper.

There are three executables to use. One is optimized for SSE2 instructions (named vsbhdap4.exe) and one is targeted at all x86 CPUs with FPU (named vsbhda.exe). There's also a zip attached for easy setup.

MPU-401 emulation is UART-only. There's also no support for 16-bit HDPMI hosts and it does not compile with Open Watcom at the moment, only with DJGPP makefiles.

Set environment variable SOUNDFONT to the path of the soundfont you want to load, and then launch any one of either vsbhda.exe, vsbhdamx.exe or vsbhdap4.exe with the appropriate arguments.

Tested with Duke Nukem 3D Atomic Edition, Vanilla DOOM 2, MBF source port and the DOSMID MIDI playback program. Tested on Gigabyte B150M-WIND motherboard with FreeDOS 1.4 RC1 installation using Intel i5-6500 (not virtualization). It also works on VirtualBox (although make sure to run Duke Nukem 3D on VESA 2.0 modes to avoid severe slowdown and audio glitches). I don't know if it will work very well with Pentium 4s (although TinySoundFont is said to work well for ARM systems) but it should work well on Pentium Dual-Core systems at the very least.

Note that bug reports from non-HD Audio systems (and especially AC97-related ones from certain SiS chipsets) are given lower priority due to my inability to maintain them.

Contributions are welcome.

Has anyone seen and know how to resolve this error?
Intel ICH detection: no IRQ set in PCI config space, try to set it to 11

This is a - questionable - feature of SBEMU/VSBHDA: it's detected that the PCI sound card has no IRQ assigned by the BIOS and hence SBEMU/VSBHDA tries to assign one - this isn't covered by the PCI specs, since this info is regarded as "read-only".

A probable fix is to set the OS to "Non-Plug and Play" in the BIOS setup.

In case the machine was reset using Win9X's "Start MS-DOS mode": I have seen at least one machine where this approach actually "disables" the sound card. So better do a fresh boot and enter DOS mode directly...

Baron von Riedesel wrote on Today, 16:44:

This is a - questionable - feature of SBEMU/VSBHDA: it's detected that the PCI sound card has no IRQ assigned by the BIOS and hence SBEMU/VSBHDA tries to assign one - this isn't covered by the PCI specs, since this info is regarded as "read-only".

You don't assign interrupts that way. The register indicating the interrupt number in PCI config space is indeed "for your information only", because it is an 8-bit latch implemented in the PCI target chip that has no function at all. Each function of a PCI device only has one IRQ pin. A PCI slot has four IRQ pins, allowing a multi-function device with up to four functions to generate separate IRQs. The PCI config space contains read-only information indicating which function is connected to which of the four IRQ pins at the PCI slot (they are called IRQA..IRQD). These routings are fixed in hardware. There is nothing a device can do to request a specific IRQ (maybe that changed with the message-signaled interrupt MSI). Instead, the IRQ pins of all the slots and on-board PCI devices are hooked up to four (early chipsets) or eight (later chipsets) interrupt input pins (this obviously means, multiple IRQ pins of on-board devices and slots need to be paralleled). The BIOS knows which PCI interrupt pin is connected to which chipset input pin, and the BIOS configures the IRQ routing inside the chipset. The BIOS then writes the IRQ numbers set in the chipset into the PCI config space of the functions that use the respective chipset routing element.

If the IRQ field in PCI config space is set to FF (IIRC), this means the BIOS did not tell the device which IRQ it is connected to. This might mean that the BIOS just forgot to set it, or doesn't want software to use that IRQ, but it might also mean that the chipset input pin this PCI function is connected to is disabled and does not generate any interrupt at all.

In any case, writing anything into the "Interrupt line" register has no functional consequence, but it hides the fact that the BIOS did not publish IRQ routing information for that device. If I were to write a tool that needs to deal with this situation in a different way than plain aborting with an error message indicating "No IRQ assigned", I would refrain from writing that register, but still assume that the card is possibly able to generate some interrupt. IRQ11 isn't a bad guess in this case, as explained down below.

Baron von Riedesel wrote on Today, 16:44:

A probable fix is to set the OS to "Non-Plug and Play" in the BIOS setup.

I'm unsure whether it is supposed to help in this case. The point of that option is to not initialize plug-and-play devices that are not essential for booting and can be enabled by the PnP OS later. While this may sound like this could apply to PCI devices, the issue is that the PnP BIOS specification does not provide an interface for the operating system to assign IRQs to PCI cards. Even the routing tables are not part of the PnP specification. Even a Plug-and-Play aware operating system can only use the IRQs assigned by the BIOS. This did change later, namely the MP specification (multiprocessing) defined a way to publish IRQ routing tables, and even later ACPI provided an interface for the "PCI Interrupt links" that can actually be used to configure the interrupt routing in the chipset. There is a recommendation (by whom? citation required) to configure all PCI IRQ input pins to IRQ11 and have the operating system use ACPI to redistribute the interrupt assignment as it sees fit. It would make some sense to enable this "everything on IRQ11" mode if the APM/ACPI setup option is set to ACPI mode.

Due to the recommendation to use IRQ11 as "default fallback", guessing IRQ11 if no information about the IRQ routing is available is a reasonable thing, but it's just a guess that can be wrong, and the IRQ router connected to the sound chip might be in "no IRQ assigned" mode, in which no guess would work.

Hey Baron,

Is there a way to forcibly enable pc speaker output over an intel HDA device that does not turn it on?

I have a nearly perfect laptop that plays well with vsbhda, but it does not route pc speaker over the audio bus, and does not have a peizo buzzer either. It cannot emit any sounds meant for pc speaker.

(If I turn on the BIOS audio options, it plays a lovely 8 note wave sample jingle, not a PC Speaker beep.)

Is there a way to turn the needed device registers on, or if not, can we get an optional switch to capture the port writes meant for pc speaker?