It is a well-known fact that AmigaOS is a single address space, totally unprotected memory operating system. The original implementation ran on a Motorola 68000, that did not support virtual memory if not by external hacks, and later models and OS version did not support it either due to retrocompatibility issues.

On the other hand, Exec's memory allocation routines accept a (no-op) MEMF_PUBLIC flag that the last official AmigaOS 3.1 Developer's Kit defines as:

MEMF_PUBLIC This indicates that the memory should be accessible to other tasks. Although this flag doesn't do anything right now, using this flag will help ensure compatibility with possible future features of the OS (like virtual memory and memory protection).

So I'm prone to think that there was at least some research internally to retrofit some memory protection/paging/swapping capability in the OS.

I also remember rumors in 1990/1 of an implementation that should have been integrated in a version of the OS past-2.04/V37.

Was this ever real? Did developers receive beta versions of the implementation?

ADDITION: I'll add that I'm not really interested in later solutions of the post-Commodore era (such as AmigaOS 4.0), and that I'm aware of what is written on AmigaOS 4.0 documentation page Obsolete Exec Memory Allocation but I don't really agree with most of what is written there.

  • 2
    I doubt there was any serious work on implementing it. The thought was probably that eventually machines with MMUs would be available, along with the AA chipset which wouldn't be backwards compatible with OCS/ECS/AGA anyway so would have to ditch a lot of old software anyway.
    – user
    Commented Apr 12, 2019 at 10:37

2 Answers 2


The Classic AmigaOS had a very good reason for not implementing protected memory when newer 68k CPUs with embedded MMUs became commonplace. The main reason was the pervasive use of shared memory message passing to communicate between tasks, including user tasks, system tasks, and device drivers.

The main reason that AmigaOS out-performed all other contemporary OS's running on similar performance-spec hardware was the efficiency inherit in this design. It's also the reason that buggy software could easily corrupt system services, and cause a system crash instead of just a program crash. Since this approach requires all task contexts to share a single view of memory, there was no way to migrate to a protected memory paradigm without breaking all the message passing behavior and the legacy code that relied on it. It would simply be a-bridge-too-far to add this feature and still be compatible with the original OS and its applications.

NOTE: I'm speaking to the efficacy of such an approach at the time. Compatibility could be managed by sandboxing tasks in a "virtual machine" container on modern processors that support such fanciness. The 68k never had an equivalent feature like the "virtual 8086" mode created by Intel for backwards compatibility.

However, this does NOT mean that MMU hardware is not used on Amigas that have it. The main application for Amiga MMUs is WHDLoad. WHDLoad is used by most owners of big-box Amigas, and also on smaller systems that don't have MMUs, to launch Amiga games that were originally floppy-based from a HDD. Besides launching the game, which then takes over the system fully, WHDLoad provides the ability to restore the system back to its original state upon exiting the game with a pre-selected keystroke. In systems with MMUs, this behavior is made very reliable by using the MMU to protect all memory areas not strictly required by the game. Then, WHDLoad only needs to provide an overlay capability to save & restore those memory regions and program the MMU to keep all other memory from being accessed while the game runs.

More info on how WHDLoad uses the MMU...

  • To be fair, the 68k family didn't need a "virtual-86"-like feature, since every processor after the 68000 were fully compliant with Popek and Goldberg virtualization requirements. Sandboxing the OS and its apps into a virtual machine was more than feasible, had they wanted to go that route. Commented Jul 15, 2023 at 15:19

The closest I've ever seen was the Enforcer tool which would utilize the MMU on systems with one to protect against illegal memory accesses. It was good to have it running while you were debugging code, but otherwise was pointless to run in normal operation.

I imagine there was never a serious push to implement memory protection simply because I believe most Amigas came with the base 68000 and not the more advanced models which had the MMU. Though many machines were built with 68020+ CPUs, note that the MMU was an optional separate chip for the '020 and with the 68030 the MMU was only included in the non-EC versions (i.e. the 68EC030 which was available in many accelerators did not have a MMU despite being an '030). If memory serves, the 68040 and '060 both had it included.

Though you didn't quite point it out in your question, I will touch on the virtual memory topic a bit by pointing out that there were two products available for the classic AmigaOS (where a MMU was present) that would bolt on virtual memory support: GigaMem and VMem. I only have experience with GigaMem back in the day and found that it didn't really solve the problem of limited RAM as well as you would expect. I recall that it was only good for helping with memory allocated by programs after they've started up, not making room for new programs to run after you've run close to memory limits. I hardly used it since it didn't work the same way that I was used to with Windows and MacOS at the time.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .