Quote:
Originally Posted by Thomas Richter
If you are loading modules with LoadModule, these will typically already end up in the fastest memory - if that memory survives a reset. MuFastROM only places the ROM components in RAM, but not those coming from LoadModule. What you can do is to use MuProtectModules to prevent them from getting overwritten.
BlazeWCP should not provide a significant improvement anymore, at least not as significant as under 3.1. The graphics.library chunky to planar conversion functions became a lot faster with 3.1.4 already.
I still wonder where FBlit is faster than P96. P96 improved its low-level functions also over the last versions, including FillRect and BltBitMap.
What you can try is MuFastZero *if* your system does not provide autoconfiguring fast RAM. This will move exec (and expansion) to the fastest RAM available. Again, this does not hold if fast ram is autoconfiguring as then exec will relocate itself to this ram already as soon as expansion got its chance to integrate the RAM.
|
I found that running:
Code:
MuMove4k A1200 PrepareEmul
MuFastROM ON PROTECT
MuFastZero ON FASTEXEC MOVESSP
... does seem to improve things slightly on a TF1230 system. How on earth do I know this?
Well... I am no expert but SysInfo gives better results, ResidentSpeed gives good results and checking with Scout everyhing seems to be located in Fast RAM, except for the expansion.library of course.
Maybe we were bashing Native/P96 a bit too hard. They are similar but I feel like Workbench usage feels snappier when using FBlit. Maybe it's because P96 doesn't patch text which is very apparent in some SysSpeed tests and you also notice it when using applications, like TextEdit or ATC for example.