Which 68060.library?

[matthey]

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)
Other

[ChaosLord]

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 ?

[Matt_H]

Commodore had a 68060.library?

[matthey]

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.

[NovaCoder]

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.

[matthey]

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.

[nicholas]

Thor's 68060.library +MuRedox on my CS060 Mk2

[Cosmos Amiga]

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)

[matthey]

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.

[nicholas]

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.

[wawrzon]

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.

[nicholas]

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?

[matthey]

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.

[nicholas]

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.

[wawrzon]

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.