Zilog Z180

168 views
Skip to first unread message

Steven Feinsmith

unread,
Mar 6, 2021, 2:36:41 AM3/6/21
to se...@googlegroups.com
I remembered from my old days related the Zilog Z800 family tried to destroy Intel 80286 and 80386 in the market before they threw a wet towel to the floor. Zilog shifted business to involve commercials only. In this situation, Zilog is still alive, and even the old Z80 remains alive nowadays. Zilog was doing it the correct way in the old days. We may see a tremendously powerful Zilog processor wipe out both Intel and AMD combined.
Have you considered the Zilog eZ80? I knew about the Benton Harbor bus limited to 8-bit (of course, except the Trionyx). 
The eZ80 address bus increased from 16 to 24 bits. The fact about the eZ80 is more powerful and speeds over the Z800 family. Perhaps it can design the boards with bridge connection to carry extra data/address lines like S100computers did with more than 16 bits.
Perhaps your future project may good to involve with the eZ80.

Thank you,
Steven

norberto...@koyado.com

unread,
Mar 6, 2021, 5:40:52 AM3/6/21
to se...@googlegroups.com

Actually is the Z8S18033VEG, Z8S180 Microprocessor IC Z180 1 Core, 8-Bit 33MHz 68-PLCC. I do not know the eZ80, so I will have to relied on feedback from Douglas and Terry G.

 

http://www.zilog.com/docs/z180/z8s180ps.pdf

 

Norberto

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAGJMgmVhhtGAAfwdctqA8VeUKMHenOLTc22thps-5xHhGTMk4w%40mail.gmail.com.

Douglas Miller

unread,
Mar 6, 2021, 7:48:41 AM3/6/21
to se...@googlegroups.com

Yes, the Z180 is a very different beast from the eZ80.

From what I've read, here are the basic differences:

Z180 is a System-On-a-Chip, with an MMU, DMA, and UARTs (and more). However, the CPU is limited to a 16-bit logical address space, but the MMU allows for a 20-bit physical address space.

eZ80 is a CPU only, but extends the logical address space from 16 to 24 bits using a special CPU mode or instruction prefixes, much like how Intel extended the x86 line from 16 to 32 to 64 bit addresses.

If I were forced to have an opinion, I might think that - for legacy code like CP/M (or HDOS) - the Z180 gives you more (provided the OS can be customized to take advantage - e.g. the BIOS can leverage the extra hardware). However, using a Z180 in a strict platform architecture like the H8/H89 means that you probably can't take full advantage of all the hardware (ROM layout, INS8250 UARTS, etc).

There are other differences and advantages, so the decision of one over the other is not this simple.

Dave McGuire

unread,
Mar 6, 2021, 1:18:05 PM3/6/21
to se...@googlegroups.com
Z800 (Z280), Z180, eZ80...all different chips.

I too drooled heavily when the eZ80 was released, and I did some
commercial designs based on it, specifically the eZ80F91. The C
compiler was pretty good, and they initially shipped a very capable RTOS
based on XINU, complete with an IP stack, which I used in the products
that I designed. All of that software supported the extended (24-bit)
addressing.

But while the compiler itself was good, the overall tool environment
was pretty awful and poorly supported. Then, they made a mask change to
the IC that made their ($400!) programming tool stop working, forcing me
to either purchase a new one or kill the products. Then they replaced
the XINU-based RTOS with an in-house-written clone of it, due to some
legal dispute. The clone was well-conceived, but raw and buggy. That
was the beginning of the end.

Then they changed the mask again, introducing more
incompatibilities...that was the last straw, and as I had just started
exploring ARM at that time, I accelerated that process and moved
entirely to ARM at that point. This was around 2006. I've been making
a living as an ARM embedded hardware and firmware developer since then,
but since the NVIDIA drama threw that world's future into doubt, I now
have a RISC-V board on my desk.

