MMCMP 1.30 crashes DOSBox-X

[sagamusix]

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:

1. Download a module file
2. Run mmcmp.exe 2nd_pm.s3m
3. Observe that DOSBox-X crashes.

Expected behavior
File should be processed as expected, and definitely not crash the emulator.

Environment (please complete the following information):

• Operating system : Windows
• DOSBox-X release version: 0.83.12

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.

[Wengier]

I can confirm the crash with MMCMP 1.30:

When the program runs the CPU goes to the protected mode, but the gate type 1 is not supported by the CPU_Interrupt() function. On the other hand, MMCMP 1.34 works fine as you said.

[sagamusix]

I can also confirm that MMCMP 1.30 runs fine on Windows XP 32-bit (inside a VM).

[Wengier]

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.

[joncampbell123]

Why is INT 21h a 286 Task State Segment, then?

[joncampbell123]

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.

0823:00000993 0F01E2              smsw dx
0823:00000996 F7C20100            test dx,0001
0823:0000099A 7529                jne  000009C5 ($+29)        (no jmp)
0823:0000099C 6633C0              xor  eax,eax
0823:0000099F 8CD8                mov  ax,ds
0823:000009A1 66C1E004            shl  eax,04
0823:000009A5 660106A400          add  [00A4],eax             ds:[00A4]=000000A8
0823:000009AA 0F0116A200          lgdt word [00A2]            ds:[00A2]=000F
0823:000009AF 66678D4201          lea  eax,[edx+0001]         [illegal]
0823:000009B4 0F01F0              lmsw ax
0823:000009B7 EB00                jmp  short 000009B9 ($+0)   (down)
0823:000009B9 B80800              mov  ax,0008
0823:000009BC 8EE0                mov  fs,ax
0823:000009BE 8EE8                mov  gs,ax
0823:000009C0 0F01F2              lmsw dx
0823:000009C3 EB00                jmp  short 000009C5 ($+0)   (down)
0823:000009C5 C3                  ret

[joncampbell123]

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.

[joncampbell123]

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).

[joncampbell123]

DOSLIB task: joncampbell123/doslib#54

[joncampbell123]

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]
ems=emm386
emm386 startup active=true

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).

[joncampbell123]

According to the Intel 386 Programmer's Reference Manual, LMSW is not supposed to let you exit protected mode.

[joncampbell123]

But.... I don't see any such remarks in the 486DX programmer's guide. Maybe Intel dropped the set-only behavior for the PE bit starting with the 486. Maybe not.

[sagamusix]

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.

[joncampbell123]

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.

[Wengier]

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:

• Visual Studio SDL1 build: dosbox-x-update.zip
• Visual Studio SDL2 build: dosbox-x-sdl2-update.zip

[sagamusix]

Thanks, I can confirm that it runs fine now.

[Wengier]

Great! Closing the thread.

[zirco77]

Hi! Author of MMCMP here. Just saw this thread. I'm genuinely surprised to see new references to my "software" as of today!

I confirm that this code was developed on (and for) a 80386, not a 80286 (that I never had), when I was like 18-19 with obviously no "professional developer habits". I learned by myself (mostly by disassembling binaries) and didn't have any of the Intel official documentation (though I had "Ralf Brown interrupt list", which also contained a lot of other info). So that's what you get ;)

The intent was to setup a 4GB flat mode, because the "expanded memory" 64kb paging thing was a real pain ;) though I did support that too in the TSR version (to decompress files on the fly)

[sagamusix]

Oh wow, great to see you here, @zirco77! Do you still have the code to any of the MMCMP versions, and have you ever thought about open-sourcing it? By now probably nobody cares anymore if it is professional or not, but it is an important bit of tracking scene history that deserved to be preserved.

[sagamusix]

I'm genuinely surprised to see new references to my "software" as of today!

I even had to disassemble parts of it a while ago, see temisu/ancient#32 ;)

[zirco77]

Oh wow, great to see you here, @zirco77! Do you still have the code to any of the MMCMP versions, and have you ever thought about open-sourcing it? By now probably nobody cares anymore if it is professional or not, but it is an important bit of tracking scene history that deserved to be preserved.

Short answer is "'I'm afraid not". I might have the source code somewhere, but last time I looked for it I could not find it. This was from 1996, and back then I was using Zip disks for my backups, until 97 or 98, when I had a total hard drive failure and realized I could not read my backup Zip disks back (the infamous "click of death"). They were written without any error, but not readable. Junk. I lost pretty much everything I did from 95 to that point, were it code, music, university assignments, etc.

EDIT: it was integrated to Impulse Tracker, albeit with some changes. It can now be found here (parts of the TSR version was used for decompression, and compression code is probably in some nearby file): https://github.com/jthlim/impulse-tracker/blob/main/IT_MMTSR.ASM

[zirco77]

I'm genuinely surprised to see new references to my "software" as of today!

I even had to disassemble parts of it a while ago, see temisu/ancient#32 ;)

Well, (de)compression routines were written in assembly, so that's the source code already ;) Rest was in C.

[sagamusix]

Ah, sorry to hear about the data loss! At least the released executables (most of them, anyway) are backed up here: https://ftp.modland.com/pub/software/utilities/DOS/MMCMP/