AmigaOS3.2 on A2000 with A2630 (030) CPU Board

[patrik]

Originally Posted by SpeedGeek

Is there any reason you can't just use CPU FastROM? Since, I already explained this in great detail and even updated the benchmark tool I think it's a fair question to ask.

Sorry if I don't understand, but would CPU FastROM make 68030.library+mmu.library use a larger MMU page size?

Nevertheless, wouldn't it be a good idea if 68030.library+mmu.library by default used an optimal MMU page size instead of resorting to 1k - so having these libraries installed would not slow down everyones 030 system more than necessary.

On this topic of MMU page size, is there any tool available which can show what the MMU page size is set to?

[SpeedGeek]

Originally Posted by patrik

Sorry if I don't understand, but would CPU FastROM make 68030.library+mmu.library use a larger MMU page size?

Nevertheless, wouldn't it be a good idea if 68030.library+mmu.library by default used an optimal MMU page size instead of resorting to 1k - so having these libraries installed would not slow down everyones 030 system more than necessary.

On this topic of MMU page size, is there any tool available which can show what the MMU page size is set to?

What I meant was, just use CPU FastROM instead of the 68030.library + mmu.library. These 2 libraries will use much more memory than CPU FastROM and their default MMU config is much slower than CPU FastROM.

As mentioned on the FastRom2MB thread the MMUX32 tool is available on Aminet:

http://aminet.net/search?query=mmux32

[patrik]

Originally Posted by SpeedGeek

What I meant was, just use CPU FastROM instead of the 68030.library + mmu.library. These 2 libraries will use much more memory than CPU FastROM and their default MMU config is much slower than CPU FastROM.

As mentioned on the FastRom2MB thread the MMUX32 tool is available on Aminet:

http://aminet.net/search?query=mmux32

Thanks for the MMUX32 tool tip , page size is not an unknown anymore:

7.Ram Disk:> version full 
Kickstart 47.7, Workbench 47.3 (2021-07-13)
7.Ram Disk:> version full mmu.library 
mmu.library 47.5 (2022-05-27)
(c) 1999-2022 The MMU.lib development group, THOR
7.Ram Disk:> version full 68030.library 
68030.library 46.6 (2021-02-18)
(c) 1999-2016 The MMU.lib development group, THOR
7.Ram Disk:> mmux32 -verbose 
MMU logical space is 4 GB, page size is 1 kB.
Translation $0, page address $0.
Early terminating short format page descriptor at level B.
Page attributes: Used,Modified,CacheInhibit.
Inherited attr.: none.
Descriptorpath:  $71D0000,$71D0800.
Levelpath:   (root),A,B.
Indexpath:   $0,$0.
Maskpath:    $FF000000,$FC0000.
Blksizepath: 24,18.

I think I should be clear about why I am interested in page size brought up in this thread.

I am not interested in running cpu fastrom as I am running 3.2.1 on an A3000 030@25MHz and have a 3.1 kickstart rom - all 3.1 components in rom are replaced with 3.2.1 components in fastram by LoadModule anyway.

As a paranthesis, I just noticed that in 3.2.1, the CPU fastrom feature has been removed.

Also, even if I had a 3.2.1 kickstart, the EPROM I would burn it on is fast enough to run at the fastest rom timing on the A3000 motherboard, which gives same wait states as fastram in this machine. The only downside to running from rom would be that it is missing the burst that the static column fastram has, so instruction cache burst fill would suffer a bit, but I am positive that the overhead of the MMU running would more than nullify that win anyway.


I want to have 68030.library+mmu.library in my system primarily to be able to run MuForce as its a great improvement to the Enforcer - for example just its ability to show the disassembly of the code where the hit happened is a killer feature imho.

What I dislike is that by just having those libraries in LIBS:, SetPatch will load them and activate the MMU with a setup that makes the computer noticeably slower - it is just a 030@25MHz, it does not need that.

As I understand, this slowdown would by way smaller if it did not use the small 1k page size, which brings me to the question I had to @Thomas Richter:
If 68030.library+mmu.library finds the MMU unconfigured, could it be improved to check for start of chipmem to be able to decide to use a larger and better performing page size instead of defaulting to 1k?

[Thomas Richter]

