Amiga.org
Amiga computer related discussion => Amiga Marketplace => Topic started by: Cosmos Amiga on July 31, 2014, 09:10:06 AM
-
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,
:)
-
Remember :
Maskset 01F43G = 0.60µm => rev1
Maskset 01G65V = 0.60µm => rev2
Maskset 02G59Y = 0.60µm => rev3 (LC/EC only)
Maskset 74E41J = 0.42µm => rev5
Maskset 71E41J = 0.32µm => rev6
(WARNING ON EBAY WITH UTSOURCE AND 68060RC60 : FAKE, I PURCHASED TWO, AND RETURNED = 68LC060 REBADGED WITHOUT FPU)
:)
-
I'm looking for a cheap 68060 with MMU & FPU idealy a rev6...
Cheap Rev 6 68060? Good luck on that one :D.
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.
-
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.
Thanks from and for him !!
So, I'll send him one of my 040/060 adapter for his A3640...
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
Ok, free for you too ! Just let me you address in MP !
:)
-
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 ;).
-
PM sent.
We'll see if SpeedGeek can make a slow A3640 fast ;).
Thanks guys, I really appreciate your generosity :) but there were a few reasons why I never built Mozart's adapter:
1) It's to tall to fit in an A3000D
2) The clock circuit needs to be modified to buffer PCLK so it can be used with the stock A3640 clock divider (74Fx803)*
3) It required some software patching (on a Zorro2 PCB) to disable the FPU (but Cosmos probably has exec.library patched by now).
Apparently, you haven't seen my 50MHz A3640 + 68030 state machine mod thread on Amibay?
P.S. Yes, a 50 MHz 060 is faster than a 50 MHz 040 and yes the 060 can run at higher clock speeds than 50 MHz but my A3640 outperforms even the fastest 3rd party 060 accelerators in access speed to all motherboard resources.
*My A3640 has a custom clock circuit which now only generates 50/100 MHz clocks but 99.99% of all A3640 owners still use the 74Fx803.
-
any of these do ?
http://www.ic2ic.com/search.jsp?sSearchWord=MC68060&q=MC68060
http://www.ic2ic.com/search.jsp?sSearchWord=MC68060FE133&prefix=M
-
Thanks guys, I really appreciate your generosity :) but there were a few reasons why I never built Mozart's adapter:
No problem. So you don't need the 68060 then?
1) It's too tall to fit in an A3000D
2) The clock circuit needs to be modified to buffer PCLK so it can be used with the stock A3640 clock divider (74Fx803)*
3) It required some software patching (on a Zorro2 PCB) to disable the FPU (but Cosmos probably has exec.library patched by now).
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?
P.S. Yes, a 50 MHz 060 is faster than a 50 MHz 040 and yes the 060 can run at higher clock speeds than 50 MHz but my A3640 outperforms even the fastest 3rd party 060 accelerators in access speed to all motherboard resources.
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
-
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).
-
@SpeedGeek & @Matthey
Gifts shipped !
:)
-
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 8).
-
Remember :
Maskset 01F43G = 0.60µm => rev1
Maskset 01G65V = 0.60µm => rev2
Maskset 02G59Y = 0.60µm => rev3 (LC/EC only)
Maskset 74E41J = 0.42µm => rev5
Maskset 71E41J = 0.32µm => rev6
(WARNING ON EBAY WITH UTSOURCE AND 68060RC60 : FAKE, I PURCHASED TWO, AND RETURNED = 68LC060 REBADGED WITHOUT FPU)
:)
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.
-
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 clearly warned UTSource about theses fake 68060, but they continue to sell them on eBay... Unbelievable...
This one fake I received from UTSource :
Maybe UTSource is the one doing the paint jobs.
The fake MC68060 looks pretty good, especially the mask information on the upper right hand corner. Looking at a real rev 6 68060, the Motorola symbol on the fake is too bold, the white dot on the fake is dark on the real one and the real one has barely legible writing ending in "02" turned 90 degrees at the bottom left hand corner. I have never seen a rev 6 MC68060RC60 which is probably rare enough that they are highly unlikely to be found circulating. Of course the actual Motorola 68060 chips, even rev 6 68060, do vary some in appearance also. My MC68060RC50 chips look more like the one on the Big Book of Amiga Hardware:
http://www.bboah.com/index.php?action=artikel&cat=68&id=2961&artlang=en&highlight=68060
-
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.
-
The fake MC68060 looks pretty good, especially the mask information on the upper right hand corner.
So, what are these fake 68060 in reality? An older mask, just painted over, or a different chip (LC, EC?). If these chips wouldn't have the bugs of the early masks, that would probably be even ok no matter whether Motorola manufactured them or not.
-
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.
Will FPU stack frames be generated by the exec task dispatcher if the FPU is not in use? Are there any FPU instructions in early startup before the possibility to do software patching? Perhaps a kickstart ROM chip for an Amiga without an FPU would be a good choice to start with?
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.
Of course the 68060.library would still be necessary. I was suggesting a minimally patched ROM that was good enough to make it out of early startup without crashing.
So, what are these fake 68060 in reality? An older mask, just painted over, or a different chip (LC, EC?). If these chips wouldn't have the bugs of the early masks, that would probably be even ok no matter whether Motorola manufactured them or not.
See Cosmos 2nd post in this thread.
(WARNING ON EBAY WITH UTSOURCE AND 68060RC60 : FAKE, I PURCHASED TWO, AND RETURNED = 68LC060 REBADGED WITHOUT FPU)
-
I have seen them sell used pulls of chips as new that had the pins HASL(hot air solder leveled) to look somewhat new.
HASL is a PCB finish. Has nothing to do with recycling components.
Yes utsource sells the same fake parts that every other Chinese broker does.. because they all source their parts from the same markets. Sometimes it's worth the risk. i.e. I have tons of 68SEC000 parts, some of them have suspect markings, but they all work and they were considerably cheaper than digikey so whatever. They could be 68EC000s for all I know.
There are guys in China that reimplement $5 chips using cheaper parts so if you think that your chances of getting a real chip that's worth around $200 from a broker in China are high you are bonkers.
If you don't want to pay the going rate but don't want to be stung look for sellers in the US or Europe that are dealing with surplus, liquidations etc.
-
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
No, we only need to disable the Fpu with these 040-060 adapters...
I tired to write "040-060 adapters", it's lame...
Need to find a name for them !
Any suggestions welcome ! Please, go go go...
I start :
ThunderDrome 060 ?
WaspNest 060 ?
EaglesRoad 060 ?
:)
-
move.l $0010.w,d2
lea _nofpu_060(PC),a0
move.l a0,$0010.w
moveq #2,d1
movec PCR,d0
and.l d1,d0 ; 2 = %0010
cmp.l d1,d0
beq.b _nofpu_060
fnop
movec d1,PCR ; = disable the 060 Fpu
_nofpu_060
move.l d2,$0010.w
This routine should works on every 68k : coders, it's ok ?
:)
-
This routine should works on every 68k : coders, it's ok ?
No. First, this code is supervisor only. Second, you do not know where the VBR is hanging around, or whether the CPU has a VBR in first place, so check ExecBase->AttnFlags first. Third, you do not know whether anyone else is trying to work on the autovectors at this moment, thus you should probably disable interrupts for the short while. (ori #$700,sr does that, it is restored as soon as you return from the supervisor mode.).
-
Hey, zero system mounted here : this code is for the very first line of the exec.library
-
Many thanks to my good friend SuperCosmos (and thanks to matthey also) for the 060 adapter and Rev. 1 CPU!!! :) ;)
After many hours of work (and some hair pulling, head scratching and saying a few 4 letter words) I finally got the adapter working! :cool:
First, was the hardware fix (getting my A3640 back to 25 MHz) and that was the relatively easy part. Then adding the PCLK skew compensation mod (again relatively easy).
Next, building a new Kickstart ROM compatible with the 060. Should have been relatively easy but very difficult due to some corrupt files in my Remus build directory. (Also, complicated a bit by the 2 separate 040 and 060 exec.library's needed). :furious:
Anyway, the end result is in A3660.jpg (for you curiosity seekers).
-
Super !
You can push 68060 rev1 at 60 Mhz : this will give you a +20% extra CPU power !!
A small fan glued on one side will help a lot to dissipate the heat into your A3000D desktop...
:)
-
@SpeedGeek
Awesome! I hope you do a full writeup when you are done playing.
You can push 68060 rev1 at 60 Mhz : this will give you a +20% extra CPU power !!
A small fan glued on one side will help a lot to dissipate the heat into your A3000D desktop...
Yea, there is a good chance 60MHz would work even in the 3000 case but a little extra cooling would be good. The 68060 would generate less heat than an overclocked 68040 for sure.
-
I would say NOT to OC any board that goes in a 3000D. Its hot enough already. These boards are rare and valuable why stress the components for just slight increase in speed? (That you need for what exactly??)
-
2 separate 040 and 060 exec.library's needed
Why can't you use a common library for both?
-
HASL is a PCB finish. Has nothing to do with recycling components.
Yes utsource sells the same fake parts that every other Chinese broker does.. because they all source their parts from the same markets. Sometimes it's worth the risk. i.e. I have tons of 68SEC000 parts, some of them have suspect markings, but they all work and they were considerably cheaper than digikey so whatever. They could be 68EC000s for all I know.
There are guys in China that reimplement $5 chips using cheaper parts so if you think that your chances of getting a real chip that's worth around $200 from a broker in China are high you are bonkers.
If you don't want to pay the going rate but don't want to be stung look for sellers in the US or Europe that are dealing with surplus, liquidations etc.
Its common in china to do solder pulls and relevel the solder on the legs to look new and pretty, HASL was the easiest way to describe it since it is basically the same thing,just on chip legs,obviously you can still tell quite easily.
no one said you would get a new full 060 cheap from china, but used pulls are common as here.
It is possible to get full 060's but its hit and miss.I have gotten some full chips with reasonable prices before, so i know its possible.
many times i just buy used MVME board to get real 060's when they are cheap enough.
-
@matthey
I've been very busy with software patching and debugging so I don't know when/if I'll find time to do a full writeup (Cosmos want's me to work on overclocking the adapter next). But thanks again for your assistance...
@NorthWay
Motorola made significant changes with each new generation of 68K CPU so code written for earlier generations usually needed some patching to make it work. Anyway, I now have a patched exec.library (45.20b) working with 030, 040 and 060! I'm sending it to Cosmos for additional beta testing, but as far as I'm concerned the Zorro2 PCB and Diag code @ $F00000 are obsolete... :D
-
Motorola made significant changes with each new generation of 68K CPU
I know. I patched my own Exec years ago to properly detect the 060, fix its status, and set the flags for it.
So I didn't really see the need for having more than one version.
-
I know. I patched my own Exec years ago to properly detect the 060, fix its status, and set the flags for it.
So I didn't really see the need for having more than one version.
I wasn't aware that you (or anyone else) had previously patched exec for the 060. Otherwise, I certainly would have been willing to try yours. What version of exec is your patch based on?
If it's and older version than BB2 some users may still prefer a newer version.
-
What version of exec is your patch based on?
The original 3.1 of course. I was in a friendly race with Piru to come up with fixes and features for it. I don't think he incorporated my subroutine call twists, and I'm also a bit of a purist so I changed many macro and local calls to use the APIs.
Apart from the 060 stuff I think Piru has all the goodies you can wish for.
Ah, I found the code - nearly the last thing before the fpu testing (just 2 more instructions before it)
********
**
** Manually turn off MMU! Needs real mmu...
**
********
moveq #0,d1
movec d1,TC
;
; Do the 68060 test - PCR register does not exist on other CPUs
;
bset #AFB_68060,d0 ; guess at 060
cs_Test060
movec PCR,d1 ; flunks if 040 and clears the 060 bit
cs_Test060done
btst #AFB_68060,d0
beq cs_Not040
and.l #2,d1
cmp.w #2,d1
beq cs_Not040
FNOP
movec d1,PCR ; clear some odd bit
cs_Not040
-
@NorthWay
Again, we are at the first top lines of the exec.library... Zero system mounted...
Remember : the goal is to disable the Fpu with a 68000/010/020/030/040/EC/LC compatibility...
:)
-
OK, as promised (to Cosmos) the first episode of A3660 overclocking has begun!
I attached a small cooling fan to the Rev. 1 CPU + Ramsey's CLK90 is modified for the A3000*.
Hopefully, as I acquire the additional components needed and time permitting clock speeds will increase with future episodes. ;)
*Note: There is no practical overclocking limit with the adapter itself.
-
OK, episode #2 of A3660 overclocking is completed!
This is the upper limit for this Rev. 1 CPU... Also, SDMAC is working at it's maximum CLK speed. I made a custom oscillator and added an extra 10 uF cap to the top PCB for this project.
Higher clock speeds are still possible but will require a late Rev. CPU and a custom timing hack to keep SDMAC happy.... ;)
-
OK, episode #3 of A3660 overclocking is completed!
Once again, many thanks to SuperCosmos for the rev. 6 060 (and for his patience with my stupid mistake delaying this update for another 2 months)
The custom oscillator I made used a dual frequency crystal so changing the frequency was quite easy. The more complex part of this episode was the CLK D4 GAL designed as the solution to keep SDMAC happy.
The CLK D4 GAL switches the mobo to a 1/4x clock during DMA so SDMAC is supplied with clock speed it can handle and the mobo runs at the 1/2x clock speed when the CPU masters the bus. See attached images.
This also works quite well with the 040 but I was really saving it for this episode! :)
Higher clock speeds are still possible but I will have to source some oscillators or crystals for the next episode. ;)
-
Good luck !!
:)
-
OK, episode #4 of A3660 overclocking is completed!
Unfortunately, SysSpeed becomes less accurate at higher clock speeds so I have included a Scout result as well.
The CLK_D4 GAL signal BGACK_040 is now connected to VCC. This always runs the mobo at the 1/4x clock speed. Also, more A3000 mobo and CLK90 timing mods were made to keep the following clocks skew compensated and stable:
68060 CPU = 80MHz
A3640 logic = 40MHz*
A3000 mobo = 20MHz
Note: Considering that the A3000 is a timing intolerant beast overclocking the mobo to 40MHz was not a practical consideration here. (http://www.a1k.org/forum/images/smilies/images/smilies/05.gif)
*A3640 state machine mod required
-
Note: Considering that the A3000 is a timing intolerant beast overclocking the mobo to 40MHz was not a practical consideration here. (http://www.a1k.org/forum/images/smilies/images/smilies/05.gif)
:laughing:
Beautiful work sir, as always! :)
Reminds me that one of these days I need to finish the speed hack you published a few years ago for the A2091. I still have one, half done, sitting on a shelf. Ugh! :(
-
OK, episode #4 of A3660 overclocking is completed!
Unfortunately, SysSpeed becomes less accurate at higher clock speeds so I have included a Scout result as well.
The CLK_D4 GAL signal BGACK_040 is now connected to VCC. This always runs the mobo at the 1/4x clock speed. Also, more A3000 mobo and CLK90 timing mods were made to keep the following clocks skew compensated and stable:
68060 CPU = 80MHz
A3640 logic = 40MHz*
A3000 mobo = 20MHz
Note: Considering that the A3000 is a timing intolerant beast overclocking the mobo to 40MHz was not a practical consideration here. (http://www.a1k.org/forum/images/smilies/images/smilies/05.gif)
*A3640 state machine mod required
Fantastic !
Will works on the A4000 ?
:)
-
Although I think that's awesome the 3640 doesn't have any memory, so it's of limited practical use.
-
Fantastic !
Will works on the A4000 ?
:)
It should work with the A4000 but I don't have one to test it on. I would expect the A4000 to have more flexible timing options for CLK90 since I'm lucky to find one which keeps Ramsey and SDMAC working at non-standard clock speeds. :rolleyes: