digger wrote on 2026-04-18, 22:48:

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?

I found the pull request through this news article on Generationamiga: https://www.generationamiga.com/2026/04/13/sd … classic-ms-dos/

Excuse me, have you tested this SDLDOS3?
We built it ourselves, but the video system does not work.

According to their readme, we used the following commands to build SDL3 and the testing demo pack.

cmake -S. -Bbuild-dos \
-DCMAKE_TOOLCHAIN_FILE=build-scripts/i586-pc-msdosdjgpp.cmake \
-DCMAKE_BUILD_TYPE=Release -DSDL_TESTS=ON
cmake --build build-dos -j$(nproc)

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.

PalMusicFan wrote on 2026-04-22, 01:01:

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.

From the README.md of my ail32-djgpp project:

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.

PalMusicFan wrote on 2026-04-22, 14:19:

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.

digger wrote on 2026-04-23, 20:03:

@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?

digger wrote on 2026-04-23, 20:03:

@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.

digger wrote on 2026-04-23, 20:03:

@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.

Excuse me, do you know how to handle ISR chain in DJGPP?

We reprogrammed the timer to a higher frequency, and would like to use chain to keep other ISRs using the default 18.2Hz. But it seems if we set the ISR to our own, the system will be buggy. Looks like a DJGPP issue.

I am testing an IRQ0 divider to speed up the IRQ while keep the BIOS timers running still at about 18.2Hz.

memset (&r, 0, sizeof (r));
r.x.cs = rm_old_irq0.rm_segment;
r.x.ip = rm_old_irq0.rm_offset;
r.x.ss = r.x.sp = 0;

// This simulates an INT but in protected mode
// It's safer than raw LCALL in many DPMI environments
_go32_dpmi_simulate_fcall_iret(&r);

If I set the frequency at about 55Hz or lower, it works well in DOSBOX-X and 86BOX emulator, also on real PC.
But in "normal" DOSBOX, only a simple demo works, not the game.

A new beta version has been released, which implements IRQ0 division, and the system timing is now relatively accurate.

Rename the files to sdlpal_IRQ0division.zip.oo1 and sdlpal_IRQ0division.zip.002, then unzip them.

zyzzle wrote on 2026-04-16, 01:14:

However, you said earlier that the game always renders in 320x200. Is that no longer true with the newer DOS builds?

I compiled a new version with IRQ0 division. The system timer is relatively normal. It's not particularly accurate, as I haven't implemented compensation for accumulated errors, but there shouldn't be much deviation in the short term.

However, the handling of IRQ0 has changed significantly. I tested its stability, and it's quite stable and acceptable on DOSBOX-X, 86BOX and my real PC hardware. Sometimes the game in the original DOSBOX 0.74-3 will be silent. In such cases, rerun the program.

Also, the default resolution is 320x240 now.

Great job!
I am glad that someone are working on a port of PAL. I am a big fan of that game, first time played it when I was in elementary school in the 1990s.
I will investigate the sound problem in the coming weeks.

BTW SBEMU now uses its own v86 and DPMI code: Re: SBEMU: Sound Blaster emulation on AC97
you may check if there is any different, I'm not confident about the new code, maybe it is even worse. but my focus will be on the new code.

crazii wrote on 2026-05-12, 14:13:

Great job! I am glad that someone are working on a port of PAL. I am a big fan of that game, first time played it when I was in […]
Show full quote

Great job!
I am glad that someone are working on a port of PAL. I am a big fan of that game, first time played it when I was in elementary school in the 1990s.
I will investigate the sound problem in the coming weeks.

BTW SBEMU now uses its own v86 and DPMI code: Re: SBEMU: Sound Blaster emulation on AC97
you may check if there is any different, I'm not confident about the new code, maybe it is even worse. but my focus will be on the new code.

Thank you so much! Actually, we have been testing to ensure compatibility with SBEMU as much as possible.

I will test your latest version soon!

BTW, we are trying to migrate the DOS version to SDL3, as they now have an official implementation for DOS. However, we have now found that their clock system is not accurate enough for realtime hardware OPL2 music playing. The system's computational load significantly interferes with the timer. So, we hope to integrate our timer system using custom IRQ0 ISR, which we implemented on SDL2, to SDL3.

We have now implemented IRQ0 frequency division, dividing 55Hz to 18.2Hz for the system timer at approximately 3:1. After testing, it was found to be compatible with the previous version of SBEMU. Are there any points we should be aware of to maintain compatibility with the new version of SBEMU?

