On a Pentium 4 MS6534 mobo in Win98 MSDOS mode, the game runs great. Weird. I suspect it's some kind of caching behaviour on the board/bios that doesn't gel well with the way the game uses its memory.

The only other computers I have to hand are both Pentium MMX machines. It's possible that it just doesn't like that one CPU somehow, some kind of division/math problem?

Can somebody check it on a different chip?

edit I've just run the pentbug checker on it and my cpu doesn't have the FDIV fault so it isn't that. I'm going to try copying over various files from the shareware version to see how that changes it

Fixed it! 😀

The problem was possibly a bad write/copy/extract somewhere along the way copying the files from my Dosbox instance to my real DOS computer.

To fix it:
- downloaded PKZIP 2.5 (dated 1999) to replace the 2.0x version (dated 1992)
- redownloaded a clean gl132r from the Sleep Furiously website
- copied my configuration files from Dosbox known version: GAME.CFG, SCORE.CFG and NEWSCORE.CFG (GAME.CFG contains your savegame - unlocked mazes and found secrets)
- burned gl132r.zip and pkzip and files to a CDRW
- extracted on the real dos computer, and copied the CFG files back in

I suspected that the old PKUNZIP was a factor when I looked through the extracted files from my first attempt and found that DATA\SOUND\EL-BUTT.RAW had been named EL_BUTT.RAW by the old version of PKUNZIP. With that renamed, I got a different numbered Whoops error. I tried copying the full contents of the shareware directory over the registered one (except the EXE and the stuff in the root) and the game booted perfectly. I didn't try playing it in case there were any file changes between the two, but at least I knew that the EXE was capable of running on my computer. (As it turns out shareware GL and registered GL are identical except for their EXEs, and the extra added mazes in the WORLDS directory - I confirmed this by comparing extracted gl131s and gl132r zips in WinMerge and all the FONTS PAL PIX SHAPES SOUND and WORLDS were identical. The language files were a little different as it seems that single string files had been renamed to ENG for multiple language support (which didn't get implemented it seems?))

Glad you fixed the problem, mate, and thanks for posting the solution in case anyone else has the problem in the future.

And thanks for the link to the game. It sounds interesting, and I'll give it a try sometime.

I've found the real reason why the filenames were broken copying Get Lost.

The reason is that whatever I was using to burn the CD was renaming files with dashes to underscores. I've noticed it happening with a few other games. It could be a limitation of the DOS-compatible filesystem of a CD? Safest thing to do is to keep games in archives if you think there may be dashes or underscores present.

MrD wrote on 2021-05-13, 16:15:

The reason is that whatever I was using to burn the CD was renaming files with dashes to underscores. I've noticed it happening with a few other games.

Doesn't DOS normally given an invalid filename error when you try to give a file a name with a dash in it? This is of course a useful way to make a game slightly more difficult to copy.

Last time I ran into a problem like this, it seemed that some CD-burning programs were more tolerant than others. In a pinch you can try making a BIN/CUE image and then manually hex-editing the filename within the image – but it's probably much easier just to use an archiver.

MrD wrote on 2021-05-13, 16:15:

I've found the real reason why the filenames were broken copying Get Lost.

The reason is that whatever I was using to burn the CD was renaming files with dashes to underscores. I've noticed it happening with a few other games. It could be a limitation of the DOS-compatible filesystem of a CD? Safest thing to do is to keep games in archives if you think there may be dashes or underscores present.

ISO 9660 filesystem details: https://wiki.osdev.org/ISO_9660

As you can see in the linked page, the only non-alphanumeric allowed in filenames is underscore. Some CD-ROM authoring software will convert "illegal" characters to underscores in the ISO 9660 filesystem according to the rules, and optionally create a Joliet extension on the disc that preserves the original filenames. MS-DOS and MSCDEX will not use the Joliet extension, but Win9X and later will. However, some authoring programs are (or can be instructed to be) less strict about the filename rules, allowing any character that MS-DOS allows.