FastRom2MB

[SpeedGeek]

FastRom2MB 1.1 for 68020/030 ©SpeedGeek 2018

INTRODUCTION:
FastRom2MB is an MMU tool which provides up to 2MB Kickstart ROM support to the AmigaOS "CPU" command. The CPU command already remaps the Standard 512KB ROM so this tool just remaps the Extended ROMs and MMU write protects the ROM images.

FEATURES:
- Remaps 512KB Extended ROM @ $E00000
- Remaps 1MB Extended ROM @ $A80000
- MMU write protects Standard and Extended ROMs
- Remaps only into available Fast RAM
- Uses ROM header detection code
- 100% assembler code

REQUIREMENTS:
- 68020 or 68030 CPU with MMU
- 1MB or 2MB Kickstart ROM installed (for remapping)
- AmigaOS CPU command (with FASTROM enabled)

NOTES:
There are only 3 Amiga models (A600, A1200 and CD32) which support 2MB of ROM. Please consider the ROM vs. Fast RAM speed before remapping. If you want to speed up copy operations see the CMQ&B.txt (included).

MMU write protection is over-rated! This tool will NOT prevent your system from crashing! But it will increase the chances of having a "Software Failure" which is useful for debugging purposes.

HISTORY:
v1.0 - First release
v1.1 - Merged FastRomWP code with existing 1MB and 2MB code so the 1MB and WP variants are now obsolete.

[Lorfarius]

In English if anyone can't figure out to translate it:

FastRom2MB 1.0
A new small Roma remapping utility with the MMU for Kickstart 2MB consisting in moving their contained in Fast RAM to accelerate somewhat the OS.

Works very well with my Blizzard 1230

Kickstart 2MB consist of three blocks:

to $ F80000 (512 KB) maprom managed by the CPU control
to $ e00000 (512 KB) managed by maprom FastRom2MB
to $ A80000 (1 MB) managed by maprom FastRom2MB


Caution for now, the new kickstart are large freezer of the 68060.library Phase5 when charged by the Blizzard SetPatch with 1260 ...

As usual, everything is available here free way ...

[SpeedGeek]

** NEWS UPDATE **

FastRom2MB 1.1 released!

v1.1 - Merged FastRomWP code with existing 1MB and 2MB code so the 1MB and WP variants are now obsolete.

NOTE: The first 6 users downloaded a typo version of 1.1. The message now reads "$F80000 (STD) ROM write protected!"

[hooverphonique]

Would it be possible to support kickstart images in files as well? This way larger kickstarts could be conveniently used by other machines.

[SpeedGeek]

Originally Posted by hooverphonique

Would it be possible to support kickstart images in files as well? This way larger kickstarts could be conveniently used by other machines.

Possible yes, but IMO not very practical. This tool relies on MMU code from the CPU command and it has no support code for loading Kickstart image files. So, it's another start all over from scratch project. But the MMU is the least reliable way to handle this particular task.

First, accelerator card custom maprom hardware with MEMF_LOCAL (memory which does not disappear at reset) is the most reliable. Next, Softkick (which requires a lot of ROM image file patching but no MMU code). Last, MMU re-kicking (which requires KickTags, Cold/Warm_capture hacks, exec_base in MEMF_LOCAL, handling expansion.library problems and MMU code but no ROM image file patching).

Finally, after all the above work, only the first option seems to work reliably with many different versions of AmigaOS.

[hooverphonique]

Originally Posted by SpeedGeek

Possible yes, but IMO not very practical. This tool relies on MMU code from the CPU command and it has no support code for loading Kickstart image files. So, it's another start all over from scratch project. But the MMU is the least reliable way to handle this particular task.

First, accelerator card custom maprom hardware with MEMF_LOCAL (memory which does not disappear at reset) is the most reliable. Next, Softkick (which requires a lot of ROM image file patching but no MMU code). Last, MMU re-kicking (which requires KickTags, Cold/Warm_capture hacks, exec_base in MEMF_LOCAL, handling expansion.library problems and MMU code but no ROM image file patching).

Finally, after all the above work, only the first option seems to work reliably with many different versions of AmigaOS.

