I'd like to see a proper gpu miniport driver, and not a generic framebuffer driver.

That, plus working baytrail audio, would let me use that BIOS-ized minnowboard Max I have sitting around with win2k, which would run 'quite acceptably' on that cpu. (N3600 series, iirc.)

wierd_w wrote on 2024-10-16, 08:30:

That, plus working baytrail audio, would let me use that BIOS-ized minnowboard Max I have sitting around with win2k, which would run 'quite acceptably' on that cpu. (N3600 series, iirc.)

Were you thinking about audio over HDMI or does the board have a separate audio connector?

Baytrail... Unlikely. pretty sure they were hdmi only.

Someone mentioned ACPI in this thread, so I remember bumping into this.
https://github.com/UltraOS/uACPI

pachuco wrote on 2024-10-16, 19:50:

Someone mentioned ACPI in this thread, so I remember bumping into this.
https://github.com/UltraOS/uACPI

That's a very interesting project, I didn't know about. Thank you for sharing, pachuco.

From what I understood this project has already done quite a lot of the development and is currently working on final issues, for example thread safety. The main developer is still active.

And there is someone else who tries to port it to ReactOS, if I understood that one correctly.

The ACPI driver from Windows 2000 (ACPI.sys) prevents some machines from booting. So any efforts in this direction might turn out to be valueable to increase the compatibility with modern hardware.

The uACPI project seems to have a big chunk of what's necessary to write an ACPI driver, but the Windows 2000 specifics are still missing.

So all in all this project is so far the most promissing path to improve the compatibility of Windows 2000 with ACPI.

As part of such a project, an Intel HDA driver for Windows 2000 that works with most recent motherboard and laptop chipsets would be useful.

myne wrote on 2024-10-16, 10:10:

Baytrail... Unlikely. pretty sure they were hdmi only.

No, on many early chromebooks, a baytrail audio solution is paired with a realtek codec to provide 'system speakers and mic'.

In the case of my minnowboard though, it is indeed the hdmi only setup.

Can you tell me how to install the TP-Link TL-WN725N or RTL8188EU on Windows 2000 with modified drivers? I heard someone got it running under Windows 2000 by modifying the Windows XP driver, but they didn’t explain the procedure to modify the driver. Could you guide me on how to modify the drivers to make this work?

https://www.overclockers.com/forums/threads/u … ws-2000.719773/

It's been a while ... anyway. Here is a small update for those who are still interested in this Windows 2000 fan project:

There is a new video presentation which covers sound in Windows 2000. The biggest subtopic is about the High Definition Audio driver that one of our community members has written.

There is a low quality version on odysee:
https://odysee.com/@startmeup

and a medium quality version in the FTP-account and the HTTP-directory listing:
http://ontheserver.de/Downloads/.../006 - ein universeller Tontreiber für Windows 2000/

Enjoy, the show.

If you have a minute left to give some feedback: I'm especially interested in what you think was the worst thing in the presentation. Thank you.

Here's my notes on your presentation:

- The Audio Controller device is normally not contained directly inside the CPU unless the CPU is a SoC (like the Bay Trail Atom). Physically, it is usually contained in the Southbridge or PCH chip. Logically, it is on the PCI or PCIe bus and accesses audio data in main memory by DMA.

- Audio could be directly generated by the CPU using interrupts and PWM (this is often done on embedded systems) but this would consume a significant amount of CPU time and any jitter in the interrupt timing would result in a scratchy unpleasant sound. Also, high performance analog and digital electronics generally require very different processes and design considerations so it is desirable to separate the analog and digital functions into separate devices when possible.

- The AC97 controller register specification is published as part of Intel's ICH documentation and most other chipset manufacturers (VIA, Nvidia, ATI) followed this design closely. AC97 drivers should normally be chosen based on the codec manufacturer because many of the codecs have vendor-specific extensions. The problem with the AC97 architecture is that there's no way to detect the codec's device ID if there is no AC97 driver installed so often the wrong AC97 driver will install but won't function correctly.

