SDL Now Supports DOS

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

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

Note this uses DJGPP, which switches processor to 32 bit mode via DPMI. You won't get old-school experience of segmented memory, near pointers and 64KB limits everywhere.

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

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

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

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.

SDL getting back to its Loki roots

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

Awesome! This makes me really happy.

>Timer: Native PIT-based timer using DJGPP's uclock()

I want to commend Dj Delorie for doing a great job. As a poor child at that time having access to a proper compiler which could ran on my old PC which only ran DOS, was awesome and amazing.

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.

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

> 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

So you can understand that "auto-calibration" as in TFA is quite a selling point!

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

Good - now we can play more DOS games again!

Well I guess Allegra was a bit old already /s

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