Porting SDL to DOS

Hello, I am in the process of porting SDL to DOS. Would a DOS backend be considered for acceptance into the upstream project? If not, I will go on my merry way. If yes, implementation and process questions will follow. :slightly_smiling_face:

I am the current owner of the Catacomb game series. My goal is to port the games to modern platforms, but also preserve DOS compatibility. DOS support in SDL will be a huge win for me. I suspect it could be useful for others in the retro game community as well.

My in-progress port is built with a DJGPP cross-compiler. The video subsystem uses VESA BIOS Extensions for linear framebuffer support. I have some of the simpler drawing tests working (e.g. chessboard, spriteminimal, streaming), but I’ve still got a lot of work to do, including input subsystems.

Regards,
Jay

DOSBox is built on SDL IIRC. That would be amusing, to have SDL running on DOSBox, running on SDL…

DOSBox is built on SDL IIRC. That would be amusing, to have SDL running on DOSBox, running on SDL…

SDLception

to add more confusion: Dosbox is built on SDL 1.2, imagine SDL 2 running on DOSBx, running on SDL 1.2…

This would be really great: I currently maintain an Allegro gfx backend just for DOS, SDL handling other platforms. If I could have only SDL I could dump a big pile of legacy code.

1 Like

I will point out that DOSBox-staging, which is a cutting edge build, uses SDL 2.0 more-or-less happily.

DOS can’t really access hardware acceleration as it would require some kind of driver. The only ones of the era were VESA (not accelerated) and Glide (3dfx, long dead).

There is some logic in wiring a DOS build for software rendering, but the code for doing so is a lot simpler on SDL 1.2.

I think it would be better if an application that wants to support DOS links with SDL 1.2 instead of 2.0. It wouldn’t be too hard to abstract basic functions away from both versions, so it can build against either.

@sam-itt, is the application you mentioned publicly available? It sounds like a good candidate for exercising my port once it’s further along. I have not worked on it in the past month, but you can find the port on GitHub in a dos branch. I should note that the commit history is not stable since it is a development branch that I occasionally rebase.

Currently, I have working video, keyboard events, and mouse clicks in DOSBox. Mouse position and cursor support is still a work-in-progress. Video currently requires VESA BIOS Extensions (VBE) version 2 for linear framebuffer support. This made it easy to get video bootstrapped, but I would like to increase compatibility eventually. It seems that SDL2’s 2D API does not currently support 8-bit paletted framebuffers, so that would have to be tackled in order to make something like VGA mode 13h a viable option.

I have yet to get the port working in FreeDOS in VirtualBox. VBE calls fail even though VBE is reported as being available when queried. I have not spent much time investigating it.

I don’t plan to add support for the sound subsystem at this time. Catacomb 3D used PC speaker and AdLib, neither of which would map well into SDL’s sound API as far as I can tell.

Yes it is: github repo.

Thank you for the link, I’ll look into that when I resume working on Teo on fall. I’m currently busy on another project and the next timeslot for Teo is fall.

What you’ve got already working is clearly great. I will be needing sound but I think that I could be able to adapt code from Allegro4 to your SDL dos version even in the form of a DOS-centric SDL extension that don’t follow the official SDL sound API (I only need to play 8 bits PCM afterall).