I was trying to figure out how you forked SDL in your project specifically for use with DOS, so I could see how I could possibly integrate the AIL/32 drivers with it. But then I did an on-line search and that turned up this pull request to add DOS support to SDL3 upstream, including Sound Blaster 16 support with DMA support and everything. The pull request is less than a week old. It even includes some kind of threading solution. Have you looked into this for SDLPAL yet?
We found audhotpl.exe worked very well in DOSBOX 0.74-3. The music sounded pretty good. But the video system did not work at all. draw.exe told us "Couldn't create renderer: Couldn't find matching render driver."
sprite.exe flashed the screen and exited.
We have built STP32.EXE for the following tests. We found it requires IRQ7, ignores SET BLASTER.
Correct. The driver API allows you to either explicitly specify the I/O address, IRQ and DMA settings of the device, or to have the drivers determine those themselves.
On the application/game side, you could include an install or setup utility where the user can select the sound card and specify these hardware settings themself, just like this was originally done with games that used the AIL/32 drivers, such as Simcity 2000. I believe that the installers and setup programs of some games allow for an auto-detect option, as well as an option for the user to override these settings.
To see how the stp32 example application deals with this, see this relevant snippet of the stp32.c example application source code:
1 // 2 // Get driver type and factory default I/O parameters; exit if 3 // driver is not capable of interpreting PCM sound data 4 // 5 6 desc = AIL_describe_driver(hdriver); 7 8 if(desc->drvr_type != DSP_DRVR) 9 { 10 printf("%s is not a digital sound driver.\n", argv[2]); 11 AIL_shutdown(NULL); 12 exit(1); 13 } 14 15 if(!AIL_detect_device(hdriver, desc->default_IO, desc->default_IRQ, 16 desc->default_DMA, desc->default_DRQ)) 17 { 18 printf("Sound hardware not found.\n"); 19 AIL_shutdown(NULL); 20 exit(1); 21 } 22 23 AIL_init_driver(hdriver, desc->default_IO, desc->default_IRQ, 24 desc->default_DMA, desc->default_DRQ);
As you can see, it just uses default_IO, default_IRQ, default_DMA and default_DRQ.
The drivers vary in how smart they handle these defaults, as you can see in the following relevant snippet of dmasnd32.asm, which contains the source code of all the PCM (digital audio) drivers that shipped in the original AIL/32 SDK:
1default_IO LABEL WORD ;Factory default I/O parameters 2 IFDEF PAS 3 dd -1 ;(determined from MVSOUND.SYS) 4 ELSEIFDEF ADLIBG 5 dd 388h 6 ELSE 7 dd 220h 8 ENDIF 9default_IRQ LABEL WORD 10 IFDEF SBSTD 11 dd 7 12 ELSEIFDEF SBPRO 13 dd 7 ;(pre-prod. = 5; prod. = 7) 14 ELSEIFDEF PAS 15 dd -1 ;(determined from MVSOUND.SYS) 16 ELSEIFDEF ADLIBG 17 dd -1 ;(determined from control regs) 18 ENDIF 19default_DMA LABEL WORD 20 IFDEF PAS 21 dd -1 ;(determined from MVSOUND.SYS) 22 ELSEIFDEF ADLIBG 23 dd -1 ;(determined from control regs) 24 ELSE 25 dd 1 26 ENDIF 27default_DRQ dd -1
As you can probably make out from the conditional directives, the Sound Blaster and Sound Blaster Pro drivers are the dumbest in this sense, since they just hard-code the typical defaults: I/O base address 220h, IRQ 7, DMA 1.
I have no idea what default_DRQ is for and how it would differ from default_DMA in practice. ¯\_(ツ)_/¯
A value of -1 for any of these properties means that the driver can auto-detect or otherwise determine these settings. In these same sources, you can see that the Pro Audio Spectrum 16 (PAS) driver will fetch these settings from the MVSOUND.SYS driver that needs to be loaded in CONFIG.SYS when DOS starts up. The Adlib Gold apparently only needs a hard-coded or specified I/O base address and can then use that address to query the IRQ and DMA settings from the card automatically.
The Gravis Ultrasound driver, that was not part of the original AIL/32 SDK distribution, but was later developed by Gravis and separately released (GUSDIG32.DLL, distributed in GAIL3214.ZIP), queries the PSP to fetch these settings from the ULTRASND environment variable, and falls back to probing the different possible I/O base addresses if that environment variable isn't set. That makes it a much smarter driver in terms of auto-configuration than the drivers that originally came with the SDK.
To my knowledge, the sources to the GUS AIL/32 drivers were never released, but I obtained this information from Claude, when I had it disassemble and analyze GUSDIG32.DLL.
It would be perfectly possible to enhance the original dmasnd32.asm source code and build a smarter version of a32sbdg.dll and a32sbpdg.dll that will fetch these settings from the BLASTER environment variable in a similar way to how the GUS drivers do it.
We also found that there is a short blank with 2 clicking sounds every time playback starts. I assume this is a design issue of the playback program, right?
I honestly don't know. I tested my AIL/32 projects in QEMU and DOSBox Staging, and I've yet to properly test this stuff on actual hardware.
But a good way to confirm this is to use the STP.32.EXE file and DLL drivers in the RELEASE.105/WR/ folder of John Miles' AIL/32 sources. That one was originally built by him using the Watcom compiler for use with DOS/4GW, and represents how DOS games back in the day used those drivers. If you get the same short blank and 2 clicking sounds with those, than this behavior was present in the original drivers and in original games too.
1. Intel 4th Gen Core i5 CPU, 16.0 GB RAM
This laptop requires CSM enabled + CSMWRAP to boot FreeDOS, and basically STP32 works well when using VSBHDA.
Cool, you also discovered CSMWRAP as well as VSBHDA and SBEMU. It's amazing to have a game run in pure DOS on a system that was never meant to boot native DOS. That's just wonderful to see. 😁
When running with SBEMU, STP32 plays the music in a lower speed. During one test, it emitted a huge noise for less than a second when exiting playback.
With SBEMU, a32sbdg.dll and a32sbpdg.dll give two different incorrect tone.
The last year or so, VSBHDA has been getting much more active development. Although I'm happy to say that I saw crazii respond again today in the SBEMU thread, after a period of absence. He seems ready to pick up work on SBEMU again, and I'm fairly sure he would be interested in hearing about these findings from you! 🙂
During one test, the program stopped after 2 seconds playback, required a hard reset.
With this combination of tools and emulators, it's hard to say whether it was the driver, the SDK, or other factors.
That's why it's really useful to test SDLPAL on older systems with ISA slots and Sound Blaster compatible sound cards as well, just to rule this stuff out.
3. 86BOX
No problem was found when testing non-PNP Sound Blaster 16 / AWE 32 cards as the IRQ was set to 7. PNP cards were not tested.
86BOX is known for its incredible emulation accuracy, so I guess that would be the next best thing other than testing on period-correct hardware.
4. VirtualBOX on platform 1
When using PIIX3 chipset, the results are similar as those of 1. No such difference for a32sbdg.dll and a32sbpdg.dll's incorrect tones.
When using ICH9 chipset, we saw "Sound hardware not found." for both SBEMU and VSBHDA.
Could very well be the emulation code, the hypervisor or a combination thereof. I noticed myself that the Sound Blaster emulation in QEMU did not work with the original AIL/32 drivers. The Sound Blaster drivers did not detect a card.
By the way, I also intend to develop an AIL/32 driver for Intel HDA and other modern sound devices as well, which hopefully will allow games that use AIL/32 drivers to support new sound hardware natively, without requiring something like VSBHDA or SBEMU. I already developed one for AC'97 ICHx (also with the help of Claude), but even that integrated sound standard is already two decades old at this point.
Also, may I ask a question about the compability of protected mode? Are those driver files complied by Watcom C compatible with STP32 built with DJGPP?
I explicitly worked on ensuring that the original Watcom/Rational-targeted driver DLLs can work with a DJGPP-built project that uses this enhanced version of the AIL/32 library and DLL loader. And I had to do a bit of extra work to get that working with CWSDPMI as well, since it doesn't include the same level of INT 21h emulation that HDPMI has.
Only the Watcom/Rational (WR) variant DLLs from the SDK are supported. These are the drivers found in RELEASE.105/WR/ (not the MP or ZF subdirectories). The WR variant is the one used and included in the vast majority of protected-mode DOS games that shipped with AIL/32 and DOS/4GW. Third-party AIL/32 drivers such as the Gravis Ultrasound drivers were also only widely released for use with Watcom/Rational (DOS/4GW).
It required extra work to get this working with CWSDPMI as well. HDPMI already handled it better out of the box, but I wanted developers to have the freedom to decide which DPMI host they want to bundle with their application or game.
You can find more details about this in the README.md file. There's also information there for people who want to develop new AIL/32 drivers for other sound devices.
Excuse me, have you tested this SDLDOS3?
We built it ourselves, but the video system does not work.
I haven't played with it yet, honestly. My advice would be to inquire about it in the Pull Request thread on GitHub, and to report those findings there.
@PalMusicFan It looks like the SDL project won't be touching my AIL/32 modifications due to a strict "no AI-generated code contributions" policy. See https://github.com/libsdl-org/SDL/pull/15353
That probably explains why they completely ignored my reply in the thread below the merge request for the DOS port.
@PalMusicFan It looks like the SDL project won't be touching my AIL/32 modifications due to a strict "no AI-generated code contributions" policy. See https://github.com/libsdl-org/SDL/pull/15353
That probably explains why they completely ignored my reply in the thread below the merge request for the DOS port.
Oh, I also just found this regulation of the SDL project. And, I just saw the DOS port PR has been accepted.
So may I ask what your next considerations are? Technically, is it possible to extend support for more sound cards with AIL/32 beyond the SDL library? Or are you planning to manually rewrite the code to meet the requirements of the SDL project?
Last edited by PalMusicFan on 2026-04-24, 13:22. Edited 2 times in total.
@PalMusicFan It looks like the SDL project won't be touching my AIL/32 modifications due to a strict "no AI-generated code contributions" policy. See https://github.com/libsdl-org/SDL/pull/15353
That probably explains why they completely ignored my reply in the thread below the merge request for the DOS port.
I'm not sure to how much extent was LLM (e.g. Claude) involved in your AIL/32 work?
If you have full understanding of the work including LLM-generated portions, as well as adequate documentations, perhaps you can start your own issue there.
I've read through the related PR and discussions. Potential license violations seems to be a main concern for LLM-generated code, as there is always the possibility that the LLM may have referenced something not compatible with the zLib license (which SDL uses) to generate the result.
But be careful. While some people may be open to constructive discussions, from the look of the (now locked to collaborators) issue/PR, there are some very rude people out there who may try to derail such.
