68060 and the 68882

[Iggy]

Can a 68060 without an FPU use a 68882RC50 as a memory mapped peripheral?

What is the fastest overclock for a 68882?

[Iggy]

Yes, any 680x0 can use a 68882 as a memory mapped peripheral.
I've been able to clock several '882's to 60mhz. I would guess that the fastest would be in the range of 66-70mhz.

How about 75Mhz if heat sinked and fan cooled?

[Iggy]

Does anyone know how to get a hold of the creator of the Oxyron Patcher?
The last address I have is Achim Koyen, Nûbelfeld 49, D-24972 Quern, Germany.
Anyone know a newer address or better yet an e-mail address?

[Iggy]

>68882 - 32-bit FPU - Frequency: 16 - 50MHz

In my A3000D 030@25MHz, I've modded the 68882@25MHz to 50MHz!
In an (old) article, it was write that Commodore has tested these 68882 at 100MHz (information not confirmed!!).
So I think there is actually an operating margin, joekster is right: 50MHz can certainly work up to 66/70MHz!

Can you send me that article? 68EC060s are more over-clockable then standard 68060s. I'd like to experiment with combining an EC with an '82.

[Iggy]

AMINET: http://aminet.net/package/docs/hard/A3000-50

So, potentially, we could run a 75Mhz 68EC060 and a 50Mhz 68882 (both with heat sinks and fans) at 100Mhz?

[Iggy]

less work to just buy a fully working 060

Not very easy getting a 68060 to 100Mhz.

[Iggy]

I'd be surprised if the 68882 lived for very long at 100MHz as that's a factor of 2 overclock from their highest rating. Remember that the last mask 68060's run at 100MHz due to their improved manufacturing tolerances and also the fact they are 3.3v parts which dissipates less heat than 5V logic.

At 100MHz, and with appropriate care taken to the method (eg, trap and patch rather than trap and emulate) you'd probably be able to write a software floating point library that is faster than you'd get a 68882 running in any case.

Karlos, where can I learn about both trap and patch and trap and emulate? Specifically, I'm interested in the trapping of FPU calls and the potential to improve upon them.

[Iggy]

Trap and emulate is one of those things that the 680x0 programmer manuals will tell you about. All you are doing is implementing your own exception handler and then writing some code to deal with the exception (note that this all happens in supervisor state and you need to know the layout of your 680x0 exception stack frame which do vary from CPU to CPU).

You can write a handler to do some specific bit of work and then have it return. Normally, you'd write the handler to implement the unimplemented operation and return from the exception. However, you can go a step further and patch instead. Basically what you do here is modify the opcode that resulted in the exception and have it jump to a location of your choosing. If you are not fairly comfortable poking around in 680x0 supervisor mode this is not trivial to do, you have to be careful how much space there is to insert your jump and also you have to make sure you flush the instruction cache and so on. However, this is the basic gist of how tools like CyberPatcher and OxyPatcher do their magic.

I'm not sure if it will help you much but I played with some CPU exception handling a few years ago on 680x0 albeit for a different purpose:

http://www.amiga.org/forums/showthread.php?t=25181

In this case, I was using the CPU to trap illegal operations and have it invoke a language level exception mechanism (a C++ throw in this case). It does demonstrate some of the sneaky shenanigans you can get up to though.

A further question. On 68Ks without FPUs, do all floating point operations produce exceptions? Further, would it be possible to program an FPGA to emulate (or improve upon these trapped illegal opcodes?

[Iggy]

The 68060 would probably be faster with an all software floating point library in most cases. You should look at the Natami project if you want a faster 68k CPU and FPU.

Interesting idea. Are you suggesting that an EC processor with a software floating point library might be faster than using the built in FPU of a full 68060?

[Iggy]

Thanks matthey,
I haven't talked with Gunnar recently and I am aware that the best performance will result when the 68K is integrated into the FPGA.
But I did just exchange a message with another Natami team member, Peter. And he mentioned that the CQFP 68060 processor used one one of the 68K cards is the same processor I've been exploring. While it lacks an FPU and an MMU its clocked at a minimum of 75Mhz.
While I'm not concerned about the lack of an MMU, I was trying to find a work around for the FPU functions. If trapping exceptions and using a software library is plausible it might provide one solution.

[Iggy]

These processors are the same CQFP package 68060 used on one of the Natami 68060 boards. They should be rated at 75Mhz and do appear to be true EC components.
While I have heard rumors of over clocks as high as 133Mhz, I believe 100Mhz is a reachable goal.
The lack of an FPU is a disadvantage, but as '30 accelerators frequently use EC processors the added speed must offer some advantage,

[Iggy]

Sounds interesting. If I can find a way to develop trap and patch code that relies on a external memory mapped peripheral I may be able to increase the speed of the math operations.
An FPGA is not the only option for this peripheral, I'm also considering what could be done with an e300 class PPC (which would be cheaper than an FPGA).

[Iggy]

I fear that approach is taking you down the path towards cache coherency issues.

Remember, you would either have to make sure that any memory shared between both processors was either uncached by both, or you'd have to take care to flush cache lines, which can be expensive. All of which is taking you back to where PowerUP and WarpOS were, except you'd be getting cache issues per externally-handled instruction.

I was not thinking of caching at all. Just a very small memory mapped area for exchange.