The effort they went to in order to maintain responsiveness is amazing. You don't truly appreciate it until you dive into the internals of the OS. I don't think most people at the time even realized just the lengths they went to.

E.g. consider cut and paste.

Easy? Right? You just have an app hand you a representation of the data to cut, and store it until someone chooses paste.

Except you're on a machine with 512KB RAM, where T: ("/tmp") might be on a floppy to save RAM.

The consequence is that "everything" in AmigaOS runs in its own "task" (process/thread - the distinction doesn't mean much since there's no memory protection). In a typical shell, when you do cut and paste, at least the following are involved:

- input.device (mouse handling)

- console.device ("low level" console window processing. This one doesn't "own" a window but can render to any window, and handles things like escape codes)

- console-handler ("high level" console window processing; this one opens/owns the window, and can handle things like line editing)

- ConClip (this one registers handlers to handle cut and paste, and mediates the process)

- clipboard.device (mediates read/writes to clipboard "units", so you can have multiple clipboards; knows where to write the clips)

- (possibly, depending on where T: is mounted: trackdisk.device, handling low level writes to floppy, or one of the ram disk devices)

- The shell process itself.

If you do a "copy", the input device sends the raw mouse events to the console.device, which "cooks them" into higher level events it sends to the console-handler, which then calls a library function in the clipboard device which will start a background write of data to the appropriate storage device. Each of those exchanges apart from calling into clipboard device (which is a bit of a hack, to be honest, but ultimately leads to another async message AFAIK) is an entirely async message exhange.

If the clipboard was on a slow device, who cares? It'd get written in the background, and the source task would be informed when it was safe to change the contents of the buffer (cut and paste in general was accomplished by pointer passing, and it was up to the source application whether it wanted to make a copy, or avoid modifying the source buffer until it was safe).

The path back, to, where console-handler might send codes to trigger highlighting the text to the console.device, which renders to screen (and the window handling is mediated by yet another task, handling Intuition, the GUI).

All in all, it's not unusual for a keypress to be processed by half a dozen tasks, and the resulting action to work it's way back through another half a dozen tasks before you see the result on screen.

All of this has lots of overhead, of course, even on a non-MMU single address space OS - there's lots of context switches, and lots of memory allocation for messages etc., all of which was anathema to most people writing OS's for home computers at the time.

But it is exactly this that made the OS so responsive: You sacrifice absolute throughput for a system that took great care to do "everything" async, so the system was nearly always responsive.

(you see the same in Amiga hardware, which ironically lost out to the brute force approach of the eras PCs, only for us today to make it back to the "co-processor" model: My servers at work has an ARM core in every harddisk, and a PPC or ARM core on the RAID controllers, and many modern ethernet cards has SOCs with ARM cores too; much like my Amiga 2000 back in the day had a 6502 compatible on the keyboard, a Z80 on my SCSI controller, a 68020 accelerator for the main CPU and a 286 accelerator on a bridge board....)

Having worked on AROS (an AmigaOS compatible OS) console support, I can say that sometimes that division is really annoying - having to think long and hard about which task something belongs in. But it leads to a system that is still usable on a 7.16MHz 68000 CPU... On a modern machine (AROS runs on any modern x86 hosted under Linux, and "native" on some x86, ARM, PPC and m68k hardware; albeit still only single core) it flies.

In fact, you truly appreciate how light these OS's were if you try them on modern hardware: I have an AROS setup that "boots" the Linux hosted version straight into FrexxEd (a great editor; one of the original authors is the guy behind CURL). On my laptop, it boots AROS and starts FrexxEd in less time than it takes a console-only build of Emacs to start....