-
Notifications
You must be signed in to change notification settings - Fork 378
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MMCMP 1.30 crashes DOSBox-X #2549
Comments
I can also confirm that MMCMP 1.30 runs fine on Windows XP 32-bit (inside a VM). |
It does works in a real MS-DOS system, and the issue is related to the CPU code. @joncampbell123 may know the best (and most accurate) way to solve this. |
So, here's about where the problems lie. Not 100% sure but it might be flawed code that uses protected mode only to try to set up "flat real mode", or at least set FS and GS to 4GB segment limits in real mode.
|
It's obvious the program is storing the machine status word (which is the same as the low 16 bits of CR0), then loading it to enter 16-bit protected mode, load FS and GS, then loading the original machine status word to reenter real mode. As far as I can tell in the debugger, DOSBox-X still thinks it's 16-bit protected mode even though LMSW DX loads a DX value with bit 0 cleared which SHOULD exit protected mode on the 386. Except that it's supposed to be sticky as it was on the 286, because you weren't supposed to exit protected mode on the 286. You were supposed to enter protected mode (set bit 0) and then stay there until reset. So DOSBox-X is technically right, in that LMSW with bit 0 cleared is ignored and protected mode is kept. |
So then... at some point, Intel allowed LMSW to clear the bit, or maybe the program was written for non-Intel x86 processors. Perhaps 486 and Pentium systems allowed it (I noticed the program executable has a date within the year 1996). |
DOSLIB task: joncampbell123/doslib#54 |
Here's a workaround: MMCMP has code to detect if the CPU is in Virtual 8086 mode, and it will skip the "flat real mode" code if it detects it. Try adding this to your dosbox.conf: [dos] emm=emm386 sets expanded (EMS) memory emulation to run in a manner similar to EMM386.EXE. The "emm386 startup active" option tells EMS emulation to run the whole DOS environment under Virtual 8086 mode. There is even an incomplete VCPI implementation in place (that most DOS extenders are not happy with yet). |
I guess it wouldn't be too unlikely that the program was indeed never able to run on 386s. Version 1.0 was also released in 1996, most people probably were on 486s or Pentiums at that point. |
The latest commit adds an option to allow/disallow LMSW to clear the PE bit, or "Auto" to pick based on CPU type (486 or higher). The commit at this stage is an educated guess, but it allows MMCMP.EXE to run without crashing. |
I can confirm that MMCMP 1.30 now works fine with the latest code. The Windows binaries based on the updated code are available below in case @sagamusix wants to test the latest pre-compiled builds:
|
Thanks, I can confirm that it runs fine now. |
Great! Closing the thread. |
Describe the bug
Trying to compress or uncompress a module file with MMCMP 1.30 crashes DOSBox-X (and also vanilla DOSBox).
To Reproduce
Steps to reproduce the behavior:
mmcmp.exe 2nd_pm.s3m
Expected behavior
File should be processed as expected, and definitely not crash the emulator.
Environment (please complete the following information):
Additional context
MMCMP 1.34 doesn't crash in DOSBox. But I need to run this specific version to test something. Of course it's possible that the program is generally faulty, but either way it should not result in DOSBox crashing.
The text was updated successfully, but these errors were encountered: