MAC emulators?

[JimDrew]

I don't think people understand how emulations work. The code for this integral, meaning that this affects the entire operation of the code. The problem is the Mac itself pokes at the MMU all of the time as part of its normal operation. This is also the case with standard Mac apps that bypass the OS routines to poke at the MMU. I have to trap and change any access to the MMU when there is an MMU present, and when there is no MMU present the CPU is suppose to fault and then that is trapped. With EMU68 there is no fault occurring because that is not supported apparently. Turning off the MMU means only 256K ROMs and no OS8.1. For FUSION this is normally not an issue because people always have a MMU present when there is a 68030/040/060 being used. There is no MMU or even basic support in EMU68, which means everything is much slower having to use 256K ROMs and constantly patching every single MMU operation on the fly. If the author of EMU68 would add the basic stuff that the Vampire and other things have, then this would not be an issue.

[Gorf]

Originally Posted by JimDrew

The problem is the Mac itself pokes at the MMU all of the time as part of its normal operation.

Ah OK - that was the missing sentence. In your last comment it sounded like Fusion needed it be itself :
"FUSION *requires* a MMU when you are using a 68030 or later, OR the CPU can fault out correctly and continue with an EC030."

Now I get it - thanks for the clarification.

[hammer]

Originally Posted by JimDrew

Still working to try to get around the problem with EMU68. FUSION *requires* a MMU when you are using a 68030 or later, OR the CPU can fault out correctly and continue with an EC030. There is something about EMU68's implementation that simply crashes the CPU when a MMU register is poked at. Toni added a fix for this to WinUAE eons ago, but the author of EMU68 doesn't seem to want to add this... Vampire, Minimeg, Replay, etc. all have this built in and work fine - it's just EMU68 with the issue.

The reality is at the moment you can't use a 512KB or 1MB Mac ROM with EMU68 and FUSION. 256K MacII ROMs work fine, but you are severely limited in what you can run for MacOS versions (no MacOS 8.x).

The standard PiStorm 68K emulation works perfectly though with FUSION - it's just EMU68 that has this issue.

This is the only hold up for releasing FUSION 4 at this point. I spent a LOT of time making FUSION work better with EMU68's caching mechanism. The MacOS does cache flushing constantly and this causes EMU68 to stall constantly. I have resolved quite a bit of that by re-writing parts of the Mac's system resources to only flush when absolutely necessary.

https://amigaworld.net/modules/newbb...140&151#854592

According to michalsc, Emu68's 68040 MMU feature is WIP.

[JimDrew]

I have been in contact with Michal about this issue in recent days. The problem was actually discovered by him probably a year ago now. The Mac on boot up starts poking at the FPU and MMU to determine what types are being used. The 68020 Macs use the 68851 and the 030/040 had different MMU configurations. The only way to know what you are really using is by doing various instructions. This process causes EMU68 to crash. So, I need to go back in history (Discord) and find the screenshots that Michal made showing the issue - which at the time he said he zero interest in supporting. That apparently has changed if I can help him pin-point the issue(s). So, that's good news.

Of course, having a real (or correctly emulated) MMU is the way to go as that guarantees extremely high compatibility. It's the reason why FUSION runs so fast and stable on real hardware (and WinUAE).