You should check it on a real DOS machine, because this may be a BASIC issue.

I mean... what kind of data is 1 and what kind of data returns VAL()? Maybe you are comparing a integer number with a float, and in some languages this can lead to unexpected results.

You might want to post this in the DOSBox-X thread to be sure that TheGreatCodeholio sees it.

DOSBox-X branch

You're correct - VAL returns a double, and then it's compared to an integer. With single-precision variables, there isn't a problem.

I don't know about the rest, but I never remember a problem with NIBBLES or Operation Neptune on my old 486DX2-66 machine that I grew up on.

There is a MS KB article about comparisons in BASIC, but ... it did work ...
https://support.microsoft.com/en-us/help/6933 … arison-problems

I have not found any FPU-testing programs online. So for now I'll just leave the fpu disabled. None of the software I'm emulating requires a fpu anyway.

Shane32 wrote:

Note that the problem does not occur with Dosbox 0.74. I'm guessing it does not emulate the fpu at all.

Dosbox 0.74 seems to always have an FPU. I wasn't able to configure it so that this simple test program doesn't detect an FPU:

1; nasm fpu_test.asm -o fpu_test.com
2
3    cpu 8086
4    org 100h
5
6start:
7    mov     dx, no_fpu_txt
8    
9    fninit
10    fnstsw  [fpu_status]
11    cmp     word [fpu_status], 0
12    jne     .nope
13    fnstcw  [fpu_control]
14    cmp     word [fpu_control], 037fh
15    jne     .nope
16
17    mov     dx, fpu_txt
18.nope:
19    mov     ah, 09h
20    int     21h
21    
22    mov     ax, 4c00h
23    int     21h
24
25no_fpu_txt:
26    db "No "
27fpu_txt:
28    db "FPU found", 13, 10, '$'
29
30fpu_status:
31    dw  0ffffh
32fpu_control:
33    dw  0ffffh

The setting `fpu=false` is neither documented in the config file or man page, nor does it have any effect on my 0.74 installation.