FastCache040+ Released!

[NorthWay]

Originally Posted by SpeedGeek

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

Well, running this tool only changes $F00000-$F80FFF to writethrough. The rest of ROM(copyback) and all of chipmem(imprecise) is unchanged.

[SpeedGeek]

Originally Posted by NorthWay

Well, running this tool only changes $F00000-$F80FFF to writethrough. The rest of ROM(copyback) and all of chipmem(imprecise) is unchanged.

That's interesting. Please specify your P5 library version and accelerator card. FixMapP5 only works after the P5 library is installed and it's possible that the firmware modifies the MMU mapping after FixMapP5 has been run (But I can't verify this on my A3660 system).

[NorthWay]

CS MK1 with 68060.library 46.15.

EDIT: And I use 'mmulist' by Michael van Elst(sp?) to look at the result.

[SpeedGeek]

With the 68060.library 46.15 I get the following (before and after FixMapP5) results:

Before:

Current 68060 MMU table setup:
$00000000-$00000FFF -> $07071000: Local  User  Valid   Read/Write Copyback
$00001000-$00003FFF -> $0705A000: Local  User  Valid   Read/Write Precise   
$00004000-$001FFFFF -> $00004000: Local  User  Valid   Read/Write Nocache 
$00200000-$00BBFFFF -> $0705A000: Local  User  Valid   Read/Write Precise   
$00BC0000-$00BFFFFF -> $00BC0000: Local  User  Valid   Read/Write Precise   
$00C00000-$00D7FFFF -> $0705A000: Local  User  Valid   Read/Write Precise   
$00D80000-$00E7FFFF -> $00D80000: Local  User  Valid   Read/Write Precise   
$00E80000-$00EFFFFF -> $0705A000: Local  User  Valid   Read/Write Precise   
$00F00000-$00FFFFFF -> $00F00000: Local  User  Valid   Read/Write Copyback
$01000000-$06FFFFFF -> $0705A000: Local  User  Valid   Read/Write Precise   
$07000000-$07059FFF -> $07000000: Local  User  Valid   Read/Write Copyback
$0705A000-$0705AFFF -> $0705A000: Local  User  Valid   Read/Write Nocache 
$0705B000-$07064FFF -> $0705B000: Local  User  Valid   Read/Write Precise   
$07065000-$07067FFF -> $07065000: Local  User  Valid   Read/Write Copyback
$07068000-$07068FFF -> $07068000: Local  User  Valid   Read/Write Precise   
$07069000-$07FFFFFF -> $07069000: Local  User  Valid   Read/Write Copyback
$08000000-$FFFF7FFF -> $0705A000: Local  User  Valid   Read/Write Precise   
$FFFF8000-$FFFFFFFF -> $07069000: Local  User  Valid   Read/Write Copyback

After:

Current 68060 MMU table setup:
$00000000-$00000FFF -> $07071000: Local  User  Valid   Read/Write Copyback
$00001000-$00003FFF -> $00202000: Local  User  Valid   Read/Write Precise   
$00004000-$001FFFFF -> $00004000: Local  User  Valid   Read/Write Precise   
$00200000-$00BBFFFF -> $00202000: Local  User  Valid   Read/Write Precise   
$00BC0000-$00BFFFFF -> $00BC0000: Local  User  Valid   Read/Write Precise   
$00C00000-$00D7FFFF -> $00202000: Local  User  Valid   Read/Write Precise   
$00D80000-$00E7FFFF -> $00D80000: Local  User  Valid   Read/Write Precise   
$00E80000-$00EFFFFF -> $00202000: Local  User  Valid   Read/Write Precise   
$00F00000-$00FFFFFF -> $00F00000: Local  User  Valid   Read/Write Cache   
$01000000-$06FFFFFF -> $00202000: Local  User  Valid   Read/Write Precise   
$07000000-$07059FFF -> $07000000: Local  User  Valid   Read/Write Copyback
$0705A000-$0705AFFF -> $0705A000: Local  User  Valid   Read/Write Nocache 
$0705B000-$07064FFF -> $0705B000: Local  User  Valid   Read/Write Precise   
$07065000-$07067FFF -> $07065000: Local  User  Valid   Read/Write Copyback
$07068000-$07068FFF -> $07068000: Local  User  Valid   Read/Write Precise   
$07069000-$07FFFFFF -> $07069000: Local  User  Valid   Read/Write Copyback
$08000000-$FFFF7FFF -> $00202000: Local  User  Valid   Read/Write Precise   
$FFFF8000-$FFFFFFFF -> $07069000: Local  User  Valid   Read/Write Copyback

I use a modified version the Enforcer MMU tool (because MMUlist is annoyingly slow and long). It's certainly possible that the P5 software (Rom2Fast, SetCacheMode, CyberGuard, etc.) can change the MMU table setup after FixMapP5 so you may need to run it again if that's the case. Sorry, but the only permanent fix is to patch the P5 libraries.

P.S. The ROM mapping change to write-through is optional and won't affect system stability.

[NorthWay]

Originally Posted by SpeedGeek

With the 68060.library 46.15 I get the following (before and after FixMapP5) results:

So I fired up Resource to take a look, and I sit here wondering:
Why do you skip changing chipram mode if you find 68040.library? I have both loaded in my system.
Why do you assume chipram starts at $00004000? My custom Kickfile has it set at $0000F000. IIRC the default is $00001000?
You're doing a check on the chipmem mappings (don't have the bits in front of me now), but if it "fails" you loop through the loop once anyway?
You do exactly the same looping in the rom space handling which would explain why I see a change of only one page.


Are you sure 1.2 is the same version you are using?

[SpeedGeek]

Originally Posted by NorthWay

So I fired up Resource to take a look, and I sit here wondering:
Why do you skip changing chipram mode if you find 68040.library? I have both loaded in my system.
Why do you assume chipram starts at $00004000? My custom Kickfile has it set at $0000F000. IIRC the default is $00001000?
You're doing a check on the chipmem mappings (don't have the bits in front of me now), but if it "fails" you loop through the loop once anyway?
You do exactly the same looping in the rom space handling which would explain why I see a change of only one page.


Are you sure 1.2 is the same version you are using?

The 68040 has neither a "Store Buffer" nor a "Precise" mode for non-cache operation. The 68040 does have a "Serialized" mode for non-cache operation. Although some software apps may be less stable with the non-serialized mode FastCache040+ is not one of them. Hence, the default setting of the 68040.library for Chip RAM (either serialized or non-serialized) is unchanged.

Chip RAM starts @ $4000 on all official Kickstarts since OS 2.04. The space @ $1000 is already set to "Precise" even thought it's not part of Chip RAM (see above). FixMapP5 was never intended to support custom Kickfiles. So you might consider using SetCacheMode as an alternative.

[NorthWay]

Originally Posted by SpeedGeek

Hence, the default setting of the 68040.library for Chip RAM (either serialized or non-serialized) is unchanged.

Maybe I wasn't clear enough: You _will_ find 68040.library on my CS060 MK1 if you call FindName("68040.library"). That test tells you nothing that a check of AFB_68040 wont already give. The check for modifying chipmem settings is if you find 68060.library or AFB_68060.

Originally Posted by SpeedGeek

Chip RAM starts @ $4000 on all official Kickstarts since OS 2.04.

No. AFAIK the only Kickstart version that starts at $00004000 is 3.1.4.
My A4000D with 3.1 ROMs starts at $00001000. I just turned it on to be absolutely sure. Users with Macintosh emulators will have reserved the first $4000 IIRC.
And if you have a 68000/010/020/030 I think chipmem starts at $00000400.

[SpeedGeek]

** 11TH NEWS UPDATE **

FixMapP5 1.3 released

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.

Originally Posted by NorthWay

Maybe I wasn't clear enough: You _will_ find 68040.library on my CS060 MK1 if you call FindName("68040.library"). That test tells you nothing that a check of AFB_68040 wont already give. The check for modifying chipmem settings is if you find 68060.library or AFB_68060.

OK, I understand now. Thanks.
FixMapP5 1.3 should solve the problem now.

Originally Posted by NorthWay