You can configure the page size yourself if you think that there is an advantage. There is no external program needed for that, just an entry in the MMU-Configuration file. The libraries are needed anyhow and do not take much memory.

You find examples for alternative page layouts in the MMU.guide that is part of the distribution. Hint: Check for the "Layout" command in the MMU-Configuration. In general, the improvements are rather minor (and the slowdowns either...).

Note well that the 68030 does have a CPU erratum, so enabling the MMU is recommended to work around this erratum - and this is even needed for some setups, for example a bridgeboard or a Cvision3D will not work without the MMU active on a 68030.

CPU FastRom has been removed because there are really better alternatives now. It does not make sense anymore in 2022 to hack the MMU manually.

You do not need any third party tools to identify how the MMU has been configured, BTW. MuScan does that job for you.

[SpeedGeek]

Originally Posted by patrik

Thanks for the MMUX32 tool tip , page size is not an unknown anymore:
I think I should be clear about why I am interested in page size brought up in this thread.

I am not interested in running cpu fastrom as I am running 3.2.1 on an A3000 030@25MHz and have a 3.1 kickstart rom - all 3.1 components in rom are replaced with 3.2.1 components in fastram by LoadModule anyway.

As a parenthesis, I just noticed that in 3.2.1, the CPU fastrom feature has been removed.

Also, even if I had a 3.2.1 kickstart, the EPROM I would burn it on is fast enough to run at the fastest rom timing on the A3000 motherboard, which gives same wait states as fastram in this machine. The only downside to running from rom would be that it is missing the burst that the static column fastram has, so instruction cache burst fill would suffer a bit, but I am positive that the overhead of the MMU running would more than nullify that win anyway.

I want to have 68030.library+mmu.library in my system primarily to be able to run MuForce as its a great improvement to the Enforcer - for example just its ability to show the disassembly of the code where the hit happened is a killer feature imho.

What I dislike is that by just having those libraries in LIBS:, SetPatch will load them and activate the MMU with a setup that makes the computer noticeably slower - it is just a 030@25MHz, it does not need that.

As I understand, this slowdown would by way smaller if it did not use the small 1k page size, which brings me to the question I had to @Thomas Richter:

Okay, it's your A3000 system and you can set it up anyway you want. But just keep in mind the page size is not the only factor in MMU performance.

Now, just because the CPU command was downgraded with this particular OS version that does not mean you can't use an older version of the CPU command. BTW, the older versions also moved the VBR into Fast RAM.

