I have 286 12 + 287 and Nec V20 with 8087.

287SXL is 387SX basicly.

Yeah, I suspect that 287XL is just a 387SX, but want to try my detection code if anyone has one, to be sure.

Anyway, I hope I'm not breaking any rules but here's a ZIP with 2 COM files to run. Both will print out about 20 small integer numbers, just write those down and report back. If free time is an issue, at the moment I'm more interested in the XT system since I can't test that on my own. I'm not even sure the code will work properly.

EDIT: ZIP removed, revised package 4 posts below.

Deunan wrote on 2020-03-04, 18:43:

Yeah, I suspect that 287XL is just a 387SX, but want to try my detection code if anyone has one, to be sure.

Anyway, I hope I'm not breaking any rules but here's a ZIP with 2 COM files to run. Both will print out about 20 small integer numbers, just write those down and report back. If free time is an issue, at the moment I'm more interested in the XT system since I can't test that on my own. I'm not even sure the code will work properly.

My 286 board with 287 is currently offline, else I would have helped out. I only have the 386 DX with 387.

Good thing you zipped that COM file. Else it would have been to huge. 😉

I have a Hedaka 286 board with 287XL on it. I was having some booting issues last time I looked at it, but will give it a try later.

I also have an Alaris Leopard with IBM 486SLC2 (i.e. a 386SX on some serious steroids) and some or other co-processor, I believe an IIT. Would you potentially want the results from that too?

Result:

CPU: NEC V20 @ 9.54Mhz
FPU: 8087 @ 9.54Mhz

Done on the 287XL:

fprem
2, 1, 0, 7, 6, 5, 4, 3, 2, 1, 0, 1, 2, 3, 4, 5, 6, 7, 0, 1, 2

fscale
2, 2, 5, 5, 5, 10, 10, 10, 10, 10, 10, 20, 20, 20, 40, 40, 10

Yeah, I know ZIP made a poor job of compressing these files but it's still a non-executable container that anybody can open. I don't want to attach the COM files directly, might upset browsers and/or OS trying to download those.

Anyway, many thanks for the tests. The issue that the docs mention (for 8087 as well) didn't manifest, weird. I assumed it was present in 8087 but fixed in 287, somehow I don't think Intel messed up two datasheets. But who knows.
Just in case I've prepared a revised testing package, there is now a second test called fprem2, and a simple detection program to test my code. matze79, when you have time, please run fprem2 on XT machine (and also detect while at it). Perhaps I interpreted the datasheet table wrong and I test too big numbers so this second test will try smaller ones. It should output something like 1, 0, (...), 0, 1

And sure, anybody can test, even on 386 and higher, though I don't expect any issues with 287XL or later co-processors. But if you do test, run the detection program as well and report results.

I have a 8087 in my V20 system, I can test on that looks like matze 79 already has this combo covered

do modern browsers and OS even recognize COM as an executable format? I doubt it

I have an IIT 2C87-10 (IIT version of 287) that I could test this weekend. I do not even know if it works so this would be a good test.

dionb wrote on 2020-03-04, 20:55:

I also have an Alaris Leopard with IBM 486SLC2 (i.e. a 386SX on some serious steroids) and some or other co-processor, I believe an IIT. Would you potentially want the results from that too?

Yeah IIT made a 387 mathco too. I have a copy of the diagnostic disk from IIT for their 287 and 387, will dig it out and post it to the library.
Added: mispelled and the II 2c87 mathco works ! will post results soon !

I got the same results as dionb and matze79 using a Headland HT12A board, Harris 286-16 and the IIT 2c87-10

maxtherabbit wrote on 2020-03-04, 23:48:

I have a 8087 in my V20 system, I can test on that looks like matze 79 already has this combo covered

do modern browsers and OS even recognize COM as an executable format? I doubt it

No 🤣 and do not think anyone will be running a modern OS on a 286 😜 I used DOS 6.

Intel 80286, 8 Mhz, Real Mode, 1/2/8/7
Intel 80287, 5 Mhz, 2/2/2/4

download/file.php?mode=view&id=78251

@Deunan are you working on detection of old FPUs? I have some code from the past to detect several of them - 8087/287/387/IIT/Cx/CT....

I've noticed that new volunteers download the original testing ZIP rather than the revised version so I've edited my post. Nonetheless, thanks for the results, seems like datasheets are not correct for fscale, or at least very poorly worded.

