SDL Now Supports DOS

Jayschwa 243 points 99 comments April 24, 2026
github.com · View on Hacker News

Discussion Highlights (16 comments)

ronsor

All that's left now is SDL for UEFI, and then all our games can run in a pre-OS environment.

raverbashing

Well I guess Allegra was a bit old already /s

jan_Sate

Uhm... excuse me? Why? Is there anyone even using DOS for anything serious these days?

alnwlsn

This is an especially funny screenshot as DosBOX itself is built on SDL.

Dwedit

Technically this already worked with HXDOS, which emulated DirectDraw well enough that SDL could use it.

vunderba

Awesome. I wonder how this would work with a 386+ targeted MS-DOS executable from FreeBASIC, which supports binding to SDL. [1] - https://github.com/freebasic/fbc

jlokier

Perfect! I was just doing some Turbo C development inside DOSBox-X inside Debian GNU/Linux inside VMware Fusion inside macOS this morning.

shevy-java

Good - now we can play more DOS games again!

looneysquash

For a open source project like SDL is, for something like this, it's usually a matter of how invasive it is, and how likely the contributors seem to stick around and maintain it. Different projects have different policies, and I don't know what SDLs is. But they already have a lot of ports, so I trust they know what they're getting themselves into.

vintermann

SDL getting back to its Loki roots

whobre

Love it! Now, let's port it to CP/M (via GSX, maybe?)

klik99

Awesome. Why? But awesome. There does not need to be a reason why

flykespice

I'm more impressed by the fact they accepted it upstream, specially for an OS target that is long gone from the market and has virtually no users. Usually upstream projects would reject such PRs under the reason they just increase maintenance cost with little to no benefit to the userbase.

TacticalCoder

> Input: ... gameport joystick via BIOS INT 15h with auto-calibration Joystick calibration: what a blast from the past! Blast from the past I encountered recently... Joysticks had to be "calibrated" and it was something you had to do for each game that supported joysticks. These would give back analog values and they'd depend on the phases of the moon or the room temperature or both. I'm not making this up: this was a serious pain point both for players and coders. FWIW in that DOS game of mine from 1991 or so for which I still had the .ASM source code files (about 30 000 lines of assembly code, 15 000 of which were auto-generated code to do very fast sprites drawing in the VGA 320x200 "tweaked" mode) and which I managed, at long last, to get to compile again a few days ago thanks to UASM (and quite some LLM help), I found lines like these: ul_corner_ch: db 63,"PUT YOUR JOYSTICK IN THE UPPER LEFT CORNER AND PRESS A BUTTON " lr_corner_ch: db 63,"PUT YOUR JOYSTICK IN THE LOWER RIGHT CORNER AND PRESS A BUTTON " p1_choose: dw 1 ;1 keyboard 2 joystick p2_choose: dw 0 ;0 none 1 keyboard 2 joystick And basically a 350 lines assembly file only for joystick calibration . So you can understand that "auto-calibration" as in TFA is quite a selling point!

cmxch

Wait, it didn’t already or am I confusing it with the VESA support on Linux?

qsera

Awesome! This makes me really happy.

Semantic search powered by Rivestack pgvector
5,498 stories · 51,880 chunks indexed