TurboMMU040+ released!

[SpeedGeek]

TurboMMU040+ 1.8 ©SpeedGeek 2020

INTRODUCTION:
TurboMMU040+ is an MMU tool to maximize the MMU performance
of most* 68040 and 68060 libraries. The MMU is a most excellent
and valuable feature of advanced 68K CPUs. Unfortunately, it's
usage does not come without any performance loss. How much
performance is lost depends on many factors, but this tool
deals specifically with the MMU configuration factors.

FEATURES:
- Enables 8K page mode MMU operation!
- Converts existing 4K page tables to 8K page tables
- Does NOT increase memory usage for MMU tables
- Enables (optional) ITTx management for 4GB of address
space!
- Uses 68040/060 library detection code
- 100% Assembler code

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

PERFORMANCE AND TECHNICAL ISSUES:
The 8K page size provides a 2x increase in the address space
which resides in the ATC. When a page address "Hits" in the
ATC it provides a "Zero" wait state address translation.
When a page address "Misses" in the ATC the MMU performs a
table search in memory to find the page address. Hence, many
wait states are incurred which result in a performance loss.
Both the 68040 and 68060 have a 64 entry ATC so 64 x 4K =
256K and 64 x 8K = 512K.

The ITTx registers manage the instruction page descriptors
for a 16MB - 4GB size of address space. They are typically
disabled but may be enabled for part of the address space by a
few libraries. TurboMMU040 optionally enables it for the full
4GB of address space. This effectively bypasses the MMU
and provides "Zero" wait state performance for all instruction
translations. The ITTx usage trade off is the loss of the of
the performance benefit (if any) from remapping the Kickstart
ROM(s) into Fast memory. Also, if the library has already
enabled the ITTx you may want to keep the default settings.

WARNINGS:
*************************************************
Systems configured with a DMA driver MUST install
FastCache040+ before using this tool! Otherwise, the
CachePreDMA/PostDMA API of the 68040/060 library will assume
the 4K page size and fail to modify the correct pages
resulting in eventual data transfer errors!
*************************************************

Failure to disable or unmap MMU remapped Kickstart ROM(s)
will result in a loss of memory which can NOT be reclaimed
after conversion to 8K pages (YOU HAVE BEEN WARNED!).

Attempted usage of this tool with existing 4K MMU tools is
VERY risky! Some tools will check the page size and safely
exit, but others will just assume the page size is correct
and proceed to crash your system! Likewise, libraries which
have a built in API (e.g. Phase 5) should be used with
caution.

This tool does NOT always provide an identical memory map to
the original. Specific cases when mapping will change are:

1) MMU remapping of the Zero page area is 4K aligned (MMU
remapping is disabled).
2) SRP table differs from URP table (URP table replaces SRP
table).
3) The Kickstart MMU remap warnings have been ignored (All
physical ROM addresses are restored).

*Compatibility support for most 68040 and 68060 libraries does
NOT mean all of them!

NOTES:
The executable file name excludes the "+" character to avoid
problems with the Amiga Shell. See TurboMMUtools.txt for info
on the initial support tools.

UPDATE:
Added MapConTM060 1.0 to archive. MapConTM060 supports the
very proprietary TekMagic 68060.library. See MapConTM060.txt
for more info. Since v1.5 TurboMMU040+ allocates 16KB of RAM
to handle the (few) libraries which use 4K aligned remapping
of the $FFFF8000 space.

HISTORY:
v1.0 - First release
v1.1 - Added code to keep the Zero page remapping if it meets
the 8K alignment requirement (So you got a 50/50 chance)
v1.2 - Added code to compare Page table address at 8K blocks
vs. 4K blocks. This might improve indirect mapping accuracy only since direct mapping is always converted to the physical address.
v1.3 - Updated code to allow indirect mapping of the "Extended" Zero page area. Added NOITTx option so the libraries default ITTx settings can be maintained.
v1.4 - Added code to detect and report FastCache040+ as a
helpful reminder.
v1.5 - Added code to keep direct remapping of $FFFF8000 space for libraries which don't use indirect. Lha_68K gets a psuedo Enforcer hit for relying on MMU remapping here.
v1.6 - Added code to disable the DTTx registers. This is a quick fix to support the very proprietary Apollo 68060.library. Apollo gets away with the default DTTx enable only because the SCSI controller doesn't use DMA.
v1.7 - Fixed typo bug for ITTx options. Now shows 4GB size.
v1.8 - Added code to disable Zero page remapping when the Chip RAM start addr is not remap compatible. Otherwise, OS3.1 systems in particular could crash if the Zero page was remapped.

TurboMMU040+ FAQ 1.1

Q. Most 68040 and 68060 libraries is not very specific. So why not
provide a list of supported libraries?

A. It was not possible to fully test the libraries on a single
system. Also, the "Very Proprietary" libraries were psuedo tested
on a generic system. For what it's worth, the list of tested
libraries is as follows:

