aVd wrote on 2026-03-15, 06:53:

Also, the prebuild 32-bit GROGMENU.EXE from the archive with the v.3.1 binaries release shows itself as the better version "16-bit Port", but in its source file it contains the correct string "32-bit DPMI".

After installing DJGPP for DOS I built G.R.O.G. 3.1 from the source, and the problem remains. But I found the culprit. I'm using normal language "translation" ENG.LNG file. Its line 68:

1BADGE_L_TEXT="16-Bit Port"

EDIT: Added missing quotation marks.

Tested the latest version on a couple of pc's. On one it works correctly. On another one I got an error (see screenshot). Tried with Emm386, only himem and also a totally clean boot. All gave an error.

The pc where it's not working is a standard pc with MS DOS 6.22 with default memory manager. The one were it was working is a bit more exotic with MS DOS 5.0 and QEMM memory manager. On both the 16-bit version worked correctly btw.

Also one feature request. If no csv file exists it doesn't want to start (error message is not nicely lined out in that case btw). It would be nice if it created an empty file if the file does not exists.

kahuna wrote on 2026-03-15, 05:51:

Hello again, everyone!

Following up on the recent discussions, G.R.O.G. v3.1 is now officially live!

The main focus of this update is hardware compatibility. I know some of you have been wanting to run GROG on original XT/AT hardware (8086/8088/286). I hope I'm not forgetting anyone, but I'm tagging a few of you who showed interest because I'd love to hear your feedback if you have a real XT/AT machine ready to go: @Ozzuneoj ; @vetz ; @aVd ; @douglar ; @zyzzle

I’ll break out the XT w/ MDA graphics this weekend and give the tantalum capacitors a stretch. I shouls also put a usb reader in it since it’s a little challenging for me to get software from the internet to a computer that only has 360kb drives.

aVd wrote on 2026-03-17, 08:45:

After installing DJGPP for DOS I built G.R.O.G. 3.1 from the source, and the problem remains. But I found the culprit. I'm using […]
Show full quote

After installing DJGPP for DOS I built G.R.O.G. 3.1 from the source, and the problem remains. But I found the culprit. I'm using normal language "translation" ENG.LNG file. Its line 68:

Copy code to clipboard

1BADGE_L_TEXT=16-Bit Port

I'm not sure, that "16-Bit Port" or "32-Bit DPMI" strings will need any translation. But why two almost identical language files just to fix this little bug in v.3.2?

One common language file with two different replacements for "BADGE_L_TEXT=......" lines:

1BADGE_L_TEXT_16="16-Bit Port"
2BADGE_L_TEXT_32="32-Bit DPMI"

And in the source files the proper string will be read through "get_lang" function: "get_lang("BADGE_L_TEXT_16")" or "get_lang("BADGE_L_TEXT_32")" for the corresponding 16 or 32-bit release source file. This seems like better solution, than doubling the language files. Also this will keep the translation flexibility, if someone decides to use language with non-latin alphabet (for example "16-bit port" to "16-બિટ પોર્ટ").

I'm not forcing anyone to do anything, just giving a simple solution for a small harmless bug.

Is there a switch to change the display for flush right languages like Arabic, Hebrew, Farsi, Urdu ?

Not urgent for me at all, I'm a Left to Right guy, it's just one of those things that's easier if you get started early. It was a headache for me to retro fit into my multi language DOS projects--