Also, there are several other tools which can disassemble memory (but I'm not aware of any that do it directly from an Enforcer hit).

On your A3000 system, you are probably better off not to enable the MMU unless you need the debugging function. But you would still want to move the VBR to Fast RAM (without the FastROM enabled).

[SpeedGeek]

Originally Posted by Thomas Richter

Note well that the 68030 does have a CPU erratum, so enabling the MMU is recommended to work around this erratum - and this is even needed for some setups, for example a bridgeboard or a Cvision3D will not work without the MMU active on a 68030.

Recommended? Not really, the MMU is just one way to work around the problem. The other simple way is CPU NODATACACHE (I'll keep my fingers crossed and hope this "Hack" didn't get removed too).

Originally Posted by Thomas Richter

CPU FastRom has been removed because there are really better alternatives now. It does not make sense anymore in 2022 to hack the MMU manually.

Better alternatives now? Nope. I'm afraid CPU FastROM is the fastest MMU ROM remapping tool you will ever see. I don't see CPU FastROM hacking the MMU any more than the mmu.library hacking the MMU. But the results do speak for themselves.

[patrik]

Originally Posted by Thomas Richter

You can configure the page size yourself if you think that there is an advantage. There is no external program needed for that, just an entry in the MMU-Configuration file. The libraries are needed anyhow and do not take much memory.

You find examples for alternative page layouts in the MMU.guide that is part of the distribution. Hint: Check for the "Layout" command in the MMU-Configuration. In general, the improvements are rather minor (and the slowdowns either...).

Thank you very much for that info and the MuScan tip!

I have fiddled with the Layout command and without knowing how to distribute the bits, it does change the performance.

Will again use ttcp results to demonstrate the difference as maxing out the CPU transferring data through the network stack is quite affected by enabling the MMU.

Reference results, no MMU running:

7.Ram Disk:> version mmu.library
kan ej finna objektet
7.Ram Disk:> mmux32 -verbose 
**MMUx: The MMU is not enabled.
7.Ram Disk:> ttcp -s -r | search seconds NONUM
ttcp-r: 16777216 bytes in 24.38 real seconds = 672.03 KB/sec +++
7.Ram Disk:> ttcp -s -r | search seconds NONUM
ttcp-r: 16777216 bytes in 24.42 real seconds = 670.93 KB/sec +++
7.Ram Disk:> ttcp -s -r | search seconds NONUM
ttcp-r: 16777216 bytes in 24.36 real seconds = 672.58 KB/sec +++

MMU enabled, standard 030 1k page size, performance -15.6%:

7.Ram Disk:> version mmu.library
mmu.library 47.5
7.Ram Disk:> muscan | search page NONUM
MMU page size is 0x400 bytes.
7.Ram Disk:> echo "${MMU-Configuration}"
${MMU-Configuration}
7.Ram Disk:> ttcp -s -r | search seconds NONUM
ttcp-r: 16777216 bytes in 28.90 real seconds = 566.92 KB/sec +++
7.Ram Disk:> ttcp -s -r | search seconds NONUM
ttcp-r: 16777216 bytes in 28.90 real seconds = 566.92 KB/sec +++
7.Ram Disk:> ttcp -s -r | search seconds NONUM
ttcp-r: 16777216 bytes in 28.90 real seconds = 566.92 KB/sec +++

MMU enabled, 4k page size ala the 040 setup from MMU.guide, performance -10.2%:

7.Ram Disk:> version mmu.library
mmu.library 47.5
7.Ram Disk:> muscan | search page NONUM
MMU page size is 0x1000 bytes.
7.Ram Disk:> echo "${MMU-Configuration}"
Layout LEVELA 7 LEVELB 7 LEVELC 6 PAGEBITS 12
7.Ram Disk:> ttcp -s -r | search seconds NONUM
ttcp-r: 16777216 bytes in 27.14 real seconds = 603.68 KB/sec +++
7.Ram Disk:> ttcp -s -r | search seconds NONUM
ttcp-r: 16777216 bytes in 27.14 real seconds = 603.68 KB/sec +++
7.Ram Disk:> ttcp -s -r | search seconds NONUM
ttcp-r: 16777216 bytes in 27.20 real seconds = 602.35 KB/sec +++

MMU enabled, 16k page size, performance -5.7%:

7.Ram Disk:> version mmu.library
mmu.library 47.5
7.Ram Disk:> muscan | search page NONUM
MMU page size is 0x4000 bytes.
7.Ram Disk:> echo "${MMU-Configuration}"
Layout LEVELA 7 LEVELB 7 LEVELC 4 PAGEBITS 14
7.Ram Disk:> ttcp -s -r | search seconds NONUM
ttcp-r: 16777216 bytes in 25.82 real seconds = 634.55 KB/sec +++
7.Ram Disk:> ttcp -s -r | search seconds NONUM
ttcp-r: 16777216 bytes in 25.86 real seconds = 633.57 KB/sec +++
7.Ram Disk:> ttcp -s -r | search seconds NONUM
ttcp-r: 16777216 bytes in 25.92 real seconds = 632.10 KB/sec +++

MMU enabled, 32k page size, performance -3.9%:

7.Ram Disk:> version mmu.library
mmu.library 47.5
7.Ram Disk:> muscan | search page NONUM
MMU page size is 0x8000 bytes.
7.Ram Disk:> echo "${MMU-Configuration}"
Layout LEVELA 7 LEVELB 7 LEVELC 3 PAGEBITS 15
7.Ram Disk:> ttcp -s -r | search seconds NONUM
ttcp-r: 16777216 bytes in 25.36 real seconds = 646.06 KB/sec +++
7.Ram Disk:> ttcp -s -r | search seconds NONUM
ttcp-r: 16777216 bytes in 25.36 real seconds = 646.06 KB/sec +++
7.Ram Disk:> ttcp -s -r | search seconds NONUM
ttcp-r: 16777216 bytes in 25.40 real seconds = 645.04 KB/sec +++

I would argue that at default 1k page size, the performance drop of 15.6% is not minor, however at 16k or 32k page size I would say it is minor.

Got a few questions:
- Now I just used the standard 040 4k setup and reduced LEVELC bits and increased PAGEBITS to achieve the 16k and 32k page sizes. Is there a better way of distributing the bits between the levels?
to distribute the bits between the levels?
- Is it correct that for the 32kB page size, I would need to run MuMove4K to free the first 32kB of chipmem to get MuForce to run efficiently?

Originally Posted by Thomas Richter

Note well that the 68030 does have a CPU erratum, so enabling the MMU is recommended to work around this erratum - and this is even needed for some setups, for example a bridgeboard or a Cvision3D will not work without the MMU active on a 68030.

No worries, got no cards with issues running with the MMU disabled in this machine.

[patrik]

Originally Posted by SpeedGeek

Okay, it's your A3000 system and you can set it up anyway you want. But just keep in mind the page size is not the only factor in MMU performance.

I can appreciate that given that there are so many variables to this. I would guess how complicated the tables are plus the distribution of lookup bits I asked about in the previous post could have quite some influence?

Originally Posted by SpeedGeek

On your A3000 system, you are probably better off not to enable the MMU unless you need the debugging function. But you would still want to move the VBR to Fast RAM (without the FastROM enabled).

Yes, for my usecase, it would be optimal if the MMU only was enabled when I need it, which is when I run MuForce, MuGuardianAngel etc.

Say if mmu.library was not activated by SetPatch, but instead only when opened by for example MuForce and then when MuForce exits, it sees it has no opens and expunges itself and disables the MMU. No idea if that would be a possible mode of operation.

[patrik]

@SpeedGeek:

As you say, CPU FastROM on a 3.1 system is indeed very fast - it causes no slowdowns at all actually, atleast not with this ttcp test which so far has been very good at indicating MMU-related slowdowns:

11.Ram Disk:> version
Kickstart 40.68, Workbench 40.42
11.Ram Disk:> version mmu.library
object not found
11.Ram Disk:> mmux32 -verbose
**MMUx: The MMU is not enabled.
11.Ram Disk:> ttcp -s -r | search seconds NONUM
ttcp-r: socket
ttcp-r: accept from 192.168.1.1
ttcp-r: 16777216 bytes in 24.16 real seconds = 678.15 KB/sec +++
11.Ram Disk:> ttcp -s -r | search seconds NONUM 
ttcp-r: socket
ttcp-r: accept from 192.168.1.1
ttcp-r: 16777216 bytes in 24.16 real seconds = 678.15 KB/sec +++
11.Ram Disk:> cpu fastrom
System: 68030 68882 FastROM (INST: Cache Burst) (DATA: Cache NoBurst)
11.Ram Disk:> mmux32 -verbose
MMU logical space is 2 GB, page size is 32 kB.
Translation $0, page address $0.
Early terminating short format page descriptor at level B.
Page attributes: Used,Modified,SharedGlobally.
Inherited attr.: SharedGlobally.
Descriptorpath:  $71EDC20,$71ED940.
Levelpath:   (root),A,B.
Indexpath:   $0,$0.
Maskpath:    $7F000000,$F80000.
Blksizepath: 24,19.
11.Ram Disk:> ttcp -s -r | search seconds NONUM
ttcp-r: socket
ttcp-r: accept from 192.168.1.1
ttcp-r: 16777216 bytes in 24.16 real seconds = 678.15 KB/sec +++
11.Ram Disk:> ttcp -s -r | search seconds NONUM
ttcp-r: socket
ttcp-r: accept from 192.168.1.1
ttcp-r: 16777216 bytes in 24.18 real seconds = 677.58 KB/sec +++

Also, as I mentioned on the A3000 with fastest kickstart ROM timing setting, the ROM is as fast as the RAM, so in this case there is no gain from enabling CPU FastROM, which you can see. Opposite worlds compared to say an A500/A2000 with an accelerator.

A big part of CPU FastROM being so efficient I guess is from it using the most performant 32kB page size, but mmu.library was not even this good at 32kB, so the rest of the table must as you say have something to do with the performance too.