Skip to content

Add DOS platform support (DJGPP)#15377

Merged
icculus merged 53 commits into
libsdl-org:mainfrom
diasurgical:sdl3-dos
Apr 23, 2026
Merged

Add DOS platform support (DJGPP)#15377
icculus merged 53 commits into
libsdl-org:mainfrom
diasurgical:sdl3-dos

Conversation

@AJenbo
Copy link
Copy Markdown
Contributor

@AJenbo AJenbo commented Apr 13, 2026

This is the combined work of @icculus @madebr @glebm @jayschwa @ccawley2011 and me rounding it off with stability fixes and missing features, thanks to everyone for pitching in.

image

This is a fairly complete port to DOS with only minor features like audio recording missing. I have tested it extensively with DevilutionX in DOSBox. But no real hardware testing. The features I didn't add is mostly because I didn't have a good way to test that they worked correctly.

For threading I took some conceptual inspiration from the PS2 port.

What's supported

  • Video: VGA and VESA 1.2+ framebuffer, RGB, and 8-bit indexed color with VGA DAC palette programming, hardware page-flipping with vsync, VBE state save/restore on exit
  • Audio: Sound Blaster 16 (16-bit stereo, up to 44.1 kHz), Sound Blaster Pro (8-bit stereo, up to 22 kHz), Sound Blaster 2.0/1.x (8-bit mono), all via IRQ-driven DMA with double-buffered auto-init
  • Input: PS/2 keyboard with extended scancodes (0xE0 prefix), INT 33h mouse with queried sensitivity, gameport joystick via BIOS INT 15h with auto-calibration
  • Threading: Cooperative scheduler using setjmp/longjmp with stack patching. Real mutexes, semaphores, TLS, and condition variables (generic fallback). Yield points in the event pump and delay functions keep audio and other threads responsive.
  • Timer: Native PIT-based timer using DJGPP's uclock() at ~1.19 MHz resolution
  • Filesystem: GetBasePath / GetPrefPath via DJGPP's searchpath(), POSIX filesystem ops fallback
  • Build: CMake cross-compilation toolchain file, DJGPP CI job, preseed cache for faster configure

What's NOT included

  • Audio recording playback only
  • SDL_TIME native implementation reuses Unix gettimeofday via DJGPP's POSIX layer (works fine)
  • Shared library loading support (no SDL_LoadObject).

How to build

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

icculus and others added 30 commits April 13, 2026 08:50
Seeking breaks otherwise. We might be able to just fflush() before or seeking
instead?
Turns out DosBox-X was having trouble with the Sound Blaster or something;
standard DosBox works correctly directly from the interrupt handler, and
without doubling the buffer size.
This is MUCH faster than just leaving buffering disabled, and also works
around getting bogus reads after an fseek. SDL_LoadWAV on test/sample.wav
no longer takes several seconds to finish, and comes up with the correct
data.

I wonder if we're triggering this in LoadWAV because we're malloc'ing data
between seeks/reads, and it's causing the djgpp transfer buffer to change. Or
maybe the Fat DS trick is confusing it? I don't know, I haven't had time to
debug it, it might just be a legit libc bug in djgpp too, for all I know.
This uses an old trick we used in SDL 1.2 for MacOS Classic, which did its
audio callback in a hardware interrupt. If the audio is locked when the
interrupt fires, make a note of it and return immediately. When the lock is
released, if the interrupt has been fired, run the audio device iteration
right then.

Since there isn't a big device lock in SDL3 (available to the app, at least),
this keeps a counter of when any SDL_AudioStream is locked, which is probably
good enough.
This uses VESA interfaces to manage the display and works with the software
renderer.

Events aren't hooked up yet, so prepare to close DosBox on each run.  :)
This gets most of the rendering examples, which use SDL_GetBasePath() to
find textures to load, working.
Of course Quake 1 solved this better, haha. It's smart: less memory, dirt
simple, and you don't even have to worry about synchronizing with the
interrupt handler, because it's safe for both sides no matter when an
interrupt fires.
[sdl-ci-filter djgpp]
[sdl-ci-artifacts]
- SDL_runapp.c: Add SDL_PLATFORM_DOS to the exclusion list so the
  generic
  SDL_RunApp() is disabled when the DOS-specific one is compiled.
- SDL.c: Exclude SDL_Gtk_Quit() on DOS. DJGPP defines __unix__ which
  sets
  SDL_PLATFORM_UNIX, but DOS has no GTK/display server. The GTK source
  is not compiled (CMake UNIX is false for DOS) so this was a link
  error.
- sdlplatform.cmake: Add DOS case to SDL_DetectCMakePlatform so the
  platform is properly detected from CMAKE_SYSTEM_NAME=DOS.
- i586-pc-msdosdjgpp.cmake: Add i386-pc-msdosdjgpp-gcc as a fallback
  compiler name, since some DJGPP toolchain builds use the i386 prefix.
- Implement double-buffered page-flipping for VBE modes with >1 image
  page
- Save and restore full VBE state on video init/quit for clean mode
  switching
- Improve DOS keyboard handling: support extended scancodes and Pause
  key
- Lock ISR code/data to prevent page faults during interrupts
- Always vsync when blitting in single-buffered modes to reduce tearing
Move audio mixing out of IRQ handler to main loop for improved
stability and to avoid reentrancy issues. Add SDL_DOS_PumpAudio
function, update DMA buffer handling, and adjust sample rate to 22050
Hz.
Silence stale DMA buffer halves to prevent stutter during load.
Detect SB version and select 8-bit mono or 16-bit stereo mode.
Handle DMA and DSP setup for both SB16 and pre-SB16 hardware.
Add FORCE_SB_8BIT option for testing in DOSBox.
- Poll Sound Blaster DSP status instead of fixed delay after speaker-on
- Clarify DPMI conventional memory is always locked; update comments
- Document and justify DMA memory allocation strategy
- Free IRET wrapper after restoring interrupt vector to avoid leaks
- Throttle joystick axis polling to ~60 Hz to reduce BIOS timing loop
  cost
- Always poll joystick buttons directly for responsiveness
Implement banked framebuffer access for VBE 1.2+ modes without LFB.
Detect and initialize banked modes, copy framebuffer data using bank
switching, and blank the framebuffer on mode set. Page-flipping is
disabled in banked mode.
@AJenbo
Copy link
Copy Markdown
Contributor Author

AJenbo commented Apr 23, 2026

Only thing is the cursor not being transparent.

Fixed

@icculus
Copy link
Copy Markdown
Collaborator

icculus commented Apr 23, 2026

Worry about cursor later?

@AJenbo
Copy link
Copy Markdown
Contributor Author

AJenbo commented Apr 23, 2026

Worry about cursor later?

To late I already fixed it :D

(I fixed it by using an unoptimized, version for RGB modes, and yeah lets worry about optimizing that til later. It should be correct in both RGB and INDEX8 (what @ccawley2011 had issues with originally) now, slightly better performance on XRGB1555 and RGB565 is very minor I think)

@palxex
Copy link
Copy Markdown

palxex commented Apr 23, 2026

A question: due to https://www.vogons.org/viewtopic.php?f=63&t=57420 , some Nvidia GPUs' 4f07(SetDisplayStart) not works well, though it reports. In my test the range maybe even bigger, up to 3060, down to 9300(not be complete, as we can only test on owed GPUs). In test I also observed the display problem in our project. But disabling features based on GPU vendor in SDL seems unwise; maybe we need a new hint to let users control page_flip_available directly?

@icculus
Copy link
Copy Markdown
Collaborator

icculus commented Apr 23, 2026

We can add that later (unless @AJenbo has already pushed it while I'm typing this, haha).

@icculus icculus merged commit a8ecd67 into libsdl-org:main Apr 23, 2026
46 checks passed
@icculus
Copy link
Copy Markdown
Collaborator

icculus commented Apr 23, 2026

Too late, it is merged! :)

Excellent work, @AJenbo. You went above-and-beyond on this work.

(Thank you to everyone else, too!)

I'm considering this a 3.6.0 feature, so let's not cherry-pick it to 3.4.x.

@AJenbo AJenbo deleted the sdl3-dos branch April 24, 2026 01:23
@AJenbo
Copy link
Copy Markdown
Contributor Author

AJenbo commented Apr 24, 2026

A question: due to https://www.vogons.org/viewtopic.php?f=63&t=57420 , some Nvidia GPUs' 4f07(SetDisplayStart) not works well, though it reports. In my test the range maybe even bigger, up to 3060, down to 9300(not be complete, as we can only test on owed GPUs). In test I also observed the display problem in our project. But disabling features based on GPU vendor in SDL seems unwise; maybe we need a new hint to let users control page_flip_available directly?

If you enable SDL_HINT_DOS_ALLOW_DIRECT_FRAMEBUFFER that probably isn't relevant.

@Dubnium32x
Copy link
Copy Markdown

Is there a discord to participate in this???? I'm very interested in making dos games happen with raylib. 👀👀👀

@slouken
Copy link
Copy Markdown
Collaborator

slouken commented Apr 25, 2026

