15 October 2018, 01:35 | #41 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 864
|
|
15 October 2018, 15:59 | #42 |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 848
|
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).
|
15 October 2018, 20:07 | #43 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 864
|
CS MK1 with 68060.library 46.15.
EDIT: And I use 'mmulist' by Michael van Elst(sp?) to look at the result. |
16 October 2018, 16:54 | #44 |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 848
|
With the 68060.library 46.15 I get the following (before and after FixMapP5) results:
Before: Code:
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 Code:
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 P.S. The ROM mapping change to write-through is optional and won't affect system stability. Last edited by SpeedGeek; 20 October 2018 at 15:50. |
20 October 2018, 03:31 | #45 | |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 864
|
Quote:
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? |
|
20 October 2018, 15:48 | #46 | |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 848
|
Quote:
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. |
|
20 October 2018, 21:38 | #47 | ||
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 864
|
Quote:
Quote:
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. |
||
21 October 2018, 18:10 | #48 | ||
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 848
|
** 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. Quote:
FixMapP5 1.3 should solve the problem now. Quote:
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. Last edited by SpeedGeek; 22 October 2018 at 19:17. |
||
23 October 2018, 15:05 | #49 |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 848
|
** 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. |
25 November 2018, 17:43 | #50 |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 848
|
** 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. |
20 December 2018, 20:14 | #51 |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 848
|
** 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. |
24 December 2018, 14:39 | #52 |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 848
|
** 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. |
18 December 2019, 02:28 | #53 |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 848
|
** 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. Last edited by SpeedGeek; 18 December 2019 at 20:23. |
07 March 2020, 18:17 | #54 |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 848
|
** 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? Last edited by SpeedGeek; 08 March 2020 at 03:49. |
08 March 2020, 07:40 | #55 |
Registered User
Join Date: Oct 2007
Location: ManCave, Canada
Posts: 1,668
|
@ SpeedGeek
thanks for the update |
08 March 2020, 08:48 | #56 |
Registered User
Join Date: Oct 2007
Location: ManCave, Canada
Posts: 1,668
|
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 Last edited by klx300r; 08 March 2020 at 09:10. |
26 October 2022, 18:01 | #57 |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 848
|
** 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. |
01 March 2024, 14:09 | #58 |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 848
|
** 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. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
plipbox 0.5 released | lallafa | News | 0 | 29 November 2013 23:11 |
Never released??? | tomcat666 | project.aGTW | 18 | 18 January 2010 14:44 |
AmigaSYS 3 Released! | Dary | News | 89 | 13 April 2007 15:34 |
16.6 Released | alexh | project.WHDLoad | 6 | 09 June 2006 10:02 |
|
|