Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: matthey on August 09, 2013, 03:32:17 AM
-
I found some FPU related bugs in ThoR's Mu 68060.library that he will be addressing soon but affect the development of other software. Which 68060 library are users using most?
1) Mu 68060.library (Thomas Richter)
2) Phase 5 68060.library (Ralph Schmidt)
3) Apollo 68060 library
4) GVP-M 68060.library (Ralph Babel and Jeff Boyer)
5) Coenobium Developments 68060.library (Carsten Schlote)
6) Cosmos 68060.library
7) C= 68060.library (this may be an earlier version of option 4)
8) Other
-
My 1200 came with an Apollo 060 and the Apollo 68060.library of course. So I always used that without giving it a 2nd thought.
Is there something wrong with the Apollo 68060.library?
I seem to recall that Thor's library utilizes a very clever wrap-around the 4GB memory map trick to get superfast speed. Which of the other libraries do the same trick?
If a person uses WinUAE and they set CPU=68060 then which 68060.library should they use, if any?
And what if they set CPU=68060 + FPU=68882?
(So there are no unimplemented FPU instructions)
Also, does any of this stuff affect OxyPatcher/CyberPatcher ?
-
Commodore had a 68060.library?
-
My 1200 came with an Apollo 060 and the Apollo 68060.library of course. So I always used that without giving it a 2nd thought.
Is there something wrong with the Apollo 68060.library?
No. It may be slower and there may be some bugs but I'm not sure the Apollo works properly with any other 68060.library. The Apollo hardware is quirky.
I seem to recall that Thor's library utilizes a very clever wrap-around the 4GB memory map trick to get superfast speed. Which of the other libraries do the same trick?
I hadn't heard that. Do you mean virtually map some code/data to the upper (negative) 32k of addresses so absolute short addressing can be used? What did he put there?
If a person uses WinUAE and they set CPU=68060 then which 68060.library should they use, if any?
And what if they set CPU=68060 + FPU=68882?
(So there are no unimplemented FPU instructions)
I believe UAE will install all the missing instructions of the 68040 or 68060 when these processors are selected. If this is the case, then the answer may be none (installing a 68060.library may be slower). I recommend checking with the UAE documentation though.
Also, does any of this stuff affect OxyPatcher/CyberPatcher ?
OxyPatcher should work with any 68060.library. CyberPatcher may require the P5 68060.library and MuRedox may require the Mu 68060.library but I'm not sure.
-
Hiya,
I've got a Blizzard so I use the Phase 5 68060.library, when I had my Apollo I used the Apollo library.
I did have bit of a play with both Mu and Cosmos library but for speed and stability you can't beat the real thing.
-
Commodore had a 68060.library?
I thought so but maybe they stopped with the 68040.library? I don't even have the C= 68040.library on my HD anymore. It was really slow and the support was not very good. I have the Mu 68060.library installed and the P5 68060.library for backup. They are both fast with good emulation and few bugs. Only ThoR's version is still maintained as far as I know. He should have an update for the FPU emulation related bug I reported when he gets back home in a few weeks :).
I've got a Blizzard so I use the Phase 5 68060.library, when I had my Apollo I used the Apollo library.
I did have bit of a play with both Mu and Cosmos library but for speed and stability you can't be the real thing.
The P5 library is fast but the Mu library was a little faster on my P5 CSMK3 when I put the Kickstart in MAPROM with BlizKick and added "MuFastZero MOVESSP ON" to my S:Startup-Sequence. The Mu library also uses and patches the utility.library with my fast integer 32x32=64 code which I don't think the P5 library can match ;). The P5 library doesn't require the tweaking and configuring that the Mu library does though. In my experience, they are both great choices for anyone that can use them.
-
Thor's 68060.library +MuRedox on my CS060 Mk2
-
A new 68060.library version for Phase5 boards is actually on test here :
68060.library v46.21
- v46.20 -> v46.21
- Removed Cyberpatcher support (users must use the very better OxyPatcher)
- Added faster Autovectors (http://leblogdecosmos.blogspot.fr/2012/05/code-optimisation-iii.html)
- _ffloord optimized (mathieeedoubtrans.library)
- _fceild optimized (mathieeedoubtrans.library)
- _fsind optimized (mathieeedoubtrans.library)
- _fcosd optimized (mathieeedoubtrans.library)
:)
-
ThoR has released a fix for the Mu 68060.library FPU bugs:
http://aminet.net/util/sys/Mu680x0Libs.lha http://aminet.net/package/util/sys/Mu680x0Libs
My tests so far have shown it to be a successful fix. If any one has any problems with it then please send ThoR a report and/or post here.
-
ThoR has released a fix for the Mu 68060.library FPU bugs:
http://aminet.net/util/sys/Mu680x0Libs.lha http://aminet.net/package/util/sys/Mu680x0Libs
My tests so far have shown it to be a successful fix. If any one has any problems with it then please send ThoR a report and/or post here.
Thanks for the heads up Matt, much appreciated.
Thanks to Thor too if you are reading this. :)
-
in case there is anyone interested to check, perhaps there is any room to improve aros 680x0.library inparallel. sorry to sound like broken record but thanks to mattheys hint on the other thread a huuuge lag in aros graphics.library could be identified, hopefully to be fixed soon.
-
in case there is anyone interested to check, perhaps there is any room to improve aros 680x0.library inparallel. sorry to sound like broken record but thanks to mattheys hint on the other thread a huuuge lag in aros graphics.library could be identified, hopefully to be fixed soon.
On a related note, does PeterK's icon.library work on AROS 68k?
-
in case there is anyone interested to check, perhaps there is any room to improve aros 680x0.library inparallel. sorry to sound like broken record but thanks to mattheys hint on the other thread a huuuge lag in aros graphics.library could be identified, hopefully to be fixed soon.
I wasn't working on the 680x0.library when I found the bug. I was testing the results of some vbcc C99 math functions against the trapped FPU 68881/68882 instructions. I'm amazed at how many major bugs I've found lately in software that has been out for so long of time. I think a good 68k compiler is an important key to AROS 68k's success. I know vbbc doesn't currently produce AROS code but I expect that will change when it gets good enough. With all the 3D programming and porting you've done, would you appreciate a compiler that has better C99 math support than GCC 3.4.0? You want to try it out?
On a related note, does PeterK's icon.library work on AROS 68k?
The newest versions should. Peter fixed a few things in the last couple of versions to get it working.
-
The newest versions should. Peter fixed a few things in the last couple of versions to get it working.
Oh good, that should make a big speed difference. I need to create an AROS partition on my A3000 to test how it works on an 060 with PIV and generate some bug reports for the AROS team.
Hopefully over time we can all contribute a bit here and there in different areas depending on expertise and make AROS a fit successor to 3.x.
-
On a related note, does PeterK's icon.library work on AROS 68k?
yes. and its quite a boost. ill try to roughly profile aros icon.lib against it next, after the bltbitmap issue is outta the way. perhaps it gives some results about critical parts, if need be to solve by asm inlines.
Hopefully over time we can all contribute a bit here and there in different areas depending on expertise and make AROS a fit successor to 3.x.
thats my hope, a fully open extended amiga os.
-
I wasn't working on the 680x0.library when I found the bug. I was testing the results of some vbcc C99 math functions against the trapped FPU 68881/68882 instructions. I'm amazed at how many major bugs I've found lately in software that has been out for so long of time. I think a good 68k compiler is an important key to AROS 68k's success. I know vbbc doesn't currently produce AROS code but I expect that will change when it gets good enough. With all the 3D programming and porting you've done, would you appreciate a compiler that has better C99 math support than GCC 3.4.0? You want to try it out?
alas its till not within reach, and even if i had any influence upon that there are technical issues in its way. it has been discussed again and again. i fear we have to live with it for now except someone will suddenly emerge who will take care of it.
-
yes. and its quite a boost. ill try to roughly profile aros icon.lib against it next, after the bltbitmap issue is outta the way. perhaps it gives some results about critical parts, if need be to solve by asm inlines.
thats my hope, a fully open extended amiga os.
Yeah, what OS4/MorphOS should have been. :)
I think you already know about the 68k assembly dos.library/scsi.device/graphics.library etc replacements on EAB.
It would be great if these things could be merged into the AROS 68k source tree if possible, obviously where it makes sense to do so for performance and compatibility reasons.
-
alas its till not within reach, and even if i had any influence upon that there are technical issues in its way. it has been discussed again and again. i fear we have to leave with it for now except someone will suddenly emerge who will take care of it.
I spent the best part of two days modifying a small tool I wrote in C for MorphOS with GCC4 to also compile without complaint with VBCC for MorphOS, VBCC for 68k and SAS/C 6.58 for 68k.
It was a very labourious (though actually quite interesting) excercise so I can't even begin to imagine the mammoth size task it would take to modify the source tree of an entire operating system to compile with something other than GCC!
-
I spent the best part of two days modifying a small tool I wrote in C for MorphOS with GCC4 to also compile without complaint with VBCC for MorphOS, VBCC for 68k and SAS/C 6.58 for 68k.
It was a very laborious (though actually quite interesting) exercise so I can't even begin to imagine the mammoth size task it would take to modify the source tree of an entire operating system to compile with something other than GCC!
AROS was suppose to avoid the GCC-isms but it's not the easiest thing to do. My understanding is that there are only a few but that they are heavily used and difficult to avoid. The new version of vbcc will have improved C99 support and many bug fixes which should help compatibility with GCC. AROS vbbc support will take some sitting down by the brains behind AROS with Frank Wille to come up with some solutions. Vbbc has some advantages over GCC that I think will become more apparent soon. It is more portable because it's small and has less compiler dependencies. I can compile vbbc with vbbc on my 68060 Amiga in a couple of hours. I can't imagine doing that with GCC. The other advantage is that it doesn't use double memory indirect addressing modes. There are some 68k fpga processors being created that would prefer to drop these addressing modes (with a new 68k ISA hopefully). Vbbc (and vasm) will need less modifications and be easier to add support for these new enhanced 68k fpga processors.
-
AROS was suppose to avoid the GCC-isms but it's not the easiest thing to do. My understanding is that there are only a few but that they are heavily used and difficult to avoid. The new version of vbcc will have improved C99 support and many bug fixes which should help compatibility with GCC. AROS vbbc support will take some sitting down by the brains behind AROS with Frank Wille to come up with some solutions. Vbbc has some advantages over GCC that I think will become more apparent soon. It is more portable because it's small and has less compiler dependencies. I can compile vbbc with vbbc on my 68060 Amiga in a couple of hours. I can't imagine doing that with GCC. The other advantage is that it doesn't use double memory indirect addressing modes. There are some 68k fpga processors being created that would prefer to drop these addressing modes (with a new 68k ISA hopefully). Vbbc (and vasm) will need less modifications and be easier to add support for these new enhanced 68k fpga processors.
I really like vbcc, it's very fast at compiling and produces well performing binaries on both 68k Amigas and MorphOS. It has a lot of potential and Frank really looks/sounds like he knows what he is doing and seems very passionate about his work which shows quite clearly in the end product.
For 68k code, which would you say currently creates the best performing binaries; SAS/C, GCC2, GCC3, GCC4 or VBCC?
In particular which produces binaries that perform best on an 060. Any particular recommended compiler switches?
One thing I like about GCC from v4.2 upwards is "-march=native" which detects the host machine's capabilities and automatically switches on the best flags for it. Combined with -O2 it creates very well performing binaries.
I don't know if vbcc has something similar?
/Sorry for derailing the thread everyone.
-
I really like vbcc, it's very fast at compiling and produces well performing binaries on both 68k Amigas and MorphOS. It has a lot of potential and Frank really looks/sounds like he knows what he is doing and seems very passionate about his work which shows quite clearly in the end product.
Frank is amazing! He deserves an award for his Amiga support. The nice thing is that he is not biased and supports everything Amiga. You get the best tech support in the world with Frank and it's free. He's a pretty good programmer too ;).
For 68k code, which would you say currently creates the best performing binaries; SAS/C, GCC2, GCC3, GCC4 or VBCC?
I think the unofficial Amiga version of GCC 2.95.3 is the best for most code. It's not the most advanced with optimizations or features but it generates consistently better than average code with few bugs. The unofficial Amiga version of GCC 3.4.0 is more advance and sometimes faster but it has a few bugs, some of which affect optimization. It's code quality can vary a lot but is generally average overall. Vbcc code quality is about on par with GCC 3.4.0 but can vary a lot also. It does some very advanced optimizations but then other generated code is obviously poor (but usually still works). Vbbc does use Frank's vasm which is the ultimate peephole optimizing assembler. It helps a lot and would benefit the other compilers if used. SAS/C is an old mature compiler. It's not advanced but the basic code generation is solid with few bugs. Some of the library link code is not the best for new processors like the 68060. Most of the classic AmigaOS is written with SAS/C so it can't be too bad but it's still pretty average code generation quality IMO. The early GCC 4.x versions generated poor 68k code. Supposedly the newest versions of GCC are better.
In particular which produces binaries that perform best on an 060. Any particular recommended compiler switches?
That's a tough call. No compiler really does much to optimize for the 68060. A good instruction scheduler would do wonders for the 68060, especially with mixed integer and FPU code. Frank mentioned something about Volker adding an instruction scheduler but I wouldn't expect anything soon. I did improve the 68060 integer 64x64=64 vclib code which is about twice as fast as GCC 3.4.0. Vbcc will be getting a m060.lib for the FPU that I have been working on and some more optimal and bug fixed FPU code in the backend, but the direct FPU support is still pretty raw. It will take some time to iron out bugs. Vasm optimizes double and extended precision fp immediates down if possible. This saves a lot of code and a few cycles. GCC still doesn't do this. GCC FPU generated code since 2.95.3 has been ok with less bugs than vbbc. The older versions of GCC use trapped instructions and don't support the 68060 as well. Some of the GCC 3.4.0 FPU code is slow as it uses the IEEE math libraries too much. The 68040 received pretty good support in GCC unlike the 68060, probably due to the 68k Macintosh.
One thing I like about GCC from v4.2 upwards is "-march=native" which detects the host machine's capabilities and automatically switches on the best flags for it. Combined with -O2 it creates very well performing binaries.
I don't know if vbcc has something similar?
No. Vbbc doesn't have anything like "-march=native" although it wouldn't be that difficult to add an option that looks at the Amiga SysBase->AttnFlags (I added an option like that in my version of the ADis disassembler). It also doesn't have any options for selecting a range of processors. However, using "-cpu=68060 -fpu=68060" and linking with the new "-lm060" should generate code that is optimized for the 68060 but works well on the 68020-68060 CPU and 68881-68060 FPU. Most 68040 programmers will want to link with "-lm060" or "-lmieee" instead of "-lm040" due to the greatly reduced precision of some functions on the 68040 because of the lack of FINT/FINTRZ (huge design mistake). My plan for the "-lm040" library is to provide high speed low precision functions without trapping. The current m040.lib is a combination of low precision and trapped FINT/FINTRZ. I've just made it more consistent. Vbbc generates much better quality code already with "-O1". It's usually an improvement to use "-O2" but not always. "-O3" didn't do much on the 68k in my experience. Some of the higher level optimizations are still not implemented for the 68k. The new version of vbbc will generate SAS/C style debugging info with the "-g" option on the 68k Amiga. This allows source level debugging with powerful gui debuggers like BDebug (Barfly) and CPR (SAS/C).
-
The early GCC 4.x versions generated poor 68k code. Supposedly the newest versions of GCC are better.
i once have benchmarked the same machine with aibb under aros and genuine kickstart for comparison and the results in most areas were the same. how would that be if gcc4.6.2 (this is the currently used version i guess) was so bad overall?
my impression is that you cant blame the compiler for aros performance flaws. its design decisions, missing, not efficient or simply wrong code, all that to be found and fought one by one.
-
So, for WinUae, what is the reccommended library when emulating the 060?.
-
Frank is amazing! He deserves an award for his Amiga support. The nice thing is that he is not biased and supports everything Amiga. You get the best tech support in the world with Frank and it's free. He's a pretty good programmer too ;).
Yeah he's one of the Rock Star Coders of the Amiga scene for sure! :)
I think the unofficial Amiga version of GCC 2.95.3 is the best for most code. It's not the most advanced with optimizations or features but it generates consistently better than average code with few bugs. The unofficial Amiga version of GCC 3.4.0 is more advance and sometimes faster but it has a few bugs, some of which affect optimization. It's code quality can vary a lot but is generally average overall. Vbcc code quality is about on par with GCC 3.4.0 but can vary a lot also. It does some very advanced optimizations but then other generated code is obviously poor (but usually still works). Vbbc does use Frank's vasm which is the ultimate peephole optimizing assembler. It helps a lot and would benefit the other compilers if used. SAS/C is an old mature compiler. It's not advanced but the basic code generation is solid with few bugs. Some of the library link code is not the best for new processors like the 68060. Most of the classic AmigaOS is written with SAS/C so it can't be too bad but it's still pretty average code generation quality IMO. The early GCC 4.x versions generated poor 68k code. Supposedly the newest versions of GCC are better.
Thanks for the info, very useful. Regarding the Amiga OS, what about 3.5 and 3.9? Do you know whether H&P used their own atrocious StormC 3 compiler or GCC/StormC 4 or even SAS/C?
That's a tough call. No compiler really does much to optimize for the 68060. A good instruction scheduler would do wonders for the 68060, especially with mixed integer and FPU code. Frank mentioned something about Volker adding an instruction scheduler but I wouldn't expect anything soon. I did improve the 68060 integer 64x64=64 vclib code which is about twice as fast as GCC 3.4.0. Vbcc will be getting a m060.lib for the FPU that I have been working on and some more optimal and bug fixed FPU code in the backend, but the direct FPU support is still pretty raw. It will take some time to iron out bugs. Vasm optimizes double and extended precision fp immediates down if possible. This saves a lot of code and a few cycles. GCC still doesn't do this. GCC FPU generated code since 2.95.3 has been ok with less bugs than vbbc. The older versions of GCC use trapped instructions and don't support the 68060 as well. Some of the GCC 3.4.0 FPU code is slow as it uses the IEEE math libraries too much. The 68040 received pretty good support in GCC unlike the 68060, probably due to the 68k Macintosh.
I'm hoping that the recently ressurected 68k branch of Debian will lead to better 060 code generation from GCC4.
No. Vbbc doesn't have anything like "-march=native" although it wouldn't be that difficult to add an option that looks at the Amiga SysBase->AttnFlags (I added an option like that in my version of the ADis disassembler). It also doesn't have any options for selecting a range of processors. However, using "-cpu=68060 -fpu=68060" and linking with the new "-lm060" should generate code that is optimized for the 68060 but works well on the 68020-68060 CPU and 68881-68060 FPU. Most 68040 programmers will want to link with "-lm060" or "-lmieee" instead of "-lm040" due to the greatly reduced precision of some functions on the 68040 because of the lack of FINT/FINTRZ (huge design mistake). My plan for the "-lm040" library is to provide high speed low precision functions without trapping. The current m040.lib is a combination of low precision and trapped FINT/FINTRZ. I've just made it more consistent. Vbbc generates much better quality code already with "-O1". It's usually an improvement to use "-O2" but not always. "-O3" didn't do much on the 68k in my experience. Some of the higher level optimizations are still not implemented for the 68k. The new version of vbbc will generate SAS/C style debugging info with the "-g" option on the 68k Amiga. This allows source level debugging with powerful gui debuggers like BDebug (Barfly) and CPR (SAS/C).
That would be very handy, I've not really had any experience with Ralph's Barfly or it's GUI debugger but I do like the SAS/C debugger as it "just works". Well, most of the time anyway. lol
Thanks again for the info, it's always an educational experience for me when you answer any questions I have about Amiga stuff. :)
Slightly OT question, but would your CopyMem routines be a good fit to merge into the 68k AROS source? I imagine they'd speed it up a great deal.
I asked Matthias Henze who wrote the HSMathLibs if he'd consider donating the source for his libs to the AROS team because he doesn't get many registrations these days (Though I tell everyone I can to buy them) but he didn't reply to that specific question so I took it as a no.
It's a shame, as there are quite a few performance patches for 68k machines that if the source were donated to AROS could be included in the OS by default and make 68k AROS a much better experience than it currently is.
The WarpDT datatypes come to mind as a random example.
-
i once have benchmarked the same machine with aibb under aros and genuine kickstart for comparison and the results in most areas were the same. how would that be if gcc4.6.2 (this is the currently used version i guess) was so bad overall?
my impression is that you cant blame the compiler for aros performance flaws. its design decisions, missing, not efficient or simply wrong code, all that to be found and fought one by one.
Well you can't blame the compiler for design flaws within AROS but a better optimizing compiler is always a good thing to have/wish for. :)
-
No 68060.library.
I just run dual 68030 libraries ...
-
No 68060.library.
I just run dual 68030 libraries ...
Yeah, from what I understand it doesn't really emulate an 060 it just shows the CPU to the emulated Amiga as an 060 but the missing instructions from the previous CPU models are still there so the 060 libs aren't needed.
-
i once have benchmarked the same machine with aibb under aros and genuine kickstart for comparison and the results in most areas were the same. how would that be if gcc4.6.2 (this is the currently used version i guess) was so bad overall?
my impression is that you cant blame the compiler for aros performance flaws. its design decisions, missing, not efficient or simply wrong code, all that to be found and fought one by one.
The newest versions of GCC 4 have improved the 68k code generation and fixed bugs. It's as good as most of the old 68k compilers now. Some of those new fancy optimizations work on the Amiga. However, judging by the only new GCC compiler code I've looked at (ffmpeg), it doesn't schedule instructions for the 68060, it uses bitfield instructions way to much for the 68060 (shift+mask is usually faster in registers) and the FPU support is worse than earlier versions of GCC but probably not used much by AROS. The new version of vbbc should have no problems beating the FPU code quality when it's debugged. Piotr tried compiling ffmpeg without bitfields and it didn't make much difference so I would expect some of these large complex programs are cache/memory bound on the 68060. We saw the same with NovaCoder's AmiQuake 2 where some of the assembler optimizations I did didn't make much different. Optimizations can still help but not nearly as much. Shrinking the code enough with optimizations so it fits in the Icache might fix the problem but that is not possible with some large complex programs and the small (compared to modern processors) 68060 caches. The 68060 may run out of Dcache processing some data also.
So, for WinUae, what is the recommended library when emulating the 060?.
I believe it's generally best to emulate a 68040 and not the 68060. If you do emulate a 68060, ThoR's Mu 68060.library does try to detect the processor correctly. There was an old thread over on EAB where someone successfully used the Mu 68060.library with 68060 emulation while most alternatives did not work. Personally, I don't have much experience with WinUAE.
Thanks for the info, very useful. Regarding the Amiga OS, what about 3.5 and 3.9? Do you know whether H&P used their own atrocious StormC 3 compiler or GCC/StormC 4 or even SAS/C?
AmigaOS 3.5 and 3.9 is mostly SAS/C code also. This is probably because the old projects were SAS/C and, as you know, it takes some effort to convert to a new compiler. The picture.datatype is GCC compiled (has 68060 trapped int 32x32=64 instructions too). There are probably some other GCC utilities but the workbench.library and diskfont.library are SAS/C for example. I don't think any code was compiled with StormC 3. Was StormC 4 (with GCC compiler) out by AmigaOS 3.9? Some of the Warp3D libraries had atrociously bad code that I didn't recognize as GCC code. I didn't know if it was pre-EGCS (2.95) GCC or StormC 3 as I haven't seen much code that bad fortunately.
That would be very handy, I've not really had any experience with Ralph's Barfly or it's GUI debugger but I do like the SAS/C debugger as it "just works". Well, most of the time anyway. lol
BDebug is my default debugger. It's very powerful but could be easier to use for beginner source level debugging. CPR is also a good debugger and could ease the transition of SAS/C developers to vbbc. Vbbc doesn' have many extra tools like an integrated editor and debugger so this is very important.
Slightly OT question, but would your CopyMem routines be a good fit to merge into the 68k AROS source? I imagine they'd speed it up a great deal.
I asked Matthias Henze who wrote the HSMathLibs if he'd consider donating the source for his libs to the AROS team because he doesn't get many registrations these days (Though I tell everyone I can to buy them) but he didn't reply to that specific question so I took it as a no.
It's a shame, as there are quite a few performance patches for 68k machines that if the source were donated to AROS could be included in the OS by default and make 68k AROS a much better experience than it currently is.
The WarpDT datatypes come to mind as a random example.
All my Amiga code is free with sources available. The AROS devs have my code and I expect some of it has been integrated in some form. If we can't revive the Amiga then it's not going to do anyone any good.
-
The newest versions of GCC 4 have improved the 68k code generation and fixed bugs. It's as good as most of the old 68k compilers now. Some of those new fancy optimizations work on the Amiga.
No way! :crazy: What happened? Pigs started flying? Hell froze over? :mickeymouse:
-
All my Amiga code is free with sources available. The AROS devs have my code and I expect some of it has been integrated in some form. If we can't revive the Amiga then it's not going to do anyone any good.
Amen to that! :)
-
The newest versions of GCC 4 have improved the 68k code generation and fixed bugs. It's as good as most of the old 68k compilers now.
its my impression, but im not an expert;) like you.
it doesn't schedule instructions for the 68060, it uses bitfield instructions way to much for the 68060 (shift+mask is usually faster in registers) and the FPU support is worse than earlier versions of GCC but probably not used much by AROS.
aros is not compiled with 68060 target, im not sure what target it actually is but i guess widest common denominator, either 020 or even 000. however the fpu effectivity is wort to check, thanks for reminder.
Piotr tried compiling ffmpeg without bitfields and it didn't make much difference so I would expect some of these large complex programs are cache/memory bound on the 68060. We saw the same with NovaCoder's AmiQuake 2 where some of the assembler optimizations I did didn't make much different. Optimizations can still help but not nearly as much.
toni calls it micro optimisations. probably this should really wait, but peter k's icon lib proves worthy to take care of it already where its due.
All my Amiga code is free with sources available. The AROS devs have my code and I expect some of it has been integrated in some form. If we can't revive the Amiga then it's not going to do anyone any good.
certainly, your code patches for mem copy are applied by aros setpatch depending on what cpu be detected. thats all how cpu bound optimisations are currently haldled on aros, as patches for the sensible functions, and i think its a good way. jason have introduced these inlines (?) you are probably mentioned in the sources.
-
OxyPatcher should work with any 68060.library. CyberPatcher may require the P5 68060.library and MuRedox may require the Mu 68060.library but I'm not sure.
First of all, thanks to Matt for reporting bugs, which finally got fixed.
To answer the last question: MuRedox requires the mmu.library and the fpsp.resource, so "technically speaking" it does not require the 68060.library from the MMU project. However, since that's the only library that offers the fpsp.resource... The point is, when writing MuRedox and updating the mathieee... libs, I shurely didn't want to re-invent the wheel and re-implement emulation code for math instructions, even more so as all the code was already there, and tested. Thus the resource.
-
A new 68060.library version for Phase5 boards is actually on test here :
68060.library v46.21
- v46.20 -> v46.21
- Removed Cyberpatcher support (users must use the very better OxyPatcher)
- Added faster Autovectors (http://leblogdecosmos.blogspot.fr/2012/05/code-optimisation-iii.html)
- _ffloord optimized (mathieeedoubtrans.library)
- _fceild optimized (mathieeedoubtrans.library)
- _fsind optimized (mathieeedoubtrans.library)
- _fcosd optimized (mathieeedoubtrans.library)
:)
The problem with any optimizations is that it is so easy to get something wrong. The trouble is, a FSIN emulation has to do more than just compute the sine of its argument. It also has to set all condition codes correctly, and return the FPU in exactly the state the "real thing" would have done. Which is more than the result. Just to give you an idea: The fpsp FMOD code looks "needlessly complicated", but in fact is not. Besides the condition codes, the "inexact" flag, the result and testing for special conditions like very large or very small arguments, the FPU also has a (relatively unknown) "quotient byte" that needs to be computed and filled in - correctly. Obviously, if you "just" wanted the remainder to be computed, all that is superfluous. But fpsp does a lot more than that, it emulates the complete instruction with all the consequences - which for the 68060.library *also* means taking traces and emulating a bus error in case you hit unmapped memory.
So, in general, this is a big "hands off" unless you know precisely what you're doing. That said, given the bugs Matt detected, I neither do that.
-
I voted "Other" in the poll.
My main system is a Macrosystem DraCo and it uses a custom 68060.library called DraCo060Emu (see attachment).
I would like to use a more current one, not so obscure, and still supported 68060.library like the one from Thomas Richter, but I am afraid I could make a bad choice and break something, since a DraCo is quite an obscure system in many aspects.
Any suggestion is welcomed.
-
The problem with any optimizations is that it is so easy to get something wrong.
The worst anyone can do on Amiga Classic is doing nothing...
Clever guys help me to improve again and again this library (or other) and stupid guys blablabla on forum...
-
Thomas technical description is very interresting.
-
The worst anyone can do on Amiga Classic is doing nothing...
Clever guys help me to improve again and again this library (or other) and stupid guys blablabla on forum...
Excuse me, but since when do I "bla bla" without doing anything... (-: It's low profile, slow going since I've a lot of other things to do these days, but if you want to do something truely useful, document what it takes to support P5 hardware since that you have apparently successfully reverse engineered it, or even have sources.
-
@ThoR
Welcome to amiga.org.
The problem with any optimizations is that it is so easy to get something wrong. The trouble is, a FSIN emulation has to do more than just compute the sine of its argument. It also has to set all condition codes correctly, and return the FPU in exactly the state the "real thing" would have done. Which is more than the result. Just to give you an idea: The fpsp FMOD code looks "needlessly complicated", but in fact is not. Besides the condition codes, the "inexact" flag, the result and testing for special conditions like very large or very small arguments, the FPU also has a (relatively unknown) "quotient byte" that needs to be computed and filled in - correctly. Obviously, if you "just" wanted the remainder to be computed, all that is superfluous. But fpsp does a lot more than that, it emulates the complete instruction with all the consequences - which for the 68060.library *also* means taking traces and emulating a bus error in case you hit unmapped memory.
It sounds like each emulated function would need 1/2 a page or more of documentation specifying requirements, warning about what to avoid and listing changes. The FPU instructions have a lot of variations too. Most errors would go unnoticed with subtle changes in behavior. I was surprised the not so minor bug you just fixed didn't cause more problems. Then again, the vbbc fp->unsigned int and fp<->64 bit int (both ways) conversion functions had major bugs and most programs still worked. Compilers are where we need to fix code so we don't have to call these dinosaurs any more.
-
@ThoR
hi! have you ever planned opensourcing your MMU.library & tools? I guess it could be a great addition to AROS and would probably bring some new life to our classics :-) Maybe somebody like Matthey could add some improvements, who knows.
-
@thomas: pls. update your lha-archiver, your lib has a 1980-datestamp ;)
-
@ThoR
hi! have you ever planned opensourcing your MMU.library & tools? I guess it could be a great addition to AROS and would probably bring some new life to our classics :-) Maybe somebody like Matthey could add some improvements, who knows.
+1 to ThoR's stuff being in AROS.
Wawrzon mentioned that Matt's ultra-fast 060 CopyMem routines are already in the AROS m68k Setpatch.
-
@ThoR
hi! have you ever planned opensourcing your MMU.library & tools? I guess it could be a great addition to AROS and would probably bring some new life to our classics :-) Maybe somebody like Matthey could add some improvements, who knows.
most what i ever needed thors 060 and mmu libraries was his muforce. now, aros (68k) has already both 060 library functionality (within the 680x0.library, based on the same open sources all other 060 libs are based on) and enforcer functionality to be turned on/off at boot time. that said having thor as consultant on above matters (and more) would certainly be quite a gain for aros team. but i doubt he has enough time and interest, especially his doubt afair was always if aros can become compatible enough.
-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: March 1994
Readme file for the 060 Software Package -- Beta Release B1 --
Read the fpsp.doc, fplsp.doc, isp.doc, ilsp.doc and test.doc
files for information about these different packages.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Files in this directory:
-------------------------
fpsp.sa Full FP Kernel Module - hex image
fpsp.s Full FP Kernel Module - source code
fpsp.doc Full FP Kernel Module - on-line documentation
pfpsp.sa Partial FP Kernel Module - hex image
pfpsp.s Partial FP Kernel Module - source code
fplsp.sa FP Library Module - hex image
fplsp.s FP Library Module - source code
fplsp.doc FP Library Module - on-line documentation
isp.sa Integer Unimplemented Kernel Module - hex image
isp.s Integer Unimplemented Kernel Module - source code
isp.doc Integer Unimplemented Kernel Module - on-line doc
ilsp.sa Integer Unimplemented Library Module - hex image
ilsp.s Integer Unimplemented Library Module - source code
ilsp.doc Integer Unimplemented Library Module - on-line doc
fskeleton.s Sample Call-outs needed by fpsp.sa and pfpsp.sa
iskeleton.s Sample Call-outs needed by isp.sa
os.s Sample Call-outs needed by fpsp.sa, pfpsp.sa, and isp.sa
ftest.sa Simple test program to test that {p}fpsp.sa
was connected properly; hex image
ftest.s above test; source code
itest.sa Simple test program to test that isp.sa was
connected properly; hex image
itest.s above test; source code
test.doc on-line documentation for {i,f}test.sa
README This file
ERRATA Known errata for this release
Did Commodore ever released some o6o-stuff out of the early moto-beta-archive?
-
+1 to ThoR's stuff being in AROS.
Wawrzon mentioned that Matt's ultra-fast 060 CopyMem routines are already in the AROS m68k Setpatch.
thor has always mentioned that he doesnt particularly like to open stuff to just everybody, in order to avoid it to be messed up by incompetence. i have talked to him about aros once in private (thomas, you remember?) so i guess if he wanted to particularly support aros he would do already. i for my part dont want to make demands of anybody, accept and understand the standpoint.
-
most what i ever needed thors 060 and mmu libraries was his muforce. now, aros (68k) has already both 060 library functionality (within the 680x0.library, based on the same open sources all other 060 libs are based on) and enforcer functionality to be turned on/off at boot time. that said having thor as consultant on above matters (and more) would certainly be quite a gain for aros team. but i doubt he has enough time and interest, especially his doubt afair was always if aros can become compatible enough.
With PeterK's icon.library, Matt Hey's CopyMem routines, ThoR's stuff, Mathias Henze's HSMathLibs and Oliver Robert's WarpDT datatypes, AROS m68k would be much better than it is now.
It's a shame the dos.library/scsi.device/graphics.library stuff on EAB can't be used as they are Resourced from the copyrighted CBM versions. :(
-
With PeterK's icon.library, Matt Hey's CopyMem routines, ThoR's stuff, Mathias Henze's HSMathLibs and Oliver Robert's WarpDT datatypes, AROS m68k would be much better than it is now.
It's a shame the dos.library/scsi.device/graphics.library stuff on EAB can't be used as they are Resourced from the copyrighted CBM versions. :(
im not sure if peter.k icon lib wasnt resourced as well, only that the complete code has been replaced. now i dont know what the situation legally is. however as the work was not based on any sources, only on reverse engineering of binary and since the current library does not contain copyrighted code its okay i guess.
its possible to use this library anyway and it gives nice speedup.
what concerns math libs i have never been sure how much do they improve upon genuine ones. at least integer wise aros is currently on the same level as aos afair. have to check for fp.
as for warp datatypes these are commercial, you can surely use them under aros 68k as you do on aos, no doubt, you just need to buy them.
all in all there are few aspects aros has serious performance problem. one of them has just been traced doen to a particular function within graphics library, seems toni has problems to improve it though. i will try to make it more public on the dev list.
-
im not sure if peter.k icon lib wasnt resourced as well, only that the complete code has been replaced. now i dont know what the situation legally is. however as the work was not based on any sources, only on reverse engineering of binary and since the current library does not contain copyrighted code its okay i guess.
its possible to use this library anyway and it gives nice speedup.
what concerns math libs i have never been sure how much do they improve upon genuine ones. at least integer wise aros is currently on the same level as aos afair. have to check for fp.
as for warp datatypes these are commercial, you can surely use them under aros 68k as you do on aos, no doubt, you just need to buy them.
all in all there are few aspects aros has serious performance problem. one of them has just been traced doen to a particular function within graphics library, seems toni has problems to improve it though. i will try to make it more public on the dev list.
Perhaps Ratte & Cosmos might be abe to help with the graphics.library problem?
-
@ThoR
hi! have you ever planned opensourcing your MMU.library & tools? I guess it could be a great addition to AROS and would probably bring some new life to our classics :-) Maybe somebody like Matthey could add some improvements, who knows.
I would prefer a different model here as I see a lot of needless branches and "headless" discussion going on in the open source world. That does not mean that I don't want to provide sources, but it means that I would prefer someone to feel responsible and "wear the hat" as we say here.
That said, if you believe you can and want to contribute to the project, want to make some changes that are well motivated, please let me know what the plans are, and allow me to review changes before publishing any future revision, and I'll send you sources. This is the least problem.
So for example, just for the purpose of "making things faster", I would prefer to see a noticable speed improvement being measured, plus an analysis that the changes made are "correct". That's all not so easy, I afraid (and please include me in not being able to write bug-free code), and exactly the reason why I'm staying away from such modifications at this time:
a) I don't believe it makes much a difference (because all the additional glue logic to decode the instructions and get operands is dominating, not the actual math) and
b) it's hard enough to get things right in first place - as you actually see.
I hope you understand.
-
@thomas: pls. update your lha-archiver, your lib has a 1980-datestamp ;)
You just found another defect in my defect-enough A2000... )-: Real-time clock battery is dead. (Despite the already known defects of the disk drives being dead, the CDRW being dead and the omniscsi/GVP scsi card being defunct).
-
You just found another defect in my defect-enough A2000... )-: Real-time clock battery is dead. (Despite the already known defects of the disk drives being dead, the CDRW being dead and the omniscsi/GVP scsi card being defunct).
Time to clone the drive to a WinUAE setup now that it has 68060 and MMU emulation? :)
-
Time to clone the drive to a WinUAE setup now that it has 68060 and MMU emulation? :)
it is (up to?) 040 mmu emulation.
-
it is (up to?) 040 mmu emulation.
12 January 2013, 16:33
Toni Wilen
68060 MMU emulation added, mostly same as 68040, different stack frames and 68060 restarts all bus faults, 68040 restarts only read faults (excluding MOVEM).
http://eab.abime.net/861457-post2.html
-
I would prefer a different model here as I see a lot of needless branches and "headless" discussion going on in the open source world. That does not mean that I don't want to provide sources, but it means that I would prefer someone to feel responsible and "wear the hat" as we say here.
i know your opinion on this, but im sure if you actually was interested, you would find a quite reasonable team behind aros. their opinions may vary but usually they are following some con-sens very close to that what a regular amiga user like me actually recognizes as "improved amiga". the platform branches are a handicap on one hand because there is no focus on particular platform but a gain on the other hand, because of cross testing and remaining future proof in a fast evolving it world. the problem is of course there is no lead, so everyone just works on what he is just interested in, and there is no way to impose anything on anyone, but this is effectively the same how it is on each and every amiga related project today (mos or os4), even if it isnt openly admitted. all in all if you handed over your sources to jason or toni im quite sure they would be treated properly, but its your choice and i don want to talk you into anything. ;)
-
Which MMU is best from the "using it under WinUAE" perspective?
-
Which MMU is best from the "using it under WinUAE" perspective?
Toni Wilen's probably the best person to ask mate. I don't think he has an account on here though, just on EAB.
http://eab.abime.net/members/toni-wilen-257.html
-
Time to clone the drive to a WinUAE setup now that it has 68060 and MMU emulation? :)
First of all, if it runs on Windows, I don't care. I don't have windows around, and it's unlikely I will get one just for the matter of emulation. There is uae on Linux, which "sort-of" works (but not quite right).
But all that aside, things like the 68060.library cannot be tested under emulation since an emulation has no point to *not* implement instructions - as the 68060 does. The best you probably do is pick up some bugs in the emulator as the trouble here is more to work with the low-level features of the CPU.
Greetings, Thomas
-
i know your opinion on this, but im sure if you actually was interested, you would find a quite reasonable team behind aros. their opinions may vary but usually they are following some con-sens very close to that what a regular amiga user like me actually recognizes as "improved amiga". the platform branches are a handicap on one hand because there is no focus on particular platform but a gain on the other hand, because of cross testing and remaining future proof in a fast evolving it world. the problem is of course there is no lead, so everyone just works on what he is just interested in, and there is no way to impose anything on anyone, but this is effectively the same how it is on each and every amiga related project today (mos or os4), even if it isnt openly admitted. all in all if you handed over your sources to jason or toni im quite sure they would be treated properly, but its your choice and i don want to talk you into anything. ;)
Well, let me ask what the benefit of this would be. For emulation, the 68060.library is really pointless. For real hardware, it is (still) in supported mode, though probably with longer turn-around times, so I have no problem with it at all when people use it with AROS - or ship it with part of AROS. This is perfectly fine. The only thing I'm asking for is if you sell(!) a CD, please send me a copy, which is - I hope - not asking for too much. (At least, I have now two Amiga Forever DVDs. (-;)
Arguably, it might be anoying that it took so long to actually look into this bug and fix it. In the old days, I had turn-around times of probably one day, now it's more one month. But it also took years to actually discover it... Feature requests and bug reports are still read, though it takes time to implement and verify. Given that I hear nothing, the interest must be really low, or things must really work well. I don't know which of the two is true, probably more the former than the latter.
So I guess, it really boils down to one question, and that is: What would be better under a different model, and what would it enable?
-
First of all, if it runs on Windows, I don't care. I don't have windows around
Glad to hear it! :)
and it's unlikely I will get one just for the matter of emulation. There is uae on Linux, which "sort-of" works (but not quite right).
The latest versions of FS-UAE on Linux work very well now. Frode has backported lots (most?) of the WinUAE code to it and it's stable and featureful enough for me to clone an exact replica of my A3000 to install, patch and configure the OS before transferring it to the real hardware anyway.
If you haven't tried it yet I really reccomend it, it's a great piece of software.
But all that aside, things like the 68060.library cannot be tested under emulation since an emulation has no point to *not* implement instructions - as the 68060 does. The best you probably do is pick up some bugs in the emulator as the trouble here is more to work with the low-level features of the CPU.
Greetings, Thomas
Understood completely. Thanks for all the work you've done on the Mu tools and libraries by the way, I really appreciate it and I'm always reccomending your work to other people to use. :pint:
Cheers!
Nik
-
@THOR: Are you able to create a special 060-LIB for 68LC060-CPUs.
Eyetech released a Winner(Apollo)1260 @ 75 MHz with a special "LC"-Library.
OK, it seems to be useless for "MMU"-Libs, but it could be nice to have a alternative choice.
Sideeffect, on A1k.org some guys are working on 040/060-adapters with higher clockrates.
(Warpengine 4040 -> 4060@80MHz .. thinking about MC68060FE133 and quad-clock setting)
-
Well, let me ask what the benefit of this would be. For emulation, the 68060.library is really pointless. For real hardware, it is (still) in supported mode, though probably with longer turn-around times, so I have no problem with it at all when people use it with AROS - or ship it with part of AROS. This is perfectly fine. The only thing I'm asking for is if you sell(!) a CD, please send me a copy, which is - I hope - not asking for too much. (At least, I have now two Amiga Forever DVDs. (-;)
Arguably, it might be anoying that it took so long to actually look into this bug and fix it. In the old days, I had turn-around times of probably one day, now it's more one month. But it also took years to actually discover it... Feature requests and bug reports are still read, though it takes time to implement and verify. Given that I hear nothing, the interest must be really low, or things must really work well. I don't know which of the two is true, probably more the former than the latter.
So I guess, it really boils down to one question, and that is: What would be better under a different model, and what would it enable?
what concerns different model, i see aros as a sort of code preservation repository, where all the good parts can be stored and eventually maintained beyond the point, where they would have been discontinued by their creators otherwise. that doesnt mean that anyone can be forced to contribute, but i dont believe anything worthwhile can be done on widest understood amiga platform today by a single person, let alone anything commercial can be pulled. sure, im certain you can maintain what you have developed for another few years. i dont ask you to contribute your code to aros. aros has already 680x0.library that includes 68060.library implementation. all i could imagine to ask to review the code if need be and consult the developers not to let them run into the bugs you are aware of.
-
@THOR: Are you able to create a special 060-LIB for 68LC060-CPUs.
Eyetech released a Winner(Apollo)1260 @ 75 MHz with a special "LC"-Library.
OK, it seems to be useless for "MMU"-Libs, but it could be nice to have a alternative choice.
Sideeffect, on A1k.org some guys are working on 040/060-adapters with higher clockrates.
(Warpengine 4040 -> 4060@80MHz .. thinking about MC68060FE133 and quad-clock setting)
Do you mean "LC" or "EC"? As far as the MMU goes, it is actually not required, not even for the mmu.library, so the 68060 without MMU should work out of the box, no strings attached. The mmu.library of course then doesn't do anything useful except sitting there and saying "hey, here's no MMU, pass on", but the 68060 lib should continue to work.
The LC does not have a FPU. I'm not sure I'm currently supporting this, but you might try. If it does not work, it wouldn't be a major trouble just to disable the FPU enable code because right off my head I don't remember what I did if the FPU is absent. Best would be just to try and let me know how it goes. It shouldn't be a major trouble to get this into the main branch - a special version wouldn't be required.
-
Just quickly reviewed what I had, and it seems to me that the code tests correctly whether a FPU is available or not, and only installs the FPU related patches if it finds a FPU. Thus, at this moment I don't see any reason why it should not work on a LC or EC processor. That being said, I haven't tested it lacking the hardware, but you probably can just give it a spin.
-
What kind of CPU are you working with .. on your broken A2000?
I think Mozart could help you to pimp a 040-system to 060 ...
He is going to test the MMU-Libs on his system (C=3640 with 68LC060).
http://www.a1k.org/forum/showthread.php?p=657336#post657336
-
What kind of CPU are you working with .. on your broken A2000?
"Working" is a nice word. I'm not so much working on this machine anymore for apparent reasons.. The CPU is a first generation first mask "broken as designed" 68060 with MMU and FPU. I forgot the mask revision, but it has all the bugs a 060 can have. But that's actually not the broken part about it. I have a 2060 that is currently installed, a GVP040 and a GVP030 card, just in case I need to do something on the other code branches.
There are a couple of things I know that are broken (disk drives, CDRW, and add now the RTC to the list), but there is something else I'm not clear about. If I leave the machine off for months (which is not so untypical anymore), then it refuses to boot. The usual procedure is then to open it, rip everything appart, put everything back in and - voila - it's alive. Hard to say what's causing this. Weary electronics I say. It's just old crap.
BTW, could you do me a favour? Please go over to a1k and send greetings to Mozart, and let him know that it doesn't take a MMU to install the mmu.library. I know this sounds weird, but it's true nevertheless. In his configuration, the lib doesn't do much except sitting in the corner wining, but it will nevertheless do enough to load the 68060 support on an EC (and telling the rest of the system that there is *really* no MMU it could program).
Greetings, Thomas
-
If I leave the machine off for months (which is not so untypical anymore), then it refuses to boot. The usual procedure is then to open it, rip everything appart, put everything back in and - voila - it's alive. Hard to say what's causing this. Weary electronics I say. It's just old crap.
I thought my machine had the same problem on my A1200T/060.
But then I learned a trick.
When pressing the power button in if I keep holding the button down for 2 seconds, instead of quickly releasing it like a normal person does, then the machine almost always boots up correctly the first time.
My A3000 and A1200T both have a pushbutton type of power switch, unlike my A2000 which has an actual power switch.
-
I thought my machine had the same problem on my A1200T/060.
But then I learned a trick.
When pressing the power button in if I keep holding the button down for 2 seconds, instead of quickly releasing it like a normal person does, then the machine almost always boots up correctly the first time.
My A3000 and A1200T both have a pushbutton type of power switch, unlike my A2000 which has an actual power switch.
It's an A2000, so it actually does have a real switch. The problem is not that the board doesn't get power. The LED is lit, but only "half". If the machine is in bad mood, it just keeps sitting like that doing nothing. Fan is rotating, but nothing else.
It's dead, Jim.
-
@ThoR
bad caps and/or bad psu?
-
@ThoR
bad caps and/or bad psu?
All possible and all not too unlikely. But no matter how you put it, I'm not wasting more money on this trash than I already did. The A2000 gave me a lot of trouble over the years, and no matter what I do, it will continue to give me trouble. That said, the caps look optically fine, but given their age, it is indeed not too unlikely that they have dried out. Disk drivers are likely only dirty, but I don't mind anymore cleaning and oiling them.
-
I'm going to throw in a vote here for ThoR's library, also. Even though I only use his stuff with a 68040, it works brilliant! :)
-
@Thomas Richter
I don't think the MC68060FE133 even exists or has someone found some secret military inventory ?
-
@Thomas Richter
I don't think the MC68060FE133 even exists or has someone found some secret military inventory ?
Of course 68060FE133 exists. Duh.
I donno if there is an MC on the front or not.
But it doesn't matter. The point is they exist and they work.
-
Of course 68060FE133 exists. Duh.
I donno if there is an MC on the front or not.
But it doesn't matter. The point is they exist and they work.
They have the MC but they are "EC" and SMD only. Here is a close up pick from the Natami site:
http://www.natami.net/gfx/NAe60F/NAe60F_2.jpg
More info here:
http://www.natami.net/hardware.htm
The price may go up soon if they are using a fault tolerant pair of them on the Tomahawk cruise missiles :/.
-
Of course 68060FE133 exists. Duh.
I donno if there is an MC on the front or not.
But it doesn't matter. The point is they exist and they work.
Speculation is they are remarked 68060FE75, Freescale have never heard about it. The mask dates back to 1997.
-
Speculation is they are remarked 68060FE75, Freescale have never heard about it. The mask dates back to 1997.
Freescale have heard about them so please don't say that they haven't.
-
@ThoR
bad caps and/or bad psu?
In all my years of working with amigas i've never seen an a2000 with "bad caps" mainly thats a600/1200 afaik..
and why do you still have a Satanic avatar? Its against the TOS and is offensive.
-
and why do you still have a Satanic avatar? Its against the TOS and is offensive.
I did a search on the US Trademark site and none of the symbols in his avatar are registered to Satan Inc. therefore they are not Satanic.
As nearly as I can tell those symbols are public domain and free for everyone to use.
Furthermore, if one of those symbols was Satanic in nature then it would be mentioned in the Bible so we could all be warned about them. I read the entire Bible and there are no Satanic symbols listed. There are quite a lot of lists in the Bible. Poetry. Sex stories. War stories. Murders. Mass Murders. All kinds of stuff. But no Satanic symbols.
Furthermore, there are many symbols which do represent real evil in the real world, such as the Microsoft logo. Will you be banning all discussion of M$ products and services? Or just the logo?
-
Yes it is fashionable to Christian bash these days.
-
@stefcep2
You want to try being Muslim for a day, then you'll really know what being bashed feels like. ;)
@Mods
Please can you delete all the off-topic posts, including this one?
-
Just been looking at the poll results and six people so far have voted "Other".
Which specific 68060.library are you actually using guys?
-
Just been looking at the poll results and six people so far have voted "Other".
Which specific 68060.library are you actually using guys?
http://www.amiga.org/forums/showpost.php?p=746386&postcount=34
-
http://www.amiga.org/forums/showpost.php?p=746386&postcount=34
How did I miss that? Lol