I'm looking for a cheap 68060 with MMU & FPU idealy a rev6...

A rev1 is ok too...

It's for a gift to SpeedGeek who have no money and work hard for the Amiga community...


Thanks,

I'm looking for a cheap 68060 with MMU & FPU idealy a rev6...

Cheap Rev 6 68060? Good luck on that one .

I have a spare rev 1 01F43G XC68060RC50 (RC=MMU+FPU) that is out of a working accelerator. I believe I overclocked it to 60MHz before I got my rev 6 68060. I live close to SpeedGeek so the shipping would probably only be 2-4 days.

I would trade for a set of 4 Lattice GAL16V8 10ns Low Heat for Amiga 3000D shipped to me in Kansas, U.S.A.

U701 = the IC with 1 white dot
U202 = the IC with 2 white dots
U203 = the IC with 3 white dots
U714 = the IC with 4 white dots

I'm not in any hurry for the GALs so it would be the next time you get around to burning some. I would ship the 68060 ASAP of course. Let me know.

Thanks from and for him !!

So, I'll send him one of my 040/060 adapter for his A3640...

Ok, free for you too ! Just let me you address in MP !

PM sent.

We'll see if SpeedGeek can make a slow A3640 fast .

any of these do ?

http://www.ic2ic.com/search.jsp?sSearchWord=MC68060&q=MC68060
http://www.ic2ic.com/search.jsp?sSearchWord=MC68060FE133&prefix=M

No problem. So you don't need the 68060 then?

That's between you and Cosmos but he really wants me to have this adapter which is useless without an 060.

You would also need a voltage regulator for a 68060. The 68060 is probably not worth it if you have to turn off the FPU (although you could use a cheaper EC/LC 68060 that overclocks more). Why doesn't the FPU work?

The 68040 is stronger in memory than the 68060 in some ways and it's very consistent in integer performance with any 68k code. The 68060 has twice the caches, higher clock speeds, better instruction and addressing mode timings (but missing int 32x32=64), superscalar (but needs optimized code for best performance), lower electrical draw and a better FPU. If you take away the 68060 FPU, the 68060 still wins easily in int speed but the 68040 is closer in no-hassle versatility and 68k compatibility.

How much faster are your access speeds to motherboard resources with a 68040 A3640? My CSMK3 68060 SysSpeed memory results:

Cache Read 283.44
ReadROMb 35.15
ReadROMw 65.62
ReadROMl 85.75
ReadFastb 38.34
ReadFastw 53.04
ReadFastl 65.41
WriteFastb 30.96
WriteFastw 48.18
WriteFastl 48.16
Fast2Fastb 17.99
Fast2Fastw 26.46
Fast2Fastl 29.93
Fast2Fastm 27.58
Fast2Fast16 37.04
ReadChipb 1.11
ReadChipw 2.22
ReadChipl 4.44
WriteChipb 1.69
WriteChipw 3.38
WriteChipl 6.75
Chip2Chipb 0.67
Chip2Chipw 1.33
Chip2Chipl 2.66
Chip2Chipm 2.68
Chip2Chip16 2.67
Fast2Chipb 1.68
Fast2Chipw 3.36
Fast2Chipl 6.72
Fast2Chipm 6.20
Fast2Chip16 6.70

The voltage regulator is included with the adapter. You only need to  disable the FPU for early startup then 68060.library enables the FPU at boot time.

My A3640 benchmarks are posted on the Amibay thread:

http://www.amibay.com/showthread.php?19993

P.S. The results are "Pure Bullsh*t" if you have the data cache enabled regardless of using SysSpeed or Bustest (unless your trying to determine the speed of the data cache).

The voltage regulator is included with the adapter. You only need to  disable the FPU for early startup then 68060.library enables the FPU at boot time.

I see. Perhaps the ROM early startup code Initializes the FPU with FRESTORE? The 68060 has a different sized stack frame that is incompatible with 68881-68040 FPU stack frames. Most 68060 libraries will patch the most common problem with FRESTORE (the FPU is not initialized for each shell program so the compiler or programmer needs to do it). FPU initialization code is possible that supports all 68881-68060 FPUs. This is what we did for the vbcc compiler which needs no patching:

__fpu_init:
     clr.l -(sp)
     clr.l -(sp)
     clr.l -(sp)
     frestore (sp)
     lea (12,sp),sp
     rte

It might be good to know if you want to try to fix the code in the ROM(s) and burn new ones.

My A3640 benchmarks are posted on the Amibay thread:

http://www.amibay.com/showthread.php?19993

P.S. The results are "Pure Bullsh*t" if you have the data cache enabled regardless of using SysSpeed or Bustest (unless your trying to determine the speed of the data cache).

Multiple reads of the same data with small buffers would measure cache performance. Large reads should have the affect of flushing the data cache and give reasonably good results. CopyBack data caching will slow down sequential (streaming) writes in most cases giving worse results. Caching is off for chip memory to begin with although the 68060 is able to use imprecise writes (allowing the use of a write buffer and speeding up writes). The actual performance is dependent on the code as well. SysSpeed results can't be compared to BusSpeedTest results for this reason and the actual data measurement may not be accurate. On a comparison basis with the caches on, I wouldn't say the results are all fantasy, but turning off the caches removes some variables.

@SpeedGeek & @Matthey
Gifts shipped !

One 68060 shipped from Kansas as well .

Utsource is the typical chinese chip peddler, they check/verify nothing and sell many fakes. I have seen them sell used pulls of chips as new that had the pins HASL(hot air solder leveled) to look somewhat new. Its estimated over 44% of chips out there are counterfeit/fakes now.

I clearly warned UTSource about theses fake 68060, but they continue to sell them on eBay... Unbelievable... No Fpu into = 68LC060

This one fake I received from UTSource :

I see. Perhaps the ROM early startup code Initializes the FPU with FRESTORE? The 68060 has a different sized stack frame that is incompatible with 68881-68040 FPU stack frames. Most 68060 libraries will patch the most common problem with FRESTORE (the FPU is not initialized for each shell program so the compiler or programmer needs to do it). FPU initialization code is possible that supports all 68881-68060 FPUs. This is what we did for the vbcc compiler which needs no patching:

__fpu_init:
     clr.l -(sp)
     clr.l -(sp)
     clr.l -(sp)
     frestore (sp)
     lea (12,sp),sp
     rte

It might be good to know if you want to try to fix the code in the ROM(s) and burn new ones.

It is more complicated than this. Yes, exec init uses an FRESTORE to test the presence of a FPU, but the problem does not go away by patching of this. The second problem is the exec task dispatcher, or rather the stack frame exec uses for saving the FPU context when it switches between tasks. The exec scheduler thus also requires patching to be able to work with 060's.  

What the 060 library does is that it *in addition* includes a patch to exec that discovers some popular mis-use cases of FRESTORE, most notably the MANX/C Compiler startup code which uses FRESTORE to initialize the FPU. The patch just detects this startup code and works around it.