MSD (Microsoft Diagnostics) misdetects FPU as 80287 when cputype=8086 or cputype=80186 about dosbox-x

[rderooy]

There are not. But the steps to compile it yourself are available here: https://github.com/joncampbell123/dosbox-x/blob/master/BUILD.md

[joncampbell123]

Still does.

[dd86k]

Funny that I landed on this. I'm writing a small processor identification program and according to Intel in Application Note 485 (AP-485), the official code to detect the coprocessor only can differentiate "class 2" FPUs (8087/80287) and "class 3" FPUs (80387). When detecting an 80486, the FPU check is skipped.

I didn't decompile MSD but considering it uses the same code (because Wintel), the snippet uses an oddity in earlier coprocessors to compare -INF and +INF:

In summary, +INF == -INF = 8087/80287, +INF != -INF = 80387 (and later).

Which could mean that there are too little different between the 8087 and 80287 to be able to tell them apart within software, at least with official code provided by Intel.

At least this is what I'm aware of. To conclude the behavior, I could disassemble MSD.

[joncampbell123]

The reason programs do not check between an 8087 and 80287 is that the 8087 (as I understand it) cannot be paired with a 286. However, I am curious what makes it think the FPU is a 80287 attached to an 8086.

When the 386 came out, the 387 wasn't ready yet, so motherboards paired the 386 with a 287. https://en.wikipedia.org/wiki/I386#Early%20problems. No such pairing was ever done with the 486. Also all but the 486SX had the FPU as part of the CPU.

[dd86k]

Got curious and checked it out. I'm using DosBox-X 0.83.23 with MSD 2.11. Default settings.

With CPU type 8086, I get 8086+8087 in MSD, so maybe this was fixed at some point, or at least I have an MSD version that supports this check.

But with CPU types 80186/80286/80386, it sticks with 80387, and this is something I noticed while writing my program. Potentially, this is a new bug from DosBox-X.

Anyway, despite seeming to have the code for the -Inf/+Inf comparison oddity, this seems to be on DosBox-X for my case, at least with my versions experienced.

Here is a snippet of a disassembly I have done with MSD 2.11 (I added comments):

   ; ...
   1906d:	c3                   	ret    
   ; check_fpu: 
   1906e:	db e3                	fninit 
   19070:	c6 06 b5 6d 00       	mov    BYTE PTR ds:0x6db5,0x0
   19075:	d9 3e b4 6d          	fnstcw WORD PTR ds:0x6db4
   19079:	8a 26 b5 6d          	mov    ah,BYTE PTR ds:0x6db5
   1907d:	80 fc 03             	cmp    ah,0x3      ; check if cpu type 80386
   19080:	74 04                	je     0x19086     ; if so, jumps to check_inf
   19082:	33 c0                	xor    ax,ax       ; clearing return value, no fpu
   19084:	eb 49                	jmp    0x190cf     ; done, jump to end
   ; check_8087: microsoft added some extra work to do a 8087 check
   19086:	81 26 b4 6d 7f ff    	and    WORD PTR ds:0x6db4,0xff7f ; trim other control word bits
   1908c:	9b d9 2e b4 6d       	fldcw  WORD PTR ds:0x6db4 ; load control word
   19091:	9b db e1             	fdisi(8087 only)   ; objdump added "8087 only" here
   19094:	9b d9 3e b4 6d       	fstcw  WORD PTR ds:0x6db4 ; fdisi changes state if 8087
   19099:	f7 06 b4 6d 80 00    	test   WORD PTR ds:0x6db4,0x80 ; did control word change
   1909f:	74 05                	je     0x190a6     ; jumps if control word didn't change, indicating 80287 or 80387
   190a1:	b8 01 00             	mov    ax,0x1      ; otherwise type 8087
   190a4:	eb 29                	jmp    0x190cf     ; done, jump to end
   ; check_inf: same as intel's example to check -inf/+inf
   190a6:	9b db e3             	finit  
   190a9:	9b d9 e8             	fld1   
   190ac:	9b d9 ee             	fldz   
   190af:	9b de f9             	fdivp  st(1),st
   190b2:	9b d9 c0             	fld    st(0)
   190b5:	9b d9 e0             	fchs   
   190b8:	9b de d9             	fcompp 
   190bb:	9b dd 3e b4 6d       	fstsw  WORD PTR ds:0x6db4
   190c0:	9b                   	fwait
   190c1:	a1 b4 6d             	mov    ax,ds:0x6db4
   190c4:	9e                   	sahf   
   190c5:	75 05                	jne    0x190cc
   190c7:	b8 02 00             	mov    ax,0x2    ; type 80287, -inf == +inf
   190ca:	eb 03                	jmp    0x190cf
   190cc:	b8 03 00             	mov    ax,0x3    ; type 80387, -inf != +inf
   190cf:	c3                   	ret    

