Native (WDM) HD Audio driver for Windows 98se/Me

[SweetLow]

14 hours ago, Drew Hoffman said:

Which system are you still having the looping problem on? Is it the Nvidia MCP78 or the Sunrise Point PCH or something else?

Realtek ALC887 @ Intel Comet Point-V PCH (Intel Core gen 10 Desktop Motherboard), of course.

[SweetLow]

On 1/28/2026 at 7:15 PM, Drew Hoffman said:

it was the HD Audio Controller's PCIe transactions no-snoop bit

Ok, I paid some time to check what happens. With high probability clearing this bit is palliative. It will work only on PCI-E devices. But HDA Controller can be pure PCI device that needs uncached buffers or flushing cache explicitly to work properly with very high probability.

And JFYI - older Indel HDA controllers are PCI-E devices but newer (including my test system) are PCI.

P.S. And second JFYI - MS driver work with this bit set on.

 

Edited January 30 by SweetLow

[schwups]

Alpha 016:

Win ME / RM / DirectX 9c
Success with MSI G41M4-F (7592) ICH7 HD AudioController ID VEN_8086&DEV_27D8 / Realtek ALC888S - line out (green also CS/RS/SS)

and Asus P5KPL EPU, ICH7 / Realtek ALC887

So far no sound on Asus P5B (ADI1988A) and Asus P5KPL/1600 (VT1708B)

Asus P5KPL/1600 black jack output has scratchy noise.

All PCIE 1.0

Edited Wednesday at 04:48 PM by schwups

[SweetLow]

On 1/28/2026 at 7:15 PM, Drew Hoffman said:

PCIe transactions no-snoop bit

Ok, I paid few more time as caching theme on x86 was slightly unclear for me (as I learnt this theme more from NT point of view - universal drivers for different architectures). But for x86 things are more simple as there is stated that PCI devices always work in cache coherent mode (as PCI-E devices with cleared no-snoop bit) and chipset is responsible for snooping. It means that all memory buffers can have usual WB chache mode and no explicit software cache control needed. But OTOH it is unclear now why my Core gen 10 system does not work - it has HDA Controller as PCI device - exactly as Core gen8.

[Drew Hoffman]

I don't have any Intel 10th Gen systems immediately available to test on and there are still similar issues with some AMD chipsets as well both older and newer. Right now I am focused on refactoring to allow support for multiple codecs on a link which is required to support laptop docking stations and HDMI display audio. 

@SweetLow you did some research on the SBEMUL.SYS driver a year ago and patched it to allow the SB16 over the low DMA channel. Did you decompile the whole thing or just reverse engineer the registry settings? Since it already traps the port for Adlib FM do you think it would be possible to route the command & data port writes to the DOSBox or Nuked OPL emulator? I have tried putting that driver into Ghidra but couldn't make much sense of the int 20 hooks and couldn't load symbols for PortCls and KS in SYM format so I didn't get very far. 

Edited Thursday at 12:32 AM by Drew Hoffman

[SweetLow]

12 hours ago, Drew Hoffman said:

I don't have any Intel 10th Gen systems

Problem is really strange as for example pangomis'es MSI PRO H610M-B DDR4 (Realtek ALC892/ALC897) with core gen12 has HDA controller as PCI device too.

So driver works on core gen8 and core gen12 but does not work on core gen10. But I slightly do not understand why his system did not work on previous versions of driver (if he tested these versions, of course).

12 hours ago, Drew Hoffman said:

just reverse engineer the registry settings?

This one. And SB16 emulation is just bonus in process of finding Registry settings as I paid attention on the string for environment with T6 type and then found variable responsible for switch - that does not export through the Registry key.

12 hours ago, Drew Hoffman said:

Since it already traps the port for Adlib FM do you think it would be possible to route the command & data port writes to the DOSBox or Nuked OPL emulator?

The fact that SBEMUL sets (null) hook for FM synthesis was the main surprise for me  But I don't understand why do you need exactly such thing. You can DISABLE FM synthesis in SBEMUL and enable it anywhere (real hardware or other emulator).

P.S. >but couldn't make much sense of the int 20 hooks

I did not understand what you are talking about for the first but now I understand. Man, you are in Windows in 386 Enhanced mode  These are just VxD calls/jumps. Some disassemblers should understand them (and I wrote few simple tools for decoding them to human readable values).

Edited Thursday at 08:17 AM by SweetLow
P.S. added

[Drew Hoffman]

So maybe a driver that only does Adlib emulation would be better to create? It's just that SBEMUL is a SYS driver not a VxD (and i think it has to be, because it's acting as a kernel streaming filter driver) but it's using the ASM interface to VMM to install the IO handlers. The alpha of VDMSound does the same port-trapping but for its own SB16 and Adlib emulation and all written as a VxD. I guess there is no other interface to the VDM on 9x? I don't have much experience or knowledge of x86 assembly.

[SweetLow]

12 hours ago, Drew Hoffman said:

It's just that SBEMUL is a SYS driver not a VxD

