Add MSDOS Dosbox libretro core

[salvadorc17]

I have made some test, and seems links properly exe files, also deals with 16mb ram size.

[salvadorc17]

Ram seems very tricky and extensive for this system

[Jamiras]

I have no idea what you're playing around with there. RALibRetro 1.20? we're only on 1.1.

I briefly tried loading three very simple DOS games: AlleyCat, King's Quest I, and Beast. All three resulted in "Game load error.". After digging into the code, this was because the Core says it can be started without content and we ignore cores that do that. After disabling that code, all three games generated hashes, but none of them did anything beyond show a black screen.

Assuming the games did load, RALibRetro doesn't currently have keyboard (or mouse) support. There's a very limited number of DOS games that are joystick only.

Prince of Persia did load, but I couldn't get it to recognize anything but "DPAD left" on my joystick and one button. As a result, it was completely unplayable.

Additionally, hashing the executable is just a coincidence. If you launched a bat file instead of the executable, that would be hashed instead, and we don't want to be hashing batch files.

Most DOS games only use 640KB or less of memory. To use more than that they have to run through an extender - typically DOS4GW - which is an executable by itself, and we don't want to be hashing that either.

Since this was opened as an issue instead of a pull request, I see no harm in leaving it here, but in my opinion, we are a long ways away from being able to support DOS.

[salvadorc17]

Update here, now dosbox core has enabled achievements support, and tested working good so far, still need to deal with the "No content to load error"

[Jamiras]

From a recent discord discussion:

DOS has a lot of gotchas. Hashing the right thing is just one. DOS covers ~30 years of functionality piled on top of itself. The first DOS machines had 64KB of RAM or less, and anything that uses more than 640KB has to go through an extended memory manager, which is also an executable, and one we probably don't want to hash.

You can't convince me that a 8MHz 8088 PC with 64KB of RAM and a single 5¼" drive is identical to a 400MHz Pentium II with 8MB of RAM, a 3½" drive, a hard drive and a CD-ROM.

Additionally, you have to worry about TSR programs. Some like ANSI.SYS are required for certain games, but most are cheat programs. moslo.com can be required to make some of the oldest games playable on the default dosbox configuration, but using it on later games could be considered cheating.

Many games can be launched with optional parameters to modify behavior.

And we have to potentially support both disk swapping and hard disk support. Some games have different releases depending on if they were released on 3½ or 5¼ disks, and others have CD releases. Many games also support full or partial hard drive installation.

It's almost like supporting the entire Nintendo console family as a single entity.

Additionally, Windows 3.1 is a DOS program. But I don't even want to contemplating supporting that through the DOS core.

[leiradel]

Sorry if this is naïve, but here's an idea.

Maybe Retro Achievements could have its own set of DOS games, with images already configured and snapshots that put the player at the very start of the game, using settings appropriate to the achievements set.

RALibretro would then load the core, open the game using the Retro Achievements ZIP, and immediately load a snapshot from the same ZIP. The hash could be computed from the snapshot, this would not only identify the game in Retro Achievements, but also make sure everyone plays with the same settings. The same thing could be done with autoexec.bat and config.sys, maybe the final hash should be the hash of the snapshot and those two files to make sure no TSRs that enable cheats have been loaded.

[meleu]

I wouldn't like to discourage the DOSBOX enthusiasts, but adding support for DOSBOX is too much effort for little return.

As we can see by the posts above :point_up_2:, it's not just a matter of simply adding a core to RALibretro. It would also bring a lot of work for RA staff to keep things with a minimum acceptable quality. Example:

• a solid documentation to guide people wanting to play it (and it would require a person with a good knowledge about this subject AND good writing skills).
• also a good documentation for achievement creators.
• provide support for people having problems with configs (because most of people don't read the docs).
• dealing with cheaters (adding preventive measures, dealing with accusations and such)
• uploading files to the server to make them available for players.
• make sure it would be playable on RetroArch.
• etc...

Also, just a small niche in our user base (which is already a niche) would really care enough to play it.

I'm sure that there are awesome games to play with DOSBOX, but, again, adding support for it would require too much effort (from many people) for little return.

[leiradel]

@meleu I believe my proposal above would take care of some of these issues, no?

[Jamiras]

DOS games typically modify data in their storage space. Anything that would be stored in SRAM on other systems is written to the disk next to the executable. We have to ignore that data when calculating the hash.

Apple II gets around this by creating a mutable copy of the disk and using that as the SRAM image. The original unmodified disk is used to calculate the hash, and everything else occurs on the copy. This doesn't prevent an overly savvy player from making unauthorized modifications to the copy, but that's basically the same as hacking the SRAM file on any other system.

We could do something similar for DOS, but DOSBox expects most of its content to be run from folders on the hard disk. An installed game could be as large as a CD (if installed from a CD), or potentially larger (for multi-CD games). Creating a clean image of something so large would be impractical.

My current idea is to assume whatever the user is launching (bat, com, exe) is in the base folder for the game, and hash all the com and exe files in that directory (including setup.exe, emm386.exe, and whatever other utility executables are present). This would capture any extra executables, which we would assume to be cheating tools, and ignore any SRAM-type modifications.

If that's not robust enough (hash collisions or for additional protection), we can have the resolvehash API return possible game IDs with additional files to hash, instead of just returning an exact match ID. This would, of course, require additional API/server support.

Of course, that would only address the hashing issue. It wouldn't prevent TSR programs launched from other folders, or additional parameters passed to the executable. DOOM famously has many command line parameters. Things like -nomonsters should obviously be considered cheating.

[leiradel]

Again, I believe that if a snapshot is loaded after the game, it would ensure that no cheats were employed, and that the game was started with the same command line parameters for all players. The achievements developer for a particular game would be responsible for creating such a snapshot right when the game starts in DOSBox, and it should be made available for download and used together with the game data, maybe by adding it to the game ZIP, or by putting it side by side with the game data with the same file name. The hash would be provided by the snapshot.

[FluffyEmmy]

adding support for DOSBOX is too much effort for little return.

More things supported is always fun. https://www.bountysource.com/issues/82645480-add-msdos-dosbox-libretro-core

[Jamiras]

Ah, I missed the fact that you were suggesting the inclusion of a memory snapshot in the game zip. I was distracted by the idea of distributing an approved game image. That's something we don't do for other systems due to legal ramifications, and hosting them would be undesirable for larger games from the later era of DOS gaming.

Maybe we could do some sort of hybrid thing where the game data is hashed first, and on successful resolution, the save state could be downloaded (or verified from local cache) and activated. It's an interesting solution.

[leiradel]

Yeah I agree that it's important to make sure the snapshot is compatible with the game data, otherwise a lot of users will become frustrated when they can't play a game because it will crash trying to load stuff from the disk image that is not in the correct location, or is from a different version of the game and has a slightly different format etc.