68060.library update

[SpeedGeek]

68060.library update

LICENSE:
Copyright by Carsten Schlote 1990-2016
This release and any subsequent adapted (or non-adapted)
release is subject to all terms and conditions the original
CC-BY-NC-BA 4.0 license release in 2016. See
http://creativecommons/licenses/by-nc-sa/4.0/legalcode

INTRODUCTION:
This 40.38 version of 68060.library is an update of the last
40.343 version by Carsten Schlote. This is a really good
"Generic" 68060.library with a few useful updates.

Updates (by SpeedGeek):
40.35
- Disables the Store Load/Bypass for CPU Rev. 0,1 and 5
- Some Global mappings changed to Non-Global
- Enables $E00000 Extended ROM as Cache Writethrough
- Allocates only Fast RAM for moving the VBR
- Library init code now safely exits in a 68040 system

NOTES: It works very well with TurboMMU040+ and
FastCache040+! Please understand a "Generic" library does
NOT offer support for all the features of proprietary 3rd
party accelerator cards.

REQUIREMENTS:
- Amiga with 68060 CPU and FPU

DISCLAIMER (For updates):
Use at your own risk. No warranty expressed or implied, etc.

USAGE:
- Copy to LIBS:
- OS3.1 Setpatch loads the "Dummy" 68040.library first
- OS3.9 Setpatch (BB2) directly loads the 68060.library
- OS3.1.4+ utility.library is no longer patched (no other
support or testing is provided)

CREDITS: Thanks very much to Carsten Schlote (Danke!)

HISTORY:
v40.35 - First release (see Updates)
v40.36 - Many improvements
- Fixed occasional crash bug in FPU dispatcher (Thanks to
Ralph Schmidt for the minor update)
- Added optimized Mult64u/s ISP patch to utility.library
functions (Much faster than exception trap code)
- Removed library versions of FPSP and ISP (Kernal versions
provide the emulation code)
- Removed lots of useless code (Debug and NOP stuff)
- Merged two library hunks into one
- Replaced Disable/Enable pairs with Forbid/Permit pairs
v40.37 - Minor update
- Added code to skip Library init on EC/LC060 detection
- Added code to enable branch prediction error handler
v40.38 - Minor changes
- Added code to skip Mult64u/s patch for v45+ utility.library
- Changed JSR branches to BSR.L branches (more PC relative code
means less reloc32 code)
- Removed FPUpatchport and Allocpatchport code (since it was
never used)

[Foul]

Added to my site... and will test it.. thx !

[gulliver]

Good to see it finally out.

[kolla]

Originally Posted by SpeedGeek

This 40.35 version of 68060.library is an update of the last
40.343 version by Carsten Schlote.

You don't know how versioning works on Amiga??

Maybe you should call it 40.350, then at least it looks like an update, and not a "downdate".

[SpeedGeek]

Originally Posted by kolla

You don't know how versioning works on Amiga??

Maybe you should call it 40.350, then at least it looks like an update, and not a "downdate".

1) I assumed the 3 digit revision number was a typo because all previous released versions used a 2 digit revision number

2) The text string for 40.343 did not specify any version or revision number

3) I offered the source code for this "Downdate" to Carsten and he neither has the time nor the interest to pursue it

4) You are welcome to release what you consider to be a proper version update any time you like.

[malko]

Originally Posted by kolla

You don't know how versioning works on Amiga??

Maybe you should call it 40.350, then at least it looks like an update, and not a "downdate".

You should not bite the hand who defended you (during your absence)

[spudje]

Will it work with MMUlib? http://aminet.net/package/util/libs/MMULib

[rzookol]

So this library is the best option for A3660? right?

[SpeedGeek]

Originally Posted by spudje

Will it work with MMUlib? http://aminet.net/package/util/libs/MMULib

I certainly hope not. Why do you think CPU libraries which expect "Exclusive" use of the MMU can function cooperatively?

Originally Posted by rzookol

So this library is the best option for A3660? right?

A good option certainly, the best option is a matter of opinion. Beware of developers who try to convince you their option is the best. Be a smart user and decide this question for yourself.

[thebajaguy]

Originally Posted by rzookol

