VOGONS

Help patching Lemmings 2 to avoid crash on Pentium-class hardware

Topic actions

First post, by vanfanel

Posted on 
User metadata
Rank Newbie
Rank
Newbie

Hi there,

According to JEMMEX author, the problem with Lemmings 2 on some hardware is that, if Soundblaster is selected as sound device in v86 mode, an exception 0D occurs in Jemm/Qemm ( MS Emm386 hangs ). It's due to a word write access at offset 0xFFFF, something not allowed in true v86 mode ( no problem for DosBox, apparently ).

I would like to hex-edit the game executable and try to get rid of that word write access at offset 0xFFFF: it should be possible.
But how would one go and find what hex position in the game executable file has to be patched?

Thanks!

Reply 1 of 4, by wbahnassi

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie

Run the game under a debugger. The debugger will break on the crash right at the offending instruction. Grab a few bytes of binary code starting from the instruction, and look for it in the executable. If it's not there, then you'll need to find it in one of the game's files which it dynamically loads. Then you can turn that into a NoP and pray it works.

BTW, what you're after is most probably a patch to the game's SB detection routine, which fails on fast CPUs (a very common problem on old games). The write to 0xFFFF is probably not going to be intentional, but a side effect of a failed handshake with the SB. It's timing sensitive, so hopefully your debugger won't slow things down too much and still causes the issue to repro.

Reply 2 of 4, by vanfanel

Posted on 
User metadata
Rank Newbie
Rank
Newbie
wbahnassi wrote on 2024-07-10, 10:04:

Run the game under a debugger. The debugger will break on the crash right at the offending instruction. Grab a few bytes of binary code starting from the instruction, and look for it in the executable. If it's not there, then you'll need to find it in one of the game's files which it dynamically loads. Then you can turn that into a NoP and pray it works.

BTW, what you're after is most probably a patch to the game's SB detection routine, which fails on fast CPUs (a very common problem on old games). The write to 0xFFFF is probably not going to be intentional, but a side effect of a failed handshake with the SB. It's timing sensitive, so hopefully your debugger won't slow things down too much and still causes the issue to repro.

I ran l2.exe under Microsoft's DEBUG, and from what I could gather, entering "g"->enter should run the program, but all it does is stall at the blinking DOS cursor.

Maybe other debug program would be preferred for this?

Reply 3 of 4, by vanfanel

Posted on 
User metadata
Rank Newbie
Rank
Newbie

Ah, doing

debug l2.com

instead, the game runs, and stalls in the same way as without debug.

But there's no way to stop execution: on GDB, I can return to the debugger, print variables, etc...
How is that done in DOS DEBUG?

Reply 4 of 4, by vanfanel

Posted on 
User metadata
Rank Newbie
Rank
Newbie

Ah well, I understood: Microsoft DEBUG included with DOS is only for .COM files.

I guess DOSBOX built-in debugger should be usable for this, too, if I knew what to look for there (the game does not hang in DOSBOX)

Go to top of page Go to top of page
Back to DOS
Close window
Close window