No. AFAIK the only Kickstart version that starts at $00004000 is 3.1.4.
My A4000D with 3.1 ROMs starts at $00001000. I just turned it on to be absolutely sure. Users with Macintosh emulators will have reserved the first $4000 IIRC.
And if you have a 68000/010/020/030 I think chipmem starts at $00000400.

EDIT:
I swapped Kickstart 2.04 (v37) and 3.1 (v40) ROMs and Chip RAM starts @ $400 but for Kickstart 3.9 (v45) it's @ $4000.

I guess my memory was not good enough to remember the extra "0" from the last ShowConfig results from 1-2 years ago.

So, I will now try to make a version to fix that problem as well.

[SpeedGeek]

** 12TH NEWS UPDATE **

FixMapP5 1.4 released

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.

[SpeedGeek]

** 13TH NEWS UPDATE **

FastCache040+ 2.0 released.

2.0 - Added code to enable only one DTTR when the Nest count
is one. Most systems have only one DMA driver and only need to
have 16MB of address space managed for this case.
Removed 1.9BR version which was over-rated due to most DMA
drivers operating at higher priority than typical user tasks.

[SpeedGeek]

** 14TH NEWS UPDATE **

FastCache040+ 2.1 released

v2.1 - Reworked the code to fix a problem with Snoopy 2.0 (Aminet).
Sorry, this version no longer supports 16 byte aligned cache enabled
MEMF_24BIT transfers. NOTE: The original P5 library functions have
problems with Snoopy too. I suppose FastCache040+ 2.0 should remain
available for the non-snoopers.

[SpeedGeek]

** 15TH NEWS UPDATE **

FastCache040+ 2.2 released

v2.2 - The Snoopy fix broke MEMF_24BIT transfers. So another
bug fix was required. Let's hope it's the last.

[SpeedGeek]

** 16TH NEWS UPDATE **

FastCache040+ 2.0 is no longer available and 2.2 is now the recommended version for all users. 2.2 is a little slower than 2.0 but it is also much more stable than 2.0. I was able to use 2.2 with the P5 68060.library (without FixMapP5) and there was only an occasional "Recoverable Alert" but never any hard crashing on my A3000/A3660 system.

THOR reported finding no instability problems at all with the P5 68060.library on his A2000/2060 system so there appears to be some hardware issues complicating the stability problem too. Hence, FixMapP5 is now optional and it's usage should be based the users determination of improved stability.

[SpeedGeek]

** 17TH NEWS UPDATE **

FastCache040+ 2.4 released.

2.3 - The 16 byte alignment code is back and now avoids the
change of cache mode for this specific case. Removed
Continue case from PreDMA since the expected results are
the same as the Non-Continue case. The cache disable test
code was removed to save the overhead of this very
uncommon case.

2.4 - Reworked PostDMA code to fix Nested call cache flush bugs.
We really don't want to forget about systems with multiple
DMA drivers do we?

[klx300r]

@ SpeedGeek


thanks for the update

[klx300r]

my results with this latest update: A1200, Viper 060@50, AmigaOS3.1.4Update1

CacheDMABench 1.1
Public memory CacheDMA FCs: 9500
Chip memory CachDMA FCs: 500
Total CDMA Function calls: 10000
Elapsed Time Microseconds: 1663797

hmmm seems this new update much slower than the previous one for my system?

with v2.2:

CacheDMABench 1.1
Public memory CacheDMA FCs: 9500
Chip memory CachDMA FCs: 500
Total CDMA Function calls: 10000
Elapsed Time Microseconds: 471939

update! noticed that TurboMMU wasn’t run properly from WBStartup as after I launched it from C and ran FastCache benchmark again the Elapsed time in microseconds was 481750

I’ve since put an assign in user-startup for fastcache and turbommu

[SpeedGeek]

** 18TH NEWS UPDATE **

FastCache040+ 2.5 released!

v2.5 - Fixed another rare but possible bug with DMA transfers
crossing the 16MB boundary of the DTTR! So now (except for
MEMF_24BIT DMA transfers) both DTTRs are enabled to
manage the full 32MB of address space.

[SpeedGeek]

** 19TH NEWS UPDATE **

FastCache040+ 2.6 released!

v2.6 - The previous bug fix only worked for addresses in the 16MB
range. This fix should should now work with any address.