Reserved Floor for further discussion...

So is this build for DOS part of the sdlpal project on GitHub (and using the recent libSDL dos target - hence the huge system requirements) or something else?

I can't find any mention of building the sdlpal source for DOS on the sdlpal repository, are the binaries from somewhere else?

megatron-uk wrote on 2026-03-18, 07:52:

So is this build for DOS part of the sdlpal project on GitHub (and using the recent libSDL dos target - hence the huge system requirements) or something else?

I can't find any mention of building the sdlpal source for DOS on the sdlpal repository, are the binaries from somewhere else?

This is part of the SDLPal project. You can view the code in the dos branch. The file `.github/workflows/dos.yaml` contains instructions on how to compile it.

The binaries are compiled by the GitHub build bot and hosted by Cloudsmith, together with other non-release SDLPal binaries.

We haven’t yet decided on a specific toolchain version, and our test environment is too limited, so we need external testing. Additionally, since the audio implementation is not yet complete, it has not been merged into the master branch.

We are now using a DOS SDL port modified from http://github.com/jayschwa/SDL

This appears to be the long-rumored DOS binary which will run the SDL engine in bare-metal DOS.

I'm still quite confused, however. Do you mean the Windows version of the SDLPal 3.3 data will work with this DOS compile provided above (latest version seems to be from 15-March-2026)? There is such a listing of pal_eng 3.3 on archive.org:
https://archive.org/details/paleng_v3.3

which claims to already have an English translation, but only for Windows 32 bit. The windows SDLPal.exe in that archive is dated 11-14-2017. Also, the archive is huge. Do we need all of those large .AVI files in order to run the DOS compile?

I don't know if this is the required SDLPal data for your DOS compile of SDLPal or not. Also, the freeware version you linked above seems to be a completely different version of the game... from 1998? More confused.

Please clarify if possible. As we discussed in the other thread, I know the 1995 DOS version is not able to be translated into English due to Chinese glyphs and font incompatibility. Thanks very much.

zyzzle wrote on 2026-03-19, 01:23:

This appears to be the long-rumored DOS binary which will run the SDL engine in bare-metal DOS. […]
Show full quote

This appears to be the long-rumored DOS binary which will run the SDL engine in bare-metal DOS.

I'm still quite confused, however. Do you mean the Windows version of the SDLPal 3.3 data will work with this DOS compile provided above (latest version seems to be from 15-March-2026)? There is such a listing of pal_eng 3.3 on archive.org:
https://archive.org/details/paleng_v3.3

which claims to already have an English translation, but only for Windows 32 bit. The windows SDLPal.exe in that archive is dated 11-14-2017. Also, the archive is huge. Do we need all of those large .AVI files in order to run the DOS compile?

I don't know if this is the required SDLPal data for your DOS compile of SDLPal or not. Also, the freeware version you linked above seems to be a completely different version of the game... from 1998? More confused.

Please clarify if possible. As we discussed in the other thread, I know the 1995 DOS version is not able to be translated into English due to Chinese glyphs and font incompatibility. Thanks very much.

Yes, this is the bare-metal DOS version of SDLPal.

Let me explain:

The RPG game LEGEND OF SWORD AND FAIRY originally had two official PC versions: the initial 1995 DOS version (which ran in 16-bit real mode and did not support English), and the later 1997–1998 Windows version, which offered limited support for English translations thanks to Windows’ ASCII backward compatibility. Of course, the official PC versions were only available in Chinese. The existing English version is fan-made.

The SDLPal project is dedicated to running both of these game versions on multiple platforms (primarily supporting the DOS version while maintaining compatibility with the Windows version), and it includes support for multilingual translation files. Therefore, as long as the game data for LEGEND OF SWORD AND FAIRY is supported by the Windows version of SDLPal, it should also be supported by SDLPal on other platforms, including this 32-bit DOS version.

The lack of English support in the official DOS version was a limitation of the EXE design, but SDLPal has completely resolved this issue.

Okay, so it is using the new libSDL Dos target, and hence why the rebuilt engine can run on Dos.

