RIP Z80

[tchicago]

Zilog announced end of life of Z80, but it is still being manufactured as of now! 

https://www.mouser.com/PCN/Littelfuse_PCN_Z84C00.pdf
--- "Last time buy orders will be accepted until June 14th, 2024."

Maybe I should order a couple of them with a cool last production date code of 2024 as the memorabilia items.

Zilog brand apparently belongs to Littelfuse these days.

[brucehoult]

The votes are in. 6502 outlasts Z80 [1].

Z80 cores will still be in other chips -- it's just the DIP40 (etc?) bare CPU that is going away.

[1] To be fair that's 65C02, the NMOS chip went away a long time ago. And there will still be eZ80.

[SiliconWizard]

Incredible lifetime!

[lunix]

My very first commercial embedded project used a Z80. Then I fell in love with the 6809. Then the PIC.  A couple of decades after that first one, Zilog was pushing a Z80-based microcontroller, and had a giveaway for a design contest. I got a kit. Then I wrote to them that it had a dead short across the power supply, and they sent a replacement.  That one didn't work either.  And that was my last Zilog experience. I'm still sad about that. It was a better 8080, and those days are long in the past now.

[woofy]

Zilog could at least wait until March 2026, just to give the Z80 a 50 year lifetime.
Federico Faggin first came up with the idea for the Z80 in 1974, so I suppose it just about has its 50 years, though the first actual Z80's were born in 1976.
I cut my teeth on the Z80 and have since purchased many thousands for control products.

R.I.P Z80. 

[coppice]

The votes are in. 6502 outlasts Z80 [1].

Z80 cores will still be in other chips -- it's just the DIP40 (etc?) bare CPU that is going away.

[1] To be fair that's 65C02, the NMOS chip went away a long time ago. And there will still be eZ80.

Surely the Z80 still being made has as little in common with the original silicon as the current 65C02.

I played with a chip some years ago with a 1GHz Z80 core in it. I can't remember what the actual chip was, but cranking a Z80 up to 1GHz seemed amusing enough for me to have a short tinker with it.

[RoGeorge]

My first Z80 design was a home computer, compatible with both ZX Spectrum and CP/M.  That was happening sometime during the late 80's.  https://hackaday.io/project/1411-xor-hobby-a-vintage-z80-computer-prototype

[tchicago]

My first Z80 design was a home computer, compatible with both ZX Spectrum and CP/M.  That was happening sometime during the late 80's.  https://hackaday.io/project/1411-xor-hobby-a-vintage-z80-computer-prototype

Oh no, you breadboarded it! Must have been an immense amount of work.
My Spectrum was the second homebuilt computer - using a common Lviv variant PCB. It looked just like this one https://speccy.info/%D0%A4%D0%B0%D0%B9%D0%BB:Lvov1.jpg

