They actually use the emms only at one place, making it a nop gets
the demo to work (plays fine up to the end afaict).

A dos game executing mmx stuff while not checking for the processor
type is a common "problem"? DOSBox fully takes care of that in throwing
exception6 which is what a real non-mmx processor does.

I just didn't think DOSBox would crash because of that. But that's maybe just in the ytkwong build. I'm sorry if this is the case. I'll check that and will inform him about it.

They actually use the emms only at one place, making it a nop gets
the demo to work (plays fine up to the end afaict).

Wow! Could you send me the depacked exe? Or did you just patch it while running. I could try it myself If I had information about the debugger (how to step through instructions/dump memory/etc.)

I just didn't think DOSBox would crash because of that.

Official 0.72 release doesn't crash for me, maybe you can doublecheck that.

I've just added the emms instruction as NOP in dosbox, didn't mess around
with the demo executables (maybe there's some pmwunpack or so around
so you could try it).
Can you build dosbox from sources?

pmwunpack

Is this the packer? I couldn't find any supicious strings in the EXE. Google gives me absolutely nothing... I guess it is something internally used in the demogroup probably...

Can you build dosbox from sources?

Not atm. Did it with 0.65 once, so I guess I could. Do you suggest adding a patch to dump the code segment or similar?

And thanks for helping so much!

Official 0.72 release doesn't crash for me, maybe you can doublecheck that.

I will this week when I find time. Promised!

Is this the packer?

The unpacker is pmwunlit, can handle the default pmode/w compression.

Do you suggest adding a patch to dump the code segment or similar?

Well if you manage to compile the dosbox sources, you can simply add
the emms to behave like a nop.

The unpacker is pmwunlit

Found it, thanks.

Well if you manage to compile the dosbox sources, you can simply add
the emms to behave like a nop.

I probably need some experimental stuff from the ykhwong build (vsync, ...). But if you point me to the file/function I need to patch I'll try to do it myself.

src/cpu/core_dyn_x86/decoder.h
At the main switch (opcode) go down a few lines
to the 0x0f switch (dual_code) and add a
case 0x77: break;

Thanks a lot. I think I'll be able to work it out now one way or another...

rarefluid wrote:

That it crashes DOSBox should be considered a bug though! Executing a bad program shouldn't crash it imo...

Well, it doesn't crash DOSBox. Crashing is something else than "Intentionally aborting". While I'm all with you, nothing ever should crash DOSBox, I think it's fine if the CPU gurus choose to E_Exit("some error message"), which is what you are seeing. An orderly, intentional exit.

Of course, we're all aware that this isn't the most userfriendly thing to do. Maybe some version in the near future will show a more userfriendly message, at least if I find out how to do it in the UI.

dosbox doesn't E_Exit for this demo, it just issues the int6 invalid instruction.
The crash (ie. real dosbox crash) is most likely related to the cvs build he's using.

It crashes the ykhwong 0.72 CVS build. It does NOT crash the offcial 0.72.
I'll report that to ykhwong's site.

This was more about help to run that program than the instruction crashing DOSBox...

Thanks for helping out guys. I decompressed the EXE and will now fire up IDA to fix this baby to make it run in DOSBox 😀

I unpacked the application and patched the EMMS instruction to 2 NOPs.
Still, the patched EXE is crashing, and its not the EMMS instruction it is crashing at... It is still the same crash address and still a 06-Exception, there are no suspicious opcodes though.
I'm a bit puzzled here.

What's the byte immediately after the instruction you NOPed out?

Another NOP (90h). The original code sequence was "0F7790h" if I'm not mistaken...

Um you got the wrong one then. The right one should be succeeded by a ret (0xc3).
Maybe patch out all those 0x0f 0x77 0xc3 ones into 0x90 0x90 0xc3

Thanks. I did it in IDA and I only found one "emms". Seems there are more that IDA somehow can't detect...