The driver is a separate file or how do you integrate it into game exe?

RayeR wrote on 2026-10-08, 12:10:

The driver is a separate file or how do you integrate it into game exe?

The AIL/32 drivers are loadable modules in an OS/2-style DLL format.

Protected Mode DOS game developers using the AIL/32 SDK would link their C or assembly code with the API (ail32.h, ail32.asm, ail32.inc and 386.mac) and the DLL loader (dll.h and dllload.c) from the AIL/32 SDK.

The drivers themselves would then be loaded by the game dynamically on startup, either through auto-detection or through explicit selection in the game's setup program, or a bit of both.

This made it relatively easy for such games to be patched with support for later sound cards. For instance, AIL/32 drivers for the Gravis Ultrasound were developed later, and adding native GUS support to AIL/32 games was as easy as overwriting the AIL/32 PCM and MIDI drivers of some other sound card that came supported with the game.

I also created a fork that enhances the AIL/32 drivers to be compatible with code compiled with DJGPP as well. (Yes, I used AI.)

Thas is great.

Nobody tried to do the same for other drivers like miles or HMI?

I think soundblaster live/audigy, ac97 and hdaudio drivers of this kind could be a great alternative for those games that have problems with sbemu.

kanyero wrote on 2026-10-08, 20:29:

Thas is great.

Nobody tried to do the same for other drivers like miles or HMI?

For HMI, yes. There is an open source HMI driver for Intel HDA and compatible devices, developed by the same person who developed vbesvga.drv, the high-quality VESA VBE graphics driver for Windows 3.1.

The developer is a big fan of the Rayman games, which apparently use the HMI drivers, so that was a specific itch to scratch, I guess. 🙂

Another example is @bristlehog's AIL/MIDPAK MIDI driver for the Innovation SSI-2001, a more obscure sound card based on Commodore's SID chip.

I think soundblaster live/audigy, ac97 and hdaudio drivers of this kind could be a great alternative for those games that have problems with sbemu.

Definitely. There is a surprisingly high number of DOS games (both real mode and protected mode) that use modular and/or third-party drivers, and which could be extended with native support for more modern sound devices without having to rely on emulation solutions. Quite a few of these DOS-era sound driver frameworks have been open-sourced (AIL, AIL/32, DIGPAK, Apogee Sound System). So it's quite feasible to write drivers for modern sound devices based on those, as we can see in the example projects above.

Then there are game development studios that developed their own in-house driver standards, which were still modular, and therefore could also be extended like this. See for instance the Sierra/Dynamix sound driver hacking thread.

In the case of driver frameworks that were never open-sourced (Miles 3 and newer, HMI, etc), it might be a bit more difficult, and to some extent perhaps even legally problematic, but in this age with increasingly capable agentic and generative AI, this is becoming easier as well.

I too would like to see more of such developments. Of course it won't replace emulation solutions like SBEMU and VSBHDA outright, but there will be a place for both, and depending on the game and the target hardware, one option will be more suitable than the other.

I haven't use AI assisted coding yet. only conversation on some guidance for old tech details. and I found it sometimes confusing/misleading. e.g. google AI gives made up options of openwatcom WCC/WCC386, or #pragma or wlink OPTIONS that never exist. 🤣.

But I believe AI could indeed help us build better programs.

I've finished VDS with test cases for basic functions, but not using it for real DMA transfers like Sound blaster. Now I started on GEMMIS. and the windows startup protocol (not only GEMMIS but 1605/1606 on INT 2F) requires a EMM to switch to real mode. I have to add some more magic to make the built-in XMM working when VDPMI is unloaded.

Here's a preview on what I'm recently on, I haven't fully tested it yet, and bugs won't be fixed after GEMMIS is done.

List of VDPMI updates besides last notice:
VDS added, DMA buffer only above 1M. windows VDMAD compatible (perhaps) VDMA interface added, SBEMU now uses VDMA function (callbacks, set states, get region info etc.) in VDPMI instead of doing on its own.
Bugfixes on EMS (memory test cases added for UMB/EMS/XMS, and I found most bugs are in EMS, the multi-map, map and jmp/call, and handle name/search functions.
fix VIF not synced properly when calling to realmode. now Jazz jackrabbit runs in normal speed in virtualbox (buggy RTC timing), and I believe it will runs in normal speed for hi-refresh rate monitors.
fix redundant VIP flag (bad for performance) or missing VIP flag (IRQ not handled in time)
/VME option to disable VME. you don't need explicitly disable VME if your CPU doesn't support it, but there will be a warning. set /VME=0 will silence the warning.
fix EMM detection through reading int67 vector.
bugfix on BIOS not reporting F000-FFFF as reserved memory.
VIntFlag in config file to disable VIF. this disables all drivers and set IOPL=3 for v86 (check VDPMI.TXT/VDPMI.CFG for more details)
PIC remapping through PIC port 20/a0 and VCPI interface. Gamewizard may run (sometimes not). DPMI still uses 08/70 vector ignoring PIC remaps, for compatibility reason.
stack SP wrapping fixes. Previously I though it was a bug of HimemX, but actually the wrapping is not handled properly in VDPMI int15h 87h.
some tiny convenient features:
when running VDPMI for the second time, it reports details about services.
when trying unloading VDPMI via /u option, and it fails, there are lists of TSRs that uses EMS/UMB/VCPI. it may not be precise.

I will continue on GEMMIS, it is not quite started yet. For SBEMU the pc-speaker/covox and new drivers from forks is not integrated yet, please wait.

There is a default CFG file, with preset of whitelist (CPUSPD.EXE and MTRRLFBE.EXE CPUID.EXE SMB.EXE)