This is outstanding. Finally a text-mode DOS game menu frontend. I wonder if it could be configured / augmented to:

1. Create a RAMDRIVE of x MB (based upon size of game -- user supplied in the .CSV file)
2. Decompress a single-archive ZIP, 7zip or RAR of the game to the RAMDRIVE
3. Execute the script by running the decompressed game directly from the RAMDRIVE.
4. Possibly run / configure SBEMU on a per-game basis for modern laptops with Intel HDA sound.

Up until now, I do all of this manually per game. They're all stored compressed in archives on a USB memory stick which boots to MS-DOS 7.1. I then decompress and run everything from a large RAMDRIVE. This is on a modern system with huge amounts of memory (8GB to 16GB), so there's plenty of RAM and CPU to spare... SBEMU / VSBHDA is also configured via .BAT file in each game's compressed archive. When decompressed, I run the .BAT file to configure and execute the game. Manually creating .BAT files for each of hundreds of games is a pain, though, and your menu solution is at once more elegant and less cumbersome.

Cool project!

So far I have been using LaunchBOX DOS Edition 2.0 and it uses the same batch wrapper trick to not use any memory when launching games. but I have been wondering when my game list will hit the conventional memory limit as it can't page data from disk.

I have also been using nested batch files to configure system speed, multiple sound cards, mixer levels, MIDI devices, disc images, configuration resets on the fly executed by typing in %ENV% commands - Speed only wouldn't be enough but also once you start spreading to other stuff the configuration options become endless and virtually impossible to maintain.

It would be cool to have some kind of extensible framework definition that pre-defines scripts that can be plugged into the software and triggered in the CSV. For exmaple if I wanted to create a definitions module that switches PicoGUS modes or loads disc images from a USB drive. Then those definitions can be shared and used by other people.

But just thinking aloud. I am kind of stuck with launchbox for now because all of the game launch scripts are in it's database which was short sighted of me, I would need to run some kind of script to pull them out into individual batch files which could be used as executable targets in GROG

Appreciate the feedback!
I'm working on the updates, stay tuned.

Hello everyone!

Happy to report that 1.5 is out! and it introduces exactly what you are both asking for: The Module System.

It is an extensible framework. You can now create custom scripts (like PICOGUS.BAT, SBEMU.BAT, or MOUNT_ISO.BAT) in a MODULES folder and trigger them directly from the CSV, complete with arguments.
Part of this is the RAM Drives and archive management. The release includes a RAMLOAD module example out of the box. It accepts a specific archive and RAM size from the CSV (e.g., RAMLOAD:"DOOM.ZIP" 32M), creates the drive dynamically, unzips the game and launches it.

There is also the new built-in config launcher with a dedicated hotkey to launch configuration/setup utilities for any game directly from the menu (`C` key).

Please take the time to go through the README file:
G.R.O.G. main page

Give it a spin and let me know how it works for you!
Download G.R.O.G. v1.5 on Codeberg

Thanks for this. It's documented very well! What I am missing is an edit function from within the program. Editing a CSV file in an editor on DOS is not a lot of fun. 😀 I know I can use Excel or whatnot on another PC but copying them back and forth is a bit cumbersome (for me at least). But overall I like it!

Read with Warcraft voice: "Your wish is my command!"

Something like this? 😉

Hopefully I can get it done and tested, then update the release and docs soon!

Wow, this sounds and looks nice! 😀
Will give this a try.

Keep up the good work!

kahuna wrote on Yesterday, 06:31:

Read with Warcraft voice: "Your wish is my command!" […]
Show full quote

Read with Warcraft voice: "Your wish is my command!"

Something like this? 😉

The attachment grog-ed01.jpg is no longer available

Hopefully I can get it done and tested, then update the release and docs soon!

Nice! Looks good. I assume you can also insert new records as well?

Does it insert records?
My friend, not only does it insert records, it calculates memory blocks, organizes your childhood, and gives a foot massage that would make LeChuck feel alive again! (massage oil sold separately)
I'm always open to hearing what the crew needs, but remember: I'm a Mighty Pirate™, not a waiter at the Scumm Bar. I can't serve every single grog that gets ordered from the back of the room!

I did, however, take a quick trip to the Swamp to consult the Voodoo Lady regarding a timeline. The cards (and my compiler) foretell that a new version will manifest likely tomorrow. Assuming LeChuck doesn't curse the upload!

