VOGONS

Common searches


DOSBox-X branch

Topic actions

Reply 1742 of 1866, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
hail-to-the-ryzen wrote:

I added fpu_control.h from your web link. It is not in mingw32, at least in a usual directory.

Hm... perhaps I should just copy the macro from the header then. MinGW Windows is one of the build targets I make for DOSBox-X.

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

Reply 1744 of 1866, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

It's built and the log shows the correct fpu header file was included:

 FPU:FPU core: long double FPU
FPU:FPU32 selftest passed
FPU:FPU64 selftest passed
FPU:FPU80 selftest passed

I tested the Explora demo and have same result as you reported. I will test Quake next.

Reply 1746 of 1866, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
hail-to-the-ryzen wrote:
That is a good plan. It may work to only adapt a small set of fpu instructions for long double precision. Testing with the x86 f […]
Show full quote

That is a good plan. It may work to only adapt a small set of fpu instructions for long double precision. Testing with the x86 fpu code shows the rendering artifacts are reproduced by reduced precision in the following two functions (tested against the beginning of the Explora demo):

diff -rupN dosbox-Orig//src/fpu/fpu_instructions_x86.h dosbox//src/fpu/fpu_instructions_x86.h
--- dosbox-Orig//src/fpu/fpu_instructions_x86.h
+++ dosbox//src/fpu/fpu_instructions_x86.h
@@ -1121,11 +1121,15 @@ static void FPU_FDIVR_EA(Bitu op1){
}

static void FPU_FMUL(Bitu op1, Bitu op2){
+ FPU_SetCW(0x37F);
FPUD_ARITH1(fmulp)
+ FPU_SetCW(0x3FF);
}

static void FPU_FMUL_EA(Bitu op1){
+ FPU_SetCW(0x37F);
FPUD_ARITH1_EA(fmulp)
+ FPU_SetCW(0x3FF);
}

static void FPU_FSUB(Bitu op1, Bitu op2){

I have some questions about those values.

According to this source: http://home.agh.edu.pl/~amrozek/x87.pdf

Bits 6-7 are not defined (0x7F and 0xFF), and bits 9-8 define the precision (0x300), so how does that affect the demo exactly?

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

Reply 1747 of 1866, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

It should have changed bit 9 to 1 from 0, so bit 8 and 9 are 11 for extended precision.

Edit: 0x37f should reflect doubles and 0x3ff flipping the bit for long doubles, at least from my binary to hex calculator. :}

Reply 1748 of 1866, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

The difference between 0x37F and 0x3FF is bit 7 (0x80), which is not listed to contain anything.

The latest commit adds code to update the FPU control word for ADD, SUB, MUL, DIV, which in the long double FPU code seems to fix the Explora glitches.

Adding the same to the non long-double non-x86 FPU code didn't fix anything. How can it when FPU operations in that code always truncate to 53-bit mantissa (64-bit) precision?

EDIT: However the control word code is probably not going to compile or work properly on my Raspberry Pi (arm7) so further changes will need to be done.

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

Reply 1749 of 1866, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

My calculation must have been off, so it must have changed another fpu parameter, such as rounding. 🙁

It does suggest, however, that the multiply is the main factor, but it would have to be confirmed (although not needed now).

Thank you for the commit! I'm building a binary now to test.

Note I added the 0x37F and 0x3FF to the x86 FPU code to test, not the non-x86 code. I was trying to cause the rendering artifact - is that what you asked?

Reply 1750 of 1866, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

When using the x86 FPU code, the only test to fail in Intel's i387 program is the transcendental test (SIN, COS, TAN, etc if I remember correctly).

EDIT: In the comprehensive test, the only failure is 35 cases of the "Scale" test (FSCALE instruction?)

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

Reply 1751 of 1866, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

That's interesting on the trigonometry functions! I also verified that I counted bit 7 incorrectly. So, I caused the fpu to reset to doubles both before and after instead of just before. However, it showed that the fmul is the reason, or at least one of the causes of the artifacts.

Reply 1753 of 1866, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
hail-to-the-ryzen wrote:

Does PCem show the same problem with the Scale test?

That's a test someone else here is going to have to do, I don't have PCem here on Linux.

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

Reply 1755 of 1866, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
TheGreatCodeholio wrote:
jmarsh wrote:

The problem may not be related to just the difference in precision, fpu_instructions.h is a very minimal x87 implementation that doesn't always take FP exceptions when it should or set flags correctly for many instructions. Using "long double" won't fix that.

Intel made a utility to test for correct x87 operation: https://winworldpc.com/product/386sx-math-coprocess/10
Dosbox fails every test unless using fpu_instructions_x86.h, which is obviously limited to (32-bit) x86 only as it uses real x87 instructions.

That's a good find, I actually have an old 386SX system I acquired some time ago where someone had installed the i387 in it, I should try that utility on it.

Link in the comment.

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

Reply 1756 of 1866, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

Both (custom builds) of pcem and dosbox-x (interpreter cpu cores) are showing many errors in all categories.

Edit: core=dynamic is not generating those errors. In fact no errors that way.

Reply 1757 of 1866, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

It seems anything other than C_FPU_X86 with DOSBox-X fails the tests completely.

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