PalMusicFan wrote on 2026-05-12, 14:58:

Thank you so much! Actually, we have been testing to ensure compatibility with SBEMU as much as possible. […]
Show full quote

crazii wrote on 2026-05-12, 14:13:

Great job! I am glad that someone are working on a port of PAL. I am a big fan of that game, first time played it when I was in […]
Show full quote

Great job!
I am glad that someone are working on a port of PAL. I am a big fan of that game, first time played it when I was in elementary school in the 1990s.
I will investigate the sound problem in the coming weeks.

BTW SBEMU now uses its own v86 and DPMI code: Re: SBEMU: Sound Blaster emulation on AC97
you may check if there is any different, I'm not confident about the new code, maybe it is even worse. but my focus will be on the new code.

Thank you so much! Actually, we have been testing to ensure compatibility with SBEMU as much as possible.

I will test your latest version soon!

BTW, we are trying to migrate the DOS version to SDL3, as they now have an official implementation for DOS. However, we have now found that their clock system is not accurate enough for realtime hardware OPL2 music playing. The system's computational load significantly interferes with the timer. So, we hope to integrate our timer system using custom IRQ0 ISR, which we implemented on SDL2, to SDL3.

We have now implemented IRQ0 frequency division, dividing 55Hz to 18.2Hz for the system timer at approximately 3:1. After testing, it was found to be compatible with the previous version of SBEMU. Are there any points we should be aware of to maintain compatibility with the new version of SBEMU?

The new v86&DPMI aka VDPMI require a minimal Pentium CPU to work, it uses the v86 virtual interrupts (VME) & protected mode virtual interrupt (PVI) extension to provide virtual interrupts.
none that I can think of except that above.

I may add a software implementation independent of the CPU support, so that it's more compatible and you don't need to care about that.
the software method existed in the beginning but makes code complicated so I removed them.

Hello again,
Where can I find the latest build of sdlpal dos?
the one listed at https://cloudsmith.io/~sdlpal/repos/sdlpal/pa … %27%5EDOS%24%27 was 1 month and 1 week ago, is it OK for test with SBEMU and VDPMI?

EDIT:
Another question: are you planned to merge the better video support for SDL to upstream? I think it'll be great to improve the upstream.

Looks like there haven't been any new commits pushed to SDLPAL repo regarding dos or dos_sdl3 branch.

I wonder if SDL3 DOS build is ready yet... and whether the SDL3 build will have proper SFX support for Sound Blaster cards (as mentioned in the SDL3 DOS support PR)...

The current issue seems to be timer (8254) related and I think it's close to being resolved.

LSS10999 wrote on Yesterday, 08:14:

Looks like there haven't been any new commits pushed to SDLPAL repo regarding dos or dos_sdl3 branch.

I wonder if SDL3 DOS build is ready yet... and whether the SDL3 build will have proper SFX support for Sound Blaster cards (as mentioned in the SDL3 DOS support PR)...

The current issue seems to be timer (8254) related and I think it's close to being resolved.

The SDL3 build is indeed not yet for being released. The issue is, the Ad Lib music timer speed is too unstable.

I think we need to port our vclock implementation to SDL3. And, yes, the timer divider is close to be implemented. If you have tested the new binary I posted here and it works normally, that could be the solution.

Previously, we achieved stable Ad Lib music playback by changing the IRQ0 frequency. However, this affects the overall timing of the PC. If it were directly implemented into SDL3, I believe the entire system would be messed up, so I must ensure that I can obtain the required IRQ0 frequency while keeping the system time basically accurate.

The next step should be to port this newly implemented frequency-divided vclock to SDL3. I need some time to accomplish this, and it would be great if there is some guidance available.

crazii wrote on Yesterday, 06:13:

Hello again, Where can I find the latest build of sdlpal dos? the one listed at https://cloudsmith.io/~sdlpal/repos/sdlpal/pa … […]
Show full quote

Hello again,
Where can I find the latest build of sdlpal dos?
the one listed at https://cloudsmith.io/~sdlpal/repos/sdlpal/pa … %27%5EDOS%24%27 was 1 month and 1 week ago, is it OK for test with SBEMU and VDPMI?

EDIT:
Another question: are you planned to merge the better video support for SDL to upstream? I think it'll be great to improve the upstream.