- Windows Vista and newer include a generic HD Audio codec driver that may be used when the manufacturer driver is unavailable but this was NOT backported to Windows 2000/XP as it depends on some aspects of the Universal Audio Architecture. Manufacturer specific codec drivers that don't have support for newer chips can sometimes be forced to install by editing the INF file to add the device IDs but this is obviously unsupported and may have unpredictable results.

- There is a reference implementation of the Intel ICH AC97 audio driver published in the Windows DDK (Driver Development Kit) Since Windows 2000; the final version in the Windows 8.1 DDK was released by Microsoft under the MIT license and I have used this as a reference for creating my HDA driver. Development of a universal AC97 driver could proceed based on this sample if this is your aim. Many other manufacturer drivers like the AMD Geode audio are directly based on this sample, which I know because they didn't bother to change any of the GUIDs or function names.

- There are also open source drivers available for the Creative Emu10k series (the KxProject) and the CMI8738 (by Dogbert1) which are the 2 most common PCI sound cards.

- It is easy to detect whether an audio controller is AC97 or HD Audio since they have different PCI Class Codes (AC97 is CC\0401, and HD Audio is generally CC\0403) so drivers for AC97 and HD Audio could be packaged together under one installer and then the correct driver file could be selected by Plug & Play. It is not necessary to merge all drivers into one binary file and this would probably be wasteful in terms of memory usage and duplicated code. I would be fine with my driver being distributed in this way as long as the terms of the MIT license are abided by and it is made clear that the driver is an Alpha and not feature-complete yet.

- The smoothing (and sine-wave ringing) of triangle and square waves is caused by either the Windows kernel mixer when resampling or by your audio codec on output, and is not an artifact of my driver (which does no sound processing whatsoever on its own, though it may pass on processing done by the Windows Kernel Mixer). In fact this is expected and desirable behavior and you would hear high frequency aliasing artifacts if this smoothing did not take place. For reference, please look up such topics as the Fourier transform, the Nyquist limit and band-limited sound synthesis

- My HDA driver is currently hard-limited to 16-bit audio and 48khz even when the underlying hardware supports better resolutions and sample rates; this is because of limits in Windows 98. I could possibly add 88.2 and 96khz audio at 16-bits for Windows 2000 and XP. It's just not high on my priorities list. I would certainly accept patches to improve this situation as long as it did not interfere with operation on Win98. Supporting 20 and 24 bit audio would require the creation of custom CopyFrom and CopyTo functions for the DMA channel to pack the samples in the way that the codec expects. See the mydma.h file.

- I'm not actually sure what's going on with your problems 4, 5 & 6... This may be due to Windows's resampling of high resolution audio down to 48 khz 16-bit?

I am somewhat interested in your display driver but there's a couple of things that make it a lot less interesting:
- Not open source
- Not available anywhere but your FTP server
- No documentation of what devices, resolutions and features are supported besides 4 hours of video? A simple Readme and Changelog file would be helpful, and zip packages including previous versions.

Of course even if it was open source I probably wouldn't be able to use much of the mode setting code to improve VmDisp9x and SoftGPU for use with Windows 9x because 98SE and ME don't support WDM for display drivers anyway, instead the mode setting is done from a 16 bit DLL.

Thank you for your feedback.

onethirdxcubed wrote on 2026-07-30, 21:19:

The Audio Controller device is normally not contained directly inside the CPU unless the CPU is a SoC.

Well, I hope that the presentation did not give the impression that the controller circuit was inside of the processor circuit. Even with a SoC these are separate circuits but they happen to be inside the same chip.

onethirdxcubed wrote on 2026-07-30, 21:19:

The AC97 controller register specification is published as part of Intel's ICH documentation and most other chipset manufacturers (VIA, Nvidia, ATI) followed this design closely.

Are you refering to the document "290655" ("Intel® 82801AA (ICH) and Intel® 82801AB (ICH0) I/O Controller Hub")? Yes, it contains the documentation of an "AC'97"-compatible controller circuit. But my understanding is, that it is a specific controller circuit and not a generic description of "AC'97"-compatible controller circuits in general. For example, it states that the vendor_id is 0x8086 and that the device_id is either 0x2415 or 0x2425, depending on whether one interfaces with the controller circuit within the ICH or the controller circuit within the ICH0. So I think that my statement, that Intel never released a document of the DC'97 as they did with the AC'97, is correct. Well, at least if we are looking for a description in the sense of a sound standard like AC'97 is. Or is the point that you were trying to make, that the specific implementations of the available controller circuits from different manufacturers are so similar, that Intel's implementation is de facto the standard? This would mean that all AC'97 controllers are more or less the same.