Is there a discord to participate in this???? I'm very interested in making dos games happen with raylib. 👀👀👀

Yep!
https://discord.com/invite/BwpFGBWsv8

@PalMusicFan
Copy link
Copy Markdown

Congratulations! SDL3 for DOS is an amazing achievement!

We quickly adapted our game port with it, and all core systems are working, including the long-awaited audio thread, and the sound effects are very good!

However, there is a speed issue with the Ad Lib FM BGM now. Our project mainly uses Ad Lib music and MIDI as BGM, and we hope to use sound card hardware under DOS to reduce CPU load. May I ask if there is a clock mechanism with a relatively high frequency (39Hz or above) that is more stable and minimally affected by CPU load? Or should we change our approach? Thank you!

Congratulations again!

@AJenbo
Copy link
Copy Markdown
Contributor Author

AJenbo commented Apr 26, 2026

The timer runs at 1.19Mhz and should be precise. A software midi player will probably be very intensive on the CPU, we can probably get MIDI music working vis OPL in SDL mixer, I have some basics working.

@PalMusicFan
Copy link
Copy Markdown

The timer runs at 1.19Mhz and should be precise. A software midi player will probably be very intensive on the CPU, we can probably get MIDI music working vis OPL in SDL mixer, I have some basics working.

1.19MHz? Wow, I think it should be precise enough. I need to take a look...

BTW, not just MIDI. we use a custom AdPlug to play BGM, directly operating the OPL2/3.

@PalMusicFan
Copy link
Copy Markdown

PalMusicFan commented Apr 26, 2026

The timer runs at 1.19Mhz and should be precise. A software midi player will probably be very intensive on the CPU, we can probably get MIDI music working vis OPL in SDL mixer, I have some basics working.

We checked the code, and indeed, the timer is fine, but how can we achieve a callback with a frequency higher than 19.8Hz 18.2Hz?

EDIT: Sorry, it is 18.2Hz.

@AJenbo
Copy link
Copy Markdown
Contributor Author

AJenbo commented Apr 26, 2026

The timer runs at 1.19Mhz and should be precise. A software midi player will probably be very intensive on the CPU, we can probably get MIDI music working vis OPL in SDL mixer, I have some basics working.

We checked the code, and indeed, the timer is fine. But how can we implement a callback higher than 19.8Hz?

I don't know where the 19.8Hz comes from, is that your FPS? If so add some SDL_Delay(0) in your game loop to task switch more frequently then the you call the event loop.

@PalMusicFan
Copy link
Copy Markdown

The timer runs at 1.19Mhz and should be precise. A software midi player will probably be very intensive on the CPU, we can probably get MIDI music working vis OPL in SDL mixer, I have some basics working.

We checked the code, and indeed, the timer is fine. But how can we implement a callback higher than 19.8Hz?

I don't know where the 19.8Hz comes from, is that your FPS? If so add some SDL_Delay(0) in your game loop to task switch more frequently then the you call the event loop.

Oh, sorry, our mistake, it is 18.2Hz.

@AJenbo
Copy link
Copy Markdown
Contributor Author

AJenbo commented Apr 26, 2026

... ok that explains nothing.

@otonoton
Copy link
Copy Markdown

You could derive your own timer by calculating how long certain instructions take on the current CPU and then adding or subtracting more instructions to get the desired delay.

@PalMusicFan
Copy link
Copy Markdown

... ok that explains nothing.

Sorry! Now I will try to reorganize my words and hope to clarify the issue.

We implemented Ad Lib music playback using SDL_Timer, but we found that the playback speed is too heavily affected by the load on other parts of the system. For example, whenever CPU-intensive effects appear on the screen, the music speed slows down noticeably.

Therefore, we would like to use the IRQ0 ISR to play BGM, but the default frequency of 18.2 Hz is not precise enough for hardware Ad Lib music. We would like a stable clock with a higher frequency. However, as far as we know, reprogramming this frequency ourselves would cause the entire system to malfunction. What should we do?

Thank you so much!

@AJenbo
Copy link
Copy Markdown
Contributor Author

AJenbo commented Apr 29, 2026

The cheap solution is to sprinkle SDL_Delay(0) around you code, probably right before and after the code that does the heavy effect. That way you can yield to the other threads more frequently then your frame rate would other wise allow you. However if your current sound generation depends on exact timing and not just frequent timing then that won't solve it.

In that case you would have to make sure that your music thread is safe for reentry (no malloc / free) and then chain it with the existing interrupt. This is similar to how things work in the Sound Blaster driver.

@PalMusicFan
Copy link
Copy Markdown