This is very very nice! Thanks for the quick updates.

A feature request for me would be some sort of auto-scan feature and perhaps a community based metabase list. So you could set it to scan "C:\GAMES" and any match with .exe/file structures would auto insert a record or prompt for validation.

I'd lower the treshold to get started on an existing system 😀

Thanks for the kind words!

Technically, building an auto-scanner in DOS is a nightmare. Recursive directory scanning is really risky in C for DOS (it loves to cause stack overflows), but the real issue is the math. To identify a game, the CPU has to read the files and calculate an MD5 checksum first. On a retro machine, crunching those hashes is agonizingly slow; you'd be waiting ages just to generate the signature before we could even look it up in some sort of local database.

This tool is really built for the hands-on enthusiast who wants their config clean 😉
Trying to force modern, checksum-based auto-discovery onto a DOS machine is roughly the technical equivalent of trying to cross a ravine using a rubber chicken with a pulley in the middle. It sounds like a solution, but you're probably just going to get stuck halfway across.

A killer feature would be to include Coverart/Screenshots.
I know this is not possible because of textmode.

Just dreaming...
Graphical mode with mouse support, Coverart/Screenshots, maybe background music from the game that is currently highlighted

Why something like this haven't exist back in the old days?

crusher wrote on Today, 07:57:

Why something like this haven't exist back in the old days?

A launcher wasn't needed for the 4 games you had installed on your computer

NeoG_ wrote on Today, 08:15:

A launcher wasn't needed for the 4 games you had installed on your computer

It was more like 40 and still is.

kahuna wrote on Today, 07:56:

Thanks for the kind words! […]
Show full quote

Thanks for the kind words!

Technically, building an auto-scanner in DOS is a nightmare. Recursive directory scanning is really risky in C for DOS (it loves to cause stack overflows), but the real issue is the math. To identify a game, the CPU has to read the files and calculate an MD5 checksum first. On a retro machine, crunching those hashes is agonizingly slow; you'd be waiting ages just to generate the signature before we could even look it up in some sort of local database.

This tool is really built for the hands-on enthusiast who wants their config clean 😉
Trying to force modern, checksum-based auto-discovery onto a DOS machine is roughly the technical equivalent of trying to cross a ravine using a rubber chicken with a pulley in the middle. It sounds like a solution, but you're probably just going to get stuck halfway across.

Do you really need to calculate a MD5 checksum? Couldn't you just go by filename(s) and/or filesize and/or directory name? It won't be perfect, but if you have manual verification in the UI you could prompt the user to enter/correct values. Windows 3.x does something similar when it checks for DOS applications to be added as PIF files.

crusher wrote on Today, 08:39:

It was more like 40 and still is.

The proverbial you, I'm sure there was scant individuals with larger amounts of games installed but not enough to create market demand for a product

Not commercial product. But a hobby driven one like this.
There was a tool for everything. Commercial or selfmade.
But I can't remember of such a simple but great idea for such games launcher.

vetz wrote on Today, 09:01:

Do you really need to calculate a MD5 checksum? Couldn't you just go by filename(s) and/or filesize and/or directory name? It won't be perfect, but if you have manual verification in the UI you could prompt the user to enter/correct values. Windows 3.x does something similar when it checks for DOS applications to be added as PIF files.

You don't have to do that of course but even than there are almost 10000 games on DOS. Who's going to create a database for them? Also a user could change paths, directories etc (not to mention the duplicate file names). So a scan would be very much a miss on a lot of systems even if there was such a database. I would like it but I don't think it's feasible.

Yoghoo wrote on Today, 12:17:

vetz wrote on Today, 09:01:

Do you really need to calculate a MD5 checksum? Couldn't you just go by filename(s) and/or filesize and/or directory name? It won't be perfect, but if you have manual verification in the UI you could prompt the user to enter/correct values. Windows 3.x does something similar when it checks for DOS applications to be added as PIF files.

You don't have to do that of course but even than there are almost 10000 games on DOS. Who's going to create a database for them? Also a user could change paths, directories etc (not to mention the duplicate file names). So a scan would be very much a miss on a lot of systems even if there was such a database. I would like it but I don't think it's feasible.

It would have to be a community based effort where you share your manual entries. It wouldn't be 100% perfect, but it'll be a good help/start to get going. If the search discovered a file which could fit multiple entries, it could prompt the user for the correct alternative.