Hacker News Reader

Comment by vidarh | Hacker News Reader

The A3000 had a ficker fixer. If you meant that the other later models should have also included it, I agree.

Regarding the MMU, the problem was/is the OS. AmigaOS uses message passing between processes extensively, and those messages often involved passing pointers to structures that the receiver expected to be able to dereference and even writ to in some cases.

I'm on record repeatedly arguing over the years that it would be possible to retrofit at least limited memory protection onto AmigaOS, but it's decidedly not something that'd be simple to do, and most likely you'd need to basically sandbox old apps and create new API's for new apps to do it properly.

View on HN

It would be simple, but somewhat incomplete. It would not look like a virtual memory subsystem where merely accessing an address can allocate physical RAM to it.

The API is already there! AllocMem(, MEMF_PUBLIC) allocates shared memory, otherwise you get private memory.

You can then enforce memory protection around that, but obviously the entire OS is still built on message-passing between tasks where the message itself remains at exactly the same (public) address and isn't copied between private memory spaces, and there's a gentlemens' agreement as to who currently owns it (PutMsg/ReplyMsg)

Software like Enforcer and MuGuardianAngel already checked this, and dinged your program for accessing non-allocated memory.

I think "somewhat incomplete" is underplaying it as such a large proportion of message exchange tends to include pointers to shared structures. That the message handling uses intrusive lists doesn't help. So "simple" really depends on where you set the bar for what you consider useful levels of memory protection.

I still think it's possible but doing it to a meaningful extent would be a long tedious effort, at least for my definition of meaningful.

You have Janus-UAE which sandboxes/emulates M68k apps for AROS "rootlessly" in that it bridges a number of structures etc. That mostly solves the problem on modern hardware for legacy apps, though it's a painful solution.

Then you could aggressively upgrade message formats for "native" apps to replace pointers with opaque handles.

If done at the time you could of course had relied on more of the developers of various apps still being active and willing to update their code and might have been able to avoid the Janus-UAE approach, but there was never a point at that time where anywhere close to a majority of users had MMU's,

Software that tried to implement memory protection or virtual memory on the Amiga had to have a huge long hit-list of software that set the AllocMem flags incorrectly and had to be treated differently. That's because the MEMF_PUBLIC flag didn't really do anything on the base OS, so programmers didn't bother using it correctly.

With mmu, every app has its own 32bit address space, and the mmu “maps” the app space to physical space. Legacy apps get shared address space, while newer apps get isolated space. To port apps, its only the messaging system that needs rework, and if the system does its magic with same API, transition is invisible. At the end of the day, only the message address space needs to be shared. Sendmessage() behind the scenes remaps mmu addresses. Not impossible, just requires the will to do it.

The problem with that is that the messaging system permeates everything on the Amiga, so you'd lose basically every app without rework. That might have worked if the Amiga had a growing market share, but at the time this became an option, the Amiga market was already dying and most users still only had 68000 based machines without MMU until long after Commodore died.

It's not "only" the message address space, as e.g. messages included pointers to a lot of other data structures that'd now either need to be copied or mapped into the receiving process, or the message formats reworked.

> The A3000 had a ficker fixer.

That's demonstratably false. But the A3000 was a ficker fixer.

Reply on news.ycombinator.com