I love it!
BTW, if the Amiga came out with a Unix-like OS from the start (such as Coherent), it'd have been a game changer. With some (a lot, really) luck we could be all be running Unixes on different CPUs instead of Windows on x86's...
I also like that cursor keys are closer to where the mouse uses to be (for the right-handed, at least)
Iirc, porting Unix software was actually very easy. I don’t think the non-Unix of AmigaOS is the reason we’re stuck with windows
It was not, but if the Amiga users who ventured past the GUI and into the command line interface were used to Unix, it'd be a much more natural migration path for them to move to Unixes than it was to move to Windows (as most did).
Also, if the Amiga was, even if by accident, positioned as an entry level Unix workstation, it'd certainly be very popular at computer labs everywhere. It cost a lot less than a diskless workstation back then.
All the UNIX ports, including the follow up AMIX, were a shadow of the multimedia capabilities of AmigaOS.
Irix, NeXTSTEP and Sun NeWS are the only UNIX based experiences, that had remarkable hardware.
All of them managed it, by being more than mere UNIX clones.
That's true, but all that could have been added to Coherent. I'm stressing Coherent here because it was the cheapest Unix clone available back then.
> All the UNIX ports, including the follow up AMIX, were a shadow of the multimedia capabilities of AmigaOS.
That's a hardware enablement issue. The biggest drawback of Coherent (and most Unixes back then) was that it couldn't run from a floppy, so, the minimum viable Amiga would need a hard disk. It could be possible to slim it down, however, or, maybe, just adding a POSIX compatibility layer on top of the AmigaDOS base would suffice. My point is that, if Amiga users had an easier path towards Unixes or if universities got lots of Amigas instead of far fewer Unix workstations (for the same money), we'd have a somewhat different world right now.
Yet hardly anyone cared about POSIX, rather whatever was on top.
And if you were on a terminal far from the machine, you wouldn't even see or hear the computer busy at work.
I remember using a windowing terminal (all text windows) that could have multiple sessions over a single RS_232 using a custom shell on the computer.
https://virtuallyfun.com/wordpress/wp-content/uploads/2017/1...
The first versions of the Amiga ran on the MC68000 processor which could not support a MMU, so no Unix there. AIUI, this became first possible with the MC68010, which however was quite uncommon early on.
As for a MMU, I guess it's not a given that Unix requires paged virtual memory. Traditionally whole processes were swapped in and out.
Indeed. As long as you didn't need more than 64K, you'd be completely happy. That, and malloc would fail if you asked for too much memory.
With an instruction like move (a2)+, (a3) the processor first loads the value from memory at the address in a2, increments a2, then goes to store it at the address in a3. If a3 holds an invalid address, the processor faults halfway through the instruction. The problem is the 68000 doesn't store enough state anywhere to tell you how to rollback and attempt the whole instruction again. (Was a2 incremented already or not?)
The dual 68K approach would keep the whole instruction pending on the other processor, in case it needed to be restarted, after resolving the page fault. And it was still possible to implement classic base-and-bounds swapping with a single 68K.
So it was unusable for more complex setups without hacks like ch_123 mentions Apollo and others used where you'd have two CPU's and let one of them pause while the second handled paging. But if you were content with killing the offending process, you could do that with "just" a single 68000 CPU and a simple MMU.
(on a side note, Apollo's OS was fascinating for the era [1]: "Certain efficiencies were gained by careful design; for example, the memory page size, network packet, and disk sector were all 1K byte in size. With this arrangement, a page fault could take place across the network as well as on the individual computer and Aegis file system was a single system of memory mapped files across the entire network. The namespace of the network was self discovering as new nodes (workstations) were added.")
It saddens me how some beautiful creations just died because of worse is better.
A compiler assisted way also comes to mind, if the issue is just certain complex instructions - if you document that you can't use non restartable instructions (at least if you want to catch signals), maybe you could have the C compiler emit only a restartable subset of the ISA.
Here's details about the Lisa architecture that includes bits about the MMU and how it's handled in Lisa OS[1]. While it doesn't describe how XENIX did it, it gives some hints about which options might have been available to them:
> Although instructions in the MC68000 processor are not generally restartable, we have empirically determined that the four instructions that access code segments, JMP, JSR, RTS and RTE are restartable. When one of these four instructions attempts to reference a code segment that is not currently present, it causes a bus error which traps to the OS.
It would have been nice if this used compiler assistance. As only trapping those would mean ensuring that you insert one of them on every segment boundary if you want to be able to cross it, and also ensuring that you don't have any BRA/Bcc (relative branches/jumps or DBcc (relative branches/jumps with register decrement) instructions crossing segment boundaries. If XENIX did this too, then it'd allow relatively painless paging of code segments. It wouldn't be very hard do do, but give a strong incentive to try to pack functions into segments so that no basic blocks crosses segment boundaries.
But it seems the Lisa's default OS required programmers to explicitly split a program into different code segments:
> The division of a program into these named code segments is dictated by the programmer through commands to the Compiler and Linker.
No idea if XENIX also required that, or if they tried to be smarter about it. It wouldn't seem that hard to at least have logic to allow the compiler to automate it, though I'd guess some might want to explicitly control to be able to trade off amount of memory pinned at a time vs. amount of jumps between code segments (potentially triggering paging) given that the maximum code segment size of 128KB was a rather sizeable chunk of a machine as constrained as that (maximum addressable memory of 2MB)
> Because the instructions that reference data are not all restartable, the system does not do automatic swapping of data segments. The memory manager must swap in all data segments needed by a process before the process is allowed to execute. However, the OS gives programs the ability to unbind data segments that are not needed in the memory while a particular part of the program is executing.
You could presumably still allow memory to grow with brk(), but trapping SEGV to decide when to not so much. Though maybe - a hack occurred to me just now (no idea if anyone did it) to allow some patterns like that work: Have the MMU trigger a "soft" error condition if you access within X bytes of an unmapped page, and trigger a normal interrupt in that case. A normal interrupt on the 68000 is triggered immediately after the instruction has executed, so as long as a single instruction doesn't touch memory both within and outside mapped data segments you can trigger the pager when it gets "close enough". That's enough to e.g. make the stack auto-extending, or to allow sequential writes that approach and cross a page boundary, as long as the applications are ok with SEGV's not being triggered precisely when a page boundary is crossed.
You'd still not be free to page data segments out. But you could free stack segments pretty easily with some minor compiler assistance to communicate lower stack bound now and again.
Your idea of only issuing restartable instructions might work, with the caveat that the M68k is exactly the wrong architecture to have to worry about that on given how heavily it relied on various complex addressing modes to make the code compact... A lot of common instruction patterns would become unviable.
[1] https://www.researchgate.net/publication/2996607_The_Archite...
Re Xenix 68k hardware - there's also Tandy. From the Xenix Wikipedia article: "Tandy more than doubled the XENIX installed base when it made TRS-XENIX the default operating system for its TRS-80 Model 16 68000-based computer in early 1983"
Apparently the TRS also had some unique extra chips, who knows if they may have been used for propping up memory management. (Z80 that apparently also worked as a kind of IO coprocessor, and some PAL chips mentioned in connection with Xenix[1])
[1] https://groups.google.com/g/comp.sys.tandy/c/HSTKgp_TbFg/m/p...
A total digression, but I love the proliferation of CPUs for IO etc. on older systems. My worst-ever Franken-machine like that was my Amiga 2000. Right out of the box the A2000 had a 6502 compatible SOC as a keyboard controller (I don't remember the model number - might be a 6507). Then I got a SCSI controller that had a Z80 on it. And a bridge-board with an 8086 on it I think. I plugged a 286 accelerator into the bridge board, and a 68020 accelerator into the Amiga side... Not all of them were used at once, but having a machine with a 6502 compatible, a 68000, a 68020, and 8086, a 80286 and a Z-80 in the same case was fun...
Of course the Commodore 128 had both a 8502 (6502/6510 compatible) and a Z80 (for CP/M) at the same time, and in CP/M mode the Z80 actually called 8502/6502 code for IO etc....
And of course for the C64, C128 and many others the floppy drive had a CPU as powerful as the actual machine (the C64 1541 floppy drive had a 6502, only marginally different (GPIO and some very minor other differences) to the 6510)
So was QNX and QNX felt a lot like Unix and had tons of tools easily ported from Unix. It ran on an 8088 PC off a floppy disk. I now runs a lot of in-car entertainment and instrumentation systems (a nice home for an RTOS)
We wouldn't never had the desktop development experience that keeps the Amiga nostalgy alive if that had been the case.
Hardly anyone discusses hardware from UNIX clones beyond what CPU they might have used.
I know the Amiga GUI was way better than X, but that the development experience would be better is not a given. Unixes were always light-years ahead of anything else in development and automation tools. That, combined with a good set of APIs for all the custom hardware, would be extremely compelling.
What would be much harder to do is direct hardware access. For that, you'd need to be running in runlevel 1 (which would make sense for a stand-alone computer).
As for Windows, on the Amiga glory days, PCs were still stuck with MS-DOS 5 and Windows 3.0, with Petzold's book as the bible.
Being the only PC ownig guy on the Amiga school gang made me quite aware of the limitations during our demoscene like weekend meetings.
The OS was close enough and wonderful under the hood. So many UNIX people bought one for home just because it was so easy to port UNIX code. I wrote Amiga apps on a Sun3/50 using Sun's compiler and just transferred the binary over to my machine. The Amiga Pascal software even had a special program included to transfer binaries over serial/parallel from a UNIX box (usually a Sun). You mostly just needed to link to a different crt.o / clib.
Edit: btw, the AmigaDOS developers manual says that there was also a cross compiler (and serial transfer tool) for MS-DOS. I am wondering whether anybody every used that.
AMIX is a whole different can of worms, they did that much later and I'd expect it was like porting between HP/UX, AIX, BSD etc. Probably pretty easy by then.
But, we are doing this -- en masse. I get your jist, though.