Commodore    68040.library 37.30
H&P          68040.library 44.2
Phase 5      68040.library 46.5¹
Phase 5      68060.library 46.7¹
Carsten S.   68060.library 40.38
TekMagic     68060.library 2.3²
Apollo       68060.library 60.10

¹Requires caution (See P5 section)
²Requires MapConTM060 (See MapConTM060.txt in main archive)

Q. The docs warn users to disable MMU remapped Kickstart ROMs
first before using the TurboMMU040 tool. OK, so then what are my
options for remapping the Kickstart ROMs after conversion to 8K
pages? 

A. See TurboRom040+ for MMU based remapping (included in 
TurboMMUtools archive). Also, you can always use accelerator card
custom MapROM hardware functions.

Q. I want to try using the ITTx option but how do I first
determine the if the library enables the ITTx by default?

A. See MMUreg (included in TurboMMUtools archive). TIP: Disabled
registers = 0  
  
Q. The docs warn libraries with an API (e.g. Phase 5) should be
used with caution. So what is the specific caution?

A. After using the TurboMMU040 tool, you must avoid using any P5
library MMU functions which use the 4K page mode (e.g.
SetCacheMode and Rom2Fast) but you can still use the non-MMU
functions (e.g. CyberMap and SetMemMode).

Q. The TurboMMUtools archive includes remapping tools but no
tools for changing the cache mode. Why?

A. You can always use existing cache mode tools while the MMU is
still in 4K page mode (see examples below):

Setpatch QUIET 
RomCache040 >NIL: ;This C= 68040.library system has a 1MB ROM!
TurboMMU040 >NIL:

Setpatch QUIET 
RomCache040 >NIL: ;This P5 68060.library system has a 1MB ROM!         
FastCache040   ;This P5 68060.library system has a DMA driver!
TurboMMU040 >NIL:

Q: Are there any 3rd party tools which support the MMU 8K page
mode?

A: Yes, MMUlist from Aminet. It's somewhat buggy on register
values and tediously slow on listings but are you willing to
make a better tool yourself?

Q: MMUlist shows the Zero page remapped before I use TurboMMU040
but not afterwards. Do I really need to use RemapZero to restore
the Zero page remapping?

A: No, remapping the Zero page is always optional. The RemapZero
tool was provided just to improve compatibility with some really
old (brain dead) software.      

Q: My favorite benchmark program shows very little (or no)
performance improvement with the TurboMMU040 tool. Why?

A: Your favorite benchmark program was probably designed to test
CPU or CPU + Cache performance (e.g. a standard MIPS test).
Fortunately, TurboMMUbench was specifically designed to test MMU
performance.

[SpeedGeek]

** NEWS UPDATE **

TurboMMU040+ 1.1 released

v1.1 - Added code to keep the Zero page remapping if it meets
the 8K alignment requirement (So you got a 50/50 chance)

EDIT:
Joe Regulars (TM) kolla require a benchmark tool to convince themselves anything is worthwhile. So TurboMMUbench 1.1 has been released! See image in post #1.

[SpeedGeek]

* 2ND NEWS UPDATE **

TurboMMU040+ 1.2 released.

v1.2 - Added code to compare Page table address at 8K blocks
vs. 4K blocks. This might improve indirect mapping accuracy only since direct mapping is always converted to the physical address.

[SpeedGeek]

** 3RD NEWS UPDATE **

TurboMMUtools 1.1 released

- 1.1 Added RemapZero 1.0

[SpeedGeek]

** 4TH NEWS UPDATE **

TurboMMU040+ 1.3 released.

v1.3 - Updated code to allow indirect mapping of the "Extended"
Zero page area. Added NOITTx option so the libraries default ITTx
settings can be maintained.

[SpeedGeek]

** 5TH NEWS UPDATE **

UPDATE:
Added MapConTM060 1.0 to archive. MapConTM060 supports the
very proprietary TekMagic 68060.library. See MapConTM060.txt
for more info.

TurboMMUtools 1.2 released.

- 1.2 TurboRom040+ 1.4 released

EDIT:
*************************************************
Systems configured with a DMA driver MUST install
FastCache040+ before using this tool! Otherwise, the
CachePreDMA/PostDMA API of the 68040/060 library will assume
the 4K page size and fail to modify the correct pages
resulting in eventual data transfer errors!
*************************************************

[trixster]

Thanks for this! I will try it this week

[SpeedGeek]

** 6TH NEWS UPDATE **

TurboMMU040+ 1.4 released.

v1.4 - Added code to detect and report FastCache040+ as a
helpful reminder.

EDIT: TurboMMU040+ 1.4 and TurboMMUtools 1.2 archives have slightly smaller executable(s) as this (edit) update.

[SpeedGeek]

** 7TH NEWS UPDATE **

TurboMMU040+ 1.5 released.

v1.5 - Added code to keep direct remapping of $FFFF8000 space for libraries which don't use indirect. Lha_68K gets a psuedo Enforcer hit for relying on MMU remapping here.

EDIT:
TurboMMUtools 1.3 released.

-1.3 RemapZero 1.1 released

[SpeedGeek]

** COMMENT UPDATE **

Now here is the real Enforcer hit:

New Shell process 3
3.System3.9:> version c:lha
LhA 2.15 68040+ Jan 3 2011

BYTE-READ from FFFFFFFF PC: 07184298
USP: 07116668 SR: 0004 SW: 0121 (U0)(-)(-) TCB: 07159660
Data: 00000000 00000000 00000001 07100000 00000000 00000005 0711669C 00030057
Addr: 00000001 071166F3 00000000 FFFFFFFF 07105D6C 0711689C 071069F8 --------
Stck: 0003A046 072301A8 00000000 071168F0 00000002 0003A0D3 00000000 00000000
Stck: 071882D3 00000001 00000000 00000000 00005702 57002D6C 68642D00 00000000
Name: "Shell Process" CLI: "lha" Hunk 0000 Offset 000063C8

As you can see, it's from the latest Lha 2.15 from Aminet. But this post is NOT made to complain about typical Software bugs. It's about the questionable policy of relying on the MMU to keep buggy Software working.

If the bugs don't get reported to the developer the bugs can't be fixed. Eventually, most Software becomes "Abandonware" and the bugs never will be fixed! But what if you want to use the Software and you only have a stock A500 (68000), stock A1200 (68020) or an accelerator card with a EC030, EC040, EC060?

EDIT: I am no longer able to reproduce this enforcer hit.

[MartinW]

Question (possibly a noob one!): How does this sit with Thors 680x0 libraries? Can it be used with it? Is it used instead of (I assume not)? If it is / can be used is there any guide as to specific things that you must or must not do within Thors libs package?

Apologies if this is obvious stuff. I'm pretty technical but admit to not really knowing what I'm doing when it comes to CPUs and MMU etc.

I have a 68060 (GBA) with 8MB sram + 128MB sdram configured in 32bit address space on boot via flash boot rom. The mmu config file is used to set the various modes of the boot rom (F00000), the Kickstart ROM (F80000) and the 32bit memory.

I don't recall offhand if I use any of the mutools that come with the library.

[SpeedGeek]

Originally Posted by MartinW

Question (possibly a noob one!): How does this sit with Thors 680x0 libraries? Can it be used with it? Is it used instead of (I assume not)? If it is / can be used is there any guide as to specific things that you must or must not do within Thors libs package?

Apologies if this is obvious stuff. I'm pretty technical but admit to not really knowing what I'm doing when it comes to CPUs and MMU etc.

I have a 68060 (GBA) with 8MB sram + 128MB sdram configured in 32bit address space on boot via flash boot rom. The mmu config file is used to set the various modes of the boot rom (F00000), the Kickstart ROM (F80000) and the 32bit memory.

I don't recall offhand if I use any of the mutools that come with the library.

The mmu.library does not qualify as most 68040/060 libraries. While it may be a functional substitute for some of them it will not function exactly the same as the libraries it replaces. So TurboMMU040+ does not "Sit" with the mmu.library for quite a number of reasons:

1) There is absolutely no compatibility testing or support
2) The MMU config and table set up is expected to differ considerably from the libraries this tool supports
3) There is a much larger API (with 4K dependency issues) than the P5 libraries which are supported with some caution.
4) Many systems are configured with a DMA driver which requires the use of FastCache040+. Since FastCache040+ does NOT support virtual memory it was never recommended for and does NOT support the mmu.library

Sorry, you can't use this tool to replace a library. A library contains a lot of code to handle unimplemented FPU and integer instructions and many system patches in addition to the MMU setup code.

[SpeedGeek]

** 8TH NEWS UPDATE **

TurboMMU040+ 1.6 released.

v1.6 - Added code to disable the DTTx registers. This is a quick fix to support the very proprietary Apollo 68060.library. Apollo gets away with the default DTTx enable only because the SCSI controller doesn't use DMA.

[SpeedGeek]

** 9TH NEWS UPDATE **

TurboMMU040+ 1.7 released.

v1.7 - Fixed typo bug for ITTx options. Now shows 4GB size.

[SpeedGeek]

** 10TH NEWS UPDATE **

- TurboMMUtools 1.4 released!
- TurboMMU040+ FAQ 1.0 released!

[SpeedGeek]

** 11TH NEWS UPDATE **

TurboMMU040+ 1.8 released!
TurboMMUtools 1.5 released!

- Added code to disable Zero page remapping when the Chip RAM start addr is not remap compatible. Otherwise, OS3.1 systems in particular could crash if the Zero page was remapped.

[Pyromania]

Does it work with the 68080?

[SpeedGeek]

Originally Posted by Pyromania

Does it work with the 68080?

Either you didn't RTFM the listed "Requirements" or you are joking. In either case LOL!

[Pyromania]

It better support AMMX too LOL!