FastCache040+ Released!

[SpeedGeek]

Hi amigasith,

Danke for the compatibility feedback! You are the 2nd user to post your results (but the 1st user here on EAB). The A3640 of course, I have already tested and the H&P v44.2 68040.library is a minor update to the older Commodore 68040.library so no surprise here either.

However, compatibility with the Fastlane Z3 SCSI driver is certainly important since I forgot to mention that other DMA drivers should be tested as well!

Regarding performance, you may notice only a SUBTLE performance improvement, if you CAREFULLY observe operations such as extracting files to RAM, directory listings and loading icons on the Workbench screen (without using RTG). Please remember the new functions help improve CPU performance under DMA conditions and DMA transfer rates are mostly determined by DMA hardware.

[SpeedGeek]

** 5TH NEWS UPDATE **

The new benchmark tool has now been released! The lamers who failed to provide compatibility feedback owe a BIG THANKS to the users who did. A very special Thanks to thebajaguy for providing feedback on multiple systems!

BTW, these benchmark results were easily predictable. It's a No-Brainer!

[SpeedGeek]

** 6TH NEWS UPDATE **

v1.5 - Found an occasional Recoverable Alert bug which could
possibly result in a crash but only on 060 systems!
The simple fix was to move "CINVA NC" in PostDMA to the
end of the code.
- Removed the "+" character from the executable name due
to a unknown "Feature" of the Amiga Shell causing script
execution and version command problems.

EDIT: [CPU060 NOWRITEBUFFER] with the Phase5 46.7 68060.library seems to be a more reliable solution than the v1.5 update. Some more testing is required.

[SpeedGeek]

** 7TH NEWS UPDATE **

v1.6 - Added code to PostDMA to Flush the cache conditionally
(if the Store buffer and cache are enabled). Added NOPs
to sync the pipelines before RTE (CINVA is now obsolete)

UPDATE:
68040 users can use v1.4 or v1.5 if they like since they will
be a little faster than v1.6 but 68060 users should use v1.6!
68060 users will now have a performance trade off to consider
in deciding whether to enable the store buffer.

[jotd]

"The lamers who failed to provide compatibility feedback owe a BIG THANKS to the users who did."

Ok, thanks to the users who did.

I'm not sure calling people lamers will increase the use of your tool, though.

[SpeedGeek]

Originally Posted by jotd

"The lamers who failed to provide compatibility feedback owe a BIG THANKS to the users who did."

Ok, thanks to the users who did.

I'm not sure calling people lamers will increase the use of your tool, though.

Given a choice between more users who do not leave feedback and fewer users who do leave feedback, then it's quite obvious what my preference is here.

But if you have a better idea for the non-feedback user stereotype than I am open to suggestions.

[SpeedGeek]

** 8TH NEWS UPDATE **

v1.6P5 Removed code to allow PostDMA cache Flush for the case of
16 byte aligned transfers. Added code to skip PostDMA
cache Flush for the case of cache disabled MEMF_24BIT
transfers.

UPDATE:
v1.6P5 is my last attempt solve compatibility problems with
the Phase5 68060.library and Store buffer enabled. This
library is unstable and buggy WITH or WITHOUT FastCache040+
so either disable the Store buffer or expect the problems to
continue with only a MINIMAL improvement provided by this
patch!

v1.7 - Removed all v1.6P5 PostDMA cache flush code so most users
(except Phase5 68060.library users) can run at full speed!

UPDATE:
Phase5 68060.library users should use v1.6P5. All others users
can (probably) use v1.4, v1.5 or v1.7 without any problems.

[SpeedGeek]

** 9TH NEWS UPDATE **

FastCache040+ v1.6P5 has been removed. Phase5 68060.library
can optionally use FixMapP5 if it improves the stability of their system.

FixMapP5 1.4 ©SpeedGeek 2018 (MMU Handler ©Michael Sinz 2001)

INTRODUCTION:
FixMapP5 is a tool to modify some of the default MMU mapping of
the Phase5 68040 and 68060 libraries. This can improve stability
and prevent crashing under the following condition:

- Hardware or software interrupts which occur during a Chip RAM
access by the 68060 (In particular when Store buffer is enabled).

Software bugs which allow illegal writes to the $F80000 Standard
Kickstart ROM can cause a debugging problem in Copyback mode so this patch corrects that problem as well.

FEATURES:
- Changes Chip RAM mode to Precise (68060 only)
- Changes Standard ROM cache to Writethrough (68040 or 68060)
- Uses 68040/060 library detection code
- 100% Assembler code

REQUIREMENTS:
- Amiga with 68040 or 68060 CPU and MMU
- Phase5 68040.library or 68060.library

WARNING:
This tool was developed ONLY for use with the Phase5 libraries but
it does NOT actually verify such usage. So it can and probably
will mess up the mapping of ANY other libraries!

CREDITS:
Thanks to Michael Sinz for his freely distributable MMU handler.