PalMusicFan commented Apr 29, 2026

However if your current sound generation depends on exact timing and not just frequent timing then that won't solve it.

Indeed, exact timing is needed, at least enough to drive a metronome. Previous tests showed that while 18.2Hz could produce music, it sounded like a band playing with an unstable rhythm.

In that case you would have to make sure that your music thread is safe for reentry (no malloc / free) and then chain it with the existing interrupt. This is similar to how things work in the Sound Blaster driver.

Got it. Is there a specific demo available for this method? Which existing interrupt would be more suitable?
Thank you very much!

@Ghabry Ghabry mentioned this pull request May 3, 2026
hifihedgehog pushed a commit to hifihedgehog/SDL that referenced this pull request May 28, 2026
* dos: Some initial work.

* dos: Turn off buffer on stdio SDL_IOStreams.

Seeking breaks otherwise. We might be able to just fflush() before or seeking
instead?

* dos: Audio implementation using the Sound Blaster 16.

* dos: remove audio Pump interface.

Turns out DosBox-X was having trouble with the Sound Blaster or something;
standard DosBox works correctly directly from the interrupt handler, and
without doubling the buffer size.

* dos: just dump and restore the stdio buffer when seeking.

This is MUCH faster than just leaving buffering disabled, and also works
around getting bogus reads after an fseek. SDL_LoadWAV on test/sample.wav
no longer takes several seconds to finish, and comes up with the correct
data.

I wonder if we're triggering this in LoadWAV because we're malloc'ing data
between seeks/reads, and it's causing the djgpp transfer buffer to change. Or
maybe the Fat DS trick is confusing it? I don't know, I haven't had time to
debug it, it might just be a legit libc bug in djgpp too, for all I know.

* dos: Protect audio device "thread" iterations when streams are locked.

This uses an old trick we used in SDL 1.2 for MacOS Classic, which did its
audio callback in a hardware interrupt. If the audio is locked when the
interrupt fires, make a note of it and return immediately. When the lock is
released, if the interrupt has been fired, run the audio device iteration
right then.

Since there isn't a big device lock in SDL3 (available to the app, at least),
this keeps a counter of when any SDL_AudioStream is locked, which is probably
good enough.

* dos: Implemented initial video subsystem.

This uses VESA interfaces to manage the display and works with the software
renderer.

Events aren't hooked up yet, so prepare to close DosBox on each run.  :)

* dos: Whoops, forgot to add these to revision control. Core and Main support.

* dos: Wired up basic filesystem support.

This gets most of the rendering examples, which use SDL_GetBasePath() to
find textures to load, working.

* dos: Fixed compiler warning.

* dos: Initial mouse support!

* dos: Move interrupt hooking code into core/dos.

* dos: Initial keyboard support!

* dos: Use a simple ring buffer for keyboard events.

Of course Quake 1 solved this better, haha. It's smart: less memory, dirt
simple, and you don't even have to worry about synchronizing with the
interrupt handler, because it's safe for both sides no matter when an
interrupt fires.

* ci: add djgpp job

[sdl-ci-filter djgpp]
[sdl-ci-artifacts]

* dos: Fix build issues after rebase onto current main

- SDL_runapp.c: Add SDL_PLATFORM_DOS to the exclusion list so the
  generic
  SDL_RunApp() is disabled when the DOS-specific one is compiled.
- SDL.c: Exclude SDL_Gtk_Quit() on DOS. DJGPP defines __unix__ which
  sets
  SDL_PLATFORM_UNIX, but DOS has no GTK/display server. The GTK source
  is not compiled (CMake UNIX is false for DOS) so this was a link
  error.
- sdlplatform.cmake: Add DOS case to SDL_DetectCMakePlatform so the
  platform is properly detected from CMAKE_SYSTEM_NAME=DOS.
- i586-pc-msdosdjgpp.cmake: Add i386-pc-msdosdjgpp-gcc as a fallback
  compiler name, since some DJGPP toolchain builds use the i386 prefix.

* Add 8-bit palette support to DOS VESA driver

* Add VBE page-flipping, state restore, and robust keyboard handling

- Implement double-buffered page-flipping for VBE modes with >1 image
  page
- Save and restore full VBE state on video init/quit for clean mode
  switching
- Improve DOS keyboard handling: support extended scancodes and Pause
  key
- Lock ISR code/data to prevent page faults during interrupts
- Always vsync when blitting in single-buffered modes to reduce tearing

* Refactor Sound Blaster audio mixing to main loop

