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?

  • 5
    It was bug-ridden at first which shied away a lot of potential customers, and it wasn't really a fast CPU.
    – tofro
    Nov 2, 2018 at 11:40
  • 1
    I think Commodore considered it. I used Zilog branded Unix systems using the Z8000 running their port of Unix (V7 based) back in the mid 80’s. They were ok. Even Zilog abandoned it later and came out with Unix systems using the WE32100 chip that AT&T used in their 3b2 systems (which was also a dog of a CPU).
    – mannaggia
    Nov 2, 2018 at 12:48
  • 3
    Commodore more than considered it: they designed a Unix workstation around it (the "Commodore 900") that was mature enough to build a batch of 50 machines for reviewers and third-party developers, before dropping the project in favour of the Amiga. May 6, 2022 at 9:57
  • Olivetti used it in its flagship PC M20. May 12, 2022 at 8:52

3 Answers 3


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.

  • Flat memory spaces are much easier to program for. MacOS let you just allocate pointers or handles and tell you if you got the memory you wanted. Even the MacPlus in 1986 using 68000 could handle 4 MB of physical memory and the Mac II in 87 could handle 20 MB, that's huge compared to the limitations of the x86 or Z8000. Nov 5, 2018 at 20:07
  • The Z8000 didn't really have an integral MMU. You could argue that the segmented version (Z8001) contained a small portion of an MMU, but it depended on external logic (which could be a Z8010 segmented MMU chip) to perform the actual mapping of the segment number to a base memory address.
    – Eric Smith
    Nov 15, 2018 at 23:27
  • 1
    @MichaelShopsin: The 8086 has the nicest design I've seen for a 16-bit CPU that needs to access more than 64KB of address space. It's best viewed as being a contiguous linear sequence of 65536 sixteen-byte chunks, which can be effortlessly grouped into objects of up to 4095 consecutive blocks, that may then be accessed as linear sequences of up to 65520 bytes. Nearly all other 16-bit systems I've seen would require adding another level of hierarchy, though on the 80286 one could get around that if one is willing to limit per-object sizes to 60KB or so.
    – supercat
    Jul 19, 2019 at 16:33
  • Programming on the 68000 is easy, all 24 bits of address space are available without any tricks. Classic MacOS and other 68000 based OSes used the direct flat memory space to its best advantage. The use of 32 bit pointers for 24 bit memory space left the ability to use more memory on the 68020/30/40 unless you did tricks with the high 8 bits (cough Photoshop, cough). Jul 19, 2019 at 17:51
  • 1
    @MichaelShopsin: I don't view the 68000 is a 16-bit CPU, since LEA always produces a 32-bit result. I also think it's noteworthy that accessing objects which are between 32768 and 65520 bytes is more efficient on the 8086 than the 68000 (notice how many structures in Classic Mac OS have a 32767-byte size limit).
    – supercat
    Jun 2, 2023 at 15:08

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.

The Western Design Centre's W65C816 has a similar problem with memory addressing, but offered software compatibility with the 6502, which made it useful for follow-ons to 6502 machines, notably the Apple IIGS, and the SNES. The Z8000 could not run Z80 software, and didn't see much use.

Zilog acknowledged the Z8000 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.


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

  • No Delete or Backspace key? Only for perfect typists! Nov 3, 2018 at 1:34
  • 1
    I'm not sure whether you should call the Z8000 design being stolen, re-engineered and copied in the GDR "second source".
    – tofro
    Nov 3, 2018 at 11:48
  • @tofro Well, since there are different stories around, including Zilog selling the details, The use of quotation marks felt apropriate to note this without taking sides.
    – Raffzahn
    Nov 3, 2018 at 13:07
  • 1
    @tofro You mean companies do only things they are legaly allowed to do? And they will never circumvent these rules, just to make money? For quotes, I dont have any online references at hand. It's from memory of speaking to people involved.
    – Raffzahn
    Nov 3, 2018 at 13:44
  • 1
    Indeed, it seems my click was supposed to be on the answer above this one. Jun 11, 2019 at 18:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .