VOGONS


Pentium MMX emulation patch

Topic actions

First post, by kekko

User metadata
Rank Member
Rank
Member

Hi everyone,
I fixed an old patch I have made years ago. It adds Pentium MMX emulation to Dosbox.
The instructions are for the interpreter; the recompiler can use it too, but it has to fall back to the interpreter core.
It finally allows to run games which strictly require this instruction set, like Serious Sam (combined with the 3dfx patch).
Probably the first AAA title from 21st century to ever run in Dosbox 😀

ss1.png ss2.png ss3.png ss4.png ss5.png ss6.png

Attachments

Last edited by kekko on 2020-06-24, 08:04. Edited 6 times in total.

Reply 2 of 24, by kekko

User metadata
Rank Member
Rank
Member
jmarsh wrote on 2020-06-23, 17:24:

The MMX registers should be using the same storage as the emulated FPU registers, otherwise they won't be saved/restored with fsave/frstor.

Fixed it, thanks for the heads up.
I also fixed EMMS handling, hoping this will work properly.

Reply 5 of 24, by kekko

User metadata
Rank Member
Rank
Member
ripsaw8080 wrote on 2020-06-23, 20:32:

The MMX support in Daum is the "old patch" kekko referred to .

Indeed. Any build out there with mmx support use that old patch, thus none of them is actually working.

Reply 6 of 24, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
kekko wrote on 2020-06-23, 20:53:
ripsaw8080 wrote on 2020-06-23, 20:32:

The MMX support in Daum is the "old patch" kekko referred to .

Indeed. Any build out there with mmx support use that old patch, thus none of them is actually working.

Correct. It's currently known to cause the kernel audio mixing in Windows 98 to misrender 8-bit audio when using the MMX CPU type.

Also noted is that the way it's integrated technically allows MMX instructions in 386, 486, and Pentium CPU types even if CPUID doesn't report MMX extensions, which I consider a bug.

Another one I noticed is that the patch only implements MMX for 32-bit code. Either because the code segment is 32-bit or because a 32-bit override was given in 16-bit mode. At least from the Pentium MMX hardware I have it is legal to use MMX instructions in 16-bit real mode too.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 7 of 24, by kekko

User metadata
Rank Member
Rank
Member
TheGreatCodeholio wrote on 2020-06-23, 21:14:

Also noted is that the way it's integrated technically allows MMX instructions in 386, 486, and Pentium CPU types even if CPUID doesn't report MMX extensions, which I consider a bug.

I just added bit 23 to EDX. Is there something else? I haven't looked much into this.

TheGreatCodeholio wrote on 2020-06-23, 21:14:

Another one I noticed is that the patch only implements MMX for 32-bit code. Either because the code segment is 32-bit or because a 32-bit override was given in 16-bit mode. At least from the Pentium MMX hardware I have it is legal to use MMX instructions in 16-bit real mode too.

I added then removed this again. I thought it was not actually supported. I didn't check against actual hardware anyway.

Reply 8 of 24, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
kekko wrote on 2020-06-23, 21:38:
I just added bit 23 to EDX. Is there something else? I haven't looked much into this. […]
Show full quote
TheGreatCodeholio wrote on 2020-06-23, 21:14:

Also noted is that the way it's integrated technically allows MMX instructions in 386, 486, and Pentium CPU types even if CPUID doesn't report MMX extensions, which I consider a bug.

I just added bit 23 to EDX. Is there something else? I haven't looked much into this.

TheGreatCodeholio wrote on 2020-06-23, 21:14:

Another one I noticed is that the patch only implements MMX for 32-bit code. Either because the code segment is 32-bit or because a 32-bit override was given in 16-bit mode. At least from the Pentium MMX hardware I have it is legal to use MMX instructions in 16-bit real mode too.

I added then removed this again. I thought it was not actually supported. I didn't check against actual hardware anyway.

