PalMusicFan wrote on 2026-05-18, 08:46:

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.

Thanks! I tested the sdlpal in virtualbox, it seems that there is a keyboard input problem that the game doesn't read keyboard port suddenly, key press has no effect in ingame-menu, and causes VDPMI keyboard buffer overflow and there is a intentional NULL pointer write to trigger a exception 0e. I've made changes when kbd buffer is full, the buffer is cleared/discarded so that there is no exception, but the underlying reason why sdlpal doesn't read keyboard is unknown, it still could be related to VDPMI, I'm looking into this.

FreeDOS is not tested yet, I will try to figure out what happens during loading.

PalMusicFan wrote on 2026-05-18, 08:46:

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.

I've no idea the currently state of video support of SDL, but I can SDLPAL works well on that. if it has better solutions, it can be useful.

crazii wrote on 2026-05-19, 03:02:

Thanks! I tested the sdlpal in virtualbox, it seems that there is a keyboard input problem that the game doesn't read keyboard port suddenly, key press has no effect in ingame-menu, and causes VDPMI keyboard buffer overflow and there is a intentional NULL pointer write to trigger a exception 0e. I've made changes when kbd buffer is full, the buffer is cleared/discarded so that there is no exception, but the underlying reason why sdlpal doesn't read keyboard is unknown, it still could be related to VDPMI, I'm looking into this.

FreeDOS is not tested yet, I will try to figure out what happens during loading.

Using the same boot disk, only that i845GL PC has the problem, while the PM965 PC boots normally.

I remember this keyboard problem, but it's not universal. What is the testing results of real hardware and DOSBOX/86BOX, etc.?

Also, is surround OPL working for you? In the SDLPal.cfg I packed, UseSurroundOPL is enabled. If you can hear the stereo Ad Lib music, it is working.

crazii wrote on 2026-05-19, 03:02:

I've no idea the currently state of video support of SDL, but I can SDLPAL works well on that. if it has better solutions, it can be useful.

Oh, I need to clarify that SDLPal does not use SDL level video decoder component, nor does it use SDL_Mixer.

I also tested the IRQ0division ZIP (5-12-26) above, and it worked for me at 320x240 resolution and stereo OPL3 sound with SBEMU (old version 1.5 with HDPMI, non-VDPMI). On my system (baremetal DOS, i5-3427 CPU @ 1.8 Ghz) it looks better than the old 320x200 screens. The speed seems better -- everything was very fast. The stereo OPL music plays well, but of course there's no .PCM output yet, just the outstanding (stereo) music. Graphics are smooth and I do not see any strange artifacts as mentioned above. 320x240 is better than 320x200- it fills the top and bottom of screen, while 320x00 had the black upper and lower borders. You .cfg file was used with "keep aspect ratio = 1"

With crazii's new VDPMI version of SBEMU, both the VDPMI server and SBEMU appear to load and correctly detect the virtual HDA Sound Blaster, but the sound is silent... I get silent audio on all games / programs, not just SDLPAL. But old 1.5 version works well on this same HP laptop with Intel HDA onboard sound.

I did notice a strange keyboard problem upon SDLPAL exiting as crazii mentioned -- keyboard buffer doesn't fill correctly and some keys don't register. This didn't happen before on other versions.

PalMusicFan wrote on 2026-05-19, 04:11:

I remember this keyboard problem, but it's not universal. What is the testing results of real hardware and DOSBOX/86BOX, etc.?

I tested with my Thinkpad T540p, the keyboard problem still exist, especially when the ARROW keys pressed.

PalMusicFan wrote on 2026-05-19, 04:11:

Using the same boot disk, only that i845GL PC has the problem, while the PM965 PC boots normally.

I've tried fixing the problem, the problem was the PM to RM switch that I made previously aggressive optimizations on, which only works on more "modern" CPUs, and causes problem on legacy CPUs like P4 or Atom. I will post another release when I finished.

zyzzle wrote on 2026-05-21, 22:56:

I also tested the IRQ0division ZIP (5-12-26) above, and it worked for me at 320x240 resolution and stereo OPL3 sound with SBEMU (old version 1.5 with HDPMI, non-VDPMI). On my system (baremetal DOS, i5-3427 CPU @ 1.8 Ghz) it looks better than the old 320x200 screens. The speed seems better -- everything was very fast. The stereo OPL music plays well, but of course there's no .PCM output yet, just the outstanding (stereo) music. Graphics are smooth and I do not see any strange artifacts as mentioned above. 320x240 is better than 320x200- it fills the top and bottom of screen, while 320x00 had the black upper and lower borders. You .cfg file was used with "keep aspect ratio = 1"

