Linked by Thom Holwerda on Mon 17th Aug 2015 22:06 UTC, submitted by BloopFloop
Amiga & AROS

The story of the Amiga family of microcomputers is akin to that of a musical band that breaks up after one incandescent, groundbreaking album: the band may be forgotten by many, but the cognoscenti can discern its impact on work produced decades later.

So the Amiga 30 event held at Silicon Valley's Computer History Museum in late July was more than a commemoration of some interesting technology of the past. It was also a celebration of the Amiga's persistent influence on personal computing.

The Amiga was easily 10 years ahead of its time. Too bad the good ones rarely win. This is also a good moment to repost the 8-part series on the Amiga at Ars.

Thread beginning with comment 616343
To read all comments associated with this story, please click here.
OS Kernel
by henrikmk on Tue 18th Aug 2015 19:47 UTC
Member since:

AFAIK, the OS kernel never changed much between 1.0 and 3.9, so it never gained that many features, other than the ability to suspend programs, which only half-worked.

I think, that if Carl Sassenrath had stuck around for a rewrite (he wanted resource tracking at the very least in the OS, but never had the chance to do it), he probably could have gotten those things in there for a much more stable OS. Alas, Commodore never embraced an MMU as a standard thing for Amigas.

But for 1985, it was pretty damn good and performance was through the roof. Reboot times were fast for the time, which was perfect if you had a crash, or if there was a power outage.

The architecture of the OS was fun too: Build your own Workbench laboriously from scratch with exactly the features and programs you need. Did that many times. Try that with Linux.

I used my Amigas until 2004 and at the end, they could still do things, my PCs at the time couldn't, but they were left in the dust with regards to CPU power.

Reply Score: 2

RE: OS Kernel
by Vanders on Tue 18th Aug 2015 20:10 in reply to "OS Kernel"
Vanders Member since:

AFAIK, the OS kernel never changed much between 1.0 and 3.9

Most of the BCPL was replaced with C in 2.0, but the functionality didn't really change that much no.

Reply Parent Score: 2

RE: OS Kernel
by JLF65 on Wed 19th Aug 2015 06:01 in reply to "OS Kernel"
JLF65 Member since:

The worst part of MMU handling was all Motorola's fault. In order to sell more parts, Motorola would mark CPUs whose MMU failed in ANY WAY as an EC part, and sell it as a "CPU without an MMU". Except it DID have an MMU, just a faulty one. Many people found their EC030 or EC040 processor ran memory management code anywhere from 75 to 95 percent okay before crashing. There was simply no way for developers to tell with software whether or not a CPU had a working MMU, so if you supported the MMU, you had to write two versions of the app - one with MMU support and one without.

If you look in any of the 030/040/060 hardware manuals, the EC versions do "unspecified actions for an unspecified length of time" when they encounter MMU opcodes. In other words, different processors will have faults in different parts of the MMU, so you can't count on any particular opcode or page entry working in a set way. Most often, code to test the presence of the MMU passes just fine. But when you try to use page tables, things don't map right and stuff crashes.

My own code would have a user control in the gui that turned on MMU handling when it was a part of my app. It would default to off, and the user could turn it on if they knew they had a properly working MMU. Then I'd have two sets of code for using or not using the MMU where applicable.

Motorola SHOULD have had a easy to burn integrated fuse for the MMU so that if it tested bad, they burn the fuse and the MMU status opcode would generate an exception. A simple method to tell if there was an MMU or not.

Reply Parent Score: 3

RE[2]: OS Kernel
by Vanders on Wed 19th Aug 2015 09:52 in reply to "RE: OS Kernel"
Vanders Member since:

I'm not sure it's fair to blame Motorola for binning parts. The real issue was that the original 68000 didn't even support the concept, and the 68010+68451 sucked. Other microcomputer OSes didn't have memory protection so it wasn't seen as a priority.

By the time the (non-EC) 68020 was available AmigaOS was already in place and the design explicitly assumed no memory protection was in use, so adding it would have been a major re-design.

Also let's not forget this is Commodore we're talking about; given the option between the 68020+68851 or the cheaper 68EC020 and no MMU, they were always going to pick the cheaper part.

Edited 2015-08-19 09:53 UTC

Reply Parent Score: 2