canadacow wrote:

there are several times more games, more game versions, and more game file variations than exist within the arcade machine world. Are you willing to catalogue them for us?

If we (users) are provided the framework, a standard methodology, and a host database, we will be more than glad to provide the info... all we need is a standard tool to figure things out.

It's not that different than MAME... it has more than 3000 different drivers for a reason. The changes may be minimal, but they have checksum info for all of them.

1 - Load a ZIP as a RAM drive. 2 - Run the game from ZIP's autoexec.bat. 3 - When the emulator is closed, run a diff between t […]
Show full quote

1 - Load a ZIP as a RAM drive.
2 - Run the game from ZIP's autoexec.bat.
3 - When the emulator is closed, run a diff between the RAM drive contents and the zipfile.
4 - Write modified files to disk.
5 - when doing 1 again, check for files on disk and replace as needed

I was actually thinking of almost the same kind of thing...
Instead of having an autoexex.bat or any other bat launch the game, how about if after having parsed through the ZIP file, it gives a list of possible launch files it finds (.exe, .bat, or .com found in the root of the file), and once selected, you could tell Dosbox to always load that zipfile with that executable the next time.

Furthermore, here's a really clean way of handling diff'ed files, and even config files for each game. All we need are 3 folders, one called Games, one called Diff, and one called Config

We keep the archives ZIP files in Games. In the Diff folder, a ZIP file with the same filename as the game in "Games" is kept with obviously the diff files that game has modified in the past. Finally, in the Config folder, a text file for each game loaded in the past, the text file could be formatted in a way to keep specific autexec.bat/config.sys and DosBox specific settings.

Now in regards to the question about the indexing the games. This is not necessary, each one of us could keep a small clean setup for our games. But with the above standardized framework in place, we could then easily share our DATs that include a standard naming convention. Hell I always wished for a TOSEC-like PC Games database. This would be a swell time to go ahead with that finally! (If not already of course).

Regarding the question of loosing the data if/when the emulator crashes. True, that's a problem, but that's also a problem with any and all emulators. How about this to help solve that: Set a hotkey, so that if it's pressed in-game, it pauses the game, does a dif on the files and modifies the ZIP file stored in the "Diff" folder as necessary. So that if you're far into a game, and you're worried about DosBox crashing, you can go ahead, at the price of a few seconds take care of that.

Finally, regarding the spirit of running DOS games, I understand where that comes from, I use to be heavily into DOS like most of you here. I have however become spoiled by all sorts of other Emulators, and love their pick a game and go philosophy, while still keeping a very clean archived set of roms/disks/sets (through Goodsets, TOSEC, MAME, etc...). Furthermore, people that were always interested in playing these games but are/were intimidated by using DOS because they never had to in the past will have a much easier time in enjoying the same games we can enjoy easily. And if more people can play as they say, there's nothing wrong with that!

Benji99

Also, I know what you are saying regarding zip archives and game intentification (not unlike what MAME does), but again, there are several times more games, more game versions, and more game file variations than exist within the arcade machine world. Are you willing to catalogue them for us?

Ugh I hate that kind of attitude, well budy, I don't think you've ever of TOSEC, tosec.org, go check out what they've done so far, and yeah they probably started with one guy doing a small thing, and things started to tumble from there. The "tackle a big challenge in groups to make it easier" philosophy doesn't just apply to coding (like DosBox), it applies to everything else in life (like indexing old PC Games).

Sooo... all of that effort would be worth it to have fewer files on your hard drive, and slightly less disk space used? And the additional hassles imposed by having lots of conflicting versions (which is still a problem with MAME despite rigorous attempts at standardization)? All for a platform that doesn't readily lend itself to such abstraction anyway (let's face it, DOS was a complex beast)?

Sometimes us programmers do something just because we can come up with a clever system for doing so... but that doesn't always make it the right choice from a design perspective. All of the changes proposed to add this kind of support imply considerable added complexity... I just don't see the effort being worth the potential benefits in this case.

There are many ways to pull it off, but indeed it does not require to be a core feature and can be handled by a frontend.

The main benefit is by no means saving space, but instead catalogue games. This list is proof that it can be done because with a bit of extra work and the right tool we could submit more info (such as file information).

The configuration is a non-issue, because basically all you need is to have whoever submits it first choose a configuration (with the only requirement that it has to work with the most current Dosbox release), and that is catalogued as the default config, which is kept as a "restore point". Then, everybody can tweak at leisure but the frontend would keep the new files separated from the original collection of files.

Is there any frontend outside of dosboxfro?

On the contrary, the list actually makes my point. There are 1622 games in there presently. Now, lets say on average each of those games has 3 versions available (yes, I know some only have one, but then each Sierra game has atleast 10 versions associated with it). Now, remember that DosBox supports a wide array of hardware, and each program is different in how its configured (some use a file, some use a commandline, some only allow for autodetection). To preserve this functionality, you'll need to make a variation for each sound, video, and input selection. DosBox currently supports 8 different pieces of sound hardware. I would conservatively say that most programs on average supported 5 different kinds (Early Sierra games supported just two, Tandy and the PC speaker. On the otherhand, Xwing supports upwards of 12). Most games also had specific setups for the mouse, keyboard and joystick. The factor I will use here is 3. Some games even had different configurations depending on memory, speed settings, unprotected versions and whatnot. For this I'm going to use a factor of 1.5. Finally, DosBox supports 7 kinds of video hardware (MDA, Hercules, CGA, TGA, EGA, VGA, VESA). Conservatively, I would say most programs supported on average about 4 of these. So, to get an estimate of the number of variations you'll need, you're looking at 1622 (games) * 3 (versions) * 5 (sound configurations) * 3 (input configurations) * 4 (video configurations) * 1.5 (Misc configs) = 437940.