I guess it also explains why the requirements are so high.

I'd love to see some more examples of the libSDL Dos version, many of us have been awaiting it for years... though it sounds like there is some substantial resource requirements to it.

Might have to download that libSDL fork and try it myself.

megatron-uk wrote on 2026-03-19, 08:26:

Okay, so it is using the new libSDL Dos target, and hence why the rebuilt engine can run on Dos. […]
Show full quote

Okay, so it is using the new libSDL Dos target, and hence why the rebuilt engine can run on Dos.

I guess it also explains why the requirements are so high.

I'd love to see some more examples of the libSDL Dos version, many of us have been awaiting it for years... though it sounds like there is some substantial resource requirements to it.

Might have to download that libSDL fork and try it myself.

The oldest systems we have on hand are from the P4 era, so we’re not sure what the minimum performance requirements are. We welcome everyone to share their test results with us.

If we disregard the overhead required for software FM synthesis, the game’s performance requirements shouldn’t be very high. As a reference, on a PSP-1000 with a 333MHz CPU, FM music disabled, and using the SDL2 solution with a software color palette, the game runs slowly but is still barely playable (I suspect there are some bottlenecks in graphics data transfer performance). I’m not sure which PC CPU models are comparable to the PSP’s CPU performance, but it should be in the Pentium II or Pentium III range.

We recommend testing our libSDL DOS version; we’ve made numerous adjustments to ensure it runs on real DOS PCs. According to this discussion (Re: NVIDIA Kepler/Maxwell/Pascal VESA Bios Bug (workaround found)), we disabled double-buffering because we found it caused frame sequence errors on certain Nvidia graphics cards, and the known workaround did not work on 9300MG .

Additionally, we haven’t yet figured out how to integrate the SDL Audio with Sound Blaster’s DMA audio. On other systems, SDL Audio runs in a separate thread, but DOS doesn’t support threads.

PalMusicFan wrote on 2026-03-19, 13:00:

We recommend testing our libSDL DOS version; we’ve made numerous adjustments to ensure it runs on real DOS PCs. According to this discussion (Re: NVIDIA Kepler/Maxwell/Pascal VESA Bios Bug (workaround found)), we disabled double-buffering because we found it caused frame sequence errors on certain Nvidia graphics cards, and the known workaround did not work on 9300MG .

Additionally, we haven’t yet figured out how to integrate the SDL Audio with Sound Blaster’s DMA audio. On other systems, SDL Audio runs in a separate thread, but DOS doesn’t support threads.

Thank you very much. I was able to run SDLPal quite well on bare metal MS-DOS 7.1

I used files from the 1995 DOS version, and overwrote the language files from the English translation link given above.

This is running on a fast "modern" DOS system with an i5-8250 CPU, running at 3.4 Ghz. When I step down the speed to 1.7Ghz, it runs well still. However, slowing the CPU down to 900 Mhz, the game starts to lag considerably. The game's isometric view is outstanding, and it played smoothly and without errors all the way to the end. I killed the final boss, and got the end screens, etc. These are things I noticed in the SDLPal for DOS on bare metal:

1. The game's resolution seems capped at 320x200. VESA modes are detected up to 1920x1080 and listed in the logfile, but not utilized. (This happens when running SDLPal using the 1995 DOS files or files from the Windows version.
2. The sound and music would not work, even with VSBDHA or Sbemu. This was expected given what you wrote above about SDL audio and pthreads being required. I assume there's no way to get any audio working in pure DOS at this point. Because the sound doesn't work, I deleted the sound data files, and the game still played perfectly, just without sound.
3. Some Chinese glyphs are still present, for example in the Spells. These spells still work fine, but not sure what they do. Most spells (~85%) are translated into English, however, and that is of course very helpful.
4. The game's ending montage / scenes after the final boss is killed are still in Chinese. These are a series of bitmapped pictures / scenes, and there's no English translation, but it seems the girl becomes a princess and lives happily ever after!
5. The large .AVI files are not required to play the game in DOS. I deleted them, and set the "Play AVI files" flag in SDLPal.cfg to 0 and the game played perfectly.
6. The game completely freezes my system when I "Exit Game" from the System settings in the game. A hard reboot is required. No other freezes occurred during the playing of the game. It seemed very stable except for exiting.
7. The final compressed size of the turnkey .7z archive that I created with all required files to run on bare metal is 14.41 mb.

