Quote:
Originally Posted by paraj
@saimo: If OS is completely off, and there is basically no MMU usage before, then yes, it will probably work. But it's not super uncommon to have things that e.g. move the first 4k to fast mem using MMU so gotta be careful about something like that.
|
I just tested it with both MuMove4K and MuForce running on my real Amiga and on WinUAE emulating a 68040 and a 68060, and it works fine. On the real Amiga the speed drops by 50% when the MMU is active, but specifying the NOMMU switch brings the speed back to normal. Funnily, thanks to the fact my PC isn't powerful, the same happens also under emulation
Could you try the attached version and see if the NOMMU switch does the magic also on your machine, please?
Changes since the previous version:
* fixed a nasty bug that caused a longword to be written to a random location when the fps indicator was on (two bsrs were used before restoring the stack pointer!);
* fixed the shell template ("/FB" -> "=FB/S");
* fixed the cleanup code in a place (it used exec.Supervisor() before the tcr and the OS were restored - thanks to the fact that the vbr points to a copy of the exceptions vectors table and that the code only modifies the level 3 interrupt and the trap #0 and #1 vectors, the flaw didn't have any practical consequences, but still...);
* avoided that the CPU tcr is fiddled with if the NOMMU switch is not specified (so that there are no problems also on 68EC060s).