is there a second oscillator socket for the 287, and is it populated?

Isn't there a jumper to enable/disable coprocessor? If it's set to disable, the BIOS might detect the FPU, but when code is to be executed, both the CPU and the FPU tries to execute it, thus corrupting the bus?

Does the BIOS report what type of FPU is present?

It's very likely these bodges are there from factory (it's just legendary Commodore 'quality' ;D - same is in my PC20-III).

Try different FPU (again!). My HT12 based Octek Fox III with 20 MHz Harris CPU didn't liked IIT 2C87-20 and showed exactly the same behaviour you described - crazy errors in Falcon 3.0, system hangs in nssi or checkit and so on. Yet, this FPU works very well on another board (so it's not broken) and slower (10 MHz) AMD FPU works fine in this board.

Thank you so much for your answers.
The board has a total of 4 populated oszillators - one 50, one 32, one 24 and one 14 MHz version. I measured a connection from the 32MHz oszillator to the Headland chip AND to the correct 287 pin (according to the datasheet).
Unfortunately I have no manual for the PC (its a Commodore SL286-16 Slimline). I found some manuals online (including a service manual) - but they are all for a completely different mainboard. Fortunately there is a sticker with a description of the jumpers attached to the power supply. However, I could not find any jumper related to the coprocessor.
Thank you @HanJammer for your suggestion. I now also bought an 10MHz AMD FPU, which will unfortunately take a while until it is here - and will also try this coprocessor. But my hopes are low since none of the coprocessors worked so far. At least the "normal" D80287-10 should have worked in my understanding. Only the fact, that the S1, S0, INTA, Ready, HLDA and CLK286 pins seem not to be connected on the mainboard - and are also referred to as "not connected" with an AMD FPU but not with an Intel FPU (according to THIS SITE) - gives me some hope (but on the other side they are also n.c. with the XL or IIC FPU).

@Speedsalat pull the 287 CKM pin to GND.

@H3nrik V! your comment is absolutely wrong. The BIOS is firmware and detects the NPU presence by means of running NPU instructions. What type of coprocessor do you think can be connected to the 286? Which bus will be corrupted and how exactly? It is normal for x86 & x87 to execute code in parallel.

georgel wrote:

@H3nrik V! your comment is absolutely wrong. The BIOS is firmware and detects the NPU presence by means of running NPU instructions. What type of coprocessor do you think can be connected to the 286? Which bus will be corrupted and how exactly? It is normal for x86 & x87 to execute code in parallel.

I stand corrected, then. I did not know how the BIOS detects the FPU - it might have just been a question of a "presence" pin or something.

What I do know is, that the FPU and CPU shares address/data bus and an FPU instruction opcode has another start. However - if the CPU is not aware of the FPU's presence, it will execute the instruction (all-though in a lot less efficient way), and the FPU will do the same, thus conflicting address/data bus.

There's a small protocol between CPU and FPU, without FPU the CPU will raise an exception when FPU instructions are executed and then some FPU emulation software can kick in, otherwise FPU does all the work.

H3nrik V! wrote:

georgel wrote:

@H3nrik V! your comment is absolutely wrong. The BIOS is firmware and detects the NPU presence by means of running NPU instructions. What type of coprocessor do you think can be connected to the 286? Which bus will be corrupted and how exactly? It is normal for x86 & x87 to execute code in parallel.

I stand corrected, then. I did not know how the BIOS detects the FPU - it might have just been a question of a "presence" pin or something.

What I do know is, that the FPU and CPU shares address/data bus and an FPU instruction opcode has another start. However - if the CPU is not aware of the FPU's presence, it will execute the instruction (all-though in a lot less efficient way), and the FPU will do the same, thus conflicting address/data bus.

Your "knowledge" IS NOT related to 286 & 287. They do not share address bus at all.

Tiido wrote:

There's a small protocol between CPU and FPU, without FPU the CPU will raise an exception when FPU instructions are executed and then some FPU emulation software can kick in, otherwise FPU does all the work.

Wrong. The 286 trap #7 is generated regardless of the presence of 287. This trap generation is toggled via the EM bit in MSW.

Speedsalat wrote:

I recently aquired a nice little Commodore 286-16 and I'm very happy with it. However, I wanted to install a 287 coprocessor to make it really complete.

Hi! I don't know which kind of Commodore PC it is, but I found a page with a selection of manuals related to Commodore ATs:
http://www.retro-commodore.eu/pc-tech/ 😀

H3nrik V! wrote:

Isn't there a jumper to enable/disable coprocessor?

Good question, I wonder the same. In the past I've seen quite a few AT boards with such jumpers myself.

Jo22 wrote:

Hi! I don't know which kind of Commodore PC it is, but I found a page with a selection of manuals related to Commodore ATs: http […]
Show full quote

Speedsalat wrote:

I recently aquired a nice little Commodore 286-16 and I'm very happy with it. However, I wanted to install a 287 coprocessor to make it really complete.

Hi! I don't know which kind of Commodore PC it is, but I found a page with a selection of manuals related to Commodore ATs:
http://www.retro-commodore.eu/pc-tech/ 😀

H3nrik V! wrote:

Isn't there a jumper to enable/disable coprocessor?

Good question, I wonder the same. In the past I've seen quite a few AT boards with such jumpers myself.

I doubt it. I've never seen a 286 AT motherboard with a jumer/switch to enable/disable the 287 or to select the 287 presence. And there is no need for such.

georgel wrote:

H3nrik V! wrote:

georgel wrote:

@H3nrik V! your comment is absolutely wrong. The BIOS is firmware and detects the NPU presence by means of running NPU instructions. What type of coprocessor do you think can be connected to the 286? Which bus will be corrupted and how exactly? It is normal for x86 & x87 to execute code in parallel.

I stand corrected, then. I did not know how the BIOS detects the FPU - it might have just been a question of a "presence" pin or something.

What I do know is, that the FPU and CPU shares address/data bus and an FPU instruction opcode has another start. However - if the CPU is not aware of the FPU's presence, it will execute the instruction (all-though in a lot less efficient way), and the FPU will do the same, thus conflicting address/data bus.

Your "knowledge" IS NOT related to 286 & 287. They do not share address bus at all.

I wasn't aware, that there was a difference in the way the 8086/8087 and 286/287 worked. However, the do share databus, and an address decoder is coupled to the address bus, and apparently chip selects the CoProcessor. Further more, a few control signals are present between the CPU and FPU. If anything goes wrong, and eg the address decoder is not enabled correctly, the CPU and FPU might try to use the databus at the same time, thus halting the system ..