Have you tried changing the machine type in DOSBox.conf ?

naturally... also tried low cycle counts, loadfix, and the different cpu settings. Should've mentioned that.

looking at the .com files, it seems like the compiler was a Borland one from '85, if that gives anyone a clue towards troubleshooting this. It ain't the infamous runtime error 200, though.

It tries to verify 8 sectors on the last track of the A: drive, which won't work in DOSBox unless you mount a floppy image. However, it does the verify twice, expecting the first to fail and the second to succeed after it has altered the diskette parameters. This may be because DOSBox does not handle the parameters in its BIOS disk routines; but booting DOS doesn't seem to help, so not sure that's the case. It could be a keydisk check, but freeware games generally don't have those. Anyway, the attached archive contains a TSR program that will tell the game what it wants to hear.

May I suggest that you write a tutorial of some sort for these things you do, Mr. Ripsaw? They sound so impressive!

Ripsaw: fantastic, works like a charm. Thanks (as always)!

haha... I doubt that a tutorial would help too many people unless they already know x86 assembly like the back of their hands and are grand wizards at debugging.
However, if there was a web page of sorts, housing all those small game-specific fixes (a bit like peterferrie's site), that could be very handy 😀

To debug DOS programs you need some specialized knowledge in a few areas; and the more you know, the less frustrating it tends to be; but you don't need to be a wizard to be effective.

In the scenario where people search vogons about a specific game or issue, an attachment is as handy as it gets. I think a storage site would only be handy for a few enthusiasts interested in finding fixes for things they didn't know needed fixing.

yeah, you probably have a point there.

Off-topic: are there any good resources you'd recommend, for those who want to start getting their heads around x86 assembly/debugging? I've got some programming background, but mostly as a hobby, and nothing near as low-level as this stuff.
I don't even have an oldschool-enough machine to do the dirty work on, so this is all theoretical, but that might change...

I looked closer at what diskette parameters the game uses for the second verify: it uses the current parameters but changes the sector size to 256 bytes. My guess is that the original floppy was formatted with standard 512-byte sectors, except track 39 had 256-byte sectors. Can't imagine any reason except copy protection via keydisk, but a workaround is necessary to run the game because DOSBox doesn't (yet) support unusual formats.

@VileRancour: To avoid going off topic, I replied to your questions with a PM a few days ago. Please check your messages.