That sounds a bit hairy - my train of thought was that extending an existing MMU-based solution would be easy to do (just copy the image from file instead of rom)... Of course the point about MEMF_LOCAL is important.. I remember having used Set040 for this in the past on my A4k, but don't remember if it was through the A3640 maprom feature, or MMU-based.

[SpeedGeek]

Originally Posted by hooverphonique

That sounds a bit hairy - my train of thought was that extending an existing MMU-based solution would be easy to do (just copy the image from file instead of rom)... Of course the point about MEMF_LOCAL is important.. I remember having used Set040 for this in the past on my A4k, but don't remember if it was through the A3640 maprom feature, or MMU-based.

Yes, hairy, messy, complicated and buggy. Loading a file in to Fast RAM is the easy part. The hard part is trying to make the re-kick operation work reliably. Set040 used Chip RAM and the MMU so it works without any custom Maprom hardware but as previously explained, the custom Maprom hardware is still the most reliable.

Anyway, if you want a more detailed explanation you should read the "Technical Details" for CpuControl106:

http://aminet.net/util/boot/CpuControl106.lha

[SpeedGeek]

** 2ND NEWS UPDATE **

FastROMbench 1.0 released. See images in post #1.

[patrik]

I am trying to replicate the difference I can see in the screenshot between setcpu fastrom and the OS-included cpu fastrom.

In the screenshot, I see that you get wastly better numbers after running cpu fastrom, but I get the same result for both.

In addition to what shown in the screenshot, I also ran FastRom2MB and tested again, but still same result.

Is there anything obvious I am doing wrong? Testing under Kickstart/WB 3.1 here as the A3000 has Kickstart 3.1:

11.Ram Disk:> version
Kickstart 40.68, Workbench 40.42
11.Ram Disk:> temp:SetCPU/SetCPU fastrom
SYSTEM: 68030 68882 FASTROM (INST: CACHE BURST) (DATA: CACHE NOBURST)
11.Ram Disk:> temp:FastROMbench 
FastROMbench 1.0 ©SpeedGeek 2019
---------------------------------
704KB Public memory reads.: 2000
Elapsed time Microseconds.: 1145948
 
11.Ram Disk:> temp:SetCPU/SetCPU nofastrom
SYSTEM: 68030 68882 (INST: CACHE BURST) (DATA: CACHE NOBURST)
11.Ram Disk:> cpu fastrom
System: 68030 68882 FastROM (INST: Cache Burst) (DATA: Cache NoBurst)
11.Ram Disk:> temp:FastROMbench 
FastROMbench 1.0 ©SpeedGeek 2019
---------------------------------
704KB Public memory reads.: 2000
Elapsed time Microseconds.: 1145329
 
11.Ram Disk:> temp:FastRom2MB 
FastRom2MB 1.1 ©SpeedGeek 2018
$F80000 (STD) ROM write protected!
11.Ram Disk:> echo $RC
0
11.Ram Disk:> temp:FastROMbench 
FastROMbench 1.0 ©SpeedGeek 2019
---------------------------------
704KB Public memory reads.: 2000
Elapsed time Microseconds.: 1143061
 
11.Ram Disk:>

[SpeedGeek]

Originally Posted by patrik

I am trying to replicate the difference I can see in the screenshot between setcpu fastrom and the OS-included cpu fastrom.

In the screenshot, I see that you get wastly better numbers after running cpu fastrom, but I get the same result for both.

In addition to what shown in the screenshot, I also ran FastRom2MB and tested again, but still same result.

Is there anything obvious I am doing wrong? Testing under Kickstart/WB 3.1 here as the A3000 has Kickstart 3.1:

You do not need to use FastRom2MB to use the benchmark tool. FastRom2MB only works with the AmigaOS CPU command.

Please provide more detailed info about your system. The FastRomBench tool assumes the "Public" memory being tested is the same Fast RAM as the remapped Kickstart ROM image. But if that's not the case...

Also, FastRomBench does not disable interrupts. So it's possible that too high of an interrupt load can mess up the Benchmark results.

[patrik]

It is a fairly unexpanded rev 6.1 A3000 with the stock 68030, 16MB SC-RAM on the motherboard, a Buster 11 and a X-Surf-100.

Ran the same sequence of commands as what I posted after a boot without startup sequence, with the same result.

[SpeedGeek]

Originally Posted by patrik

