What limited the use of the Z8000 (vs. 68K and 8086) CPU for 16-bit computers?

Question

As compared with the 68000, which also was available from 1979, and which also started off quite popular in desktop-sized UNIX machines, it apparently has a much more sophisticated memory model, which I suppose means that process isolation etc would be more easily implemented.

Also it looks like I would prefer the Z8000's register file to work with. If you're working with a lot of small values, on the 68k you'd run out of d registers before you'd run out of rh and rl registers on the Z8000. And for whatever reason, the GDR engineers chose to reverse-engineer or clone this one over the 68k.

From 20 000 feet, it looks like a reasonable upgrade path coming from the Z80 too. If you have experience writing Z80, my guess is you'd easily get used to the Z8000. Maybe compilers are easy to convert as well; but I don't know that.

So when the Macintosh, the Amiga, the Atari ST, the Sun-1 etc etc all flooded the market in the mid to late eighties, why did none of these use the Z8000? Or to put it another way, why does this generation of computers not feature any well-known example which uses the Zilog as its CPU?

Answer 1

The Zilog Z8000, Motorola 68000, and Intel 8086 all arrived at roughly the same time-frame and each represented the new 16-bit architecture of their respective CPU designers. They differed markedly in their approach to hardware memory addressing.

The Z8000 and the 8086 used a segmented memory approach, whereas the 68000 was a flat address space, and focused on addressing as much memory as was realistic without segmentation boundaries (or any of the protection or paging features segmentation might offer!) In short, Zilog especially and Intel to a lesser extent were already implementing simple memory management features in a manner integral and internal with their CPU's instruction architecture. Conversely, Motorola was eyeing sophisticated memory management as an external function provided by a coprocessor, which would monitor and intercede the CPU's memory access.

These two differing CPU architecture "philosophies" were then handed to the systems engineers of the time, whose main focus was to use the new 16-bit processors to introduce sophisticated new computers with capabilities not possible on the earlier 8-bit systems, which had much more limited memory capacity and bus bandwidth. And it is not as if these systems engineers were aiming at merely imaginary goals, either. They were already becoming acquainted with sophisticated systems like the Xerox Alto, with its large bitmap display, mouse, and GUI abilities. And they were also already aware that gaming would be a major part of the consumer software market, in which sophisticated graphics and sound capabilities would be a key hardware differentiator. NOTE: I'm talking about systems engineers who were focused on computing's future here. The IBM PC's systems engineers, and others seeking mass-market business computer appeal, had a different agenda which was more distinctly looking backwards.

Here is where the rubber meets the road because these forward looking systems engineers were designing systems in which the "forced" memory management architecture appearing in the Z8000 (and the 8086) were mostly a hindrance to their designs. This is mostly because managing large data structures, including bitmaps that could exceed the 64K segment size of the Z8000, was integral to the advanced features they wanted to deliver. They wanted access to a lot more memory (compared to 8-bit systems) and they wanted the added freedom to design their systems so that access to that big memory by both the CPU and external hardware (e.g. DMA) wasn't subjected to complicated memory management and segmentation constraints.

We can see the affects of the above engineering thought process in the products you mention. Can you imagine trying to design the Amiga, with its 25 DMA channels, to coexist cleanly with a CPU architecture that needed to deal with CHIP memory segment boundaries? That's the extreme case; but even the simpler hardware of the Macintosh having to design its memory map and large bitmap display buffers around the constraints of segmentation would have added needless hardware complication and an extra burden for programmers to worry about. Contrast this with the simple, flat, large (24-bit today, 32-bit tomorrow) addressing of the 68000!

The case of the Sun-1 is somewhat unique. Here the designers were aiming toward a sophisticated OS (Unix) that would enforce memory protection, and they needed a sophisticated MMU to support it. But, at least in the minds of the Sun engineers, the Z8000's integral MMU was not the best approach. So they opted for the flat addressing of the 68000 and added their own custom external MMU. This was a common approach for the earliest workstations using the 68000 and 68010.