onethirdxcubed wrote on 2026-07-30, 21:19:

My HDA driver is currently hard-limited to 16-bit audio and 48khz even when the underlying hardware supports better resolutions and sample rates; this is because of limits in Windows 98. I could possibly add 88.2 and 96khz audio at 16-bits for Windows 2000 and XP.

What about support for lower sample rates like 44,100 samples per second and the 8 bit resolution? Does Windows 98 allow these so you can do the testing? At the moment when playing music, for example, the incorrect output is clearly audible when playing files with a sample rate of 44,100 samples per second while files with 48,000 samples per second play much better.

onethirdxcubed wrote on 2026-07-30, 21:19:

I am somewhat interested in your display driver but there's a couple of things that make it a lot less interesting:
- No documentation of what devices, resolutions and features are supported besides 4 hours of video? A simple Readme and Changelog file would be helpful, and zip packages including previous versions.

That's a thing that can be done. I'll work a bit on the documentation. Also, once a change log exists in the documentation, I can refer to the documentation instead of going through every bug that was fixed in my presentations. That saves a bit of time on my end and makes the presentations shorter and more interesting.

Start me up wrote on 2026-07-31, 14:20:

onethirdxcubed wrote on 2026-07-30, 21:19:

The AC97 controller register specification is published as part of Intel's ICH documentation and most other chipset manufacturers (VIA, Nvidia, ATI) followed this design closely.

Are you refering to the document "290655" ("Intel® 82801AA (ICH) and Intel® 82801AB (ICH0) I/O Controller Hub")? Yes, it contains the documentation of an "AC'97"-compatible controller circuit. But my understanding is, that it is a specific controller circuit and not a generic description of "AC'97"-compatible controller circuits in general. For example, it states that the vendor_id is 0x8086 and that the device_id is either 0x2415 or 0x2425, depending on whether one interfaces with the controller circuit within the ICH or the controller circuit within the ICH0. So I think that my statement, that Intel never released a document of the DC'97 as they did with the AC'97, is correct. Well, at least if we are looking for a description in the sense of a sound standard like AC'97 is. Or is the point that you were trying to make, that the specific implementations of the available controller circuits from different manufacturers are so similar, that Intel's implementation is de facto the standard? This would mean that all AC'97 controllers are more or less the same.

I looked into this some more and there do appear to be some differences in the AC97 controller implementations between chipset manufacturers, though most of the Codec drivers support at least Intel, VIA and SIS implementations. This may be in separate driver files or chosen by setting some Registry keys based on the manufacturer ID. The Codec used is only communicated through the Subsystem Plug & Play ID and this is a poor signal for compatibility. However I think the general rule that AC97 drivers should be chosen based on the Codec stands, with the following known exceptions: Nforce 2 chipset with SoundStorm, AMD Geode audio, and AC97 codecs used on a PCI card such as with the Ensoniq ES1373, Asus Xonar and Sound Blaster Live series.

Also it really shouldn't be hard to find a functioning manufacturer or vendor provided driver supporting Windows 2000 for just about every AC97 implementation, as this standard was superseded and disappeared from the marketplace circa 2006 while Windows 2000 was still in active support. So a generic driver is not really needed in my opinion but may be desirable for open source licensing reasons like for ReactOS, which incorporated the DDK driver for ICH audio after it was open sourced.

Start me up wrote on 2026-07-31, 14:20:

onethirdxcubed wrote on 2026-07-30, 21:19:

My HDA driver is currently hard-limited to 16-bit audio and 48khz even when the underlying hardware supports better resolutions and sample rates; this is because of limits in Windows 98. I could possibly add 88.2 and 96khz audio at 16-bits for Windows 2000 and XP.