Anyway, the eZ80 is a very fast (50MHz!) extended Z80 implementation
with lots of on-chip peripherals, chip-select generators, etc. The
eZ80F91 has an on-chip Ethernet controller. CP/M was ported to it many
years ago. Building a board around it would be pretty neat, but you'd
need those programming dongles, and it's a surface-mount chip, which
many people seem to have an irrational fear of.

The Z180 family is also rather nice, but not quite as featureful as
the eZ80, and is available in a few different packages. No direct
through-hole, but there are PLCC implementations, for which through-hole
sockets are available.

Several years ago I got a really good deal on two trays (a few
hundred) Z182 ICs in TQFP packages. I designed an SBC around that chip,
and ported CamelFORTH and standalone MBASIC to it, just as change of
scenery. (this is what I do instead of "vacationing") There's an IDE
interface on that board, so I will eventually write a CP/M BIOS for it.

Anyway, good chips, but I would probably avoid the eZ80 family
because of the awful tool ecosystem. The Z180 family is at least
everywhere in huge volumes, so there's less risk of chip unavailability.

If anyone wants to do a design based on these in the hobbyist-class
space, like an H8 CPU board etc, I would be open to the idea of
pipelining the PCBs through my lab, gratis, for any required
surface-mount soldering. Actually, that offer stands for any such
designs in this space. ("my lab" is an actual commercial lab with proper
equipment for this, not a "spare bedroom" or "basement" type of setup)

-Dave

--
Dave McGuire, AK4HZ
New Kensington, PA

Dave McGuire

unread,
Mar 6, 2021, 1:21:56 PM3/6/21
to se...@googlegroups.com
On 3/6/21 7:48 AM, Douglas Miller wrote:
> Yes, the Z180 is a very different beast from the eZ80.
>
> From what I've read, here are the basic differences:
>
> Z180 is a System-On-a-Chip, with an MMU, DMA, and UARTs (and more).
> However, the CPU is limited to a 16-bit logical address space, but the
> MMU allows for a 20-bit physical address space.
>
> eZ80 is a CPU only, but extends the logical address space from 16 to 24
> bits using a special CPU mode or instruction prefixes, much like how
> Intel extended the x86 line from 16 to 32 to 64 bit addresses.

No, the eZ80 is not a CPU only. It's an SOC with many on-chip
peripherals, the larger ones (eZ80F91 in particular) even have on-chip
Ethernet controllers.

But yes, they all have a 16-bit logical address space, which is how
they can run unmodified Z80 code.

> If I were forced to have an opinion, I might think that - for legacy
> code like CP/M (or HDOS) - the Z180 gives you more (provided the OS can
> be customized to take advantage - e.g. the BIOS can leverage the extra
> hardware). However, using a Z180 in a strict platform architecture like
> the H8/H89 means that you probably can't take full advantage of all the
> hardware (ROM layout, INS8250 UARTS, etc).

There might be opportunities to use the other on-chip hardware, but
obviously not for "system" devices if one wants to run unmodified HDOS,
etc. But new drivers could easily be written I think, and that would be
a great project. At the very least, one could use the extended
addressing to implement a bank-switched RAM disk or something like that.
(but again, drivers would need to be written)

Douglas Miller

unread,
Mar 6, 2021, 1:55:39 PM3/6/21
to se...@googlegroups.com
You must be talking about variations based on the eZ80 then, where the
eZ80 CPU is coupled with peripherals. The datasheets I have describe
only the CPU, so these other chips must be hybrids that use the eZ80 core.

Dave McGuire

unread,
Mar 6, 2021, 1:57:40 PM3/6/21
to se...@googlegroups.com

Can you point to some part numbers? I was "all up in there" with
that chip family for many years, and never saw any standalone processor
implementations of the eZ80.

-Dave

Douglas Miller