It reproduces the same behavior as the Intel code when it comes to detect 80287 or 80387. So in your case, it was probably due to improper detection of the 8087 in your case with the specific instruction. Without it, MSD jumps to check_inf, which would display 80287, and that's on MSD's fault.

I'm no maintainer of DosBox-X, but I was just passing through. Hope this helps someone.

[rderooy]

Intel had a special FPU diagnostic software that may be useful. Search for "Intel MCPDIAG".

[dd86k]

Regardless of value, this screen is shown from MCPDIAG:

I don't think it's feeling well.

[joncampbell123]

Got curious and checked it out. I'm using DosBox-X 0.83.23 with MSD 2.11. Default settings.

With CPU type 8086, I get 8086+8087 in MSD, so maybe this was fixed at some point, or at least I have an MSD version that supports this check.

But with CPU types 80186/80286/80386, it sticks with 80387, and this is something I noticed while writing my program. Potentially, this is a new bug from DosBox-X.

Anyway, despite seeming to have the code for the -Inf/+Inf comparison oddity, this seems to be on DosBox-X for my case, at least with my versions experienced.

Here is a snippet of a disassembly I have done with MSD 2.11 (I added comments):

   ; ...
   1906d:	c3                   	ret    
   ; check_fpu: 
   1906e:	db e3                	fninit 
   19070:	c6 06 b5 6d 00       	mov    BYTE PTR ds:0x6db5,0x0
   19075:	d9 3e b4 6d          	fnstcw WORD PTR ds:0x6db4
   19079:	8a 26 b5 6d          	mov    ah,BYTE PTR ds:0x6db5
   1907d:	80 fc 03             	cmp    ah,0x3      ; check if cpu type 80386
   19080:	74 04                	je     0x19086     ; if so, jumps to check_inf
   19082:	33 c0                	xor    ax,ax       ; clearing return value, no fpu
   19084:	eb 49                	jmp    0x190cf     ; done, jump to end
   ; check_8087: microsoft added some extra work to do a 8087 check
   19086:	81 26 b4 6d 7f ff    	and    WORD PTR ds:0x6db4,0xff7f ; trim other control word bits
   1908c:	9b d9 2e b4 6d       	fldcw  WORD PTR ds:0x6db4 ; load control word
   19091:	9b db e1             	fdisi(8087 only)   ; objdump added "8087 only" here
   19094:	9b d9 3e b4 6d       	fstcw  WORD PTR ds:0x6db4 ; fdisi changes state if 8087
   19099:	f7 06 b4 6d 80 00    	test   WORD PTR ds:0x6db4,0x80 ; did control word change
   1909f:	74 05                	je     0x190a6     ; jumps if control word didn't change, indicating 80287 or 80387
   190a1:	b8 01 00             	mov    ax,0x1      ; otherwise type 8087
   190a4:	eb 29                	jmp    0x190cf     ; done, jump to end
   ; check_inf: same as intel's example to check -inf/+inf
   190a6:	9b db e3             	finit  
   190a9:	9b d9 e8             	fld1   
   190ac:	9b d9 ee             	fldz   
   190af:	9b de f9             	fdivp  st(1),st
   190b2:	9b d9 c0             	fld    st(0)
   190b5:	9b d9 e0             	fchs   
   190b8:	9b de d9             	fcompp 
   190bb:	9b dd 3e b4 6d       	fstsw  WORD PTR ds:0x6db4
   190c0:	9b                   	fwait
   190c1:	a1 b4 6d             	mov    ax,ds:0x6db4
   190c4:	9e                   	sahf   
   190c5:	75 05                	jne    0x190cc
   190c7:	b8 02 00             	mov    ax,0x2    ; type 80287, -inf == +inf
   190ca:	eb 03                	jmp    0x190cf
   190cc:	b8 03 00             	mov    ax,0x3    ; type 80387, -inf != +inf
   190cf:	c3                   	ret    

It reproduces the same behavior as the Intel code when it comes to detect 80287 or 80387. So in your case, it was probably due to improper detection of the 8087 in your case with the specific instruction. Without it, MSD jumps to check_inf, which would display 80287, and that's on MSD's fault.

I'm no maintainer of DosBox-X, but I was just passing through. Hope this helps someone.

Are you using normal core when testing?
I have code specifically to check for the -inf / +inf comparison if CPU type is 286 (should it do the same for 8086?)
It sounds like if DOSBox-X wants cputype=8086 to be detected as having an 8087, it needs to do something to FPU state on FDISI/FENI... or see if it even decodes those instructions. Supposedly they're a No-Op on later FPUs.

[dd86k]

All tests were done using the normal core, as it is the default setting.

The FDISI instruction is indeed used to check if the control word changes, and is only effective on the 8087. Later FPUs are confirmed by Intel to not change any internal states if the instruction is executed.

Which I believe DosBox-X is doing well (in my case, but not the issue's case, which is a few years old, so things may have changed). And according to cpu-word, the 80186 worked with the 8087. It did not have a co-processor counterpart.

After the 8087 check, the -Inf/+Inf check can only distinguish between 80287 (and earlier FPUs if -inf==+inf) and 80387 (and later FPUs if -inf!=+inf). This is done without assuming the CPU because I think both the 80287 and 80387 can be paired with a 80386, but the 80387 cannot be paired with an 80286. And seems to be where DosBox-X is failing at (in my case).

[joncampbell123]

I see that the -inf/+inf check is nonexistent if config.h has defined C_FPU_X86, meaning if your host CPU is x86 and using FPU instructions in assembly language.

[dd86k]

That would explain it. Does DosBox-X perform anything specific worth noting when the 8087 is selected?

[joncampbell123]

It does the same -/+inf check because that case only checks if CPU type is 286 or lower. FENI/FDISI are silently ignored by the CPU normal core so far, which is why MSD thinks it's a 80287 or higher.

[joncampbell123]

Actually, src/fpu/fpu.cpp has code to emulate FENI/FDISI already there, in FPU_ESC3_Normal(), but only if CPU type is 8086. MSD is correctly showing 8086/8087 now with cputype=8086.

However that code only matches 8086, it does not consider the 80186. There's no 80187 that I'm aware of, so I can only assume the 80186 might have been paired with an 8087. Right?

[dd86k]

However that code only matches 8086, it does not consider the 80186. There's no 80187 that I'm aware of, so I can only assume the 80186 might have been paired with an 8087. Right?

According to cpu-word, the 80186 worked with the 8087. It did not have a co-processor counterpart.

[joncampbell123]

@dd86k Please try the latest commit. It should show the proper FPU for 8086, 286, and 386 emulation.

In addition, the "fpu" setting in dosbox.conf can now either specify "true" or "false" as it always has, or you can now specify "287" or "387" to emulate a specific FPU i.e. cputype=387 and fpu=287.

[rderooy]

I gave MCPDIAG a go, and it works for the most part with the latest changes. But there are still some issues...

With default cputype=auto, 386 or 486 the transcendental diagnostic test always fails:

When it detects a 386 or 486 CPU type, it also offers a "Floating Point Conformance Test", and here it always fails for 35 of the scale operations.

With cputype=386, MCPDIAG thinks there is an Intel RapidCAD CoProcessor. Even if fpu=287

Lastly, with cputype=286 or older, the diagnostic tests passed without issue (conformance test is not offered).

[dd86k]

@joncampbell123 Are there CI/nightly builds available?

[dd86k]

Successfully compiled with SDL1!

Okay, this is what I get from commit afcbf8e:

cputype	fputype (expected)	fputype (result)
8086	8087	8087
80186	8087	8087
80286	80287	80287
80386	80387	80387
80486	N/A	N/A

I think it's now working as intended. Still using MSD 2.11.

[Torinde]

However that code only matches 8086, it does not consider the 80186. There's no 80187 that I'm aware of, so I can only assume the 80186 might have been paired with an 8087. Right?

Per the Wikipedia x87 article there is a 80187, which actually is a 387. All combos I see described there:

• 8086, 8086+8087
• 80186, 80186+8087, 80186+387 (aka 80186+80187)
• 80286, 80286+287, 80286+387 (aka 80286+80287XL)
• 80386, 80386+387, 80386+287
• 80486 (aka 486SX), 80486+487 (aka 486DX), 80486+387 (aka Cx486DLC+387)
• Nx586, Nx586+Nx587
• Pentium and above - always with a x87

Per the DOSbox-X wiki all of the above combos should be supported since you can force 8087/287/387 on ANY x86 CPU and also you can disable x87 on ANY CPU.

Separately, relevant for the PC-98:

• NEC Vxx, Vxx+μPD72091/D9008D (FTAN, FATAN, FTANH, FXP2, FXPT, FXPE, FLGTX, FLGEX, FREM, FLDDTR, FSAVEA, FNSAVEA, FRSTORA, FSTENVA, FNSTENVA, FLDENVA, FLDCWA, FPOWER) 1,2,3

[Torinde]

I ran on AMD Ryzen two MCPDIAG variants - under VirtualBox with MS-DOS 7.10, under latest Staging MSYS2 artifact, under latest DOSbox-X MinGW64 artifact with auto settings:

• '486 detected' and 'Transcendental fail' when using 188KB https://archive.org/details/MDIAG_ZIP
• 'no Intel FPU' when using 18KB https://archive.org/details/msdos_MCPDIAG_shareware
  
  same as @dd86k above.

1. 386+387 = detected wrongly as RapidCAD (which means 486+487) - fails "full" Transcendental (as expected for 487?). But RapidCAD ID is wrong - why doesn't it show "Intel387(tm)"? CHKCPU properly identifies that as 387SX.
2. 286+387 = detected properly as 287XL (which means 387) - fails "full" Transcendental, as expected if assumption for real 387 failing is true
3. 186+387 = detected wrongly as 8087 - Transcendental OK (but test appears to be different). CHKCPU properly identifies that as "80187" (which means 387)
4. 86+387 = detected wrongly as 8087 - Transcendental OK (but test appears to be different). CHKCPU wrongly identifies that as "8087" - but 86+387 combination is not valid anyway.
5. 486+387 = detected wrongly as 486 (should've been 387+Cx486DLC) - fails "full" Transcendental. CHKCPU identifies that as 486DX (when using "old" without CPUID) or 486 (when using 486 CPUID type) - so, unclear about the FPU part.
6. 386+287 = detected wrongly as RapidCAD (which means 486+487) - fails "full" Transcendental (as expected for 487?). CHKCPU properly identifies that as 386SX+287.
7. 286+287 = detected properly as 287 (both MCPDIAG and CHCKCPU) - Transcendental OK (but test appears to be different).
8. 186+287 = detected wrongly as 8087 (MCPDIAG) or 187 (CHKCPU) - Transcendental OK (but test appears to be different). Combination is not valid anyway.
9. 86+287 = detected wrongly as 8087 (both MCPDIAG and CHKCPU) - Transcendental OK (but test appears to be different). Combination is not valid anyway.
10. 386+8087 = detected wrongly as RapidCAD (which means 486+487) - fails "full" Transcendental (as expected for 487?). CHKCPU wrongly identifies that as 386SX+287. Combination is not valid anyway.
11. 186+8087 = detected as 8087 - Transcendental OK (but test appears to be different). CHKCPU wrongly identifies that as 186+187.

I can understand both MCPDIAG and CHKCPU being confused by the odd CPU/FPU combinations, but the straightforward one 386+387 being misdetected may be to blame on the DOSbox side. Hopefully Jon or somebody else will test at real 386+387 PC.

MCPDIAG 188KB seems to have two different tests - one for 87/287 (passing always) and another for 487 (failing always). I couldn't make it show "387 detected", so I'm not sure on what side 387 goes - closest is that I got detection as 287XL (relabeld 387) and it got the 487 test and failed.

So, I think it's not that 287 is successful at Transcendental test and 387 or 487 becomes incompatible - I think the tests themselves are different.

[rderooy]

@Torinde did you miss 8086+8087?

[Torinde]

On bare metal Penryn CPU with FreeDOS the 18KB version gave "detected an i486~ Family Math CoProcessor" - unlike DOSbox.
Transcendental test still failed in both 18KB and 188KB versions.

DOSbox-X with 8086+8087 - properly detected (both MCPDIAG 188KB and CHCKCPU) - Transcendental OK (but test appears to be different).

[Torinde]

86box - Celeron CPU is detected as RapidCAD in 188KB (all/many tests fail, not only Transcendental) and as "not Intel" in 18KB MCPDIAG.
Seeing that I don't have high hopes for a 386/387 config in 86box to give good clues. Better to test on real hardware.