What about support for lower sample rates like 44,100 samples per second and the 8 bit resolution? Does Windows 98 allow these so you can do the testing? At the moment when playing music, for example, the incorrect output is clearly audible when playing files with a sample rate of 44,100 samples per second while files with 48,000 samples per second play much better.

The 8-bit bit depth should be allowed but the Windows kernel mixer will upconvert 8-bit audio to 16-bit and also decode various ADPCM formats like A-law. Support for HD Audio's 44100 hz sample rate is allowed on Windows 9x when the codec reports that it supports it, but the kernel mixer does not always use it and seems to default to resampling to the highest rate supported by the sound card when that highest rate is more than 2x the requested rate. 48000 hz is always required to be supported by the spec. Do 20-bit, 24-bit and 32-bit WAV files work on Windows 2000 with another sound card? I think these high depth formats may not be supported by the OS at all.

Start me up wrote on 2026-07-31, 14:20:

onethirdxcubed wrote on 2026-07-30, 21:19:

I am somewhat interested in your display driver but there's a couple of things that make it a lot less interesting:
- No documentation of what devices, resolutions and features are supported besides 4 hours of video? A simple Readme and Changelog file would be helpful, and zip packages including previous versions.

That's a thing that can be done. I'll work a bit on the documentation. Also, once a change log exists in the documentation, I can refer to the documentation instead of going through every bug that was fixed in my presentations. That saves a bit of time on my end and makes the presentations shorter and more interesting.

Thank you very much for this.

Windows 2000 is IMO one of the best operating systems Microsoft ever released. It's great to see people writing drivers for modern hardware. I bet Microsoft never envisaged the OS would still be in use some 25 years after it was released. I think I still have my boxed version somewhere, now might be the time to reinstall it one one of my old computers and have a bit of a play 😀.

onethirdxcubed wrote on 2026-07-31, 18:49:

I looked into this some more and there do appear to be some differences in the AC97 controller implementations between chipset manufacturers

Alright, I'll just leave this part of the presentation as it is for now. Maybe at a later time if AC'97 becomes a main topic then I will look into this issue once again and might be able to clarify the situation a bit further which components are covered by the sound standard and which ones not so much.

onethirdxcubed wrote on 2026-07-31, 18:49:

The 8-bit bit depth should be allowed but the Windows kernel mixer will upconvert 8-bit audio to 16-bit and also decode various ADPCM formats like A-law. Support for HD Audio's 44100 hz sample rate is allowed on Windows 9x when the codec reports that it supports it, but the kernel mixer does not always use it and seems to default to resampling to the highest rate supported by the sound card when that highest rate is more than 2x the requested rate. 48000 hz is always required to be supported by the spec.

Every bit of support for additional sound data formats helps to increase the output quality and to reduce the CPU load by converting less samples from one format to another.

onethirdxcubed wrote on 2026-07-31, 18:49:

Do 20-bit, 24-bit and 32-bit WAV files work on Windows 2000 with another sound card? I think these high depth formats may not be supported by the OS at all.

I think that 32 bits are supported but I have no idea about 20 bits and 24 bits. I limited my tests to figuring out which problems exist and to describe the nature of the problems. With all the test files this already needed nearly 400 tests.

I did not do any tests to figure out, why these problems occure or what can be done about it.

When I do my presentations I usually cover 15 to 20 versions of a driver, so that I got a bit to talk about. In your case I know less about sound than I know about graphics because it's you who works on the sound driver and it's me, who works on the graphics driver. So I might need to wait a few more versions until I can do another presentation about your sound driver. Whenever I do a presentation about your sound driver I add a section where I try to contribute something. This time it was the analysis of the situation and the existing bugs to the extend limited to figuring out which bugs exist and what they are about. Maybe the next time I will try to contribute something in a different area like an in-depth analysis of a specific bug and how it can be fixed. But not this time.

onethirdxcubed wrote on 2026-07-31, 18:49:

Start me up wrote on 2026-07-31, 14:20:

onethirdxcubed wrote on 2026-07-30, 21:19:

No documentation of what devices, resolutions and features are supported besides 4 hours of video? A simple Readme and Changelog file would be helpful, and zip packages including previous versions.

