[livrem]

> porting to a modern OS and potential improvements and bugfixes will be carried out under a separate project in the future.

Or just focus on DOS? Thanks to Dosbox and its various ports I don't think any other system will be as stable or support as many different platforms. Instead of having to fix bugs every six months when the modern systems inevitably change in some anoying and not backwards-compatible ways, a DOS version will just keep running everywhere.

[boricj]

DOSBox is fine for playing MS-DOS games as they were back in the day, but not if you're looking for a modern, streamlined experience.

DOS means joysticks with 4 axis and 4 buttons max, short 8.3 filenames, obsolete network protocols, SVGA graphics mode, stereo SoundBlaster 16, three button mice, basically no integration with the host system... Also, terrible SDKs and 16-bit real mode nonsense if you're the developper.

Technology has progressed over the past 30 years and DOS is firmly stuck in the 1990s. If you're decompiling a video game with the eventual objective of making improvements and bugfixes to it, you might as well port it to modern systems too. Some of these like high-definition resolutions for example will require it anyway.

[livrem]

I did not consider the problem with joysticks. Did DOS flight simulators never support any more advanced joysticks, for instance by using the MIDI-based API that some later joysticks had, that still allowed the use of the game port but with any number of axis and buttons? Was that something that only happened in Windows 95?

But Dosbox is a bit more flexible than if you had to target actual DOS only on real hardware. A DOS game can support VESA modes up to 1920x1080 (at least?) in Dosbox-X for instance. Mapping extra joystick buttons to keyboard keys sounds like it should be possible on a modern machine? Supporting ancient DOS hardware sounds like fun ("fun"?), but I think more of Dosbox as a very stable and portable virtual machine. No need to be restricted to what would realistically work on a real old DOS computer.

[rasz]

>MIDI-based API that some later joysticks had

Which ones did that? Afaik the "digital" protocol joysticks bit-banged serial communication using standard gameport pins.

[livrem]

I do not remember which models I read about that did that and never owned a gameport joystick/gamepad with extra buttons. MIDI was (de-facto) standard gameport pins and using the UART wired to the MIDI input pin was probably more convenient than to read serial signals from the buttons but I do not know how common it was to use that pin instead of the button pins.

https://retrocomputing.stackexchange.com/questions/24946/how...

[rasz]

In that thread ssokolow links reverse engineering for gravis https://github.com/prosper00/GRiP-duino and sidewinder https://github.com/MaZderMind/SidewinderInterface, both are bitbanging joystick button pins. You couldnt ship joystick relying on MIDI as people still had plain gmeport cards, not to mention some sound cards didnt support MIDI.

[livrem]

The sidewinder used MIDI for force feedback though, for models that had that: https://web.archive.org/web/20151220120836mp_/https://code.g...

Found this page that has a list of some 10 different protocols for sending digital signals from joysticks to a gameport: https://dosdays.co.uk/topics/joysticks.php Other than the sidewinder and GriP protocols I have not managed to find any specs for the other protocols. I clearly think I remember from back in the day that using MIDI for extra buttons was a thing so it may be one of those other protocols did, or it could be that I am just wrong.

[LowLevelMahn]

porting over to recent platforms is for most reversing projects the main goal and there are no modern system changes that can harm such an small code base with so few dependecies :) mostly SDL fits all needs for all relevant platforms and i think he will keep DOS compilation ability even when ported to other systems