Normal software uses bit 23 of CPUID to check for MMX. What I'm saying is that the way it's integrated into normal core, MMX instructions can be executed for 486 and Pentium cores by programs that do not check CPUID properly.

16-bit real mode does indeed seem to support MMX instructions. Or else, 16-bit builds of the MMX test program in DOSLIB would crash when run: https://github.com/joncampbell123/doslib/blob … er/hw/cpu/mmx.c

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 9 of 24, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

On a related note, the Pentium III system I have on hand is also happy to support SSE instructions in 16-bit real mode as well, as demonstrated by this test program: https://github.com/joncampbell123/doslib/blob … er/hw/cpu/sse.c

All you have to do is set the bit in one of the control registers, and it works.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 11 of 24, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
kekko wrote on 2020-06-24, 06:32:

Thank you. Would you mind to make a patch?

16-bit real-mode MMX, yes?

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 12 of 24, by kekko

User metadata
Rank Member
Rank
Member
TheGreatCodeholio wrote on 2020-06-24, 06:34:
kekko wrote on 2020-06-24, 06:32:

Thank you. Would you mind to make a patch?

16-bit real-mode MMX, yes?

Yes, please. For the other issue I added this at the beginning of each instruction:

if (CPU_ArchitectureType<CPU_ARCHTYPE_PMMXSLOW) goto illegal_opcode;

Reply 13 of 24, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
kekko wrote on 2020-06-24, 06:38:
Yes, please. For the other issue I added this at the beginning of each instruction: […]
Show full quote
TheGreatCodeholio wrote on 2020-06-24, 06:34:
kekko wrote on 2020-06-24, 06:32:

Thank you. Would you mind to make a patch?

16-bit real-mode MMX, yes?

Yes, please. For the other issue I added this at the beginning of each instruction:

if (CPU_ArchitectureType<CPU_ARCHTYPE_PMMXSLOW) goto illegal_opcode;

Here you go. Kind of hackish but it helps minimize changes to the code and avoids duplicating the MMX instructions. This is a recent DOSBox-X commit but I think it should be easily adaptable to SVN and other forks.

Attachments

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 14 of 24, by kekko

User metadata
Rank Member
Rank
Member
TheGreatCodeholio wrote on 2020-06-24, 06:44:

Here you go. Kind of hackish but it helps minimize changes to the code and avoids duplicating the MMX instructions. This is a recent DOSBox-X commit but I think it should be easily adaptable to SVN and other forks.

I just updated the patch in the first post. Thank you.

Reply 16 of 24, by kekko

User metadata
Rank Member
Rank
Member

I was looking for an efficient way to implement mmx instruction set to the dynamic recompiler when I found that someone made this addition to my patch
https://github.com/joncampbell123/dosbox-x/pull/290/files

seems quite fast, unfortunately it does not seem to work correctly in all cases (i.e. serious sam hangs right before showing titles, where interpreter works fine).
Do you see anything obviously wrong in it? I am not very confident with the recompiler

Reply 17 of 24, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
kekko wrote on 2020-06-24, 08:47:
I was looking for an efficient way to implement mmx instruction set to the dynamic recompiler when I found that someone made thi […]
Show full quote

I was looking for an efficient way to implement mmx instruction set to the dynamic recompiler when I found that someone made this addition to my patch
https://github.com/joncampbell123/dosbox-x/pull/290/files

seems quite fast, unfortunately it does not seem to work correctly in all cases (i.e. serious sam hangs right before showing titles, where interpreter works fine).
Do you see anything obviously wrong in it? I am not very confident with the recompiler

I personally don't, maybe it's something subtle. I'm not THAT familiar with the dynamic core.

The way I would go about it is to partially undo it piece by piece until you find the case where Serious Sam works again.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 19 of 24, by kekko

User metadata
Rank Member
Rank
Member

I am trying to save/restore host mmx regs <-> dosbox fpu regs, in order to be able to switch between recompiler and interpreter and comment out opcodes from the recompiler, until eventually I get the wrong instruction.
Any hint on how to perform this in the recompiler?