437,940: This is what I believe is a conservative estimate of the number of versions/checksums you're going to need in a database for your frontend to even approach completeness. Nevermind that this figure leaves out applications and more business-orientated software which themselves have their own eccentric setups. I hope you're getting my drift now that DOS games are not cartridge games.

I've said this before and I'll say it again: While I can only speak for myself, I am fairly confident you will not see such an inane feature implemented in DosBox unless you code it yourself. I know this sounds harsh, but there is a significant list of features DosBox could use long before this gets implemented. Here's a few I can think of:

16-bit Soundblaster 16 support
Heavy optimization
16-bit/32-bit VESA support
Some additional video oversampling methods
IPX networking tunneling/support (perhaps even a TCP/IP socket layer too)
Savestates

Well, I did believe you that it's not a good idea to keep one image per configuration. That's why, instead, I was suggesting keeping one default config on the database (and eventually a field with the name of the config program). The checksum check would only be applied to files that are not modified by the game or the config. For those files, we just store a default one and allow for flexibility, keeping the original default file somewhere to go back to it if needed.

But I understand that Dosbox devs have other things to look at for now. Further, a tool like this would be useful for more than just Dosbox, so it should be looked at elsewhere. Maybe the TOSEC guys, they already have a database of boot-disk images, so maybe they could index install floppies as well. I should go and ask 😀

The checksum check would only be applied to files that are not modified by the game or the config.

Then how do you intend to deal with software with install programs separate from the main application? Furthermore, how do you intend to deal with software that needs options specified at the command line?

Ok I think the ZIP feature would only work well with already installed games that are ready to be ran.

As far as I'm concerned, regarding the different soundcards and video modes, if DOSBox could choose a supported sound card or video mode for a game, I'd like it to just select the best, more recent one. VGA over VESA, Soundblaster over Tandy, etc...

The database thing, the default configs can be all worked out in time by other users.

What would need to get implemented by DOSBox natively are:

• - Loading of a zip file as a DOS directory and loading an executable file (it prompts the first time a specific game or version of a game is launched), that same prompt could also leave room for command line options if needed
  
  - Before excuting the game, grab the zip file with the diffed files, and copy them to the main game directory, in some cases over certain files
  
  - By the press of a hotkey in-game, DOSBox checks all the files in the game's directory and copies the changed files to another zip in another place
  
  - Do the same as above when quitting the emulator and clear the directory.
  
  - Keep settings for each game in a text file in a different directory. IE: Which executable to start, which autoexec.bat or config.sys file is the most optimized for this game, etc.. NOTE: This does not mean that anyone should compile a list of configs, in the beginning, we could all do our own personal configs that fit our needs. Perhaps with time a database could be compiled for the configs...

None of what's above is utterly complex, but I also agree that other improvements are also very important as you mentioned Canadacow.

just select the best, more recent one. VGA over VESA, Soundblaster over Tandy

Its not that simple though. People who have a deeper nostalgia for the games may prefer other modes of operation (and in fact, different sound and video modes can enable/disable certain features). VESA is actually superior to VGA, but at the same time, VGA would give better performance on older systems, so again, VGA may be the best choice for older computers running DosBox. Again, these are things you have to account for that you don't with cartidge games. Please, stop trying to make DosBox into a cookie-cutter console-like emulation system. DOS was not cartidge based (well, atleast versions post 1.0) and as such I think its a serious bastardization to try to fit it into that mould.

Canadacow:
1) I'm not sure that I understand your question, but if it's what I'm thinking, you just need to reference two files, one being the main launcher and the other being the config utility.
2) Dosbox can be launched with a custom autoexec.bat that contains the required command line switches.

Also:

People who have nostalgia for a given system can still customize it to their tastes. The idea is to provide something good enough for most users.
And it's no more a "bastardization" than it was for the Apple II, the Atari ST, the Amiga, the C64, the PC98, and so on and so forth.
There is already a preliminary TOSEC effort on the way to catalogue install floppies, although it's still in very preliminary stages.

Its not that simple though. People who have a deeper nostalgia for the games may prefer other modes of operation (and in fact, different sound and video modes can enable/disable certain features). VESA is actually superior to VGA, but at the same time, VGA would give better performance on older systems, so again, VGA may be the best choice for older computers running DosBox. Again, these are things you have to account for that you don't with cartidge games. Please, stop trying to make DosBox into a cookie-cutter console-like emulation system. DOS was not cartidge based (well, atleast versions post 1.0) and as such I think its a serious bastardization to try to fit it into that mould.

Dude, you're argument is getting weak 😀
Our proposal is for an ADDED feature, people could choose to use it, or keep using DOSBox the way it is now. So in this case everybody wins.

Regarding VGA vs VESA, and all that, that's the whole point of config files, If "I" decide I want to play everything in CGA, then I can just edit the config files myself.

Anyway, if it all means so much to you, and you take at heart to make sure you keep DOSBox as is, as pure DOS as possible, then by all means we should stop arguing. Besides, I've lost my programming skills long ago, so I won't be able to implement something like this any time soon, I'm just trying to convince someone to give this shot, but if I fail, it's not a big deal, but it was worth a shot though!

As Far As I'm concerned will DOSBox stay as much as DOS as DOS used to be.

Any zipping and unzipping should IMHO be handled by a frontend

At the moment there isn't a fronted which can do that.
So please go make one instead of claiming-to-know-how-to-do-it.