With crazii's new VDPMI version of SBEMU, both the VDPMI server and SBEMU appear to load and correctly detect the virtual HDA Sound Blaster, but the sound is silent... I get silent audio on all games / programs, not just SDLPAL. But old 1.5 version works well on this same HP laptop with Intel HDA onboard sound.

I did notice a strange keyboard problem upon SDLPAL exiting as crazii mentioned -- keyboard buffer doesn't fill correctly and some keys don't register. This didn't happen before on other versions.

Let's discuss them separately. There are at least four situations now: the CI version and the IRQ0 divisor attachment version here, each paired with Sound Blaster 16 and SBEMU.

I assume real SB16 card does not work with SurroundOPL=1, but SBEMU does, regardless the version of SDLPAL.EXE, right?
And keyboard issue exists in all the 4 cases, right?

crazii wrote on 2026-05-22, 10:36:

PalMusicFan wrote on 2026-05-19, 04:11:

I remember this keyboard problem, but it's not universal. What is the testing results of real hardware and DOSBOX/86BOX, etc.?

I tested with my Thinkpad T540p, the keyboard problem still exist, especially when the ARROW keys pressed.

I am using "cli" to temporarily disable interrupts in that piece of inline assembly that jumps to the BIOS timer. Could it be the problem? Sorry, I don't have enough knowledge about this. I was told this method works in this project: https://github.com/ctm/executor/blob/master/s … itimer32.c#L211

PalMusicFan wrote on 2026-05-22, 13:18:

crazii wrote on 2026-05-22, 10:36:

PalMusicFan wrote on 2026-05-19, 04:11:

I remember this keyboard problem, but it's not universal. What is the testing results of real hardware and DOSBOX/86BOX, etc.?

I tested with my Thinkpad T540p, the keyboard problem still exist, especially when the ARROW keys pressed.

I am using "cli" to temporarily disable interrupts in that piece of inline assembly that jumps to the BIOS timer. Could it be the problem? Sorry, I don't have enough knowledge about this. I was told this method works in this project: https://github.com/ctm/executor/blob/master/s … itimer32.c#L211

I don't think there is a problem. "cli" is redundant if code is in irq handler but not to cause problems. for hardware interrupt (irqs) in PM, cpu turns off IF automatically (necessarily through an interrupt gate in IDT) like RM interrupt.

itimer32.c is better in ways to chain the pm handlers, in case any pm handlers installed previously (any TSRs maybe), and the last pm handler in chain is a built-in DPMI function that calls to the rm handler in IVT, like calling _go32_dpmi_simulate_fcall_iret().

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

I assume real SB16 card does not work with SurroundOPL=1, but SBEMU does, regardless the version of SDLPAL.EXE, right?

I just did a test with the CI build regarding UseSurroundOPL=1. Well, it works there, though the music plays a bit slower than IRQ0division build, kind of like when playing NES games in PAL mode instead of NTSC mode.

Not sure what might have caused the IRQ0division build to hang. To be precise, in IRQ0division build, with cinematic disabled (per the SDLPAL.CFG shipped in the archive), the opening music (and intro screen) does work, but as soon as it tries to go to the main menu, it hangs, kind of like the first few SDLPAL builds I've tried.

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

And keyboard issue exists in all the 4 cases, right?

I'm afraid the keyboard issue might be something specific with SBEMU, as I never had this issue on my system (with CT2950) since the very beginning.

BTW: I'm using PS/2 keyboard here. As for cases with SBEMU I wonder if USB keyboard is being used there. Probably the legacy USB implementation of the system might also be a factor for the keyboard issue...

LSS10999 wrote on 2026-05-23, 16:20:

I'm afraid the keyboard issue might be something specific with SBEMU, as I never had this issue on my system (with CT2950) since the very beginning.
BTW: I'm using PS/2 keyboard here. As for cases with SBEMU I wonder if USB keyboard is being used there. Probably the legacy USB implementation of the system might also be a factor for the keyboard issue...