Move audio mixing out of IRQ handler to main loop for improved
stability and to avoid reentrancy issues. Add SDL_DOS_PumpAudio
function, update DMA buffer handling, and adjust sample rate to 22050
Hz.
Silence stale DMA buffer halves to prevent stutter during load.

* Add DOS timer support and update build config

* Add support for pre-SB16 8-bit mono Sound Blaster audio

Detect SB version and select 8-bit mono or 16-bit stereo mode.
Handle DMA and DSP setup for both SB16 and pre-SB16 hardware.
Add FORCE_SB_8BIT option for testing in DOSBox.

* Add SB Pro stereo support and simplify IRQ handler

* Add DOS joystick driver support

* Improve DOS hardware handling and clarify memory allocation

- Poll Sound Blaster DSP status instead of fixed delay after speaker-on
- Clarify DPMI conventional memory is always locked; update comments
- Document and justify DMA memory allocation strategy
- Free IRET wrapper after restoring interrupt vector to avoid leaks
- Throttle joystick axis polling to ~60 Hz to reduce BIOS timing loop
  cost
- Always poll joystick buttons directly for responsiveness

* Query and use mouse sensitivity from INT 33h function 0x1B

* Add support for VESA banked framebuffer modes

Implement banked framebuffer access for VBE 1.2+ modes without LFB.
Detect and initialize banked modes, copy framebuffer data using bank
switching, and blank the framebuffer on mode set. Page-flipping is
disabled in banked mode.

* Add optional vsync to page flipping in DOS VESA driver

* Add cooperative threading support for DOS platform

* Move SoundBlaster audio mixing to SDL audio thread

* Fix DOS platform comments and workarounds for DJGPP support

* Fix SoundBlaster IRQ handling and DMA setup for DOS

- Pass IRQ number to DOS_EndOfInterrupt and handle slave PIC EOI
- Validate DMA channel from BLASTER variable
- Correct DMA page register selection for SB16
- Improve BLASTER variable parsing and error messages
- Unmask/mask IRQs on correct PIC in DOS_HookInterrupt
- Rename SDL_dosjoystick.c to SDL_sysjoystick.c
- Include SDL_main_callbacks.h in SDL_sysmain_runapp.c
- Add include guard to SDL_systhread_c.h

* Add DOS platform options and preseed cache for DJGPP

Disable unsupported SDL features when building for DOS. Add
PreseedDOSCache.cmake to pre-populate CMake cache variables for DJGPP.

* cmake: use a 8.3 naming scheme for tests on DOS

* Apply code style

* Update include/SDL3/SDL_platform_defines.h

Co-authored-by: Anonymous Maarten <madebr@users.noreply.github.com>

* Code review clean up

- Split DOS VESA mode-setting into its own file
- Replace magic numbers with named constants
- Update copyright dates to 2026
- Substract time taken by other threads form delays

* Fix DOS bugs and improve compatibility

- Disable fseeko64 for DJGPP due to broken implementation
- Refactor DOS timer delay to always yield and avoid busy-waiting
- Fix animated cursor rendering in DOS VESA backend
- Always set display mode when creating DOS VESA window
- Work around DJGPP allowing invalid file access in testfile.c
- Bump max threads to 16
- Apply workarounds for threading tests

* Add DOS platform documentation and fix a few issues

- Fix fullscreen default resolution
- Improve best mode matching
- Fix builds on GCC older than 7.0
- Fix text input events

* Fix keyboard mapping of "*"

* Fix running, and existing, under PCem

* Apply suggestions from code review

Co-authored-by: Cameron Cawley <ccawley2011@gmail.com>

* Pre-mix audio in ring buffer and copy to DMA via IRQ thread

* Video fixes and optimizations

* DOS: Fix Intel 740 and VGA compatability

* DOS: Update readme

* DOS: Fix thread ID, get GPU name

* DOS: Cap mouse range

* DOS: Map test resources to 8.3 names

* DOS: Skip unsupported WM color modes

* Fix "windowed" resolution selection

* DOS: Hide INDEX8 modes behind SDL_DOS_ALLOW_INDEX8_MODES

* Remove SDL_HINT_DOS_ALLOW_INDEX8_MODES and order modes logically

* Don't convert cursor if dest is not INDEX8

---------

Co-authored-by: Ryan C. Gordon <icculus@icculus.org>
Co-authored-by: Anonymous Maarten <anonymous.maarten@gmail.com>
Co-authored-by: Cameron Cawley <ccawley2011@gmail.com>
Co-authored-by: Gleb Mazovetskiy <glex.spb@gmail.com>
Co-authored-by: Jay Petacat <jay@jayschwa.net>
Tested-by: Cameron Cawley <ccawley2011@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.