HISTORY:
v1.0 - First release
v1.1 - Added code to skip mapping $F00000 space (which included $F80000 space) for CyberstormPPC, CyberstormMK3 and BlizzardPPC
v1.2 - Replaced FindName() with FindResident() since v1.1 wasn't
working at all. Also, fixed a typo on module names.
v1.3 - Swapped order of 68040/060 library test. Some OS 3.1
systems use a dummy 68040.library (which does not expunge)
and prevented the chip RAM change to precise. Thanks to
Northway for reporting this bug.
v1.4 - Added code to determine the Chip RAM start address from the system memory list. Hopefully, this solves the problem with
Kickstart versions which config the Chip RAM differently.

[HanSolo]

Is there any sense to use this patch with THOR 68060.library ??

[SpeedGeek]

Originally Posted by HanSolo

Is there any sense to use this patch with THOR 68060.library ??

http://www.a1k.org/forum/showthread.php?t=62552

[kolla]

If you prefer stability and functionality over marginal speed gains, you avoid this patch.

[SpeedGeek]

Originally Posted by kolla

If you prefer stability and functionality over marginal speed gains, you avoid this patch.

Marginal speed gains? No, quite impressive speed gains really. The stability problem is already solved for Phase5 68060.library users. 68040.library users never had a problem (see feedback from amigasith).

[kolla]

Originally Posted by SpeedGeek

Marginal speed gains? No, quite impressive speed gains really. The stability problem is already solved for Phase5 68060.library users. 68040.library users never had a problem (see feedback from amigasith).

who wrote...

but I also didn't notice any speedup

It's the same old story - there are some "significant" speed gains when running specific benchmarking, but close to nothing in real world use. Instead you have general weirdness and stability issues.

I don't mind what you are doing, there are people who enjoy very much drooling over benchmarks, but don't push this on "joe regulars" who have no idea what your patching involves.

[SpeedGeek]

Originally Posted by kolla

who wrote...


It's the same old story - there are some "significant" speed gains when running specific benchmarking, but close to nothing in real world use. Instead you have general weirdness and stability issues.

I don't mind what you are doing, there are people who enjoy very much drooling over benchmarks, but don't push this on "joe regulars" who have no idea what your patching involves.

Of course, the "Joe Regulars" don't understand the technical reasons why this patch easily out performs the code it replaces. That's why I told them exactly what to look for and developed a Benchmark tool just in case they can't observe it.

This patch wasn't pushed on anybody and obviously I could have saved a lot of time and effort by ignoring the "Joe Regulars". I wonder if you would be willing to make these same comments on PeterK's icon.library thread?

[kolla]

Are you suggesting that "Joe Regulars" cannot tell the difference between PeterK's icon.library and the "official" ones?

[SpeedGeek]

Originally Posted by kolla

Are you suggesting that "Joe Regulars" cannot tell the difference between PeterK's icon.library and the "official" ones?

Not at all, but you imply that "Joe Regulars" also can't understand how/why PeterK's code easily out performs the code it replaces.

[apex]

I am using his libs and tools since over 10 years on 2 060 systems here and I just can say that the mmu.lib package is working perfect.

[SpeedGeek]

** 10TH NEWS UPDATE **

v1.8 Released!
- Reworked the code to eliminate a serious (but seldom noticed) data transfer corruption bug for the case of multiple DMA drivers in the same system. Special Thanks to Ralph Babel for his excellent knowledge on this topic.

[SpeedGeek]

** 11TH NEWS UPDATE **

v1.9 Released!
- Fixed "D2 Register Not Preserved" coding bug in PreDMA.
Most DMA drivers don't seem to need it preserved but
Thanks to Cosmos for reporting it anyway. Moved PostDMA
Nest count code to user section of code. This eliminates
any calls to Supervisor when the count is more than 1.
v1.9BR Added new "Experimental" code which should allow only
DMA targeted 16MB blocks of Fast RAM to change to Write
Through mode. This "In Theory" allows the other 16MB
blocks to remain in Copyback mode. This can only benefit
"Big RAM" systems with 32MB+ of Fast RAM and ONLY when
these systems run apps which use the extra Fast RAM.
WARNING: Use at you own risk!

CACHEDMABENCH:
v1.0 - First release
v1.1 - Fixed address and size bugs in FC loop code which
could have affected the results.

[starship]

A4000 - cyberstorm mk3 72mhz - 128mb fastram

Without Fastcache040

CacheDMAbench 1.1 ©SpeedGeek 2018
---------------------------------
Public memory CacheDMA FCs: 9500
Chip memory CacheDMA FCs..: 500
Total CDMA Function Calls.: 10000
Elapsed time Microseconds.: 393637

With Fastcache040

CacheDMAbench 1.1 ©SpeedGeek 2018
---------------------------------
Public memory CacheDMA FCs: 9500
Chip memory CacheDMA FCs..: 500
Total CDMA Function Calls.: 10000
Elapsed time Microseconds.: 113858