A quick report from test on real hardware. G.R.O.G. 16-bit v.3.2 runs fine on my XT clone with Juko ST, NEC V20-12MHz (it's actually a factory overclocked V20-8MHz), 1MB of RAM. The lagging begins, when I switch off the "turbo mode" button (seems like "turbo mode" is more than 4.77MHz, but never bothered to measure how much), but I think, it's still bearable. If this matters, I have only 28 game titles in the database added (I don't use most of the data fields, 3/5 of them are empty). And after all I'm a normal retro PC user, not a web-scraper with obsession to build some enormous database with several hundreds of records, just because I can write my own Python script to scrap data from the MobyGames site 😀

I'm very happy with 16-bit build. It runs fine on XT-class PC and PIII too.

P.S. Just forgot to mention. Finally I found an appropriate usage of "Volume" data field. Now I can sort the games according to which CPU they use as a minimum: 8086/88, V20/30/186, 286, 386, etc. 😀

Hello everyone,

Replying to comments here:

Yoghoo wrote on 2026-03-17, 10:48:

Tested the latest version on a couple of pc's. On one it works correctly. On another one I got an error (see screenshot). Tried with Emm386, only himem and also a totally clean boot. All gave an error.
The pc where it's not working is a standard pc with MS DOS 6.22 with default memory manager. The one were it was working is a bit more exotic with MS DOS 5.0 and QEMM memory manager. On both the 16-bit version worked correctly btw.
Also one feature request. If no csv file exists it doesn't want to start (error message is not nicely lined out in that case btw). It would be nice if it created an empty file if the file does not exists.

Hey there, thanks for the testing! Your screenshot was exactly what was needed to track this down.

You noted that the 16-bit version worked perfectly, which makes total sense. The 16-bit version is highly optimized to fit entirely within conventional DOS memory. The 32-bit version, on the other hand, is built to handle vastly larger databases. To achieve this, it operates in 32-bit Protected Mode and relies on a DOS extender (like CWSDPMI) to access Extended Memory.
When there is no physical XMS/EMS RAM available, GROG leverages CWSDPMI to create a virtual memory swap file on your hard drive to manage those large game lists. The crash you experienced strongly suggests CWSDPMI couldn't create that swap file. This usually happens if the disk is full, write-protected, or otherwise restricted.

I actually spent some time looking into patching this to gracefully load a "partial" list of games when RAM runs out. However, I realized this introduces a catastrophic data corruption risk: if the system only loads a fraction of your games and you save an edit, the program will permanently overwrite your GAMES.CSV with just that truncated list. A loud crash to the DOS prompt is always safer than silent data corruption, so the current memory management will be kept as the intended behavior. To avoid this crash going forward, ensure the drive running the 32-bit version has a bit of free, writeable space so CWSDPMI can properly manage its virtual memory.

Regarding the request to auto-create a missing CSV, it sounds like a great quality-of-life feature, but it’s actually a bit of a trap in a DOS environment. If you accidentally launch GROG from the wrong directory and it auto-creates a blank file, you might panic thinking your real database was wiped. I prefer the program to simply stop and alert the user if the database isn't found.

douglar wrote on 2026-03-17, 11:16:

I’ll break out the XT w/ MDA graphics this weekend and give the tantalum capacitors a stretch. I shouls also put a usb reader in it since it’s a little challenging for me to get software from the internet to a computer that only has 360kb drives.

I feel you! Thanks for taking the time to test it out.

douglar wrote on 2026-03-17, 15:19:

Is there a switch to change the display for flush right languages like Arabic, Hebrew, Farsi, Urdu ?
Not urgent for me at all, I'm a Left to Right guy, it's just one of those things that's easier if you get started early. It was a headache for me to retro fit into my multi language DOS projects--

That is unfortunately not on the roadmap at the moment. It's involved enough just to create the Spanish translation as the charset is not strictly ASCII, but an extended codepage. I cannot imagine what it could be redoing the TUI rendering logic to support right-to-left!

aVd wrote on 2026-03-17, 16:58:

A quick report from test on real hardware. G.R.O.G. 16-bit v.3.2 runs fine on my XT clone with Juko ST, NEC V20-12MHz [...]

Happy to see GROG running in an XT machine, that's the real test I was talking about. Thanks for taking the time to do so.

aVd wrote:

[...]I'm not sure, that "16-Bit Port" or "32-Bit DPMI" strings will need any translation. But why two almost identical language files just to fix this little bug in v.3.2? [...]

Because they might need it, not just for those strings but for others as well. I'm just trying to be thorough and avoid leaving anything out.
While I was adding more dictionary entries for the export volume feature, I noticed I had forgotten to include the "16‑bit" .LNG files, which is why they are now present in v3.2.

Have fun!

“Flush right” is a pain but it isn’t that hard. You preserve the order of the characters from the csv, but you draw the spaces at the beginning instead of the end.

kahuna wrote on 2026-03-18, 01:06:

To avoid this crash going forward, ensure the drive running the 32-bit version has a bit of free, writeable space so CWSDPMI can properly manage its virtual memory.

The drive where it's running from has 1.3GB free disk space left (out of 2GB). Also it has 32MB memory with at least 30MB free.

kahuna wrote on 2026-03-18, 01:06:

Regarding the request to auto-create a missing CSV, it sounds like a great quality-of-life feature, but it’s actually a bit of a trap in a DOS environment. If you accidentally launch GROG from the wrong directory and it auto-creates a blank file, you might panic thinking your real database was wiped. I prefer the program to simply stop and alert the user if the database isn't found.

Maybe make it a config file option?

While I was trying to sent the "galleon" code back to it's appropriate era - a C99 compliant code (and further C89/90), I found this:

Seems like missing "else" in GROG-16.C file. It is actually a block of code for a nested scope.

I didn't ask for permission to adapt the 16-bit code in C99 or older standard, but I hope this doesn't break any GPL 3 rules. At least, while peeking at the code I'm starting to find some bugs. I'll have to take more detailed look into the functions responsible for handling the newest "Volume" data field switching, as it seems like those may cause some troubles to me.

EDIT: Not a missing "else", but curly brackets for a nested scope.

Hey everyone, just a quick note here.

I've tracked down an actual issue affecting the 16-bit version of GROG. I'll start working on a fix soon, expect a patched version in the next few days.
If you're using the 32-bit version, you're all good!

Stay tuned!

Yoghoo wrote on 2026-03-18, 07:33:

The drive where it's running from has 1.3GB free disk space left (out of 2GB). Also it has 32MB memory with at least 30MB free.

To figure out exactly what was happening, I actually ran some tests in a virtual machine and managed to reproduce the exact stack dump from your screenshot. However, I could only trigger it when I intentionally starved the VM of RAM and completely blocked the DOS extender (CWSDPMI) from creating its virtual memory swap file (either by artificially filling the disk or forcing swap creation off). Interestingly, that stack dump only happened once out of over 15 tries; the rest of the time, I got the standard "out of memory" message that's built into GROG's code.

At this point, I believe there is a specific configuration setting or background driver on this PC that is mimicking that "starved" state, essentially blocking CWSDPMI from either seeing your 32MB of RAM or dropping its swap file onto that 1.3GB of free space.
Rather than us guessing what it might be, could you please share the contents of your CONFIG.SYS and AUTOEXEC.BAT files, along with the output of the mem /c command? That will be helpful in figuring out exactly what is choking the memory manager.

Ahoy, @kahuna!
Nice to see, that you're working on fixing the 16-bit version bugs. I gave up with tracing the problems in this very big GROG-16.C source file by mostly using "find this, next find that, then what was the thing before..." 😀

I agree with your view, that auto-creation of empty GAMES.CSV database in wrong directory may lead to confusion. But what about missing GROG.CFG configuration file? The program has it's internal default settings, but it will be nice to automatically create the GRPG.CFG (in G.R.O.G.'s directory) file with these default setting, so later it may be edited with custom settings, if needed.

You haven't commented on whether there's a problem, if I continue to adapt the 16-bit version code to comply with the C99 standards (or even C89/C90). Are there any license issues or restrictions on that?

Thank you!

P.S. Unfortunately I can't test the 16-bit G.R.O.G. on "a real XT" machine, as my XT PC is a compatible clone with factory overclocked NEC V20 CPU and it's something like i80186, which is like i286 without protected mode. I think, "the real XT" machines have intel 8086 or 8088 CPUs running at 4.77MHz to 8MHz, and currently I don't have such a CPUs to experiment with.

kahuna wrote on 2026-03-19, 07:11:

At this point, I believe there is a specific configuration setting or background driver on this PC that is mimicking that "starved" state, essentially blocking CWSDPMI from either seeing your 32MB of RAM or dropping its swap file onto that 1.3GB of free space.
Rather than us guessing what it might be, could you please share the contents of your CONFIG.SYS and AUTOEXEC.BAT files, along with the output of the mem /c command? That will be helpful in figuring out exactly what is choking the memory manager.

Is it really helpful? As it also happens with only himem.sys (only device=himem.sys) or nothing at all (so no autoexec.bat/config.sys). Also tried some other CWSDPMI alternatives like PMODE/DJ but that errors out as well. All other games etc which are using a DPMI server do work correctly. See the output from mem/c for both scenarios.

Someone may say "hey, why do you bother to make C99 or C89/C90 standards compatible GROG-16.C code, just use Linux and crosscompile".

I tried to use GCC IA-16 compiler under Linux, but there's no full package of DOS libraries (header files like "dos.h" are missing) for Linux version of GCC IA-16 or I can't find way to install them. So, under Linux I managed to crosscompile only the LB2GROG 16-bit DOS executable.

Next I tried the GCC IA-16 toolchain for DOS from FlaterCo site, but I got similar errors like the @Yoghoo's one due to CWSDPMI.EXE DOS extender:

The other problem with DOS version of GCC IA-16 is that it borrows DOS libraries from DJGPP, but again the path environment is different and no "dos.h" could be found, even if it's places in the original IA-16's "INCLUDE" directory. So, I gave up trying to use this GCC IA-16 compiler.

I just tested version v2.7c, v3.0a and v3.1 as well on this 'problem' 486. All these versions work correctly. So this pc only has a problem with the latest v3.2 version.

Hi, @Yoghoo,
I don't know if this can help with your v.3.2 memory error, but there's a way for CWSDPMI DOS extender to be embedded into the software's executable instead of using the external CWSDPMI.EXE host.

First you need EXE2COFF.EXE to strip the 32-bit DJGPP built executable from the default GO32 stub, which is responsible to start the external CWSDPMI.EXE host before the execution of the actual executable's code:

1exe2coff grogmenu.exe

This will produce stripped GROGMENU file.

And finally you'll need to concatenate another CWSDSTUB.EXE stub as a header of already stripped GROGMENU binary file:

1copy /b cwsdstub.exe+grogmenu grogmenu.exe

That's it. All the needed CWSDPMI files can be found in the official DJGPP "csdpmi7b.zip" zipped package here. EXE2COFF.EXE can be found in the official DJGPP package "djdev205.zip".

I tried this and the produced 32-bit G.R.O.G. executable with the embedded CWSDPMI extender works fine without the need of the external CWSDPMI.EXE host.

Hi everyone!

Apologies for being missing in action lately due to some changes in my professional life. I just got a new job and have been focusing on setting up my workspace with everything I need, whilst also finding alternatives to bypass all the spy software they install on company issued laptops 🤣
I really should be immersing myself in the joys of the new gig and learning the ropes. But just before I fully dive into that, I wanted to release a hotfix version - GROG v3.2a.

This update brings some essential stability improvements to both the 16 bit and 32 bit builds.
Starting with the 16 bit version, a nasty data loss bug was squashed. Previously, pushing past the memory limit with massive game libraries would silently wipe out parts of the database. The engine now neatly catches this limit, aborts the loading process, and safely drops right back to DOS to protect those precious files. Strict traps for out of memory situations and broken pointers were also added across the board to halt the program safely instead of crashing randomly. On the visual side, the interface got a nice polish by better centering the browse category window and giving the boot error screens some extra breathing room.

For both versions, the generic crash screen for a missing database file was replaced with a friendly troubleshooting guide that tackles common DOS folder and directory quirks. A visual glitch where error screens awkwardly inherited leftover background colors was fixed by properly resetting the display settings. Some spring cleaning was also done in the language files to clear out unused user interface text.

The 32 bit version received a stability overhaul. A major crash caused by leftover memory garbage messing things up in the background was fixed. Strict memory checks were enforced across the board, so the engine will now cleanly halt with a dedicated error screen instead of silently crashing or corrupting memory if the system runs out of RAM. Special character handling is fully locked down too, meaning accented letters will no longer confuse the background processes, ensuring smooth sailing when sorting and searching international databases. Finally, the database text reader was completely rewritten to correctly handle line breaks and empty trailing fields.

Download: https://codeberg.org/jjmarcos/grog/releases
Source/Docs: https://codeberg.org/jjmarcos/grog

P.S.: It turns out I have a ton of hardware lying around, but somehow not a single 16-bit platform. So, I finally pulled the trigger on a NuXT board. Looking forward to testing GROG on actual XT-class hardware!

Enjoy!

I am blown away by the work you've put into this in such a short amount of time.

Having a 16bit version is really awesome and I will definitely be using it on as many DOS machines as I can. Thank you!

Ozzuneoj wrote on 2026-04-06, 20:14:

I am blown away by the work you've put into this in such a short amount of time.
Having a 16bit version is really awesome and I will definitely be using it on as many DOS machines as I can. Thank you!

Thanks, appreciate it!
Definitely let me know how it runs on your different setups. I'm super curious to hear how it performs in the wild while I wait for my NuXT board to arrive so I can finally join the hardware testing fun!

Hello everyone, it's been a while!

I'm very happy to share that a new version of G.R.O.G. has been released!
We are jumping straight to v3.5 because of the number and depth of upgrades packed into this new version.

I recently got my hands on a NuXT board and started experimenting with it, which naturally included testing G.R.O.G. on real hardware. Picture below for attention!
Running it on the NuXT, I quickly realized that hard-limiting the string size of game titles in the 16-bit version wasn't ideal. Sure, "The Secret of Monkey Island" fits fine, but "Where in the World is Carmen Sandiego - Enhanced Edition" gets cut off, which looked pretty lame.

That sparked the development of a more dynamic engine. Instead of reserving a static chunk of RAM based on a specific title length, the engine needed to adapt to whatever is actually in your database. The challenge with dynamic allocation is the "Swiss cheese" memory fragmentation effect. If you aren't careful, memory gets fragmented quickly when navigating deep menus, leading to stack collisions and violent crashes.

My first approach to solving this conundrum was to try a FAR memory version. Instead of being confined to the 64KB DGROUP of the small memory model, it could reach out into conventional RAM. This meant holding more games and ignoring title length caps entirely.
I knew it would be slower than the NEAR version (which stays strictly within the 64KB DGROUP boundaries), but I didn't expect it to be quite that slow. Ultimately, I decided not to pursue that route for the main build. While the FAR version's source is stored in the `BODEGA` directory in the Codeberg repository, and its compiled binary is available in this v3.5 release, there are no plans to maintain it further.
The final solution was to rebuild the memory manager. It now reserves just enough RAM for the program to function and has several defensive mechanisms to free RAM in a very controlled way. Also, it turns whatever is left into a "Master Arena”. G.R.O.G. sizes your game list before loading it into this space. No more game title caps, and no more memory fragmentation.

Speaking of RAM allocation, a /TEST parameter was added to both the 16-bit and 32-bit versions. It analyzes your GAMES.CSV file and tells you if it will fit in memory. If it doesn't, it will encourage you to split your collection into volumes. This way, you can load a dedicated, lightweight volume for your 286 instead of trying to cram your entire 7,000-game library into it.

I also noticed my poor NuXT took quite a while chewing (tokenizing) the CSV file on boot. To address this, the 16-bit engine now compiles your library into a fast .idx binary cache, reducing load times.
Other major 16-bit adjustments include a move to pure BASH-style TAB autocomplete, which  eliminates the XT keyboard buffer overflow issues we had with the old passive background scanning. Also, adding a new title now takes fractions of a second because it simply appends to the end of the file rather than rebuilding the entire CSV.

As for the 32-bit DPMI version, it learnt a few tricks from its 16-bit sibling. While it's a totally different beast, it dynamically grows to fit your database now, pulling in chunks of memory safely as needed.
There are many other internal updates across the board. For instance, the 32-bit version now features advanced multi-volume exports. If you have one volume defined for your XT and another for your 286, you can now tag them both and safely combine them into a single CSV directly from G.R.O.G.'s interface.

As usual, here are the full release notes, downloads, and documentation:

Download: https://codeberg.org/jjmarcos/grog/releases
Source/Docs: https://codeberg.org/jjmarcos/grog

Have fun!