I wonder if the handles system makes uncaught memory access violations better or worse in applications developed at the time, as it sounds like you need to validate every pointer of each memory allocation your application has each time you access them.


....i kiiiinda see what this was trying to solve without a MMU.... and it shows this was architected with very little future prospect to it, oh well captain hindsight and all that.

Handles are necessary when your OS moves an application (and any memory allocated for it) around in memory at will. It took me awhile to get the hang of it - "now, this is not an address - this is pointer to a pointer!"

There is psuedo memory protection, but it just throws up a bomb unless you have trapped this. There were a few programs (like MacBugs) that did this. I supported a couple of them, and actually used this feature a couple of times to figure out what the Mac was trying to walk on... mostly null/$4 issues.

There are not really "access violations" available as there is no MMU needed (or used) to make this work.



The trouble is, and this is a correct observation, that you need to be very disciplined when using this system. You cannot pass pointers around, you need to pass handles around, well noting that handles can become invalid. There are a couple of Os functions to help you there (LockHandle - to avoid migrating the resource associated to a handle, or MoveHandleHi to avoid that a locked handle blocks defragmentation), but this is very tedious and error-prone.


The good part is that every application consists of (in principle) disk-based resources that can be loaded into memory or migrated if short of memory, which allows a global system application ("ResEdit") to modify applications and its menus, buttons, dialogs and other GUI elements without even having source code available. "ResEdit" and its principles are certainly the better part of MacOs. The memory manager not so much, though the two are of course closely coupled and one wouldn't work without the other.



Maybe even more than you think. The original memory manager used the upper 8 bits of the 24 bit pointer address the 68K CPU offers to indicate the state of a handle (e.g. whether it is locked or not), and then MacOs had to patch around this as later processors offered a larger address space.


As said, it didn't age well. The problems it tried to solve could have been solved better by a MMU similar to what Unix offered already, though - obviously - the CPUs required for this were not available at the time the Mac was designed, or were simply not attractive due to their price.

I never knew what MacOS used those upper bits for, but that makes sense even.



That's quite similar to tagged memory architectures on Burroughs mainframes and LISP machines, of course with those you'd have something like a 32bit pointer with another 4 bits of tags.

I didn't "claim" anything.. I stated a fact. The FPU in the Vampire does not meet the 80 bit precision requirement that Apple relies on for their OS, especially OS8.x.

Apple uses the FPU to do everything from real intense math calculations to simple things like determining the slider position in a window. The slider issue is a dead give away that you don't have full 80 bit precision. For WinUAE this requires that you select the "Soft float" option, which emulates the FPU correctly. Otherwise, you need to turn off the FPU with the Vampire which use to be (I am not sure now) an option that you could do. At that point, the Mac uses software FPU emulation and it works fine, but extremely slow!

You can't. That's the sad part, the FPU stays always on. The only thing you can turn off is the support for the transcendental functions, but it stays double-only. That's what you find on FPGAs today.

Hmmm... you use to be able to turn off the FPU completely using one of the custom registers. I wonder why that went away? If that is true then it validates my decision to abandon custom support for FPGA based Amiga emulations. A non-working FPU on a Mac makes it pretty much useless for compatibility.

You can turn the FPU off in the Vampire still today. When you do that then the soft-FPU kicks in on MacOS.

No, you cannot. You can disable the "minicode" that implements the transcendental functions, but you cannot disable the 64bit-limited FPU instructions for elementary algebra.

Yeah, this is how it use to work - then Soft-FPU works fine at that point. Thanks for confirming.

For the 68060 FPU, yes. But again, as far as I understand - this is not how the Vampire FPU works. I had this discussion during testing of SoftIEEE, the AmigaOs implementation of a software FPU. The elementary FPU algebra cannot be disabled AFAIK, unlike on the 68060. FPU disable bit in the PCR works differently.

We are talking about the Vampire's FPU support... not the 68060. There is a function to disable the FPU completely. The Mac pokes at the FPU directly to see if it can do certain FPU functions to know there is an FPU present or not. When this fails the OS then invokes the software FPU functions which support the industry standard IEEE 80 bit precision.

To disable the FPU on the Vampire so that it works with FUSION you need to run the VControl program and disable the FPU with this line from a CLI:

VControl FP=0

Happy if it works, but I received contradicting informations from other parties, see above.

If software FPU is built-in to MacOS, then why is there a third party extension for it? https://macintoshgarden.org/apps/softwarefpu-307

Several companies made a "SoftwareFPU" for the Mac. Apple's math libraries use the FPU if present, otherwise it is software emulated and you MUST call their libraries (which Apple said you were suppose to do). Many functions like transcendentals are not available via the library.

The software FPU programs actually patch the FPU exception vectors and emulates the FPU exactly in software so you can issue standard FPU commands at a low level. A lot of programs don't call Apple's math libraries and poke at the FPU directly. Those won't work if you don't have a real (or a software emulated) FPU. By running one of the software FPU programs you can basically run everything that requires a real FPU.

There were several Mac machines that used the 68LC040, which is the FPU-less version. ALL Macs had a MMU, even the 020 versions using the 68851, but not all had a FPU. Software FPU programs were necessary for the machines that never had a FPU if they required a FPU (because using actual FPU instructions instead of Apple's library).

I replaced Apple's math packages with my own, which is why math under FUSION is anywhere from 25% to 250% faster than any equiv speed Mac (or other emulator). Its also the reason why A4000's w/EMPLANT boards replaced real Mac AVID video post production systems in Hollywood in the mid-90's. You could render and edit way faster with an Amiga setup than any Mac on the planet at the time.

MacOs comes with its own math functions, named "Apple SANE" that provide programs with numerical algorithms. You can roughly compare "SANE" with what the mathieeedoubbas/doubtrans libraries are on the Amiga. If there is no FPU present, this library (or rather collection of traps on the Mac side) implement the algorithm through the CPU. If an FPU is present, the FPU implements them.

Unfortunately, and like on the Amiga, some software existed that used the FPU directly and did not call through Apple SANE, and for that software you could get this patch, which again is roughly comparable to SoftIEEE on the Amiga.

Hi Guys,
is there a reason why Fusion 3.2 hangs Amiga just before going into Mac emulation on AmigaOS 3.9, while is working perfectly OK with same config on AmigaOS 3.5?
SnoopDOS detects no warnings too.

FUSION doesn't officially support AmigaOS3.9... I have never even tried that version (or AmigaOS 3.5 for that matter).

I can definitely confirm that Fusion is working fine with OS 3.9.

Maybe you should carefully compare the "Startup-Sequence"s of both setups. Also mind SYS:Expansion and SYS:WbStartup. CPU-related libraries (e.g. 68060.library, 68040.library, MuLib-related libraries, or FPU-related libraries) may also be different on your two setups. You could also check if RTG-related libraries (if you use RTG) are differring.

Thanks for confirming! :)