Past the boot, where it used a VGA/EGA/MDA-like font, the terminal font looks remarkably similar to Sun's console font.
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)
Part of the reason the Amiga was well received is it’s OS. It was exceptionally well designed, and everything except, I think, multiuser (which was missing) and process separation (which did not have proper hardware support at first, and not enough memory), was better than what Unix could offer at the time.
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
> 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.
> UNIX never had anything like AmigaDOS and the way it was extensible via dyanmic libraries for file formats
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.
Being POSIX compliant never prevented an OS from having excellent multimedia capabilities. Perhaps Commodore management didn't see the value of a Unix-like OS for a home computer back then and, when they saw it, with the 3000/UX, it was way too late for the 68K.
I find it sad that Commodore didn't include CPUs like the 68020 and 68030 in base Amiga models until many years after their initial release. Maybe with a bit more revenue from higher end CPU models, Motorola could have put more effort into advancing the product line. How different a world it would have been if IBM went with the 68000 instead of the 8088.
Does anyone else remember Fred Fish disks? They always had a bunch of ported Unix commands/utilities on them. Certainly all the important stuff like UUCP and whatnot.
I still remember the first time I used Unix after a lifetime on the 8-bit home computers and DOS/Windows PCs, and typed an ampersand after a command. It took me about five minutes to convince myself that what the computer said was happening was actually happening. It was like finding an advanced alien ship with an antigravity generator and not believing it actually works.
> We wouldn't never had the desktop development experience that keeps the Amiga nostalgy alive if that had been the case.
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).
Depends on what you are targeting. The bare Windows API was tragic, but you could avoid a lot of the low-level stuff with some care, and the Amiga felt much nicer - the events you'd deal with were much higher level, but the environment itself was not. Macs had a reasonable GUI designer (at least for dialog boxes). Where Unix excelled was in the rich tooling that didn't exist (or was poorly implemented) on other platforms - lex, yacc, grep, sed, m4, some source control versioning tools, pipes, etc - it was developed mostly for programmers, by programmers, so that's not surprising.
> BTW, if the Amiga came out with a Unix-like OS from the start (such as Coherent), it'd have been a game changer.
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.
Microsoft sold Xenix for the 68000, I wonder how that worked given the often mentioned unix problem caused by inability of the processor to recover from bus faults.
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.
I learned C on a Unix-like OS, QNX, running on a 640K 8088 PC clone. It booted from a 360K floppy and had, in those 360K, a shell, vi and a C compiler.
Wow, I didn't know QNX was always so compact. I remember a demo disk released in '99 or '98 that would boot from one floppy into a graphical environment with a web browser and a few other things. It was really impressive on a single floppy.
The 8086 was the first microprocessor UNIX was ported to. Maybe unsurprising as the first 16 bit processor that could address more than 64 KB of RAM. 8086 segmentation was and is much-lamented, but it did enable a poor man's form of virtual memory. If the user process never touched the segment registers, the OS could move allocated code, stack and data blocks in RAM around transparently to the process. It also allows every process to assume it starts at address 0.
Some of the early 68k workstations, including the original Sun and Apollo hardware simulated an MMU by using an extra 68k. IIRC, in the event of a trap, the second CPU would kick in, set up some mappings, and then hand control back to the main CPU.
Those workstations still had custom MMUs, and the 68K had most of the signals to work with an MMU. The issue was instruction recovery on exception, particularly page fault.
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.
Some C compilers for the 68000 added an instruction to do a dummy read before doing any stack operations to trigger a fault in a way that it didn't matter to the instructions doing real work.
It was not entirely unable to recover from bus faults. It was unable to restart the instruction executing at the time correctly.
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.")
I thought restartable signal handling pretty ingrained - eg Bourne shell apparently used to handle memory allocation by trapping SEGV and calling brk() from the signal handler. I guess it's possible Xenix people just changed all the problematic bits in the port.
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.
I can't tell whether or not Xenix was available for other M68k platforms than the Lisa. The Lisa had some sort of MMU. The SUN 1 also had a custom MMU for the 68k. As long as you're content with dealing with the restart problem either by disallowing it (crashing any process that you can't help by triggering a bus error for - optionally minimised by doing paging while halting the main CPU like the Apollo's did) or other awful hacks, you can still do some things with the MMU with the 68000 too.
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.
Interesting stuff, I never knew Lisa and the OS used used a MMU!
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])
> Z80 that apparently also worked as a kind of IO coprocessor, and some PAL chips mentioned in connection with Xenix[1]
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)
Yeah, except no. AmigaOS was built on a lightweight, near-real-time, multitasking microkernel that was designed in tandem with the hardware and which a single person could understand in totality. There's no way something as amazing as the Amiga could be produced on a Unix base and still be affordable.
> Yeah, except no. AmigaOS was built on a lightweight, near-real-time, multitasking microkernel
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)
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.
Maybe I am missing some context here, but are we talking about AMIX or AmigaOS? I am asking because the latter never looked particularly UNIX-like to me. But maybe that's because I never worked with MS-DOS, so, being only familiar with Linux, Windows, and AmigaOS, I might be overestimating the difference between UNIX and AmigaOS.
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.
I'm talking about AmigaOS. Bits and pieces were based on https://en.wikipedia.org/wiki/TRIPOS and the kernel itself had a lot of UNIXy sort of features. In the late 1980s if your work job is sitting in front of a Sun workstation you bought an Amiga for home instead of a Mac or DOS machine. I would dial my Amiga into work before going to work and remote shell in (rlogin/rsh/rcp) and just shuffle things back an forth without effort. One could do CS homework both on the Amiga and on the SunOS systems just by linking to a different library. I never even had a C compiler on my AMIGA, didn't need one. I can't imagine writing some code on UNIX and that trivially making it run on a Mac or DOS machine. People even build stub UNIX libraries for AmigaOS that faked the user/group/permissions and other bits of the UNIX experience. It was just a pleasant experience for those late 80s compared to the alternatives.
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.
The Amiga had to be sold with a minuscule amount of memory to have any chance in the home computer market. Memory at this time was very expensive and UNIX would have required too much of it.
I'm not user that much memory would be needed in the lower end models. A home computer would run on single-user mode and that wouldn't need a lot of the extra memory structures a multi-user environment needs.
FWIW, a mid-1980's high-end multi-user CP/M system I was looking at has 1 meg of RAM for four users: 64K for each user, and the rest to run the system. It was in the $8,000 range, without the terminals.
An Amiga 1000 came with 256K of RAM for a single user. The 500 came out with at least twice as much. The TRS-80 Model 16 came with 128K and Xenix, about five years before the 1000. A Unix-based Amiga 1000 would be completely feasible.
Another interesting Z-8000-based machine (and this one was actually produced and sold) is the Olivetti M-20. It's chunky, but I really like it's monolithic design. It says "serious computer" all over it. If anyone has a spare one, my birthday is in March.
Also the East German P8000 (https://en.wikipedia.org/wiki/P8000), unfortunately(?) the "higher-ups" then decided to hop on the x86 train not much later.
PS: the conversion from East German Mark to Deutsche Mark doesn't make much sense on that Wikipedia page (the conversion factor seems to be inverted).
This machine actually could be in many ways considered a predecessor to the Atari ST rather than the Amiga. Shiraz Shivji (one of the designers of the C64 and eventually director of engineering at Commodore) worked on it and then left to join the new Atari Corp with Jack Tramiel where he was the chief designer of the Atari ST hardware. In fact there was a lawsuit accusing him of stealing IP from the CBM900 (he was acquitted.)
The whole situation with Jack Tramiel leaving Commodore, acquiring Atari, Commodore staff following Jack to Atari, the Amiga Corporation[1] loan from Atari pre-Tramiel, subsequent repayment under Tramiel, and acquisition by post-Tramiel Commodore reads like fiction. It's an amazing story to me.
Oh there are a few documentary's that cover it and was a a good one saw recently that encompassed all this - https://www.imdb.com/title/tt5706894/ do recommend that one.
Looking at the specs and focus, out of interest, what would have be taken from the C900 over to the ST?
Different CPU, board and bus, graphics on a plugin card, different OS, different market focus and pricepoint. I can't see anything there apart from Shivji that's common.
I'm guessing that this was a countersuit to delay Atari after they sued Commodore for 'stealing' the Amiga, thereby delaying the Amiga.
As far as OS goes, ironically MultiTos is POSIX compatible. Had Atari stuck it out, it might have ended up similar to OSX in that you could cross-compile UNIX apps to MultiTos to use with a standard UI (GEM).
Yeah for sure there's little in common and I'm sure it was just corporate legal hostility. But I'm sure the general experience of developing a 16-bit machine was educational. And I'm sure the choice to go with the 68000 (or NS32k which they also evaluated at first at Atari) was likely informed by the annoyance of having fiddled with the Z8000's awkward segmented architecture.
Re: POSIX, we Atari users were already crosscompiling things to MiNT (that MultiTOS was based on) back then before MultiTOS came out. In 1990/1991 I ran a setup (off floppies!) that had a bash shell, uucp, nn, etc all set up. Friends of mine with larger hard drives and TTs were using GCC and so on. This was all just before Linux came out and before I moved to a 486, which I only did because Linux was an option there.
Eric R Smith was the author of MiNT and was hired by Atari in their latter days to work on TOS and make his work "official." Sort of a last gasp effort after neglecting TOS for years, and the last few OS releases for the Falcon and TT were actually pretty compelling and competitive in some ways with what was on the Mac, etc..
Later, MiNT was all open sourced under GPL as FreeMiNT and it's still very actively developed today. You can set up a whole open source Unix-like environment today on FreeMiNT + EmuTOS complete with bash, login, initd, etc. RPM package management, whole thing.
> informed by the annoyance of having fiddled with the Z8000's awkward segmented architecture.
That's interesting, I was under the impression that Z8000 uptake was hindered due to bugs in it's implementation, do you have any references about this segmented architecture?
I'm not saying the segmentation is the reason Z8000 uptake was low, I have no idea why it didn't succeed.
But you can read about the Z8000's segmentation on WP: "The Z8000 used a segmented memory map, with a 7-bit "segment number" and a 16-bit offset. Both numbers were represented by pins on the Z8001, meaning that it could directly address a 23-bit memory, or 8 MB.[4] Instructions could only directly access a 16-bit offset."https://en.wikipedia.org/wiki/Zilog_Z8000#Memory_handling
Many 16-bit systems around this time did this kind of thing. Makes it really annoying to do things like draw in a framebuffer bigger than 64k. It does look like at least the PC could hold a whole 23-bit address, so that's good.
The 68000 had a nice flat linear memory model and that made it much easier to write code for.
Acquitted only applies to criminal charges. Since this was a civil and not criminal matter, you’d just say that Shivji won (or Commodore lost) the lawsuit.
You have to look at the video and audio: the SID is still to our day one of the best analog 8-bit generation synth chips, the VIC-II pushed 8-bit graphics to their logical extreme.
NES and SMS both had separate video chips that where not programmable from the CPU or shared the RAM in the same manner. Also the C64 had software that you could copy!
Finally the C64 has more releases today than the PC, the Apple 2 has maybe one release every 2 years: http://csdb.dk
Maybe I should have added "with audio/visual quality".
Unrelated to the post, but since this thread is likely to attract a bunch of Commodore enthusiasts, I'll mention here that a Commodore 64-DX/C-65 popped up on fleaBay a few days ago.
Unfortunately, it's in kinda rough shape, and the starting bid is $15,000. I don't think he'll get any bidders at that price.
92 comments
[ 3.3 ms ] story [ 169 ms ] threadI 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)
https://virtuallyfun.com/wordpress/wp-content/uploads/2017/1...
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.
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.
[1] https://en.wikipedia.org/wiki/HLH_Orion
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.")
[1] https://en.wikipedia.org/wiki/Apollo_Computer
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 i...
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)
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.
PS: the conversion from East German Mark to Deutsche Mark doesn't make much sense on that Wikipedia page (the conversion factor seems to be inverted).
[0] https://en.wikipedia.org/wiki/Amiga_Corporation
https://archive.org/details/8bit_Generation_The_Commodore_Wa...
Following the "by Commodore" link on that page leads to some other interesting archives as well, including an AmigaDOS manual.
As far as OS goes, ironically MultiTos is POSIX compatible. Had Atari stuck it out, it might have ended up similar to OSX in that you could cross-compile UNIX apps to MultiTos to use with a standard UI (GEM).
Re: POSIX, we Atari users were already crosscompiling things to MiNT (that MultiTOS was based on) back then before MultiTOS came out. In 1990/1991 I ran a setup (off floppies!) that had a bash shell, uucp, nn, etc all set up. Friends of mine with larger hard drives and TTs were using GCC and so on. This was all just before Linux came out and before I moved to a 486, which I only did because Linux was an option there.
Eric R Smith was the author of MiNT and was hired by Atari in their latter days to work on TOS and make his work "official." Sort of a last gasp effort after neglecting TOS for years, and the last few OS releases for the Falcon and TT were actually pretty compelling and competitive in some ways with what was on the Mac, etc..
Later, MiNT was all open sourced under GPL as FreeMiNT and it's still very actively developed today. You can set up a whole open source Unix-like environment today on FreeMiNT + EmuTOS complete with bash, login, initd, etc. RPM package management, whole thing.
That's interesting, I was under the impression that Z8000 uptake was hindered due to bugs in it's implementation, do you have any references about this segmented architecture?
But you can read about the Z8000's segmentation on WP: "The Z8000 used a segmented memory map, with a 7-bit "segment number" and a 16-bit offset. Both numbers were represented by pins on the Z8001, meaning that it could directly address a 23-bit memory, or 8 MB.[4] Instructions could only directly access a 16-bit offset." https://en.wikipedia.org/wiki/Zilog_Z8000#Memory_handling
Many 16-bit systems around this time did this kind of thing. Makes it really annoying to do things like draw in a framebuffer bigger than 64k. It does look like at least the PC could hold a whole 23-bit address, so that's good.
The 68000 had a nice flat linear memory model and that made it much easier to write code for.
I had a new transparent case for it since a while back, time to fill that case!
I also hoarded breadbins for a while with RR-Net and Nunchuk64 + NES classic controllers, so I definitely have the Commodore disease!
The first open successful computer; the last being the Raspberry 4, for eternity probably... Q.E.D.
I love the C64, but the first was probably the Apple II
You have to look at the video and audio: the SID is still to our day one of the best analog 8-bit generation synth chips, the VIC-II pushed 8-bit graphics to their logical extreme.
NES and SMS both had separate video chips that where not programmable from the CPU or shared the RAM in the same manner. Also the C64 had software that you could copy!
Finally the C64 has more releases today than the PC, the Apple 2 has maybe one release every 2 years: http://csdb.dk
Maybe I should have added "with audio/visual quality".
https://www.autometer.de/unix4fun/coherent/#vbox
https://www.autometer.de/unix4fun/coherent/ftp/vms/
http://www.nesssoftware.com/home/mwc/manpage.php?contents
http://www.nesssoftware.com/home/mwc/manual.php
Unfortunately, it's in kinda rough shape, and the starting bid is $15,000. I don't think he'll get any bidders at that price.
I have a very nice 64-DX/C-65 on a shelf in the lab.
I also have a factory sealed, brand-new-in-box, Sun Sparcstation 20 :)
https://datamuseum.dk/wiki/Commodore/CBM900
The boot-roms of the CBM900 has been reverse-engineered in the PyReveng3 project: https://github.com/bsdphk/PyReveng3/tree/master/examples/CBM...