The fact that something built as .SYS does not prevent it from using .VXD interfaces. More I can say - it does not prevent from exporting .VXD interfaces. Look at ACPI.SYS for example.

12 hours ago, Drew Hoffman said:

So maybe a driver that only does Adlib emulation would be better to create?

Yes, I assume.

12 hours ago, Drew Hoffman said:

I guess there is no other interface to the VDM on 9x?

No. But Windows 9x kernel has enough functionality for any port trapping/injecting into DOS code/interrupt handling chaining you want to use in form of VxD interfaces.

P.S. >I don't have much experience or knowledge of x86 assembly.

Сalling of vxd interfaces are available in C code of drivers and almost all needed headers exist, of course

Edited yesterday at 07:38 AM by SweetLow
P.S. added

[defuser]

It is not necessary that it is a VxD driver. WDM drivers of some sound cards also support FM under Windows 98 (at least) and this is done by the same (Main) device driver (DS1.SYS):

[deomsh]

I tested latest version (WDMHDA Alpha-016) on 960GM-GS3 (AMD SB710) with codec ALC662.

I got sound if listening to a music WAV-file in Mediaplayer, but first only ONE intermitting 'tone' or 'tic', and sometimes after replay a highly distorted sound, but no music. According to DXDIAG al tests from a software buffer are 'good' (said oke if I heard sound).

For High Definition Audio AMD SB710 seems te be same as SB600.

First I checked with Watler's tool INTELHDA.EXE (AHDA17O) at pci-level:

Except for Pci-Mem same as (working) W20 $0000 $0002:

Re: High Definition Audio
« Reply #113 on: Dec 2nd, 2017, 4:57pm »	QuoteModifyDelete Post
Are the chickens happy again?

I think I found something interesting with help of AHDA17L.

I compared VERB response values and Register values in AHDA17L after starting Windows with and without HDA2.DLL or BUG.BAT (JUDAS21C).
On the codec-level I found no real differences when starting Windows with BUG.BAT in comparison with HDA2.DLL only (apart from some minor volume-levels). Also no differences in HD Audio Controller Memory Mapped Registers. In the HD Audio Controller PCI Configuration Space Registers I found one different value in row W20.

TEST: AHDA17L

	NO DRIVER:		HDA2.DLL (98E):	BUG.BAT (JUDAS21C):
PCI W1:$ W2:$ 		W1:$ W2:$ 		W1:$ W2:$
W0 	1002 4383 		1002 4383 		1002 4383
W2 	0006 0410 		0006 0410 		0006 0410
W4 	0000 0403 		0000 0403 		0000 0403
W6 	2010 0000 		2010 0000 		2010 0000
W8 	4004 F7FF 		4004 F7FF 		4004 F7FF
WA 	0000 0000 		0000 0000 		0000 0000
WC 	0000 0000 		0000 0000 		0000 0000
WE 	0000 0000 		0000 0000 		0000 0000
W10	0000 0000 		0000 0000 		0000 0000
W12	0000 0000 		0000 0000 		0000 0000
W14	0000 0000 		0000 0000 		0000 0000
W16	1849 7662 		1849 7662 		1849 7662
W18	0000 0000 		0000 0000 		0000 0000
W1A	0050 0000 		0050 0000 		0050 0000
W1C	0000 0000 		0000 0000 		0000 0000
W1E	010B 0000 		010B 0000 		010B 0000
W20	0000 0000 		0000 0000 		0000 0002
W22	0001 0000 		0001 0000 		0001 0000
W24	0000 0000 		0000 0000 		0000 0000
W26	0001 0000 		0001 0000 		0001 0000
W28	0001 C842 		0001 C842 		0001 C842
W2A	0000 0000 		0000 0000 		0000 0000
W2C	0000 0000 		0000 0000 		0000 0000
W2E	0000 0000 		0000 0000 		0000 0000
W30	0005 0080 		0005 0080 		0005 0080
W32	0000 0000 		0000 0000 		0000 0000
W34	0000 0000 		0000 0000 		0000 0000
W36	0000 0000 		0000 0000 		0000 0000
W38	0000 0000 		0000 0000 		0000 0000
W3A	0000 0000 		0000 0000 		0000 0000
W3C	0000 0000 		0000 0000 		0000 0000
W3E	0000 0000 		0000 0000 		0000 0000

When starting Windows with HDA2.DLL only and setting W20/W2 to 0002 enables sound immediately when playing a WAV-file in Sound Recorder. Reset to 0000 disables again, etc.

When I counted right, this can be Misc Control 2 Register - R/W - 8 bits - [PCI_Reg: 42h] in the AMD SB700/710/750 Register Reference Guide.

So I suspected the interface.

I believe Watler's driver HDA2.DLL defaults to CORB/RIRB (Verbinterface=$1 in HDACFG.INI), but can be set to Immediate Command (ports). If I try Verbinterface=$0 I get no sound whatever with Watler's driver.

So don't know if that will be a solution....

Edited 1 hour ago by deomsh