Then what do you do when a new "must have" option is introduced in the DosBox config file? Or if you decide to move your games to another folder/drive? Correct hundreds of independent config files/shortcuts to make use of this new setting? The advantage of being able to change settings live from …

Bold statement (640kb is enough for everyone), but you're probably right about that one. I still believe virtual harddrives (of some form) are the way to go in order to isolate Dosbox data from the host os, but I guess I'm pretty much alone on this one, so I'll back down.

(sigh) 1. I'm not saying that the current file system isn't usable. What I'm saying is that if the file system isn't abstracted to a virtual harddrive then it might become a problem when the modern file systems begin to differ from what we're used to (i.e. no folders). The current system is …

You seem to focus only on the space-saving aspect of zip-support, which is, of course, one of its benefits. However, this is not at all why I suggested adding this support. My main concern is usability, that is, you should only be presented with things/files that are relevant to you in your host …

How about this scheme: 1. All files being accessed in the zip are decompressed to memory and changes to their contents are kept there. 2. Whenever a file is opened a counter is incremented, and when it is closed the counter is decremented. When the counter hits zero you can write the new zip as no …

That's the difference between treating the zip file as a directory using on-the-fly compression/decompression vs. the zip-support you'll find in frontends for console emulators etc. What you are describing is the zip-support seen mainly in frontends. These (usually) decompress the zip file to a …

Don't underestimate the "neatness factor" of being able to group all resource files of a specific game into one package in the host file system. Some older games consists of hundreds of small resource files which are uninteresting to me in the host os. It would be more convenient if they were …

Wouldn't creating a new file correspond to adding a file to the existing zip-archive? I haven't looked at the sources yet so I don't know if you're abstracting interaction with the host file system at the moment. If an abstraction is used then (using zlib?) an extension could translate: fopen -> …

Have you considered adding zip-support to the dos shell, so that zipped files appears as directories inside dosbox? I would imagine that on-the-fly compressing/uncompressing wouldn't generate much overhead when used with zipfiles containing relatively small files? Regards, Allan

Nagi works perfectly with all the games and emulates the Tandy-sound too. It is purely for nostalgic reasons that I would prefer to have them running in the original interpreter 😀

Yeah, but if you press ALT+D when playing the game and check the AGI-version then (on my KQ1) it is a higher version than LSL1 and Black Cauldron. KQ1 was probably rereleased with a newer version of the interpreter and this is the version I have, I think.

Yes, I've tried using some of the newer interpreters, but it seems that they are incompatible with the resource files used by the two games.

I've been trying to get all my old Sierrra AGI games working with Tandy sound, however, for some reason I can't get Leisure Suit Larry 1 and Black Cauldron working correctly. I'm launching the games using the -t parameter, ex: sierra -t ...which has worked perfectly with all the other games. Has …

Had any luck with Leisure Suit Larry 1 and Black Cauldron? For some reason I can't get these two working with Tandy sound. It appears the AGI-version is slightly older on these two when compared to my other AGI games. Do older AGI versions require a different parameter than -t?