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 block of code with useless "{}" .

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 redundant curly brackets.

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 Yesterday, 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 executable from the default 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 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.

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.