Hacker News Reader

Comment by alexisread | Hacker News Reader

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).

View on HN

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.

Reply on news.ycombinator.com