(Note: by Z8 I mean Z8 Encore! XP or any other way-too-long name with a dumb "!" in the middle.)

I have to say that the most important feeling that I have regarding Zilog's product line is indeed that it still seems to live in the past, and not just the Z80.

As many people say today, the core doesn't matter, it's all in the peripherals. Well I'd take a Z8 core anytime over a PIC core (I actually like the Z8!), but the peripherals aren't going anywhere. CAN/LIN? USB? Multiple fast ADCs and DACs? Advanced ISP/IAP/debugging code in ROM, user accessible? All kinds of timers, multi-protocol serial ports, quadrature encoders, and so much more? Just add everything to every single chip, except for a few transistor-hungry peripherals maybe, and let the users configure the pins.

The other thing that I find quite disturbing is the slowness in fixing erratas. The ZNEO has had the POPF R3 corruption errata ever since it came out, 3 years ago or so, and outside of a hack using an undocumented instruction nothing has been done. Finding workarounds is good, fixing bugs quicky even better. The ZNEO might not have been as successful as hoped, though. It would be a pity, as it's a very neat classical old-school architecture, much easier to grasp and program than many others.

Talking about architecture, the implementation of the CPUs also seem to be stuck some decades ago. Instruction state machines and such were all the rage in the pre-RISC world, but nowadays they seem a bit old. The Z8 flash bus, limited to 1 byte per CPU cycle, and therefore wasting cycles if the next instruction has a higher number of bytes than the current instruction's cycle count, is positively retarded. Every single instruction also takes at least two cycles, but most of them could be brought back to one using a little pipelining magic (or a white lie like Microchip, just giving the MIPS counts for its MCUs, and disclosing quietly in a buried part of the user manual that the actual core frequency is > 100MHz). With a little effort, a Z8 derivative could be a really mighty MCU, and that statement extends to other product lines as well...

Another strong selling point nowadays is the whole low energy comsumption, athough that's not something that I've seen Zilog investing a lot of effort an PR into. Maybe the power-related forum channel on this forum will help? When will I get a Z8 to run on a button cell for years, or hooked up to a tiny solar panel?

I happen to have at home a few dev kits, and all those kits share what I believe to be the same debug module. Although paying 50$ for such a kit including the probe is amazing, I don't really need 3 or 4 of them. Make (very) small demo boards with some ultra-basic form of programming and minimal debugging built straight into them, and some more evolved development kit that would work with the probes. Keep the prices low, that's the best incentive to buy one!

Talking about dev tool, completely opening up the specs of the debug interface and probe and helping to write a Linux gdb server for it would be a good idea. Linux user are quite often tinkerer and share what they do. That's an excellent way of helping build up a happy, messy and noisy community that would be an excellent testing ground.

The website needs to be fixed, as it is crucial to offer proper product description and documentation. It's not up to snuff right now, amongst other things the links to distributors are mostly broken.

You've got to get your products sexy again. Sexy isn't only in the latest buzzword, but also in being one of the top contenders. The Z80 and 6502 owned the market 30 years ago because they were cheap, an overall better than the rest. That's pretty much what you've got to go back to. Realize that you might have to make some small incompatible changes to build a much better product (everyone did at some point or another). Blow on that a little je-ne-sais-quoi, the little things that make people want to play with your products, and off you go.

On a purely personal note, the tinkerind kid in me would love to see one of those two products:
- a console on a chip, using a fast cleaned-up Z80 core, NTSC/PAL or VGA or even modern DVI-D output, basic USB host for I/O, either an internal memory or an external bus to a high-speed 4bit SDRAM, some form of sound output (I2S to DAC?), and a pair of MMC/SDHC buses. In a cool little box, with a couple of Zilog paddles. USB device connector for debugging (ie probe included) and serial console. Change the graphics output for LCD, and you've got a chip that can fit in an ever-increasing number of products.
- a modern Z80 or a ZNEO with a paging MMU in a easy-to-use package (DIP or PLCC). Additional points for using it in the previous project, geek points for having a multi-core CPU. It's time to rewrite UNIX.

Ed Dantes wrote:

- a console on a chip, using a fast cleaned-up Z80 core, NTSC/PAL or VGA or even modern DVI-D output, basic USB host for I/O, either an internal memory or an external bus to a high-speed 4bit SDRAM, some form of sound output (I2S to DAC?), and a pair of MMC/SDHC buses. In a cool little box, with a couple of Zilog paddles. USB device connector for debugging (ie probe included) and serial console. Change the graphics output for LCD, and you've got a chip that can fit in an ever-increasing number of products.
- a modern Z80 or a ZNEO with a paging MMU in a easy-to-use package (DIP or PLCC). Additional points for using it in the previous project, geek points for having a multi-core CPU. It's time to rewrite UNIX.

I would rather like to see something that is as easy to use as an AVR but with Von-Neumann architecture. (Should be, we are talking Z80 here. )
Get 5V (or 3.3V if you insist) from somewhere, pack a simple ISP connector on the board that can be used trough something as easy as three resistors and a diode on a parallel port and off you go. Crystal is optional as the MCU has its own internal clock generator.
Bonus points for an open source tool for flashing, i showed more than one microcontroller maker my back for not supporting Linux with their dev-chain. (Hello Freescale!)
Big Bonus points for selling it trough Reichelt at a reasonable price.
Bigger Bonus points for not using error-prone fuses. Oh man, i hate those!

Ah but you're being serious again! That wish list was my pipe dream, the stuff I would like to play with, not work with.

You make a very valid point, though. Microchip ate up so much of the market simply by having chips that were easy to use, and reasonably reliable. Atmel is going the same way with its AVR. Both have pretty good support under Linux, although it's mostly community-based and therefore might sometimes be missing some functionalities.

Ed Dantes wrote:
- a console on a chip, using a fast cleaned-up Z80 core, NTSC/PAL or VGA or even modern DVI-D output, basic USB host for I/O, either an internal memory or an external bus to a high-speed 4bit SDRAM, some form of sound output (I2S to DAC?), and a pair of MMC/SDHC buses. In a cool little box, with a couple of Zilog paddles. USB device connector for debugging (ie probe included) and serial console. Change the graphics output for LCD, and you've got a chip that can fit in an ever-increasing number of products.
- a modern Z80 or a ZNEO with a paging MMU in a easy-to-use package (DIP or PLCC). Additional points for using it in the previous project, geek points for having a multi-core CPU. It's time to rewrite UNIX.

Mmm second thoughts, the ZNEO core would be much nicer for a console on a chip. It's a cleaner architecture, with a much larger address space, and 16-bit plays much more nicely with graphics and sound. And of course, for the second bullet I should have said "additional points for using the core in the previous project", not the exact same chip.

And add a ton of SPI buses to connect everything under the sun.

Wish list can vary a lot from one customer to an other ...

About peripherals i like the idea of the PSDxxx series of ST : a flash + sram + cpld logic for interface + user cpld array.

The idea of putting flash + sram together in the same package is good , almost evident when you think MCU , but
zilog products have MCU+flash+sram already .

Still the idea of having cpld array also makes it very intesting !

So my wish list would be a companion chip for mcu with
CPLD + most common peripherals core + small eeprom + sram extension .

there could be different variation in the family depending on the size of the cpld (cost) or
the type of peripherals :
universal , serial , gpios , ethernet mac , memory interface sdram/ddr, usb, sensor drive...

CPLD is very helpfull since you dont need them to add logic for decoding of address of
peripherals and others.

and guess what it could even be companion chip for other mcu types.

ZNEO ? - yes, nicer opcodes, but the MHz is rather too low for serious contention in 2010.

Sadly, the ZENO also has close to zero software eco-system.

The Rabbit 6000 shows where the Z80 should at least be, by now. It has some 32 bit registers/opcodes, and a usable 200MHz
speed spec.

The smartest Serial ports are USART ones, that do SPI/Async .

To keep costs down, QuadSPI memory might be usable as Code storage, and then you focus on MAXIMUM Sram, and a lower cost process.
(pretty much what R6000 does)

Still complete silence from Zilog on their Cortex release, so sounds like that project died.