What are the differences in the DOS version and Windows version? The .mkf files in the Windows version are all larger (for example, the file GOP.MLF is ~16 mb in the Windows version, but only ~10 mb in the DOS version, yet the game seems to look and play exactly the same with both sets of files using your 32-bit DOS DJGPP binary of SDLPal from 15-Mar-2026 (which has an uncompressed size of 6.01 Mb).

megatron-uk wrote on 2026-03-19, 08:26:

I'd love to see some more examples of the libSDL Dos version, many of us have been awaiting it for years... though it sounds like there is some substantial resource requirements to it.

Might have to download that libSDL fork and try it myself.

I was able to run Diablo on bare metal DOS with a compiled DOS DJGPP SDL binary on the same system as above and it plays well, but it is far too dark. Something with the gamma is screwed up, which I'm sure is buggy code in the SDL port. This can be partially compensated for by raising the brightness within the game (it has a brightness adjustment setting), but then it gets washed out. The source needs to be analyzed and brightness gamma bug fixed.

However, the SDLPal SDL binary for DOS played with perfect brightness (Gamma 2.2?) and wasn't dark at all.

These were both played on bare metal DOS, of course.

The SDL port for DOS is huge news. I am also hoping more SDL games get ported to DOS. Any news on this end will be greatly appreciated!

zyzzle wrote on 2026-03-19, 13:37:

Thank you very much. I was able to run SDLPal quite well on bare metal MS-DOS 7.1 […]
Show full quote

PalMusicFan wrote on 2026-03-19, 13:00:

We recommend testing our libSDL DOS version; we’ve made numerous adjustments to ensure it runs on real DOS PCs. According to this discussion (Re: NVIDIA Kepler/Maxwell/Pascal VESA Bios Bug (workaround found)), we disabled double-buffering because we found it caused frame sequence errors on certain Nvidia graphics cards, and the known workaround did not work on 9300MG .

Additionally, we haven’t yet figured out how to integrate the SDL Audio with Sound Blaster’s DMA audio. On other systems, SDL Audio runs in a separate thread, but DOS doesn’t support threads.

Thank you very much. I was able to run SDLPal quite well on bare metal MS-DOS 7.1

I used files from the 1995 DOS version, and overwrote the language files from the English translation link given above.

This is running on a fast "modern" DOS system with an i5-8250 CPU, running at 3.4 Ghz. When I step down the speed to 1.7Ghz, it runs well still. However, slowing the CPU down to 900 Mhz, the game starts to lag considerably. The game's isometric view is outstanding, and it played smoothly and without errors all the way to the end. I killed the final boss, and got the end screens, etc. These are things I noticed in the SDLPal for DOS on bare metal:

1. The game's resolution seems capped at 320x200. VESA modes are detected up to 1920x1080 and listed in the logfile, but not utilized. (This happens when running SDLPal using the 1995 DOS files or files from the Windows version.
2. The sound and music would not work, even with VSBDHA or Sbemu. This was expected given what you wrote above about SDL audio and pthreads being required. I assume there's no way to get any audio working in pure DOS at this point. Because the sound doesn't work, I deleted the sound data files, and the game still played perfectly, just without sound.
3. Some Chinese glyphs are still present, for example in the Spells. These spells still work fine, but not sure what they do. Most spells (~85%) are translated into English, however, and that is of course very helpful.
4. The game's ending montage / scenes after the final boss is killed are still in Chinese. These are a series of bitmapped pictures / scenes, and there's no English translation, but it seems the girl becomes a princess and lives happily ever after!
5. The large .AVI files are not required to play the game in DOS. I deleted them, and set the "Play AVI files" flag in SDLPal.cfg to 0 and the game played perfectly.
6. The game completely freezes my system when I "Exit Game" from the System settings in the game. A hard reboot is required. No other freezes occurred during the playing of the game. It seemed very stable except for exiting.
7. The final compressed size of the turnkey .7z archive that I created with all required files to run on bare metal is 14.41 mb.

What are the differences in the DOS version and Windows version? The .mkf files in the Windows version are all larger (for example, the file GOP.MLF is ~16 mb in the Windows version, but only ~10 mb in the DOS version, yet the game seems to look and play exactly the same with both sets of files using your 32-bit DOS DJGPP binary of SDLPal from 15-Mar-2026 (which has an uncompressed size of 6.01 Mb).

Thank you very much! Your feedback is very important. It looks like we might have to raise the minimum system requirements to a P3 1GHz processor.

Regarding the information you provided:
1. This game is designed to run only at a resolution of 320x200. While it is possible to upscale the resolution on modern platforms using GLSL filters, this is not possible with the DOS version. Of course, the rendered image can be scaled up for output, but for compatibility reasons, 320x200 is the safest option for DOS.
2. Open sdlpal.cfg, and check the following options:
UseSurroundOPL=0
Music=RIX
OPLCore=REAL
If everything is working properly, you should hear the FM background music. Additionally, in the OPL3 software emulation mode for SBEMU and VSBHDA/VSBCMI, you can use `UseSurroundOPL=1`. If it still doen not work, please tell us.
3. Are there any screenshots? Are you using the romhacking version of the patch?
4. We have essentially only implemented translation for the text portions. Text in bitmaps and videos is currently left as-is.
5. AVI files were only available in the 1997–1998 Windows versions; the DOS version does not include these videos. However, the Windows version still retains the corresponding animations from the DOS version, which SDLPal can support.
6. Does this happen every time you exit the game? Also, will using Alt+F4 to exit cause any issues?
7. Yes, the original DOS version of this game was released on floppy disk. The later DOS CD version had some animations added and included some CD audio tracks.

There are still some differences between the DOS version and the Windows version, both in terms of data structures and game design.

zyzzle wrote on 2026-03-19, 13:58:

I was able to run Diablo on bare metal DOS with a compiled DOS DJGPP SDL binary on the same system as above and it plays well, b […]
Show full quote

megatron-uk wrote on 2026-03-19, 08:26:

I'd love to see some more examples of the libSDL Dos version, many of us have been awaiting it for years... though it sounds like there is some substantial resource requirements to it.

Might have to download that libSDL fork and try it myself.

I was able to run Diablo on bare metal DOS with a compiled DOS DJGPP SDL binary on the same system as above and it plays well, but it is far too dark. Something with the gamma is screwed up, which I'm sure is buggy code in the SDL port. This can be partially compensated for by raising the brightness within the game (it has a brightness adjustment setting), but then it gets washed out. The source needs to be analyzed and brightness gamma bug fixed.

However, the SDLPal SDL binary for DOS played with perfect brightness (Gamma 2.2?) and wasn't dark at all.

These were both played on bare metal DOS, of course.

The SDL port for DOS is huge news. I am also hoping more SDL games get ported to DOS. Any news on this end will be greatly appreciated!

We haven't encountered any issues with colors being too dark in SDLPAL DOS. I'm not sure if this has anything to do with the fact that it enforces the RGB888 format.

Could you please post the contents of your SDLPAL.CFG file and provide the log files?
In order to write debug data to a text file, these two items should be in SDLPAL.CFG:
LogLevel=1
LogFileName=log.txt

Please note that it will write some of your system info and lots of gameplay data to the text file.
Also, it will significantly increase performance requirements.
So it is intended for testing purposes only. Remove these items after the test.

PalMusicFan wrote on 2026-03-19, 14:30:

2. Open sdlpal.cfg, and check the following options: UseSurroundOPL=0 Music=RIX OPLCore=REAL If everything is working properly, […]
Show full quote

2. Open sdlpal.cfg, and check the following options:
UseSurroundOPL=0
Music=RIX
OPLCore=REAL
If everything is working properly, you should hear the FM background music. Additionally, in the OPL3 software emulation mode for SBEMU and VSBHDA/VSBCMI, you can use `UseSurroundOPL=1`. If it still doen not work, please tell us.
3. Are there any screenshots? Are you using the romhacking version of the patch?

Thank you for your suggestions. I followed 2 above and now OPL music works very well in pure DOS with SBEmu loaded. That makes the game even more wonderful. When I modified sdlpal.cfg as directed, the game no longer crashes upon exiting. I tried over a dozen times, and it no longer freezes my system when I quit (Alt-F4) or press "Q". The DOS prompt returns as normal.

I pressed ramdom keys until I got the game to take a screenshot, which I've posted below. What is the exact key which takes a screenshot in SDLPal DOS? I thought possibly F12 but am not sure? You may see in the screenshot that some spells contain Chinese characters, but most are in English. Yes, I used the exact romhacking English patch you gave above. I overwrote the DOS PAL files and made sure sdlpal.cfg contains MessageFileName=m_eng.txt

PalMusicFan wrote on 2026-03-20, 04:00:

We haven't encountered any issues with colors being too dark in SDLPAL DOS. I'm not sure if this has anything to do with the fact that it enforces the RGB888 format.

Attached are the requested logs.

Note that SDLPal DOS was never too dark for me. It is perfect brightness, very bright. There is no problem there. I am sorry for the confusion.

The game that's too dark is the Diablo port for DOS - a totally different DOS SDL implementation. This uses the DevilutionX Diablo codebase for its DOS port to DJGPP. This SDL port is discussed on:

https://www.high-voltage.cz/sortky/diablo-po- … stupny-pre-dos/

zyzzle wrote on 2026-03-20, 08:45:

PalMusicFan wrote on 2026-03-19, 14:30:

2. Open sdlpal.cfg, and check the following options: UseSurroundOPL=0 Music=RIX OPLCore=REAL If everything is working properly, […]
Show full quote

2. Open sdlpal.cfg, and check the following options:
UseSurroundOPL=0
Music=RIX
OPLCore=REAL
If everything is working properly, you should hear the FM background music. Additionally, in the OPL3 software emulation mode for SBEMU and VSBHDA/VSBCMI, you can use `UseSurroundOPL=1`. If it still doen not work, please tell us.
3. Are there any screenshots? Are you using the romhacking version of the patch?

Thank you for your suggestions. I followed 2 above and now OPL music works very well in pure DOS with SBEmu loaded. That makes the game even more wonderful. When I modified sdlpal.cfg as directed, the game no longer crashes upon exiting. I tried over a dozen times, and it no longer freezes my system when I quit (Alt-F4) or press "Q". The DOS prompt returns as normal.

I pressed ramdom keys until I got the game to take a screenshot, which I've posted below. What is the exact key which takes a screenshot in SDLPal DOS? I thought possibly F12 but am not sure? You may see in the screenshot that some spells contain Chinese characters, but most are in English. Yes, I used the exact romhacking English patch you gave above. I overwrote the DOS PAL files and made sure sdlpal.cfg contains MessageFileName=m_eng.txt

Where did you get the game data? And the save files? It seems you have some spells which are not in the character's spell list. Since these spells should not appear in the players' item box, the translators did not translate them. But technically they could be translated.
You were using sdlpal.cfg from the English patch, right? Then we will take a look at why it caused the problem when exiting game.
Oh, we know the DevilutionX DOS version, as well as the dark graphic issue. We are just guessing why this issue appears.

PalMusicFan wrote on 2026-03-20, 10:57:

Where did you get the game data? And the save files? It seems you have some spells which are not in the character's spell list. Since these spells should not appear in the players' item box, the translators did not translate them. But technically they could be translated.
You were using sdlpal.cfg from the English patch, right? Then we will take a look at why it caused the problem when exiting game.
Oh, we know the DevilutionX DOS version, as well as the dark graphic issue. We are just guessing why this issue appears.

The game data I'm using is from the 1995 DOS release:
https://archive.org/download/legend_of_sword_and_fairy_dos

The save game files were modified with trainer from old DOS site to maximize character traits and spells.

The sdlpal.cfg I'm using is the one I uploaded above. With this sdlpal.cfg, my freezing problem on exiting the game is completely eliminated. The freezes stopped when I modified it as you directed above to enable the OPL music.

zyzzle wrote on 2026-03-20, 23:30:

The game data I'm using is from the 1995 DOS release: https://archive.org/download/legend_of_sword_and_fairy_dos […]
Show full quote

PalMusicFan wrote on 2026-03-20, 10:57:

Where did you get the game data? And the save files? It seems you have some spells which are not in the character's spell list. Since these spells should not appear in the players' item box, the translators did not translate them. But technically they could be translated.
You were using sdlpal.cfg from the English patch, right? Then we will take a look at why it caused the problem when exiting game.
Oh, we know the DevilutionX DOS version, as well as the dark graphic issue. We are just guessing why this issue appears.

The game data I'm using is from the 1995 DOS release:
https://archive.org/download/legend_of_sword_and_fairy_dos

The save game files were modified with trainer from old DOS site to maximize character traits and spells.

The sdlpal.cfg I'm using is the one I uploaded above. With this sdlpal.cfg, my freezing problem on exiting the game is completely eliminated. The freezes stopped when I modified it as you directed above to enable the OPL music.

The screenshot key is P. However, there's currently an issue with how screenshot files are named—they're only labeled with the date, so new screenshots taken on the same day will overwrite the old ones.
Also, if you have time, would you please test this configuration:
LogLevel=0
LogFileName=log.txt
And there will be two txt files there, sdl_log.txt and log.txt. We would like to check these two files. Thank you so much!
What is your sound card? Intel HDA + SBEMU? If so, UseSurroundOPL=1 works for you. The stereo music is pretty good.

zyzzle wrote on 2026-03-19, 13:58:

I was able to run Diablo on bare metal DOS with a compiled DOS DJGPP SDL binary on the same system as above and it plays well, but it is far too dark. Something with the gamma is screwed up, which I'm sure is buggy code in the SDL port.

This very much sounds like a software mix-up between 6-bit color (which is what typical VGA cards use for color entries in their hardware palette) and 8-bit color. Or alternatively, it could be a newer graphics card implementing a hardware palette by using the full 8 bits instead of only the lowest 6 - this is supported in the VESA standard but games rarely checked for it and nearly always assumed the color entries were 6-bit.

Thanks for information about "P" capturing screenshots. That explains why I was only ever able to get a single screenshot no matter how many times I tried! The file is named something like 20260321.bmp which is the max DOS 8.3 character limit. Perhaps modify code to make it something like: 26032100.bmp to 26032199.bmp (or in mmddyy format which would be 03212600) which would allow for 100 screenshots per day!

Yes, I have Intel HDA + SBEMU sound. Even the mono music is good; I can't wait to try the stereo. Thanks for your hints and help.

I'll modify sdlpal.cfg as you specified and re-post my new logs when I get a chance (this will be in 2-3 days, as I'm out of town now and that system with SDLPal DOS is at home).

I'm surprised there hasn't been more commentary in this topic. The game is outstanding!

jmarsh wrote on Today, 02:10:

This very much sounds like a software mix-up between 6-bit color (which is what typical VGA cards use for color entries in their hardware palette) and 8-bit color. Or alternatively, it could be a newer graphics card implementing a hardware palette by using the full 8 bits instead of only the lowest 6 - this is supported in the VESA standard but games rarely checked for it and nearly always assumed the color entries were 6-bit.

Sounds like it, but when I run 6bitDAC.com to "fool" my 8-bit DAC onboard vbios (Intel HD graphics using 64 mb onboard system RAM) to using the 6-bit color, the darkness palette problem still persists, and when I exit Diablo, *all* DOS programs (even text-based ones) remain very dark until I reboot the system. It's like a persistent gamma bug which darkens the gamma permanently.

Again, this problem thankfully doesn't happen with the SDL implementation that SDLPal Dos uses. It's a relief the the brightness is perfect in the DOS port.