Yes, I did some tests and compare with cwsdpmi/hpdmi, it seems only vdpmi has such problem, even without sbemu.
I remember sdlpal had no keyboard response, while the menu highlight was animating. but now it freezes. not quite sure but
I'm looking into it.

Did some debug and found the culprit: sdlpal reads port 64/60 for keybd scancode multiple times in a single irq1 handler call, that's uncommon and vdpmi intentionally won't return the next byte to it, keeps sdlpal dead loops in reading port 60.
for a keyboard/mouse handler, the good way is to read one byte one on each interrupt, the next bytes DOES NOT necessarily belong to the the same device.

An easy and straightforward way to exhibit that, is to install CTMOUSE and press arrow keys & moving your mouse at the same time in sdlpal, you may see expected behaviors (in DOSBox or with hdpmi it seems OK, but with cwsdpmi it doesn't). Even if it is OK in the game, some mouse data is gone (read/eaten by sdlpal) and then you exit sdlpal and run games with mouse function, or edit.com, move the mouse, the data is corrupted.

currently vdpmi doesn't handle port 61h, to present the next scancode byte, that can be improved to solve the freeze. and vdpmi has no mouse driver. adding a simple mouse driver that caches mouse data may solve the conflict, because like windows VMM/DPMI, the real interrupt flag IF in vdpmi is never off, the real irq12 can be handled even in program/bios keyboard handler, only the virtual irq12 can be blocked by virtual irq1, but mouse data already processed by driver.

I did a quick coding to add a simple mouse driver, and remove the repeating read of scancode, now the problem is totally gone. I will do more tests and make a new release.

Here is the breakdown of ps2 kbd mouse interrupts behavior:

when a key is pressed down, there are a series of scancode generated by kbd controller, key up is the same. the ps2 controller will fire interrupts for each scancode.
mouse is the same, multiple interrupts with 1 byte from each, for a single move event (usually 3 if I recall). the ps2 controller knows which device generates the data, so the right interrupt is fired.

when keyboard and mouse operations happens at same time, data may came to the ps2 controller in a random, "interleaved" pattern, e.g. in such timely order:

• scancode1 for key 'X' : IRQ1
• mouse move packet0 : IRQ12
• scancode2 for key 'X' : IRQ1
• mouse move packet1 : IRQ12
• ...

it is a recommended way that each interrupt service routine only read only one byte of data from the ps2 controller.
otherwise, if the keyboard isr reads a scancode, and further reads more, e.g. "mouse move packet0" which belong to the incoming IRQ12, and that data is not a keyboard scancode.

I think VDPMI will handle that properly so the problem is gone, no corrupted mouse data anymore. so no needs to change your code if it is not critical.

LSS10999 wrote on 2026-05-23, 16:20:

I just did a test with the CI build regarding UseSurroundOPL=1. Well, it works there, though the music plays a bit slower than IRQ0division build, kind of like when playing NES games in PAL mode instead of NTSC mode.

Well... Here is a test version with no BIOS Timer named sdlpal_0.exe. It comes with
outportb(0x20, 0x20);
instead of jumping to BIOS timer. So, BIOS Timing stops until you exit game.

Rename sdlpal_IRQ0_2.00*.7z to sdlpal_IRQ0_2.7z.00*, and unzip them.

Note that sdlpal.exe is still the 05-21 version, for comparison.

crazii wrote on 2026-05-24, 05:57:

I think VDPMI will handle that properly so the problem is gone, no corrupted mouse data anymore. so no needs to change your code if it is not critical.

That is good!
Perhaps we will switch to the official SDL3 version later. I will check at that time whether it has this problem.

Another issue, the official SDL3 for DOS seems to have a keyboard buffer overflow issue (as I understand it), causing the speaker to frequently emit noise. I have heard it is because thet hook the keyboard interrupt but also still call the BIOS keyboard handler. It is not directly related to the topic here, just recording it.

PalMusicFan wrote on 2026-05-24, 11:22:

Well... Here is a test version with no BIOS Timer named sdlpal_0.exe. It comes with outportb(0x20, 0x20); instead of jumping t […]
Show full quote

LSS10999 wrote on 2026-05-23, 16:20:

I just did a test with the CI build regarding UseSurroundOPL=1. Well, it works there, though the music plays a bit slower than IRQ0division build, kind of like when playing NES games in PAL mode instead of NTSC mode.

Well... Here is a test version with no BIOS Timer named sdlpal_0.exe. It comes with
outportb(0x20, 0x20);
instead of jumping to BIOS timer. So, BIOS Timing stops until you exit game.

Rename sdlpal_IRQ0_2.00*.7z to sdlpal_IRQ0_2.7z.00*, and unzip them.

Note that sdlpal.exe is still the 05-21 version, for comparison.

Tested this one... No difference between SDLPAL.exe and SDLPAL_0.exe. Both hang on music playback if UseSurroundOPL=1. It seems the non-cinematic intro music can also hang in this case, though at one time it did not.

UseSurroundOPL=1 does work on older CI builds, just that music plays a bit slower in comparison, regardless of UseSurroundOPL.

So I wonder how exactly UseSurroundOPL works. Perhaps it has issues with the new timer mechanism...

LSS10999 wrote on 2026-05-24, 13:52:

Tested this one... No difference between SDLPAL.exe and SDLPAL_0.exe. Both hang on music playback if UseSurroundOPL=1. It seems the non-cinematic intro music can also hang in this case, though at one time it did not.

UseSurroundOPL=1 does work on older CI builds, just that music plays a bit slower in comparison, regardless of UseSurroundOPL.

So I wonder how exactly UseSurroundOPL works. Perhaps it has issues with the new timer mechanism...

Actually, this design is very simple; it just enables the native OPL3 mode and copies and slightly adjusts the original OPL2 operations to send them to the newly added channels in OPL3.

What I am now questioning is whether this multiplication slightly exceeds the ISR resource limit in the test configuration.

In the CI version, the BGM handler is chained, but in the IRQ0 version, the BGM handler is set to the default handler. I am just a beginner in this part, and am not sure whether this difference requires more resource.

LSS10999 wrote on 2026-05-23, 16:20:

I just did a test with the CI build regarding UseSurroundOPL=1. Well, it works there, though the music plays a bit slower than I […]
Show full quote

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

I assume real SB16 card does not work with SurroundOPL=1, but SBEMU does, regardless the version of SDLPAL.EXE, right?

I just did a test with the CI build regarding UseSurroundOPL=1. Well, it works there, though the music plays a bit slower than IRQ0division build, kind of like when playing NES games in PAL mode instead of NTSC mode.

Not sure what might have caused the IRQ0division build to hang. To be precise, in IRQ0division build, with cinematic disabled (per the SDLPAL.CFG shipped in the archive), the opening music (and intro screen) does work, but as soon as it tries to go to the main menu, it hangs, kind of like the first few SDLPAL builds I've tried.

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

And keyboard issue exists in all the 4 cases, right?

I'm afraid the keyboard issue might be something specific with SBEMU, as I never had this issue on my system (with CT2950) since the very beginning.

BTW: I'm using PS/2 keyboard here. As for cases with SBEMU I wonder if USB keyboard is being used there. Probably the legacy USB implementation of the system might also be a factor for the keyboard issue...

Please check the latest SDL3 build. Everything works now. v2026-06-28-gf31c4c2.

PalMusicFan wrote on Today, 13:00:

Please check the latest SDL3 build. Everything works now. v2026-06-28-gf31c4c2.

Finally we have working sound effects in SDLPAL DOS (yay!).

Some notes with this build:
- UseSurroundOPL=1 works as expected. I get stereo music from my real SB16.
- Cinematics play a bit slower than normal, with the sound stuttering, especially in the SOFTSTAR logo video.
- Normal ingame sound effects seem to work okay in most cases, though I can't do extensive tests yet as I haven't progressed much.
- Ingame Sound and Music toggles still don't work. Also, it seems the music simply hangs if a cutscene wants the music to stop.
- Music playback speed is on the slow side (like the older CI builds, not the IRQ0 version which is faster).

Regarding the stuttering, there's no difference when booting with or without EMM (e.g. JEMMEX).

EDIT: It seems sound works fine with JEMMEX or without any EMM. However, with VDPMI, sound only plays for the first time then it stopped working. Also, while it exits fine with JEMMEX or without EMM, when using VDPMI, the game hangs on exit.

EDIT 2: Having progressed a bit further and it seems sound effects work well enough (apart from the cinematics). Just that I kind of need to tweak the volumes as right now the OPL3 music feels a bit too loud compared to sound effects especially while in combat.