RIP Z80

[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?