68LC060 with 68882?

[Matt_H]

Here's a random question that occurred to me (perhaps it's been discussed before):



With the current supply situation, most 060 chips now circulating are the versions without an embedded FPU. Does it make any sense for accelerator designers to create a board with an LC060 and a separate 68882 chip? In other words, is it electrically possible to interface the two chips and does it offer any sort of speed benefit (compared to no FPU)?


Likewise, could a board hypothetically also have a provision for a 68851 for the EC060 chips lacking both MMU and FPU?

[Toni Wilen]

It is not possible. 68040 and 68060 does not have external co-processor interface. Only 68020 and 68030 have it.

(yes, 68000 + 6888x is possible but it means emulating co-processor protocol in software. Better forget it existed..)

[Matt_H]

Oh well. That's that, I suppose. Thanks for the quick answer, Toni!

[d4rk3lf]

Originally Posted by Toni Wilen

(yes, 68000 + 6888x is possible but it means emulating co-processor protocol in software. Better forget it existed..)

Now you got me curious.

[Toni Wilen]

Originally Posted by d4rk3lf

Now you got me curious.

Some older thread probably has better explanation but basically 6888x is IO mapped to some address space and software emulates 68020/030 co-processor interface protocol to execute FPU instructions.

It is horrible kludge

[d4rk3lf]

Maybe Lightwave could use FPU to gain some speed during rendering.
I've managed to install Lightwave 3 on my Amiga 500.
Maybe even Real 3D could use it.

But I got ya.
By the time 3D apps were able to use FPU, much better Amiga's existed for these stuff, then the first models with 68000 .

[Thomas Richter]

Originally Posted by Matt_H

With the current supply situation, most 060 chips now circulating are the versions without an embedded FPU. Does it make any sense for accelerator designers to create a board with an LC060 and a separate 68882 chip?

No, it doesn't. The 68060 (or 68LC060) does not have a coprocessor interface. Thus, you would have to manually interface with the 68882, using it as an I/O chip, and would to implement the coprocessor interface in software. This also rules out using FPU instructions, unless someone writes an exception handler that would then forward the instructions manually to the FPU.


Frankly, this doesn't make much sense. There were FPU add-onn cards which provided a mathieee.resource, which then implemented this interface, and the Os math libraries had support for this resource, but all of this was removed from the Os simply because the software interface was slow, actually slower than implementing the FPU operations in software in first place instead of emulating an FPU.


Thus, rather live with the mathieee-libraries, which would likely be faster than a software-defined manual I/O towards an external, non-integrated FPU.

[alexh]

You also have to consider that some 68LC060 and 68EC060 branded chips have an FPU in them but it's broken. The hardware inside is not disabled and there's no reliable way to distinguish them from full 060s. Trying to use any software that uses FPU can be difficult for these CPUs as they try to use the broken hardware

[Thomas Richter]

For the 68060, the situation is actually easy. The PCR register allows to distinguish between a full 68060 and a EC or LC model. Also, the LC and EC create a FPU-disabled exception whenever you attempt to execute an FPU instruction.
This is somewhat different to the MMU on the 68030 were you have no clear means of identifying whether it is broken or not.

[alexh]

Originally Posted by Thomas Richter

For the 68060, the situation is actually easy. The PCR register allows to distinguish between a full 68060 and a EC or LC model. Also, the LC and EC create a FPU-disabled exception whenever you attempt to execute an FPU instruction.

I have some early chips labelled XC68EC060RC50, they are Rev1 and their PCR decodes to full 68060, only the FPU doesn't work.

[Thomas Richter]

It seems the early EC/LS were produced from the same mask set, but Mot seem to have changed that with the 2G masks.