Welcome, Guest. Please login or register.

Author Topic: 68060.library update  (Read 10148 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline SpeedGeekTopic starter

68060.library update
« on: March 22, 2019, 01:35:28 AM »
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 of the original
CC-BY-NC-BA 4.0 license release in 2016. See
http://creativecommons.org/licenses/by-nc-sa/4.0/legalcode

INTRODUCTION:
This 40.35 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):
- 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 directly loads the 68060.library

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

HISTORY:
v40.35 - Update release of 40.343

Here is the link:

http://eab.abime.net/showthread.php?p=1312476
 
« Last Edit: April 11, 2019, 02:44:51 PM by SpeedGeek »
 
The following users thanked this post: klx300r

Offline SpeedGeekTopic starter

Re: 68060.library update
« Reply #1 on: April 11, 2019, 02:45:37 PM »
** NEWS UPDATE **

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

Offline SpeedGeekTopic starter

Re: 68060.library update
« Reply #2 on: February 20, 2020, 11:17:07 PM »
** 2ND NEWS UPDATE **
v40.36 released!

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
« Last Edit: February 20, 2020, 11:35:56 PM by SpeedGeek »
 
The following users thanked this post: klx300r

Offline SpeedGeekTopic starter

Re: 68060.library update
« Reply #3 on: February 21, 2020, 07:13:57 PM »
** 3RD NEWS UPDATE **

v40.37 - released!

Monor update:
- Added code to skip Library init on EC/LC060 detection
- Added code to enable branch prediction error handler
« Last Edit: February 22, 2020, 04:26:46 AM by SpeedGeek »
 
The following users thanked this post: klx300r, 10MARC

Offline SpeedGeekTopic starter

Re: 68060.library update
« Reply #4 on: February 25, 2020, 01:47:53 PM »
A common problem is that its CachePre/PostDMA() functions do not work properly - they need to translate logical to physical addresses and not just pass them through. Another typical problem is the exeception generation of floating point exceptions in case its target address is not mapped. In such a case, the 68060.library needs to generate an access error of the right address - namely the address of the EA in the code being emulated. The original mot sources have call-outs ("hooks") to get this work done, but most - if not all (but one) - 68060 "optimizations" simply drop these call-outs and then generate an exception that is coming from the wrong code path, namely within the 68060.library, and not within the user code.

Thus, while I haven't tested, I afraid that we have here a library that falls into the same pitfalls the P5 libs fell into, namely not handling exceptions properly. It is a case that does not typically happen, but in case we would have virtual memory, would fail miserably. The Mu-based libs have been carefully crafted to handle such cases correctly, thus do not generate exceptions by executing code itself, but creating artificial exceptions that (seem to) come from the user code, such that the Os layer can handle them correctly.

Here we go again... ::)

This library, the original C= 68040.library (and ALL 3rd party libraries EXCEPT your mmu.library) don't support virtual memory. I assume that's one of the reasons (besides your own EGO) why you trolled against FastCache040+ when it was first released (even though the documentation clearly warned users about this).

What is interesting, is that since you already added the logical to physical address code to the mmu.library you failed to realize this simple test can determine the choice of using the dog slow CachePre/PostDMA() functions or the much faster functions.

So, far I've never received a single request to support virtual memory (Thanks to many smart users!), but I did quote it as one of the reasons why TurboMMU040+ doesn't support the mmu.library.  ;)
     
 

Offline SpeedGeekTopic starter

Re: 68060.library update
« Reply #5 on: February 25, 2020, 04:19:00 PM »
The original 68040.library does not run into this borderline case because it does not exist on the 68040, that's quite simple. The issue exists on the 68060 since it does not, unlike the 68040, attempt to fetch operands into its stack frame. The mentioned call-outs are only available on the 68060, for reasons.
This mentioned 68060 call-outs again assume virtual memory is enabled, if the CachePre/PostDma() functions don't support it then there is no practical need for the call-outs to support it either.

If it doesn't work correctly because it does not satisfy specs, it does not work correctly. That's as simple as it goes.

"But these functions are wrong - but look how fast they are!". Hey, everyone can write "fast functions" violating the specs. That's not an art. The issue does not only exist for virtual memory. It also exists for any type of MMU remapping, such as MuFastZero or MuMapROM. In both cases, DMA will be run from the wrong addresses.

The specs are conditional for virtual memory support, so most CPU library developers wisely exercised the option not to support it. The Zero page is not a valid memory location for DMA but the ROM could support read only DMA. Now, if the remap is a mirror image of the physical ROM then there is no problem for a DMA read (without translation).

So, now we come to the extremely uncommon case of the unreliable MMU hacks for loading Kickstart image files... and of course a DMA read will fail here (without translation) but your giving up some really impressive performance improvements to maintain such an uncommon case.  ::)     
« Last Edit: February 27, 2020, 07:04:18 PM by SpeedGeek »
 

Offline SpeedGeekTopic starter

Re: 68060.library update
« Reply #6 on: December 04, 2022, 07:52:07 PM »
** 4TH NEWS UPDATE **

v40.38 released!

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)