You could make an argument that the problem with the Z8000 was that it was just "ahead of its time" in adding fairly sophisticated memory management features integral to the CPU. Perhaps this aggressive attempt at innovation was partially responsible for the bugs that plagued the Z8000 early on. In any event, for the engineers designing the Atari, Amiga, and Mac, those features were not helpful as none of them had any aspirations to run an OS as sophisticated as Unix. And for the early graphical workstation engineers, the Z8000 just wasn't powerful enough on its own to satisfy their CPU needs.

Answer 2

I was at college 1979-83, studying computing, and remember being told in a microprocessor course that the Z8000 wasn't very good. After a browse through the user's manual I can see why.

The memory model seems to have been designed by a hardware engineer who didn't think very much about software. Indeed, the whole architecture seems designed to do the same jobs as the Z80, only better, unlike its more successful competitors. The crucial difference was that most 8-bit software was written in assembly languages, while 16-bit and later software was mostly written in compiled high-level languages.

The 68000 family was clearly designed with an eye towards high-level language programming. The architecture was 32-bit in concept, although the original implementations were 16-bit. It had "flat" unsegmented memory addressing, which is always easier for compilers, and could address 16MiB of RAM, which increased to 4GiB in later members of the family.

The 8086 family was less ambitious, but was practical. It could only address 1MiB of RAM, and it dealt with it in 64KiB segments, but you could place those segments anywhere in memory. This made it practical, if inconvenient, to deal with data structures larger than 64KiB. Once 16-bit MS-DOS had begun to dominate the business microcomputer market, there was plenty of motive to improve the programming tools.

The Z8000 family came in two models. The Z8002 could only deal with 64KiB RAM, although you could stretch that by using separate 64KiB address spaces for code, data and stack. However, writing an operating system that works with that is gratuitously difficult. Operating systems have to be able to handle program code as data when they load programs. The multiple address space trick is mostly useful for embedded systems without general-purpose operating systems.

The Z8001 was the large memory version, able to handle 8MiB RAM in each address space. It deals with the memory in 64KiB segments, but it has a crucial flaw. The segments are at fixed addresses. Segment 0 is at address 0, segment 1 is at address 64Ki, segment 2 is at address 128Ki, segment 3 at address 192Ki, and so on. The segments can't overlap, and you can't change their positions.

This makes handling data structures larger than 64KiB very cumbersome. It also restricts the use of smaller data structures, because you really don't want them to cross segment boundaries. This creates arbitrary restrictions, makes linkers and loaders more complicated, and generally reduces your flexibility in the use of memory. Operating system people hate that, and so do compiler writers. The combination of that, plus buggy initial chips, doomed the Z8000.

Zilog acknowledged the memory model had been a mistake with the Z80000, which had a mode with a 4GiB linear address space. It also supported Z8002 and Z8001 modes, with more and larger segments available in the Z8001 mode. However, by the time it appeared in 1986, the x86 and 68000 were well-established and the fashion in new processors was RISC. The Z80000 was very much non-RISC, and doesn't seem to have got anywhere.

Answer 3

To start with, there was the Olivetti M20 of 1982 (*1). It wasn't only a Z8001 based computer, but also rather successful all over Europe. Olivetti also used the Z8000 in their Linea 1 systems, more mini like multi user systems. All with their own OS PCOS. In fact, the Z8000 systems where so popular, that they produced a Z8000 subsystem for their later DOS compatible M24 (*2,3).

Zilog did promote ZEUS, a Version 7 compatible Unix, and several manufacturers used it in OEM systems. It was as well used in East Germany with their P8000 Unix systems. After all, they did manufacture the Z8000 as 'second source'

What limited the use of the Z8000 in personal computers?

Most notably Zilog being late to deliver and needing more than 3 years to fight all (known) bugs.

---

*1 - Byte Magazin got a M20 Review in their June 1983 issue.

*2 - Better known in the US as AT&T 6300 and Xerox 6060.

*3 - Olivetti was also among the few Z80,000 users, building a new Z80,000 based machine as late as 1989 to replace the upper end Linea 1 systems, as well as offering an upgradepath for M20 users. The system got canceled short before introduction