So this library is the best option for A3660? right?

It depends on your goal.

Lean, basic data-cache handling (all that the base Amiga OS ever needed with it's DMA and shared-memory zones) - This is a candidate for that goal.

Features-added 68060.library to support software development environments (i.e. software memory protection/exceeding bounds detection, possibly toy with virtual memory) = more code to support those features, adds potential overhead. In this case, performance is not your goal, so your needs may lie elsewhere.

[Romanujan]

AFAIK the MMULib was designed to allow using external 68060.library - as some boards might be non-standard and not work with the library provided by Thor, so one would have to test it (I wonder which library will achieve better scores in AIBB...). The limitation is, that some features (virtual memory) might work unreliably with non-Thor 68060.library.

[gulliver]

The MMULib documentation suggests that this library work ok with them:

In the thanks section:

..."Carsten Schlote: For preparing a MMU.library aware 68060 library."...

[SpeedGeek]

Originally Posted by Romanujan

AFAIK the MMULib was designed to allow using external 68060.library - as some boards might be non-standard and not work with the library provided by Thor, so one would have to test it (I wonder which library will achieve better scores in AIBB...). The limitation is, that some features (virtual memory) might work unreliably with non-Thor 68060.library.

I don't know of what practical use this feature would provide beyond using the board specific library just by itself. In any case, TurboMMU040+ and FastCache040+ don't support the mmu.library so I hope users will make "Smart" decisions about which options they prefer.

BTW, AIBB can't show the performance advantages of these tools (You need to use the benchmarks provided with them).

Originally Posted by gulliver

The MMULib documentation suggests that this library work ok with them:

In the thanks section:

..."Carsten Schlote: For preparing a MMU.library aware 68060 library."...

IIRC this was true for the 40.17 version but not other versions. This version had specific code to load the mmu.library before building it's own MMU tables.

[Hewitson]

Would this be better to use than the official Apollo 68060.device on a 1260?

[Mathesar]

Originally Posted by SpeedGeek

I certainly hope not. Why do you think CPU libraries which expect "Exclusive" use of the MMU can function cooperatively?



A good option certainly, the best option is a matter of opinion. Beware of developers who try to convince you their option is the best. Be a smart user and decide this question for yourself.

I have just finished my A3660 build (using your improved statemachine, dirty pics here: http://eab.abime.net/showpost.php?p=...5&postcount=23 and I am having problems with OS3.9. I am running an fpu-less 68LC060 and probably having an fpu optimized library somewhere on my system (resource.library can't be opened ).
Will this new library work well with an fpu-less 68LC060?

[SpeedGeek]

Originally Posted by Hewitson

Would this be better to use than the official Apollo 68060.device on a 1260?

Apollo 68060.library is a proprietary library which supports proprietary hardware features. If you don't need this proprietary feature support then you may be able to use a generic library. But again, it's a decision to be made by the user.

Originally Posted by Mathesar

I have just finished my A3660 build (using your improved statemachine, dirty pics here: http://eab.abime.net/showpost.php?p=...5&postcount=23 and I am having problems with OS3.9. I am running an fpu-less 68LC060 and probably having an fpu optimized library somewhere on my system (resource.library can't be opened ).
Will this new library work well with an fpu-less 68LC060?

Congrats on finishing your A3660 build. Please remember this is not a new library but simply an update of an old library.

Typical problems with LC variant compatibility are caused by not having the Commodore or H&P math#?.libraries installed and they can happen with any CPU library. These problems can sometimes be avoided by using non-FPU versions of software but it's not a complete solution.

[SpeedGeek]

** NEWS UPDATE **

Changed requirements to 68060 CPU and FPU due to Mathesar's reported problem with LC060 compatibility.

[klx300r]

want to test this 060 lib on my Viper 060 but the lha seems to be corrupted.



Can someone please PM me so I can get a hold of the 68060.libray file

[wiz12]

The lha is ok with me, did you try it download it again?

[klx300r]

Originally Posted by wiz12

The lha is ok with me, did you try it download it again?

yes I did try on another computer and no problem with corrupted lha file...unfortunately i can't get my 1200 to boot at all with this 060 lib installed.