unread,
Mar 6, 2021, 2:37:04 PM3/6/21
to se...@googlegroups.com
As I stated, I was reading the datasheet I pulled off the web, which
only talks about the CPU. Unlike the Z180 documentation, where it
appears that the set of SOC peripherals is standardized. Probably speaks
to how the eZ80 is/was marketed. I have a couple "REX 6000"
credit-card-sized PDAs (https://en.wikipedia.org/wiki/REX_6000) that are
supposedly based on the eZ80 - I have no idea what actual chip they
used. It is supposedly possible to jail-break them and program the eZ80
directly, but I never got around to trying that.

Dave McGuire

unread,
Mar 6, 2021, 3:26:55 PM3/6/21
to se...@googlegroups.com

I did not mean to be argumentative.

I think what we're seeing is a difference in documentation style.

The Z180 family also has chips with different peripheral sets. One
of them (the Z182, the one I have a bunch of) even has a very strange
mode that allows it to emulate an 8250 on a bus, meaning you can connect
it to a system where you'd connect an 8250 (electrically and logically,
not physically) and have it respond as an 8250, and all the register
reads/writes etc are visible to the Z180 firmware. It's very weird.

But yes, different variations of each, but I think they just
emphasized them differently in the documentation.

That PDA looks neat; it would be cool to jail-break them.

-Dave

rand...@hotmail.com

unread,
Mar 6, 2021, 5:20:23 PM3/6/21
to SEBHC
Just my $0.02:

The ez80 is a poor choice for most Z80 applications it has no mmu for the 8 bit mode. Without a common ram DRI OS's that use more than 64K of ram won't work.

Another option to consider: FPGA, there are many FPGA modules with large amounts of RAM so the biggest space used are simple level converters. Below is one example of an S-100 FPGA/z80 system:


The best part is being able to make major modifications by only modifying the code to change what the hardware does.

John uses an FPGA module that uses 2mm spacing but there are other modules with 0.1" spacing. But of course by following John's design on the H8 would give a huge head start. John has his own mmu he used but the z180 mmu is open source if you prefer it.


Randy

Norberto Collado

unread,
Mar 6, 2021, 7:14:46 PM3/6/21
to se...@googlegroups.com

Thanks for the FPGA Z80 link as it contains useful information on what it was done to initialized the SD cards.

 

I do not understand the following comment as I have a 2GB on Drive 0 and a 128GB on Drive 1, working fine so far, once they are initialized.

Note you cannot use two different cards on the same drive (A or B). 

 

Thanks,

Norberto

--

You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.

George Farris

unread,
Mar 6, 2021, 7:20:22 PM3/6/21
to se...@googlegroups.com
I close friend of mine has one of these boards and he has never been able to get it to run consistently.  He has done a lot of work on the FPGA code as well but memory tests that will run for days on the H8 but spit out errors anywhere from minutes to a hour but rarely longer.

He is using the Z80 FPGA code.  I would suggest not going down that route.

If anyone wants more info I will pass their email address on to him and he can give you more about what he went through.

Cheers
George

norberto...@koyado.com

unread,
Mar 7, 2021, 5:48:34 AM3/7/21
to se...@googlegroups.com

Based on discussions, I will keep working on the Z180 CPU H8 board. Also we have invested so much time on the Z180 development targeted to the H8 system. Combining this CPU board with the H8 CF board we should be able to run such system between 20MHz-33MHZ easily, depending on DIMM’s speed. Also we can leverage the wait states build-in to push the speed.

 

Thanks for the feedback,

Norberto

--

You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.

Joseph Travis

unread,
Mar 7, 2021, 7:45:42 AM3/7/21
to se...@googlegroups.com
Well, now that's settled... Is it gonna have a connector to accept GameBoy cartridges?  ;)

Norberto Collado

unread,
Mar 7, 2021, 4:11:04 PM3/7/21
to se...@googlegroups.com

Is it gonna have a connector to accept Gameboy cartridges?  ;)

 

It has been in my mind for a while, but the LR35902 CPU is not compatible with the Z-80 nor is it compatible with the 8080. The architecture is different.

 

Diagram

Description automatically generated

 

Norberto

Reply all
Reply to author
Forward
0 new messages