These machines had a real following for a reason. Multi-user on hardware that small in the early 80s was genuinely impressive. Glad someone is still writing about them.
The AM-100/L we used at work until about 1988 did not have any memory protection. It was a pain in the rear trying to develop on it while it was being used in production, as you could easily lock up the entire machine and shut everybody down for five minutes while it rebooted. But our current ERP system is still derived from a Windows port of a DOS port of the original system I built in Pascal on that AM.
We've still got the old machine sitting in a dusty storage room. Last time I tried to fire it up, which was probably more than twenty years ago, it wouldn't boot due to bad RAM. I called the company to see if I could get any documentation on it, as ours was long gone, but they told me they had no interest in helping.
They didn't (not for AMOS at least, the UNIMOS capable machines had an external MMU).
"AMOS is also a strict real-memory operating system, which is to say there's no MMU, and programs were expected to be fully position-independent and run wherever the monitor ended up loading them. This makes it fast, but also makes it possible for jobs to stomp on other jobs, and it was not uncommon for busy systems to crash on a regular basis."
68451 or a custom SUN-like (SRAM, kind of like a PDP11) MMU, there was a guy who went around Silicon Valley in the mid 80s designing SUN-like MMUs for companies, they were all different, and some were broken (couldn't protect user space from kernel space).
68000s however had a problem: they couldn't return correctly from a page (MMU) fault (68010s fixed that) for a pre-VM (pre BSD or SVR2) UNIX world - however you could get around this with a few smarts
yeah, that's rather a pain though and it effectively leaves one 68k frozen while the other services the page fault - it means you can't run another user process while the page is being read in (because it too might cause a page fault)
These machines had a real following for a reason. Multi-user on hardware that small in the early 80s was genuinely impressive. Glad someone is still writing about them.
How did they get memory protection on 68000?
The AM-100/L we used at work until about 1988 did not have any memory protection. It was a pain in the rear trying to develop on it while it was being used in production, as you could easily lock up the entire machine and shut everybody down for five minutes while it rebooted. But our current ERP system is still derived from a Windows port of a DOS port of the original system I built in Pascal on that AM.
We've still got the old machine sitting in a dusty storage room. Last time I tried to fire it up, which was probably more than twenty years ago, it wouldn't boot due to bad RAM. I called the company to see if I could get any documentation on it, as ours was long gone, but they told me they had no interest in helping.
If only we had rust back then
They didn't (not for AMOS at least, the UNIMOS capable machines had an external MMU).
"AMOS is also a strict real-memory operating system, which is to say there's no MMU, and programs were expected to be fully position-independent and run wherever the monitor ended up loading them. This makes it fast, but also makes it possible for jobs to stomp on other jobs, and it was not uncommon for busy systems to crash on a regular basis."
68451 or a custom SUN-like (SRAM, kind of like a PDP11) MMU, there was a guy who went around Silicon Valley in the mid 80s designing SUN-like MMUs for companies, they were all different, and some were broken (couldn't protect user space from kernel space).
68000s however had a problem: they couldn't return correctly from a page (MMU) fault (68010s fixed that) for a pre-VM (pre BSD or SVR2) UNIX world - however you could get around this with a few smarts
I think someone worked around it by running two 68000 in lock-step, or-one-step-behind or something like that.
yeah, that's rather a pain though and it effectively leaves one 68k frozen while the other services the page fault - it means you can't run another user process while the page is being read in (because it too might cause a page fault)