Mumak wrote on 2020-03-05, 07:50:

@Deunan are you working on detection of old FPUs? I have some code from the past to detect several of them - 8087/287/387/IIT/Cx/CT....

Not as such, but I'm very interested in that code anyway 😀 Basically I wrote a simple benchmark program for early x86 machines, originally it was meant for 386+ and FM Towns systems so that I could compare them apples to apples. And since I use OpenWatcom compiler but can't really use the libraries, I had to write my own minimal C lib. The floating-point test is something I came up with decades ago based on a book I have.

Long story short, I now also have a 286 system so I ported the test suite to pure 16-bit DOS, but kept the FPU stuff mostly as my own assembly, so now I have to work around some limitations of the 287 vs later co-processors. I started coding that and it turned out the docs are full of BS, and it seems some C compilers fell victim to that as well.

This is purely a hobby project, though I'm proud it now has support for Plantronics ColorPlus and compatible cards 😀

I too had developed some code decades ago for HWiNFO for DOS 😀 So I don't recall all the details and sources for it, but AFAIR the 287 used the same encoding for +inf and -inf, while 387 was different.
It was originally pure ASM, later I ported it to partially C++.
Attaching the first test for a 8087/287/387 class FPU:

And here the test for a Cyrix FPU:

IIT FPU test:

Mumak wrote on 2020-03-05, 09:15:

Attaching the first test for a 8087/287/387 class FPU: test87.txt

Nice, I use pretty much the same method. I mean, it's not like there are other, equally easy, ways to tell them apart. Here's the code, maybe it can be useful to someone (NASM syntax):

cpu 8086
push bp
mov bp,sp
; detect NPU/FPU presence
mov ax,~0
push ax
fninit
.delay1:
dec al
jnz .delay1
fnstsw [bp-2]
.delay2:
dec al
jnz .delay2
pop ax
test al,al
jnz .nofpu
push ax
fnstcw [bp-2]
.delay3:
dec al
jnz .delay3
pop ax
and ax,0x103f
cmp ax,0x003f
je .test287
.nofpu:
xor ax,ax ; no NPU/FPU

First, there is fninit - the n is important as we don't want to wait on BUSY signal. Some machines are wired wrong or use this signal for other purposes so that would hang the system. Because of that the fnstsw and fnstcw are also no-wait variants, and to account for rather slow NPU execution time, there are the delay loops. It's a pretty bullet-proof code this way.

For the 8087 detection I also have a (f)wait after each and every co-processor instruction, just as required. Otherwise the code will run properly on anything 287+ but might not actually execute as expected on a true 8087, leading to false mis-detection. In general, I detect 8087 but refuse to work with it, because the rest of my code isn't peppered with waits (and also OpenWatcom cannot target 8086 anyway, and I'm not writing a big program like that in pure ASM).

Thanks for the information! It's been so long when I have been dealing with such old systems, that I almost forgot everything 😀
I recall now that for some 8086 I had to use self-modifying code to replace the 1st byte of some instructions with a NOP, which the compiler automatically stored with a FWAIT prefix..
Do you know which systems had the issue with BUSY signal, was this 8086 only?

Some MASM versions would automatically insert wait after (or was it before? that's better for performance) every NPU instruction if the target CPU was set to 8086. That's one way to keep the source code cleaner. Some compilers, including OpenWatcom, have the math libs written for 8087 even though you can't target anything below 286 anymore. Which means some performance is lost in 16-bit DOS code due to all those waits and not using fstsw ax.

And BTW, i prefer to use wait rather than fwait mnemonic, as the instruction is actually CPU not NPU one, and this is why it's a problem. I'm not aware of any particular machine or system but I've read that BUSY signal was sometimes used in x86-based process controllers, and other special-purpose PCs, to allow software-based wait cycles.

Let's say you had a "slow" I/O port that needed variable amount of time to access (say, read after a write). Rather than use the max wait cycles on the bus, for worst case, which might be so slow that you can't do that by using regular signals as this might interfere with RAM refresh on XT, you'd use BUSY. This way the CPU would execute wait, freeze until BUSY is cleared, and resume execution right away without having to do some sort of I/O pooling loop (which, again, might not be possible right after a write operation). That's one example, I guess there can be other uses for a very-low latency signal that can suspend the CPU and is software-oriented.