DOSBox-X branch

Here you can discuss the development of patches.

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2019-2-02 @ 04:28

Attached.
You do not have the required permissions to view the files attached to this post.
hail-to-the-ryzen
Member
 
Posts: 332
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2019-2-02 @ 04:30

Also, ignore my previous report about a full core in dosbox (actually tested normal versus dynamic cores only).
hail-to-the-ryzen
Member
 
Posts: 332
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2019-2-02 @ 06:31

I just incorporated and adapted fpu_instructions_x86.h from SVN into DOSBox-X and the code from configure.ac to enable it.

It seems to fix the glitches.

So as far as I can tell there's something Explora does with the FPU that requires the full 80-bit precision to render it's graphics correctly.

I think the best course of action is to change DOSBox-X's non-x86 FPU emulation to use "long double" which will enable the full 80-bit precision on everything except Microsoft Visual C++ (which can use fpu_instruction_x86.h anyway now).
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 694
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2019-2-02 @ 06:37

I do know from previous programming experiments that "long double" is the full 80-bit IEEE format when compiled with GCC on x86, x86_64, arm7 (Raspberry Pi) and an old PowerPC powerbook I loaded YDL Linux on. Any noncompliant targets can be set up to error out at compile time if long double is not longer than double.
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 694
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2019-2-02 @ 07:01

fpu_instructions_x86.h does not work in VS2015 when targeting x86_64 because VS2015 does not allow inline __asm when targeting 64-bit Windows.

Is there something that SVN has to work around that or does 64-bit SVN have the same limitation?
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 694
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2019-2-02 @ 07:36

Probably the VS would reduce backward compatibility, so the gcc systems may be preferred.

Thank you for the commits!

Edit: I see now. They must not target x64 for the VS path. I read that generally the code would have to be changed.
hail-to-the-ryzen
Member
 
Posts: 332
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby jmarsh » 2019-2-02 @ 13:56

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.
jmarsh
Member
 
Posts: 282
Joined: 2014-1-04 @ 09:17

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2019-2-02 @ 16:59

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.
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 694
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2019-2-02 @ 17:09

Every test passes except for 35 of the SCALE tests. Hm...
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 694
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2019-2-02 @ 22:29

pcem shows same issue so both the svn and pcem code would likely have to have the same missing emulation. However, pcem does not have the full long double handling.
hail-to-the-ryzen
Member
 
Posts: 332
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2019-2-04 @ 03:05

Both the x86 and the non-x86 fpu code defaults to double precision in DOSBox/-X. One possibility is the EXPLORA demo resets the fpu to long double precision.

First, confirmed that the working x86 fpu emulation, with core=normal, does not have the rendering artifacts at beginning of the demo. Then disabled any change from double precision in the x86 fpu emulation which then led to the artifacts:
Code: Select all
diff -rupN dosbox-Orig//src/fpu/fpu.cpp dosbox/src/fpu/fpu.cpp
--- dosbox-Orig//src/fpu/fpu.cpp
+++ dosbox/src/fpu/fpu.cpp
@@ -32,7 +32,7 @@ FPU_rec fpu;
 
 void FPU_FLDCW(PhysPt addr){
    Bit16u temp = mem_readw(addr);
-   FPU_SetCW(temp);
+   // FPU_SetCW(temp);
 }
 
 Bit16u FPU_GetTag(void){
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
@@ -1251,7 +1251,7 @@ static void FPU_FLDENV(PhysPt addr){
       tag    = static_cast<Bit16u>(tagbig);
    }
    FPU_SetTag(tag);
-   FPU_SetCW(cw);
+   // FPU_SetCW(cw);
    TOP=FPU_GET_TOP();
 }
hail-to-the-ryzen
Member
 
Posts: 332
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2019-2-04 @ 06:10

So then the non-x86 core might be able to make the demo happy on Linux systems at least if I can change it to use long double and use the right GCC macros to make sure extended precision is enabled.

https://code.woboq.org/userspace/glibc/ ... rol.h.html
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 694
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2019-2-04 @ 08:30

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):
Code: Select all
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){
hail-to-the-ryzen
Member
 
Posts: 332
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2019-2-04 @ 08:37

I just made an alternate fpu_instructions_longdouble.h which uses long double instead of double.

It doesn't seem to resolve the artifacts yet, but perhaps focusing on those two functions might help.

However "Toontown" is able to display properly without the need for the "use80" hack in the original fpu_instructions.h (FPU Pentium memcpy trick, remember?)
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 694
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2019-2-04 @ 08:44

That is good news. It sounds like you have the issue almost resolved. :)
hail-to-the-ryzen
Member
 
Posts: 332
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2019-2-04 @ 08:46

hail-to-the-ryzen wrote:That is good news. It sounds like you have the issue almost resolved. :)


Maybe. I'm testing the new long double FPU code against DOS games like Heretic, Quake, Duke Nukem 3D, etc. anything known to use the FPU to see if the changes broke anything obvious.
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 694
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2019-2-04 @ 08:47

I'll test, too.
hail-to-the-ryzen
Member
 
Posts: 332
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2019-2-04 @ 08:50

hail-to-the-ryzen wrote:I'll test, too.


Help is appreciated. Make sure C_FPU_X86 is not set and that HAS_LONG_DOUBLE is defined from include/dosbox.h. Do not test with Microsoft C++, long double doesn't work there.
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 694
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby hail-to-the-ryzen » 2019-2-04 @ 08:52

Will do. Nonuse of MS C++ is a bonus.
hail-to-the-ryzen
Member
 
Posts: 332
Joined: 2017-3-09 @ 01:34

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2019-2-04 @ 08:55

Looks like Quake is the latest casualty in the DOSBox-X problem of too many VESA BIOS modes, but only if you try to change video mode. :)

Use the 'vesa modelist cap' option if Quake crashes when you try to set a SVGA mode.
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 694
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

PreviousNext

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 2 guests