Please look up, I have put the document in the attached files here Re: SDLPAL DOS port for the RPG game LEGEND OF SWORD AND FAIRY. I test it with new SBEMU and VDPMI loaded, it is working. Just one issue, on an i845GL PC, the FreeDOS startup stops when loading VDPMI.

About the better video support, is there an new implementation available now? I know the current one works, just not so good when running under DOS.

PalMusicFan wrote on 2026-05-12, 13:00:

A new beta version has been released, which implements IRQ0 division, and the system timing is now relatively accurate.

Rename the files to sdlpal_IRQ0division.zip.oo1 and sdlpal_IRQ0division.zip.002, then unzip them.

Tried this on my system. Most of the stuffs work just like the previous CI builds with no differences that I could notice.

Though when I used the config file that came with the archive the game hanged when entering the main menu, while my original SDLPAL.CFG worked fine.

After some investigation I found that the hang was caused by the UseSurroundOPL option. Setting it to 1 leads to the hang, so for now I have to keep it at 0.

Not sure whether RealOPLUpdateFreq still matters. My original SDLPAL.CFG had 50 whereas the new one is 55, but I don't feel any difference.

And I think the game was originally meant for 320x200, as ingame text is correctly rendered under that resolution.

With 320x240, however, ingame text feels a bit uneven, with some horizontal lines drawn thinner than usual.

LSS10999 wrote on Yesterday, 15:21:

Tried this on my system. Most of the stuffs work just like the previous CI builds with no differences that I could notice. […]
Show full quote

PalMusicFan wrote on 2026-05-12, 13:00:

A new beta version has been released, which implements IRQ0 division, and the system timing is now relatively accurate.

Rename the files to sdlpal_IRQ0division.zip.oo1 and sdlpal_IRQ0division.zip.002, then unzip them.

Tried this on my system. Most of the stuffs work just like the previous CI builds with no differences that I could notice.

Though when I used the config file that came with the archive the game hanged when entering the main menu, while my original SDLPAL.CFG worked fine.

After some investigation I found that the hang was caused by the UseSurroundOPL option. Setting it to 1 leads to the hang, so for now I have to keep it at 0.

Not sure whether RealOPLUpdateFreq still matters. My original SDLPAL.CFG had 50 whereas the new one is 55, but I don't feel any difference.

And I think the game was originally meant for 320x200, as ingame text is correctly rendered under that resolution.

With 320x240, however, ingame text feels a bit uneven, with some horizontal lines drawn thinner than usual.

OK, I think this is what you found. Are the CI builds showing the same bug? I assume you were using the old SBEMU then this bug appeared, right?

I remember I tested this version using UseSurroundOPL=1 with the new SBEMU VDPMI beta and it worked.

About the resolution, yes, the original resolution is 320x200 but it is displayed in 4:3.

PalMusicFan wrote on Yesterday, 15:49:

OK, I think this is what you found. Are the CI builds showing the same bug? I assume you were using the old SBEMU then this bug appeared, right?

I remember I tested this version using UseSurroundOPL=1 with the new SBEMU VDPMI beta and it worked.

About the resolution, yes, the original resolution is 320x200 but it is displayed in 4:3.

I'm not using SBEMU. It's actual Sound Blaster 16 (CT2950) with YMF289 (OPL3).

I haven't tested the previous build yet but... does UseSurroundOPL work on real Sound Blaster hardware?

I just remembered this feature was more for SBEMU back then... If so, never mind...

LSS10999 wrote on Yesterday, 18:17:

I'm not using SBEMU. It's actual Sound Blaster 16 (CT2950) with YMF289 (OPL3). […]
Show full quote

PalMusicFan wrote on Yesterday, 15:49:

OK, I think this is what you found. Are the CI builds showing the same bug? I assume you were using the old SBEMU then this bug appeared, right?

I remember I tested this version using UseSurroundOPL=1 with the new SBEMU VDPMI beta and it worked.

About the resolution, yes, the original resolution is 320x200 but it is displayed in 4:3.

I'm not using SBEMU. It's actual Sound Blaster 16 (CT2950) with YMF289 (OPL3).

I haven't tested the previous build yet but... does UseSurroundOPL work on real Sound Blaster hardware?

I just remembered this feature was more for SBEMU back then... If so, never mind...

Oh, sorry.

I think this feature is working for, or at least supposed to be working for both emulated OPL3 and real hardware OPL3. I remember I tested it with a YMF724 card +(an old version of) SBEMU as the driver, and it worked.