It is a fairly unexpanded rev 6.1 A3000 with the stock 68030, 16MB SC-RAM on the motherboard, a Buster 11 and a X-Surf-100.

Ran the same sequence of commands as what I posted after a boot without startup sequence, with the same result.

Okay, I think I know what the problem is. The MMU tables for the AmigaOS CPU command terminate early (at the end of the 24 bit address space). The same thing is probably happening with SetCPU.

So FastRomBench is testing Public Fast RAM which is not managed by the MMU in either case. Hence, the results are nearly identical. I will give some thought to revising the FastRomBench tool to handle this issue.

[SpeedGeek]

** 3RD NEWS UPDATE **

FastROMbench 1.1 released
- Changed Public memory to MEMF_24BIT memory. This
should handle the problem of early MMU table termination on
systems with 32 Bit extended Fast RAM.

[patrik]

Now I get a very large difference between setcpu fastrom and cpu fastrom:

11.Ram Disk:> temp:SetCPU/SetCPU fastrom
SYSTEM: 68030 68882 FASTROM (INST: CACHE BURST) (DATA: CACHE NOBURST)
11.Ram Disk:> temp:FastROMbench11 
FastROMbench 1.1 ©SpeedGeek 2022
-----------------------------------
704KB MEMF_24BIT memory reads: 2000
Elapsed time Microseconds....: 3967341
 
11.Ram Disk:> temp:SetCPU/SetCPU nofastrom
SYSTEM: 68030 68882 (INST: CACHE BURST) (DATA: CACHE NOBURST)
11.Ram Disk:> cpu fastrom
System: 68030 68882 FastROM (INST: Cache Burst) (DATA: Cache NoBurst)
11.Ram Disk:> temp:FastROMbench11 
FastROMbench 1.1 ©SpeedGeek 2022
-----------------------------------
704KB MEMF_24BIT memory reads: 2000
Elapsed time Microseconds....: 1723758
 
11.Ram Disk:> temp:FastRom2MB 
FastRom2MB 1.1 ©SpeedGeek 2018
$F80000 (STD) ROM write protected!
11.Ram Disk:> temp:FastROMbench11 
FastROMbench 1.1 ©SpeedGeek 2022
-----------------------------------
704KB MEMF_24BIT memory reads: 2000
Elapsed time Microseconds....: 1720363

Does these numbers make more sense? Is the reason for the speed difference the MMU page size difference between setcpu and cpu?

FastROM2MB is not supposed to change the speed I assume, only add support for 2MB kickstarts?

[SpeedGeek]

Originally Posted by patrik

Now I get a very large difference between setcpu fastrom and cpu fastrom:

Does these numbers make more sense? Is the reason for the speed difference the MMU page size difference between setcpu and cpu?

FastROM2MB is not supposed to change the speed I assume, only add support for 2MB kickstarts?

Yes, the numbers make sense. On the A3000 system you mentioned above, the MEMF_24BIT memory tested would in fact be Chip RAM. So using a low bandwith screen mode will provide the fastest results.

The MMU page size is the primary (largest) factor in overall MMU performance. The MMU table config is the secondary (smaller) factor in overall MMU performance.

BTW, you can use FastROMbench for testing other MMU tools if you like. It only checks that the MMU is enabled (so the Kickstart ROM does not have to be remapped).

P.S. FastRom2MB can remap 1MB Kickstarts or just use it to MMU write protect 512KB ROMs if you like.

[hooverphonique]

But does using MEMF_24BIT even make sense on an A3000/A4000 with motherboard or accelerator board ram? It would use chip ram for the rom remap, which isn't even cacheable?

[SpeedGeek]

Originally Posted by hooverphonique

But does using MEMF_24BIT even make sense on an A3000/A4000 with motherboard or accelerator board ram? It would use chip ram for the rom remap, which isn't even cacheable?

It makes sense for the benchmark tool since it does not do any ROM remapping. The remapping tools are using either MEMF_PUBLIC or MEMF_FAST for the remap.

The only difference is that using MEMF_PUBLIC could result in Chip RAM being used for the ROM remap if no Fast RAM was available. That's why FastRom2MB uses only MEMF_FAST.

P.S. CPU version 44.4 now uses only MEMF_FAST.