search

joncampbell123 / dosbox-x

DOSBox-X fork of the DOSBox project
GNU General Public License v2.0
2.81k stars 383 forks source link

QuickBasic calculation error #1939

Open akcansoft opened 4 years ago

akcansoft commented 4 years ago

Quickbasic calculation error on DOSBOX-X

Dosbox-X v0.83.6 PRINT VAL("5") OUTPUT: QuickBasic v4.5 -> 4.999999999999999 Qbasic v1.1 -> 5 QBX v7.1 -> 5

DOSBOX v0.74-3 PRINT VAL("5") OUTPUT: QuickBasic v4.5 -> 5

Wengier commented 4 years ago

I have just tried QuickBasic 4.5 and run the command PRINT VAL("5") inside DOSBox-X 0.83.6, and this is the result I got:

image

image

I downloaded the QuickBasic 4.5 files from:

https://winworldpc.com/product/quickbasic/45

So it seems that the result here is correct (5 instead of 4.999999999999999). I tried with the default configuration (dosbox-x.exe -defaultconf). If you have modified the DOSBox-X configuration file, you can certainly try with the default setting and see if the result is correct.

joncampbell123 commented 4 years ago

If you are using VS2019 builds and NOT using dynamic core, you may get some loss of floating point precision. VS2019 does not support the "long double" data type.

The same issue exists with a QBASIC game that checks it's own EXE file size.

Try running a MinGW build, or switch on dynamic core, or use dosbox.conf to disable the FPU emulation so that QBASIC is forced to emulate floating point in software.

akcansoft commented 4 years ago

I tried with the default configuration. dosbox-x.exe -defaultconf not modified DOSBox-X configuration file. QuickBasic v4.5 PRINT VAL("5") Result : 4.999999999999999 ss

Wengier commented 4 years ago

@akcansoft Can you please post a screenshot that shows the full welcome banner ("Welcome to DOSBox-X ! ..."), which will include details about the actual build you are using, e.g. Windows (VS) or MinGW, 32-bit or 64-bit, SDL1 or SDL2, etc? Thanks!

akcansoft commented 4 years ago

i tried new download and install download page: https://github.com/joncampbell123/dosbox-x/releases download file: dosbox-x-vsbuild-win-20200930224615.zip https://github.com/joncampbell123/dosbox-x/releases/download/dosbox-x-v0.83.6/dosbox-x-vsbuild-win-20200930224615.zip extact zip file to folder run: folder/bin/x64/Release/dosbox-x.exe SS: command_000 mount c c:\dosprg c: cd QB45 QB Quickbasic v4.5 PRINT VAL("5") Result: 4.999999999999999

run: folder\x64\Release SDL2\dosbox-x.exe result is the same

next. new test: download and unzip file: dosbox-x-mingw-win64-20200930235023.zip https://github.com/joncampbell123/dosbox-x/releases/download/dosbox-x-v0.83.6/dosbox-x-mingw-win64-20200930235023.zip folder\mingw-build\mingw\dosbox-x.exe qb test result : 5 it's ok. should I use this version?

Wengier commented 4 years ago

@akcansoft Yes, the last version is the MinGW build that @joncampbell123 mentioned earlier, which should work fine for this case.

blindphoneman commented 4 years ago

Interestingly, I ran QB under DOS 6.22 running in an HD image under DOSBox-x and it gave 5 as the answer.

Dwedit commented 3 years ago

Is this about the initial state of Floating Point rounding mode?

Dwedit commented 3 years ago

I think this issue is serious enough that the either MSVC builds should have the Dynamic core selected by default, or the MinGW builds should be prioritized by the installer instead of the MSVC builds.

Either that, or figure out what's going on with the floating point conversion (bad rounding mode?), and fix the bug.

Dwedit commented 2 years ago

Bug is still present in newest release. Maybe make the MingW build the default?

joncampbell123 commented 2 years ago

Can you try adding:

[cpu] fpu=false

Also try using a build other than the Visual Studio based ones. Microsoft's C++ compiler does not support "long double" and maps it to plain "double".

Dwedit commented 2 years ago

Tried logging FPU related stuff, only saw this in the logfile:

         0       FPU:FPU core: double FPU (caution: possible precision errors)

And I am aware that picking the MinGW build fixes the problem, but the MinGW build is not the preselected build when you try to install the program.

Setting "fpu = false" in CPU configuration does display the correct 5. As does using Dynamic core.

But this is about having correct behavior out of the box without needing to adjust anything.

Since MSVC appears to simply not support 80-bit floating point at all, perhaps move the 80-bit floating point code into a separate DLL that can be built using another compiler, like MinGW which does support 80-bit floating point. But this would inline very poorly. MSVC also doesn't support assembly code for the situations where you explicitly need 80-bit floating point support.

Are there programs with known issues on the Dynamic core? Making that the default could resolve the 80-bit FPU issues.

Allofich commented 2 years ago

I haven't really looked into it, but when I tried the MinGW build recently, it seemed to have a problem with delayed input in the game Descent. I tried the Visual Studio build after that (built on the same code) and it didn't have the problem. So the MinGW build may have its own issues and isn't necessarily the superior option of the two.