But in general, the Spectrum was just for games, and not serious learning of computer science. For the latter, I kept using my first homebuilt computer based on i8080 (https://en.wikipedia.org/wiki/Radio-86RK). It had those big serious interface chips like i8257, i8275, and i8255 which were fun to learn and program.

[RoGeorge]

Some games for the ZX Spectrum were incredibly good for an 8-bit 3.5MHz Z80 that was also bit-banging the sound, reading the keyboard, refreshing the DRAM, and updating the image for each frame, all at the same time.  I remember Knight Lore was a total shock back then.  It was looking amazingly good:



The next jaw-dropping game for me was to be many years later, around the year 2000 when Half-Life came out (for PC).



By that time Z80 was rather rare, the IBM-PC standard was everywhere, and Z80 was only used for automations and such.  Z80 has had so far an outstandingly long life, considering with how many microcontrollers it was competing over the last 30 years or so. 

[woofy]

DRAM refresh was built in, with a 7-bit counter output during the M1 cycles of an instruction read, but yeah, it was quite amazing what programmers could do with a few MHz in and 8-bit processor. 

[MathWizard]

Was/Is the Z80 copied a lot, by counterfeiter's? I wonder where all the ebay ones come from.

[nctnico]

That is a long lifetime indeed. There was a time where I knew most of the Z80's instruction set by opcode. Goodbeye old friend... 

[Howardlong]

DRAM refresh was built in, with a 7-bit counter output during the M1 cycles of an instruction read, but yeah, it was quite amazing what programmers could do with a few MHz in and 8-bit processor.

Yes, DRAM refresh was "built in" in that there was a counter and notification that it's safe to do a row refresh.

Not so great was that to get the timings into spec that the DRAM of the day required, a fair bit of fettling and empirical work with glue logic & RC networks was required to get the RAS/CAS and setup/hold timings to work within tolerances, particularly if you were doing a production run.

It became easier and cheaper to stick in static RAM as time proceeded, what with higher densities, substantially reduced glue logic, and dropping prices.

[woofy]

DRAM refresh was built in, with a 7-bit counter output during the M1 cycles of an instruction read, but yeah, it was quite amazing what programmers could do with a few MHz in and 8-bit processor.

Yes, DRAM refresh was "built in" in that there was a counter and notification that it's safe to do a row refresh.

Not so great was that to get the timings into spec that the DRAM of the day required, a fair bit of fettling and empirical work with glue logic & RC networks was required to get the RAS/CAS and setup/hold timings to work within tolerances, particularly if you were doing a production run.

It became easier and cheaper to stick in static RAM as time proceeded, what with higher densities, substantially reduced glue logic, and dropping prices.

Yeah, my first Z80 design used 8 x 4164 dram's. It never sold many, nobody ever needed that much ram on a controller in those days and subsequent revisions used 6116 and 6164 sram's.
That was my only time putting dram's on the Z80.

[iMo]

I got my first Z80 inside the ZX81 kit when it appeared, added a DIY 16kB module made of 8x4116. Then ZX Spectrum. Messed for while with U880D. Then switched to 68k and never went back to the Z80. It was a nice time, indeed.. 

[coppice]

DRAM refresh was built in, with a 7-bit counter output during the M1 cycles of an instruction read, but yeah, it was quite amazing what programmers could do with a few MHz in and 8-bit processor.

Yes, DRAM refresh was "built in" in that there was a counter and notification that it's safe to do a row refresh.

Not so great was that to get the timings into spec that the DRAM of the day required, a fair bit of fettling and empirical work with glue logic & RC networks was required to get the RAS/CAS and setup/hold timings to work within tolerances, particularly if you were doing a production run.

It became easier and cheaper to stick in static RAM as time proceeded, what with higher densities, substantially reduced glue logic, and dropping prices.

Controlling DRAM took quite a few chips in those days, yet the total logic involved was not that great. Zilog threw the refresh counter into the MPU, but left the rest out. I was always puzzled that nobody tried throwing the whole DRAM control thing into their MPU. Its not like getting the feature set right was a problem. From the earliest days practically all DRAMs were drop in replacements for each other, with a well defined path to the needs of future generations.

[brucehoult]

A couple of friend and I designed and built a wire-wrapped 6809 machine in 1983. We thought about 68000 but it was expensive and the 6809's 8x8->16 multiply was faster than the 68k's (wider) multiply, and the 8x8 suited the music synthesis one of us wanted to do.

We did DRAM refresh in software, with an interrupt causing a page of NOPs to be executed. Or that could be turned off when you knew the software would be doing sufficient memory references itself -- or just masked for a short while for a critical loop.

[HwAoRrDk]

Was/Is the Z80 copied a lot, by counterfeiter's? I wonder where all the ebay ones come from.

In period there were several clones by Warsaw Pact states - East Germany, Soviet Union, Romania.

It's doubtful that's what ebay counterfeiters are selling today. I believe they mostly are selling chips that aren't Z80s at all, or remarking older chips to appear newer.

[coppice]

A couple of friend and I designed and built a wire-wrapped 6809 machine in 1983. We thought about 68000 but it was expensive and the 6809's 8x8->16 multiply was faster than the 68k's (wider) multiply, and the 8x8 suited the music synthesis one of us wanted to do.

We did DRAM refresh in software, with an interrupt causing a page of NOPs to be executed. Or that could be turned off when you knew the software would be doing sufficient memory references itself -- or just masked for a short while for a critical loop.

A lot of machines performed DRAM refresh in software. I've also seen a DMA channel committed to refresh. You still have to do things like RAS/CAS muxing in hardware. The refresh counting is only a modest part of the DRAM support problem.

[SeanB]

The Zilog one might be stopping, but the Toshiba and Sharp units are likely to stay in production for a good number of years still, as they also have all the peripherals of the Z80 family inside the package, and thus you can make a complete SOC with them, as they all now have 32k of RAM and 32k of flash built in, though there are still a fair number made with older OTP Eprom memory, which is in a lot of industrial equipment, copiers and such, along with lots of other applications where they have a very long code base life, and are familiar with the design.

[GromBeestje]

They have the peripherals inside the package? Something like the Zilog's eZ80? That one stays in production. It's the classic chips that go out of production. I was wondering if there was any of the other manufacturers still make the classic chips?

[amyk]

I think almost everyone has used a device with a Z80 core at some point in their lives, even after the 8-bit minicomputers faded away. The https://en.wikipedia.org/wiki/S1_MP3_player and the Texas Instruments calculators are the most prominent examples I can think of. (GameBoy doesn't count, as it's not truly compatible.)

[wek]

The votes are in. 6502 outlasts Z80.

There are still plenty of 8051 made, most of them binary-, some pin-, and maybe still a few of them clock- compatible with the original (1980).

JW

[peter-h]

I started on the Z80 too. A great chip and really versatile in its time.

Today, most embedded stuff (except low end) is done in C and if the clock is fast enough the CPU architecture becomes almost irrelevant. And those who cut their teeth on the Z80 are mostly retired now.

And few of the original products will be selling today; I still nominally sell a Z180 based box designed in 1991 but the volume is very low. There are still GA avionics (like the JPI EDM700 family) which use the original Z80, EPROM, SRAM but their sales will be very low too, even in that extremely slowly innovating field.

How long a product can run is always a fun debate but the truly original DIP40 Z80 must have virtually ended. Even in the military sphere, things have moved on. The other day I saw the internals of the Javelin missile; a 30 year old design but still current on the Ukraine battlefield, which uses all kinds of expensive chips.

Littelfuse owning Zilog is the ultimate insult; a shit company making boring stuff owning a one-time real innovator.

[coppice]

Today, most embedded stuff (except low end) is done in C and if the clock is fast enough the CPU architecture becomes almost irrelevant.

If you try to sell an MCU to many large customers now they show no interest unless it has an ARM core, or perhaps increasingly a RiSC/V core. You can talk about a totally unsuitable chip for their needs, and they'll listen if is has an ARM core. You can talk about a great fit for their needs, and they are not listening simply because it doesn't have an ARM core. But the core is almost irrelevant, because almost all new MCU code is developed in C. The MCU's value is all about its unique qualities - interesting peripherals, special memory qualities, like error detection/correction or non-volatility, partitioning to meet regulatory requirements, etc.

[PCB.Wiz]

The Zilog one might be stopping, but the Toshiba and Sharp units are likely to stay in production for a good number of years still, as they also have all the peripherals of the Z80 family inside the package, and thus you can make a complete SOC with them, as they all now have 32k of RAM and 32k of flash built in, though there are still a fair number made with older OTP Eprom memory, which is in a lot of industrial equipment, copiers and such, along with lots of other applications where they have a very long code base life, and are familiar with the design.

Yup, the process FAB that makes Zilog's CMOS version of the NMOS Z80, is being terminated. The NMOS Z80 is long gone.

Zilog still have other CMOS process Z80 variants, as do other companies.

Just like intel no longer publicly sells stand alone 8051, there are many companies making new-process 80C51 variants.
The original 8051 has 8 bit opcode fetch, and 12 clocks per opcode.

The newest 80C51's can fetch 24 bits of opcode in a single clock cycle, and run at 45Mhz +
The 80C51 is the most widely sourced 8 bit MCU on the planet.
 

[bson]

Yes, DRAM refresh was "built in" in that there was a counter and notification that it's safe to do a row refresh.

I built a numeric door lock in 1985 that could have different codes for different people and allowed tracking and revoking individual access.  It had battery-backed SRAM so I used the refresh cycle to scan the keypad and pull the INT# pin if any key was pressed.  I forget exactly what logic was used, but I thought it was pretty cool to get a hardware keypad scan with only one incremental logic IC. (A latch register of some variety.)

[nimish]

Today, most embedded stuff (except low end) is done in C and if the clock is fast enough the CPU architecture becomes almost irrelevant.

If you try to sell an MCU to many large customers now they show no interest unless it has an ARM core, or perhaps increasingly a RiSC/V core. You can talk about a totally unsuitable chip for their needs, and they'll listen if is has an ARM core. You can talk about a great fit for their needs, and they are not listening simply because it doesn't have an ARM core. But the core is almost irrelevant, because almost all new MCU code is developed in C. The MCU's value is all about its unique qualities - interesting peripherals, special memory qualities, like error detection/correction or non-volatility, partitioning to meet regulatory requirements, etc.

ARM cores have a far better software development toolkit than one-off proprietary architectures and you aren't forced to buy from a single vendor. Since software development is the most expensive part it pays to reduce those costs. Would you rather use LLVM 18 or some jank vendor gcc? Even RISC-V is kind of stuck here, CLIC isn't ratified yet either.

So I'm not surprised they stop listening when someone proposes the use of a wacky new ISA for no really good reason.

[brucehoult]

Even RISC-V is kind of stuck here, CLIC isn't ratified yet either.

Not ratified, true, but frozen and very unlikely to change. It's currently in ARC (Architecture Review Committee) review, after which it needs Committee Chair and CTO sign-off, then a public review period, then the ratification vote. My guess is ratification will be around July.

[peter-h]

If you try to sell an MCU to many large customers now they show no interest unless it has an ARM core

That however is a reasonable approach.

Nowadays, with a 168MHz core, 99% of applications can be done with 1 or 2 chips e.g. the 32F4xx. These have been around > 10 years, even the chinese do copies, the dev kits are free and well understood by anyone using them, the chips are $5 in quantity, and they are 10x to 100x fast enough for most jobs. I've just done a project with a 32F417 and I am certain I will not need to look at another CPU in the rest of my actuarial life expectancy (20 years). With ETH and USB done and working (not optimally but well enough) and with 21MHz SPI, I can do absolutely anything I have done since 1980 and absolutely anything I can imagine having to do. For highly specialised stuff e.g. a modern DSLR one needs specialised chips, but for nearly all "industrial control" and consumer stuff, more is not needed.

The most important thing is preserving in-house dev expertise, because devs tend to care little for "your" company, and love picking the latest fancy parts (good for the CV, too) so you have to steer them to using the right parts. You can always tell when some company doesn't do this correctly; you get crap like 10.1k resistors all over the place I can show you some Honeywell autopilot schematics...

The Z80 performed this job for many years. There was simply no point in using the other "8/16" bit CPUs, for embedded work. And it had the massive advantage of a short learning curve. The RM was maybe 200 pages. All the product schematics ended up pretty much the same basic stuff. Today you have a 300 page DS, 2000 page RM, ~5000 pages ARM32 CPU RM... building up expertise with a popular chip has never been more important.

What buggered the Z80 and Zilog, before the right time, was the 64k addressing. IAR C got around it reasonably well with their Large Model but linear addressing have the 68k a good start. Had the Z80 had even 20 bit addressing, a lot of other chips would have never got off the ground.

[coppice]

If you try to sell an MCU to many large customers now they show no interest unless it has an ARM core

That however is a reasonable approach.

Nowadays, with a 168MHz core, 99% of applications can be done with 1 or 2 chips e.g. the 32F4xx. These have been around > 10 years, even the chinese do copies, the dev kits are free and well understood by anyone using them, the chips are $5 in quantity, and they are 10x to 100x fast enough for most jobs. I've just done a project with a 32F417 and I am certain I will not need to look at another CPU in the rest of my actuarial life expectancy (20 years). With ETH and USB done and working (not optimally but well enough) and with 21MHz SPI, I can do absolutely anything I have done since 1980 and absolutely anything I can imagine having to do. For highly specialised stuff e.g. a modern DSLR one needs specialised chips, but for nearly all "industrial control" and consumer stuff, more is not needed.

You must have worked on a very narrow range of MCU applications, or perhaps only on small volume products, to have such a view. The vast majority of MCUs produced are quite narrowly tailored to a few applications they suit well. If you don't think the chip is narrowly tailored you probably just don't recognise the applications it was tailored for, You gave no explanation for why an ARM core would be beneficial. Sticking with one maker, and their peripheral set, can be a big speed up in development work. Who cares what the core is, apart from a few special qualities like getting in and out of low power states, where a few designs excel?

[SiliconWizard]

Except if you are writing some generic RTOS, the core itself rarely matters as long as its meets the performance requirements you have. So, that's from the software POV.

The point, as some have said already, is more with the toolchains. If it's an ARM core, you can use mainline GCC for ARM targets (or LLVM), you can (usually) use generic JTAG/SWD probes, and so on. More odd architectures will usually require very specific vendor tools, which you'll be tied to (and which may be expensive). Whether this is an issue in your particular case, only you can answer.

[peter-h]

The vast majority of MCUs produced are quite narrowly tailored to a few applications they suit well.

I think most MCUs are designed for a specific automotive or other consumer application, against a customer requirement for say 10M chips annually. This is pretty obvious with some chips like Siemens ones that go into ECUs but you rarely see them generally.

But since almost nobody doing that is posting here (not allowed to, for a start) we are talking mostly about lower volume stuff.

Sticking with one maker, and their peripheral set, can be a big speed up in development work. Who cares what the core is, apart from a few special qualities like getting in and out of low power states, where a few designs excel?

We are saying the same thing, I think. A well managed company will make strategic choices in this area. They will also have direct accounts with firms like ST. They won't be searching Digikey for a suitable chip

[coppice]

I think most MCUs are designed for a specific automotive or other consumer application, against a customer requirement for say 10M chips annually. This is pretty obvious with some chips like Siemens ones that go into ECUs but you rarely see them generally.

That used to be a common practice, but things have changed. Producing a new die is now so expensive vendors want to develop MCUs that can potentially cater to a whole application segment, rather than a particular customer. So they tend to survey customers, and try to figure out a feature set that will have broad enough appeal to capture a number of big players in that application space. Then they make the chip and offer it in their catalogue. This has created some interesting brinkmanship dynamics. Leave out one pin needed by some of the big players, and you can be out of the market. The few cents of extra hardware needed to simulate that missing pin can kill your chances. Throw in a few too many things, and pad out the pin count, and you might be too physically big or too expensive.

But since almost nobody doing that is posting here (not allowed to, for a start) we are talking mostly about lower volume stuff.

You'd be surprised. A number of people here either work or used to work in high volume stuff.

[brucehoult]

But since almost nobody doing that is posting here (not allowed to, for a start) we are talking mostly about lower volume stuff.

You'd be surprised. A number of people here either work or used to work in high volume stuff.

I'm on the software side, not the chip/board side (though I do interact with those people from time to time), but ... would you consider Galaxy S / Galaxy Tab high volume? And the TVs. A lot of my work is in those. Well, and some upstreamed into generic Android too. And Firefox for that matter, but that was long ago.

Back in, say, 2016, we prototyped a lot of stuff on Pi 3 and Odroid C2 (and the 32 bit but fast XU4 before that) before trying it on Google phones, and only finally on prototype Samsung ones. Now the latest things are being developed on VisionFive 2.

[CatalinaWOW]

The high volume markets drive the chips (and the SW toolsets).  The low volume folks have to dodge around and try to figure out where the high volume people are going so that their choices will meet their market needs.  And there is a big split in the low volume market.  Those who will be producing for years or even decades, and those who make a production run or two and then move on to the next model or product.  That first group is the one that really needs to be clairvoyant or clever.  Fortunately many of those old chip designs can be adequately emulated on current hardware allowing transparent to software and user replacements for ones that have gone EOL.

[nimish]

Even RISC-V is kind of stuck here, CLIC isn't ratified yet either.

Not ratified, true, but frozen and very unlikely to change. It's currently in ARC (Architecture Review Committee) review, after which it needs Committee Chair and CTO sign-off, then a public review period, then the ratification vote. My guess is ratification will be around July.

Cool, I hope it'll work with the sifive/t-head/WCH implementations. I really would not want stuff like https://discourse.llvm.org/t/rfc-prestacked-annotation-to-solve-risc-v-interrupt-stacking-mess/74120 proliferating

And a standardized debug adapter interface like ARM's SWD/DAP/coresight would be great too. Who the hell wants a different *-Link for every vendor?

[brucehoult]

Cool, I hope it'll work with the sifive/t-head/WCH implementations. I really would not want stuff like https://discourse.llvm.org/t/rfc-prestacked-annotation-to-solve-risc-v-interrupt-stacking-mess/74120 proliferating

I don't have a problem with that proposal at all, or indeed even see the situation as a "mess".

Some people are used to hardware saved registers on other ISAs and want that feature on their RISC-V processors, and probably more manufacturers than at present will (in my opinion) waste transistors that could have been used for better things (or just use less silicon) on duplicate register sets (worse) or a FSM to stack registers.

Maybe the people who want to implement/use this will agree on a single spec for it, but as it's pretty much 100% "we think it give us a competitive advantage" thing I wouldn't hold my breath, at least in the short term.

That's pretty much inevitable with a community-owned ISA. You can see it as a disadvantage, but I see it as a strength.

And I think @jnk0le's proposal is both very easy to implement and solves the problem neatly. It makes perfect sense.

[nimish]

Cool, I hope it'll work with the sifive/t-head/WCH implementations. I really would not want stuff like https://discourse.llvm.org/t/rfc-prestacked-annotation-to-solve-risc-v-interrupt-stacking-mess/74120 proliferating

I don't have a problem with that proposal at all, or indeed even see the situation as a "mess".

Some people are used to hardware saved registers on other ISAs and want that feature on their RISC-V processors, and probably more manufacturers than at present will (in my opinion) waste transistors that could have been used for better things (or just use less silicon) on duplicate register sets (worse) or a FSM to stack registers.

Maybe the people who want to implement/use this will agree on a single spec for it, but as it's pretty much 100% "we think it give us a competitive advantage" thing I wouldn't hold my breath, at least in the short term.

That's pretty much inevitable with a community-owned ISA. You can see it as a disadvantage, but I see it as a strength.

And I think @jnk0le's proposal is both very easy to implement and solves the problem neatly. It makes perfect sense.

Design by committee is fine but I'd rather have had a finished baseline standard and then add the rest on as extensions. I don't care about this particular instance per se, but it is wild to not have an NVIC equivalent standardized.

[SiliconWizard]

I don't see how "wild" it is. RISC-V was designed as a general-purpose, extensible ISA. Apart from the core functions, everything was left as future extensions. And that's part of its strength.
Of course, it also leads to fragmentation, but that's unavoidable.
If we nitpick, "x86" CPUs are also heavily fragmented, in that each new generation has added a large number of new instructions and features. So if you stick to the least common denominator, you're left with, not that much actually.

The NVIC example is interesting and ill-positioned: indeed; the NVIC controller is only available on Cortex-M cores (so, in short, MCUs), while Cortex-A cores have a different interrupt controller. So there's also "fragmentation" even in the ARM world.

Sure, those who are only interested in RISC-V MCUs for now may throw a tantrum, because it's fragmented even in this "niche". But that comes with openness and its relative youth. When CLIC is ratified, sure vendors are likely to adopt it, but still, some may add particular features to gain a competitive advantage, that may require specific, non-standard support. And that's good. I like having options.

The fact that a given different implementation of an interrupt controller may impact compilers or not is another story. Not all implementations require anything more than the basic "interrupt" behavior of GCC/Clang. And here, once this register saving thing is settled (which will be generic enough to accomodate pretty much all cases), the rest will only require accessing some CSRs and memory-mapped registers, so there shouldn't be any more vendor-specific support required in compilers.

[nigelwright7557]

I wrote the software for a Teletext adaptor for the Sinclair Spectrum in around 83/84.
It was fun trying to fit in 40 colour attributes into a 32 attribute screen.
Worked out ok in the end.
For its time the Z80 was an a great processor to write code for.
If they had made a 32 bit Z80 we might all have pc's with Z80 in them.

[SiliconWizard]

If they had made a 32 bit Z80 we might all have pc's with Z80 in them.

They made a 16-bit, and even 32-bit derivative of the Z80, actually. The Z280 and Z8000 (16-bit), and the Z80000 (32-bit). They didn't get a lot of traction. But that existed.

[oPossum]

Steve Ciarcia (Byte/Circuit Cellar) made a Z8000 coprocessor for the PC.

https://www.smbaker.com/the-trump-card-zilog-z8000-comprocessor-card-for-the-ibm-pc

http://www.dtweed.com/circuitcellar/trumpcrd.pdf

[coppercone2]

how many years until we can make a z80 DIY with low cost?

a few more generations of UV exposure projectors....

[peter-h]

They made a 16-bit, and even 32-bit derivative of the Z80, actually. The Z280 and Z8000 (16-bit), and the Z80000 (32-bit). They didn't get a lot of traction. But that existed.

According to Zilog, I did the first design-in in the UK for the Z280 c. 1987 and second in Europe (someone in Germany did another one). A great printer/plotter sharing box called Multibuffer Sold really well; £2500 for the 4MB version Nothing on google; it is too old, I left the company in 1991 and they went bust in 1993 and then Windoze finally got printer sharing working...

It was still a 16 bit CPU. The address range was 16MB but via a MMU. You could do the same thing with a Z80 and bank switching. But it had extra instructions and a cache which made it run much faster per MHz than a Z80. Very good for embedded. Nice features like a rapid cache fill using the typical EPROM fast read if /CS=0 and you increment the address; most EPROMs managed about 50ns. I wrote a simple RTOS for it; posted the source here somewhere.

The Z8000 also had a 64k address space but with segmentation like the 8086/186/286. Yes you could have built a "PC" with it but by then Intel had a big lead.

The Z80000 did exist but only NMOS and ran pretty hot. AIUI it got one design-in: some sort of laser printer.

[SiliconWizard]

There was some kind of PC with a Z8001 (discovered it a few months ago) from Olivetti:


You can still play with the Z280 these days: https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:z280rc

[peter-h]

Yes; the Olivetti machine. Never sold AFAIK. Had a unix OS.

I wonder where that firm gets the Z280 chips? Must be from some used stock source.

[woofy]

Zilog kind of lost focus when Federico Faggin stepped down in 1980. I remember all the hype around the Z800 and looking forward to the new chip, but it was endlessly delayed. Zilog was working on the Z80000 32 bit and Z8000 16 bit non-Z80 compatible processors. The Z800 finally appeared as the Z280 10 years after the Z80, way too late. They had some success with the Z180 which was a copy of Hitachi's 64180 and their Z8 embedded controller, but really, it was game over.

[Howardlong]

I worked on a Z8000 based multiuser system with dumb terminals running Pick (anyone remember that?) around 1987 thru 1989, including offering Mac based terminal emulator for it so copy could be keyed into the dumb terminals, then imported into the Mac for desktop publishing.

A friend of mine developed his own Eurocard based systems based around the Z8000 around this time, but as others have indicated, Intel was the way everything was going.

[coppice]

Zilog kind of lost focus when Federico Faggin stepped down in 1980. I remember all the hype around the Z800 and looking forward to the new chip, but it was endlessly delayed. Zilog was working on the Z80000 32 bit and Z8000 16 bit non-Z80 compatible processors. The Z800 finally appeared as the Z280 10 years after the Z80, way too late. They had some success with the Z180 which was a copy of Hitachi's 64180 and their Z8 embedded controller, but really, it was game over.

I think you must be talking about the Z8000. The Z800 was a later part. Zilog hit severe process problems with the Z8000 family, which was supposed to be launched with quite high performance, AMD had their second sourced parts ready for the whole family, and couldn't sell them as their agreement with Zilog said Zilog had to get to market first. This proved to be a dumb idea, as the whole bundle was so late to market everybody moved on, and the Z8000 was toast. AMD could have kept things alive until Zilog was able to ship.

Did any Z80000 parts ever ship?

[coppice]

I worked on a Z8000 based multiuser system with dumb terminals running Pick (anyone remember that?) around 1987 thru 1989, including offering Mac based terminal emulator for it so copy could be keyed into the dumb terminals, then imported into the Mac for desktop publishing.

A friend of mine developed his own Eurocard based systems based around the Z8000 around this time, but as others have indicated, Intel was the way everything was going.

Are you sure you have those dates right, or did you mean the Z80000? The Z8000 was pretty much dead before 1987. I wasn't sure if the Z80000 ever shipped, but if it did, it should have been around 1987.

[woofy]

Yes, Z8000 was first, but was not Z80 compatible. The Z800 was Z80 compatible.. The Z280 was essentially an update the Z800 design.

[brucehoult]

I worked on a Z8000 based multiuser system with dumb terminals running Pick (anyone remember that?) around 1987 thru 1989

An ex university classmate was using Pick at their city council work and showed me around it, but I think it was running on a Pr1me machine (which I wrote a small system in COBOL on in the 82/83 summer holidays at another council, but that was running regular PrimeOS).

My Z8000 experience was a System 8000 Unix machine at university in 1984. It was the first real *nix I used and first exposure to vi. It was closer to a souped-up PDP-11 than to a VAX. I think we would have preferred a 32016 or 32032 machine but they weren't available yet, or too expensive or something. We had a project to support several programming languages (Modula 2 and some local student languages such as Lawrence D'Oliviero's "Peano" on several different ISAs (VAX, Z8k, M6809), and develop an intermediate representation, optimiser etc that could work with all combinations. Not an original idea but no one had made it work well at the time. Of course GCC and LLVM and others (Microsoft CIL) do today.

[SiliconWizard]

Yes; the Olivetti machine. Never sold AFAIK. Had a unix OS.

Nope. Market lifetime was about 2 years, and they sold about 50,000 in the first year, according to the Wikipedia article. Sales plummeted after that, so I don't know exactly how many they sold in total. Probably under 100k. That's not what they expected, but not ridiculous either.

And the OS was not Unix at all - it was some kind of proprietary OS (single user, single task) which was part of the issue. Had they ported CP/M right from the start, the machine may have had a lot greater success. They did provide a CP/M emulator later on, but it was too late.

https://en.wikipedia.org/wiki/Olivetti_M20

its successor was just some PC "compatible" (M24).
It's easy to claim to know, in restrospect, what they should or shouldn't have done, or that the IBM PC would become a de-facto standard, but it was absolutely not in the late seventies, when the M20 (and many other machines) was designed, and the IBM PC wasn't even a thing yet.

I wonder where that firm gets the Z280 chips? Must be from some used stock source.

Not sure. I couldn't find any myself through the usual channels.
The Z180 is still available at Digikey though.

[coppice]

I think we would have preferred a 32016 or 32032 machine but they weren't available yet, or too expensive or something.

You might have preferred at 32032, but only masochists preferred the 32016. It was very buggy. By the time they got the 32032 out and cleaned things up they were too far behind in performance the get anywhere. The 68020 had already got into most of the workstations.

[coppice]

I worked on a Z8000 based multiuser system with dumb terminals running Pick (anyone remember that?)

There was a time when Pick seemed to be everywhere for modest sized database needs. It seemed to be doing great, until the relational databases started to roll in.

[peter-h]

I still make a Z180 product, though not sold any for about a year.

Remember the Z180 was sold in two versions: a "mask 160" or some such, and the latest one which has a broken UART hardware handshake. When the UART bug was found, Zilog did not have the resources to do another mask so they continued to sell the older one under that funny name

I never used the Hitachi 64180 in production, though I did start with a huge ceramic version with an EPROM window. Hitachi sold a lot of the 64180, including lots of the EPROM version.

Good chips, with the IAR C Large Model, straight up to 1MB codespace. You just had to choose the bank size to be bigger than your largest function. In those days (1980s) the banking overhead was negligible, since IAR C was so crap We developed a box converting between IBM coax and twinax, and RS232/Centronics for printer emulation. But other (printer buffer) products sold more, and the Z280 box, with 14 configurable ports, sold so fast we could not make it fast enough. Good days, when a reasonably bright individual could design and sell a product to a general end user application

Olivetti M24 and M28 were my first "PCs". Never had an IBM one.

[gatk555]

Surely, any discussion of the Z80's successors should include Captain Zilog: https://archive.computerhistory.org/resources/text/Zilog/Zilog.Z8000.1979.102646293.pdf. (Link button does not work for me.) I recall seeing the paper comic in a small ICL development office in Ealing, London around 1980.

[coppice]

Remember the Z180 was sold in two versions: a "mask 160" or some such, and the latest one which has a broken UART hardware handshake. When the UART bug was found, Zilog did not have the resources to do another mask so they continued to sell the older one under that funny name

In 1987 Zilog was still launching major things like the Z80000. In 1993 or 94 I remember a friend joining Zilog and the rest of us asking the same question. Why? Zilog was already pretty much dead in the water, and even our friend couldn't give a convincing answer about his move. Such a major downfall, from which they never seemed to recover.

[brucehoult]

In 1993 or 94 I remember a friend joining Zilog and the rest of us asking the same question. Why? Zilog was already pretty much dead in the water, and even our friend couldn't give a convincing answer about his move. Such a major downfall, from which they never seemed to recover.

I hope you mean Zilog, not your friend!

I was astounded in 2005 when my cousin left Coca Cola to join NZ Yellow Pages -- a company that clear as day was going to get steam-rolled by the internet. Maybe he figured it was just a short term CV builder, and anyway after three years he went to a nice safe museum director position he's now had 15+ years.

[peter-h]

Mask 1960 was the one with the non-broken UART

In 1987 Zilog was still launching major things like the Z80000. In 1993 or 94 I remember a friend joining Zilog and the rest of us asking the same question. Why? Zilog was already pretty much dead in the water,

The Z80k was a great chip, and 1987 was before the Intel domination with the x86. But sentiment is like a tidal wave...

I still have somewhere the Z80k C compiler. I believe it was generated entirely with YACC MUFOM tool kit.

Maybe Zilog's mistake was to not make microcontrollers. A smaller company must address a smaller and more specialised market - true for any business. And look at today's uC market, with so many players  co-existing. People would have gone for a Z80 based uC very readily in say 1990. And it was easy... they had the PIO SIO SCC (85C30) CTC DMA. Just throw them on the same chip. Product designers would have almost no work to do. And the custom CMOS ASIC business was well developed in 1990; I was prototyping ASICs on Xilinx FPGAs, using schematic entry on Viewlogic 4, routing with XACT5, so for Zilog to knock up a uC with all this would have been dead easy. A Z80 is only a few k gates, and would fit in a mid level 1990 FPGA like a XC3090.

1976 was hard work for a new uC (the chips were laid out by hand) but 1990 was dead easy.

[mikeselectricstuff]

A couple of decades after that first one, Zilog was pushing a Z80-based microcontroller, and had a giveaway for a design contest. I got a kit. Then I wrote to them that it had a dead short across the power supply, and they sent a replacement.  That one didn't work either.  And that was my last Zilog experience.

I think that was the Z86<something> - if you turned it upside-down, the pinout was compatible with the PIC16C54. ISTR it was mostly used by people making universal remotes as Zilog had licensed a big library of IR codes & made it available free to anyone using their chip.

 

[coppice]

The Z80k was a great chip, and 1987 was before the Intel domination with the x86. But sentiment is like a tidal wave...

Perhaps, but the market the Z80k was targetting was already dominated by the 68k, with people looking towards things like SPARC to replace it. It had no compelling benefits.

Maybe Zilog's mistake was to not make microcontrollers. A smaller company must address a smaller and more specialised market - true for any business. And look at today's uC market, with so many players  co-existing. People would have gone for a Z80 based uC very readily in say 1990.

That's true.

And it was easy... they had the PIO SIO SCC (85C30) CTC DMA. Just throw them on the same chip. Product designers would have almost no work to do.

It would probably have been uncompetitive in 1990 to throw that stuff in. Gate count was still important, and most MCUs were fine tuned, with every SKU being its own die. Successful peripherals on MCUs didn't usually look that similar to successful peripherals in their own package. Today it would be a no-brainer to throw in the kitchen sink.

1976 was hard work for a new uC (the chips were laid out by hand) but 1990 was dead easy.

Wow. I see you never worked in MCUs in the early 90s.

[peter-h]

No but I was doing ASICs of the right sort of gate count. The ASIC business was highly competitive, with sub $1 pricing for 10k+ (yes only 10k!), say 10k gates.

I don't know about today but putting a CPU in an FPGA was never competitive.

Has a Z80 schematic (or VHDL) ever been published? Various 3rd party ones exist e.g. https://opencores.org/projects/a-z80

[CatalinaWOW]

CPUs on a gate array makes no sense in new designs or where chip cost drives program cost.  But if there is a large software investment, or other large one time costs involved it can be a huge cost saving.

[RoGeorge]

Found this, pointed by Hackaday, an open source Z80 in hardware:
https://github.com/rejunity/z80-open-silicon
https://hackaday.com/2024/04/28/the-z80-is-dead-long-live-the-free-z80/

[peter-h]

Many years ago I was asked to do an FPGA plug-in equivalent for some TMS9900 peripherals. These seemed to have a funny silicon problem in that they all died after some years.

The size of the FPGA needed was surprising - something like a (then) Xilinx 3090. Not cheap at about 100 quid.

It was also a huge job. I quoted the guy about 20k for the design. He didn't go for it.