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 2026-03-25, 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 2026-03-25, 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 2026-03-25, 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?

mkarcher wrote on 2026-03-25, 18:07:

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.

BTW how Win9x do this IRQ (and other resources) allocation? In control panel you have usually some choice to manually select IRQ from a few options instead default auto. So I think Win9x have some ability to override default PnP BIOS allocation. Not sure it it's possible even with ACPI disabled (during Win9x installation). Could it be done also under plain DOS by reconfiguring some chipset registers or so?
I'm thinking about if it's possible to free e.g. IRQ5 for a legacy device even in case when modern SETUP lacks an PnP option to reserve IRQ5-legacy which is then occupied by some USB controller or other PCI devices...

RayeR wrote on 2026-03-27, 07:04:

mkarcher wrote on 2026-03-25, 18:07:

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.

BTW how Win9x do this IRQ (and other resources) allocation? In control panel you have usually some choice to manually select IRQ from a few options instead default auto.

I just booted my ECS K7S5A system (because that's a Win'98 system I have at hand at the moment), and while you can uncheck the "Assign resources automatically" checkbox for PCI devices, Windows generally refuses to change the IRQ ("this setting can not be modified"), it just allows to change the I/O and memory addresses (those can be reassigned by an operating system via PCI configuration space, so no BIOS assistance is needed for that). On the other hand, I am able to change the IRQ of the onboard parallel port that way, because that device is managed by the PNPBIOS interface that is supposed to lift non-PnP onboard devices to the same level of OS control as ISA Plug-and-Play devices.

RayeR wrote on 2026-03-27, 07:04:

So I think Win9x have some ability to override default PnP BIOS allocation.

Windows indeed has some capability to influence PnP BIOS allocation, again using the PNPBIOS interface. The IRQ/DMA setup page of your BIOS usually has a toggle "PnP resources controlled by" which can be set to "operating system" (or "auto") or "manual". If you configure "operating system" there, Windows 95 (or any other operating system that interfaces with the PNPBIOS interface) is able to reserve IRQ and DMA resources for legacy cards.

RayeR wrote on 2026-03-27, 07:04:

Not sure it it's possible even with ACPI disabled (during Win9x installation).

I suggest you recheck that IRQs can really be reassigned on your system. The system I just tested is installed in ACPI mode, and as far as I know, the BIOS offers the required ACPI methods to reconfigure IRQ links, yet Windows 98 does not allow reassigning PCI IRQs on that system.

RayeR wrote on 2026-03-27, 07:04:

I'm thinking about if it's possible to free e.g. IRQ5 for a legacy device even in case when modern SETUP lacks an PnP option to reserve IRQ5-legacy which is then occupied by some USB controller or other PCI devices...

I hope even that modern BIOS still implements the PNPBIOS interface that allows Windows 95 to reserve IRQ5 for legacy devices, even if the setup page has been removed or limited to no longer allow user configuration. In that case, using Windows 95 to reserve IRQ5 should be sufficient to get that IRQ free for legacy devices - even if you boot into another operating system! This is because the PNPBIOS interface stores the configuration set Windows 95 (resources assigned to onboard devices, resources reserved for legacy devices) as part of the ESCD, which is stored in flash memory and applied during POST. I suppose instead of using Windows 95 to interface to the PNPBIOS interface, the Intel ICU ("ISA configuration utility") should work as well, but I never used that tool.

I can't recall now if I have seen changable IRQ of PCI device undrer win98 or if it was possible only for onboard pnp devices. Just checked one of my laptop with Win98 and IRQ is changable only for onboard LPT and COM. Maybe PCI IRQ reallocation cam be done only at boot phase during PnP initialisation?

My experience on a MB with onboard LPT is that I can select ECP mode with IRQ 5 or 7 or EPP mode without IRQ. When LPT IRQ is enabled it's assigned as exclusive. Whrn disabled other PCI devices like USB, LAN, etc. will occupy it. I can trick it that I disable LPT block in superIO after boot with my DOS utility so IRQ5/7 left free. But how to achieve this on MBs without onboard LPT? It maybe still possible force PnP BIOS or is it hardwired in some BIOS table? I didn't study PnP BIOS spec yet so I don't know that possibilities... ICU should work also in this case? I didn't play with it, is it universal for any chipset?

RayeR wrote on 2026-03-28, 19:36:

Maybe PCI IRQ reallocation cam be done only at boot phase during PnP initialisation?

The usual way PCI interrupts get assigned is that the BIOS determines how many of the (let's say 4 for now) PCI interrupt inputs of the Host/PCI-Bridge are connected to interrupt sources. It then assigns IRQs to these interrupt inputs from a list of "free" IRQs. This list is built from the "PnP/legacy" switches, IRQs assigned to onboard resources and possibly ISAPnP cards. If I remember correctly, this happens between the memory test and the initialisation of Option ROMs.

RayeR wrote on 2026-03-28, 19:36:

But how to achieve this on MBs without onboard LPT?

To get Windows 95 to free up an IRQ for legacy resources without a hack like the parallel port thing you are doing, there are two ways:

• The obvious one: Install a driver for the legacy device in Windows 95 that claims this IRQ. The PnP resource management in Windows 95 will tell the BIOS that this IRQ is assigned to "Legacy ISA".
• If there is no Windows 95 driver for that device: Right-Click "My Computer" (the top node) in the Device Manager, and open the second tab. That tab allows the "reservation" of all kinds of resources. If you add "IRQ5" there, Windows 95 is supposed to tell the BIOS that this resource is assigned to "Legacy ISA".

RayeR wrote on 2026-03-28, 19:36:

ICU should work also in this case? I didn't play with it, is it universal for any chipset?

I also never used the ICU, but it is supposed to only use official interfaces, that is PCI BIOS, PnP BIOS and ISA PNP, which all are not chipset dependent. If you run Windows 95 on a computer, you don't need the ICU, the Windows 95 resource management basically integrates the functionality of the ICU, and the Device Manager mostly is a user interface to that integrated ICU.

mkarcher wrote on 2026-03-29, 07:38:

If there is no Windows 95 driver for that device: Right-Click "My Computer" (the top node) in the Device Manager, and open the second tab. That tab allows the "reservation" of all kinds of resources. If you add "IRQ5" there, Windows 95 is supposed to tell the BIOS that this resource is assigned to "Legacy ISA".

This sounds interesting, I'll try this. So win9x just instuct pnp BIOS to add such IRQ on don't use list somewhere in NVRAM and apply after reboot. And how about newer windows if they are installed on the same machine? Couldn't they interfere? And what MB generation still supports pnp BIOS interface? I mean that new with UEFI but still with CSM. I wouldn't be surprised if it alredy vanished...

RayeR wrote on 2026-03-29, 12:58:

This sounds interesting, I'll try this. So win9x just instuct pnp BIOS to add such IRQ on don't use list somewhere in NVRAM and apply after reboot. And how about newer windows if they are installed on the same machine? Couldn't they interfere? And what MB generation still supports pnp BIOS interface? I mean that new with UEFI but still with CSM. I wouldn't be surprised if it alredy vanished...

Other installations of Windows (newer or not) might interfere, I have no experience with that. The PnP BIOS interface is two-way: You can not just add reserved IRQs (although I have to admit, this is outside my expertise, I don't know how the interface works in detail), but you can also read the list of reserved IRQs. So another installation of Windows might very well read the list of "extra reserved IRQs" from the BIOS, and include it in its resource management. Basically, its not different from what you get when you switch an IRQ from "PnP/PCI" to "Legacy ISA": Suddenly, Windows 95 is no longer allowed to use that IRQ in its own resource management.

I have no idea how long the PNPBIOS interface has been carried on. ACPI was designed to replace it, and just like PNPBIOS, ACPI allows reconfiguration of onboard legacy ports like COM or LPT ports, but I don't remember any interface in ACPI that allows persistent storage of resource assignment. As ACPI also is designed to allow PCI IRQ re-routing (obviously, not single IRQs of on PCI device, only one collective IRQ lineI), it might well be that with ACPI, the PCI resource assignment performed by the BIOS was seen as "preliminary" instead, and if the recommendation "put everything to IRQ11" was followed, that preliminary assignment usually did not disturb legacy components, and if it did, reconfiguring legacy components to not use IRQ11 usually is possible. You just get issues if the BIOS assigns IRQ5 to ISA PnP stuff - but that can be fixed up by an ISA configuration utility (including the one in PnP-enabled Windows versions) afterwards. This means unless you require IRQ5 or IRQ7 for booting, there is no immediate need for the BIOS to know whether this IRQ needs to be avoided. Well, kind of. If the legacy component on IRQ5 or IRQ7 starts without that IRQ line being tristated, it can conflict with an ISA PnP component being configured to IRQ5 as well. Being able to tristate IRQ lines was common in '80s hardware (like the standard serial port, parallel port, XT hard disk controller, floppy disk controller), but I'm unsure how much the capability of tristating the IRQ line was carried on in the 90s. For example, I don't think the is an "IRQ/DMA enable" bit on the SoundBlaster card.

Baron von Riedesel wrote on 2026-03-25, 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 he […]
Show full quote

jkammueller wrote on 2026-03-25, 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...

That's how I use MS-DOS. I always choose option 5) Command prompt only from Windows 98SE's F8 menu. I have a GO.BAT file I start after everything boots since Windows 98SE does not like VSBHDASF.

Also, something crazy to make you think for a bit....I now have two working laptops that have IRQ 11 set in Windows 98SE. Dell Latitude C610 and Dell Latitude D600. Every device with IRQ 9 set in windows has not detected as of yet for me.

This is why I was hoping for a test build that would allow an IRQ override parameter so instead of looking for IRQ 11, the user could tell VSBHDASF which IRQ to look for. Of course, I'd tell VSBHDASF to look on IRQ 9.

It'd be something like:

VSBHDA.EXE /HWIRQ9 /VOL8 /F44100

or

VSBHDA.EXE /CHK9 /VOL8 /F44100

the /HWIRQ9 or /CHK9 would be the IRQ it will look for with 9 being any IRQ you specify. It would look on that IRQ instead of the default IRQ (which is 11). If no parameter is set, VSBHDASB would default to IRQ 11.

I could try it and report back.

The crazy thing is there's an alternate Windows sound driver that seems to use IRQ 11 on the Dell Latitude D600. I reinstalled the SigmaTel audio driver since the SigmaTel driver works better with Duke3D but that alternate driver was fine in Windows APPs.

Got this working great on my Asus M5A97 motherboard (AM3+with Phenom II 1100T, 16GB DDR3 ram and an Audigy 2 ZS). I could never get the Creative drivers to load no matter what I tried, VSBHDA (non F, I just now realized this is another fork) working great. Not sure if theres a way to reduce "digital sounds" though? For example in Wolfenstein 3D the door and shooting are way louder than everything else. Doom and Duke3D I need to adjust my levels but yeah, really happy to finally have realmode 6.22 working on this PC.

https://youtu.be/6CMAbP-RUmA

For soundfonts I copied the 8MB one (CT8MGM.SF2) from the Creative DOS folder and it loads without issue, not sure if there are better ones out there? I need to setup MPU-401 for MT-32 next.

AaronS wrote on 2026-04-26, 20:06:

Got this working great on my Asus M5A97 motherboard (AM3+with Phenom II 1100T, 16GB DDR3 ram and an Audigy 2 ZS). I could never get the Creative drivers to load no matter what I tried, VSBHDA (non F, I just now realized this is another fork) working great. Not sure if theres a way to reduce "digital sounds" though? For example in Wolfenstein 3D the door and shooting are way louder than everything else. Doom and Duke3D I need to adjust my levels but yeah, really happy to finally have realmode 6.22 working on this PC.

https://youtu.be/6CMAbP-RUmA

For soundfonts I copied the 8MB one (CT8MGM.SF2) from the Creative DOS folder and it loads without issue, not sure if there are better ones out there? I need to setup MPU-401 for MT-32 next.

I think there is an issue with the volume of FM output - it can be quite low compared to digital sounds on some devices, and the last time I looked there wasn't a separate volume control for the two sources (three if you count the sf2 midi). I've had this on a couple of laptops, but not all of them - it seems like it might be device specific.

I like jnsgm2.sf2 - it's around 35mb - and sounds pretty good in titles like Doom, Duke3d and Descent; very Sound Canvas/Yamaha XG like. It's the default sound font I load on all of the machines I get VSBHDA working on.

You do need more free memory than the size of the file to load it under VSBHDA though. Up to around 2x the size in some soundfonts.

mkarcher wrote on 2026-03-29, 07:38:

To get Windows 95 to free up an IRQ for legacy resources without a hack like the parallel port thing you are doing, there are two ways:
[*]If there is no Windows 95 driver for that device: Right-Click "My Computer" (the top node) in the Device Manager, and open the second tab. That tab allows the "reservation" of all kinds of resources. If you add "IRQ5" there, Windows 95 is supposed to tell the BIOS that this resource is assigned to "Legacy ISA".

I finally tried this IRQ reservation method in Win98SE but the result is not satisfying...
After I added IRQ5 as reseved resource and reboot Windows it runs into classic PnP device detection cycle where I got multiple of BSODs and have to reboot multiple times. But finally it booted and IRQ5 in devmgr was really reserved. But when I rebooted back to DOS the IRQ5 was taken by PCI devices again so the reservation is not persistent in BIOS. So I tried to reboot to DOS mode directly from Windows (without passing the POST) but in this mode the DOS was unstable and everytime I try to run HWINFO or Norton Sysinfo to check IRQ allocation it just hanged and after reboot the reservation has gone. So it seems it's only temporary while Win98 are running so it's not usefull for this purpose of permanent reservation. Maybe the BIOS is too new and missing stuff like ESCD (there's no such message displayed that could be seen on older true ISA PnP BIOSes)...

megatron-uk wrote on 2026-04-28, 06:35:

I think there is an issue with the volume of FM output - it can be quite low compared to digital sounds on some devices, and the last time I looked there wasn't a separate volume control for the two sources (three if you count the sf2 midi). I've had this on a couple of laptops, but not all of them - it seems like it might be device specific.

Oh I see, well it's not a huge deal I can live with it, I wonder if it might be worth using my onboard audio and not the Audigy.

For the MPU-401 thing, how does it work exactly? I put this in my start.bat

1set blaster=A220 I5 D1 H5 T6 P330
2vsbhda.exe /VOL9 /sf:jnsgm2.sf2 /P330

But for games like Monkey Island 2 it seems to make no difference.

AaronS wrote on 2026-04-28, 21:17:

Oh I see, well it's not a huge deal I can live with it, I wonder if it might be worth using my onboard audio and not the Audigy. […]
Show full quote

megatron-uk wrote on 2026-04-28, 06:35:

I think there is an issue with the volume of FM output - it can be quite low compared to digital sounds on some devices, and the last time I looked there wasn't a separate volume control for the two sources (three if you count the sf2 midi). I've had this on a couple of laptops, but not all of them - it seems like it might be device specific.

Oh I see, well it's not a huge deal I can live with it, I wonder if it might be worth using my onboard audio and not the Audigy.

For the MPU-401 thing, how does it work exactly? I put this in my start.bat

Copy code to clipboard

1set blaster=A220 I5 D1 H5 T6 P330
2vsbhda.exe /VOL9 /sf:jnsgm2.sf2 /P330

But for games like Monkey Island 2 it seems to make no difference.

You need to configure the game to use midi. It won't automatically use the soundfonts support unless it is configured for GM / Midi / Port 330.

Easiest way to test is to use something like Duke3d/Dark Forces/Descent or similar, which allows you to configure the music device (and test it) directly from the setup utility.