That's a thing that can be done. I'll work a bit on the documentation.

Thank you very much for this.

Here it is: The new documentation which now also contains links to the old versions of the driver.

Well, about your "Thank you.": Could we have a new and improved version of your driver instead, please? 😀

Dame1701 wrote on 2026-08-04, 21:05:

I bet Microsoft never envisaged the OS would still be in use some 25 years after it was released.

Indeed. They released Windows XP way to early which prevented Windows 2000 from becoming a widespread operating system. But it's not dead but lives on and on.

20, 24 and 32 bit WAV files work with Winamp 2.95 (though they are downconverted to 16 bits). It seems that Windows Media Player 6.4 just cannot play those high bit depth WAVs at all.

According to my test results (line 10 and 11 for example), 32 bit is supported by the Media Player 6.4 if signed floating point values are used.

sample_files.7z

onethirdxcubed wrote on 2026-08-12, 00:44:

20, 24 and 32 bit WAV files work with Winamp 2.95 (though they are downconverted to 16 bits).

Well, you said that your driver supports nothing but 16 bits as a resolution, so the samples need to be converted to 16 bits at some time. If Winamp is capable to detecting MMX support or similar instruction set extensions, then it makes sense that Winamp does the conversion itself instead of letting the kernel mixer do the conversion with the regular instruction set.

Maybe the Media Player 6.4 is limited to what can be output by the driver directly plus the conversion abilities supported by the kernel mixer. But this is pure speculation. However, I would not be surprised if the Media Player does not have full wave support but is limited itself to the most common sound data formats.

According to this knowledge base article, it seems KMixer support for audio bit depths greater than 16-bit was added to a hotfix which was later included with Windows 2000 SP3. https://www.betaarchive.com/wiki/index.php?ti … _Archive/308883

So maybe proper high bit depth support could be added for Win2K SP3 and upwards; it seems that I would also have to migrate the driver project to the Windows XP DDK to achieve this because the Win2K DDK doesn't have the headers for WaveFormatExtensible (or reimplement only the bits I need).

Again this is not the highest priority for me but I'm willing to take patches to address this.

Support for actually playing high bit depth WAV files in Windows Media Player is a separate issue probably involving codec files.

onethirdxcubed wrote on 2026-08-12, 18:03:

According to this knowledge base article, it seems KMixer support for audio bit depths greater than 16-bit was added to a hotfix which was later included with Windows 2000 SP3. https://www.betaarchive.com/wiki/index.php?ti … _Archive/308883

So maybe proper high bit depth support could be added for Win2K SP3 and upwards

That might not be necessary because SP4 has this update included. Q308883 will install the version

• "5.00.2195.5237"

of the file "Kmixer.sys". SP4 comes with the version

• "5.00.2195.6655".

The Windows 2000 update that I mention in my presentation includes the version

• "5.00.2195.6752".

This update addresses an issue with resolutions higher than 32 bits.

So the question is rather whether Windows 98 supports the 24 bit resolution. The Windows 2000 update, that introduced the support, (Q308883) includes a version of the file "kmixer.sys", that was compiled on the 22nd of March 2002. So this was roughly the time when Microsoft implemented the support. In your readme you mention 2 Windows 98 SE updates:

• Q242937 contains a version from the 21st of March 2000, so this one is 2 years too early.
• Q269601 which seems to be the same update

Is there any newer version for Windows 98?

Anyway, regarding the situation in Windows 2000: The update you found proves that support for 24 bits in kmixer alone is not enough to allow playback with the Media Player 6.4.

onethirdxcubed wrote on 2026-08-12, 18:03:

Support for actually playing high bit depth WAV files in Windows Media Player is a separate issue probably involving codec files.

Well, I hope that wave support isn't something hardcoded because it might be very well the first file format that the developers supported and maybe this dates back to a time when the developers didn't yet think about adding file format support via external files (software codecs).

onethirdxcubed wrote on 2026-08-12, 18:03:

Again this is not the highest priority for me but I'm willing to take patches to address this.

Which bug is the most interesting one of those mentioned in my presentation?