WOW WOW WOW WOW!!! The manual for this game was one of the best, if not the best, I’ve seen, read, and not fully understand as my teen mind was coping with the awesome graphics and gameplay. Loved this game to shreds!!!! I’m really sorry I lost the manual :-(
> 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.
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.
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.
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.
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.
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
Super interesting project, however I do not believe that striving for producing 100% identical binaries worth it. They themselves seem to have already deviated from that, by producing a combined binary.
In the absence of some formal proof of equivalence, an identical binary is the only way to prove that you've written code that is functionally equivalent to the original source code.
So I can definitely see the appeal of the idea, as daunting as it seems.
Projects that aim for perfect decompilation (i.e. producing a source tree and build instructions that recreates the original artifacts bit-for-bit) like the one for Super Mario 64 are essentially preservation projects in spirit. The advantage with that approach is that once it is done, you can be sure that you didn't introduce any changes or bugs compared to the original release. They can also be a starting point for ports or mods.
Not all projects aim for that. Some like REDRIVER2 (for Driver 2) retains the core of the original game, but with bug fixes and quality of life improvements bordering on a full-blown PC remaster. It obsoleted the original PlayStation release with its atrocious framerate and embarrassingly low draw distance.
Heck, in my own reverse-engineering/decompilation project I went for a highly unconventional approach where I delink the original PlayStation executables into relocatable object files and attempt to relink them as a Linux MIPS program. The idea was to do a Linux port on the cheap, which I can then rewrite piece by piece in C until I don't have any MIPS object files left, at which point I could port the source tree to modern architectures. The first part panned out but not the second one (too many issues to sort out), so instead I think I'll rewrite the game piece by piece while staying on the PlayStation platform.
Decompilation projects are essentially bespoke, one-off R&D projects. The closest to a standard would be decomp.me, but that is geared towards perfect decompilation only. Step outside that and you're basically on your own, writing your own tooling in a barren landscape where everyone do things their own way.
