More thoughts on building a Z-80 (64bit!!!)

From: Allison J Parent <allisonp_at_world.std.com>
Date: Thu Oct 22 11:36:45 1998

< I have looked at Z180's, Z380's and etc.... They are SLOW!!!!!! The
< only availabe packaging for the Z380 is un-useable to me as a hobbist
< (without a lot of headache.)

Slow clock but they use fewer clocks and 16bit fetch. The effective
speed is higher. Also the chip spped in climbing.

The socket is a 25$ item to get from flat pack to wire wrapable.

< I hate the way that Zilog has taken the nice and simple control bus sche
< of the Z-80 and really made it a pain-in-the-butt on the Z-380!.

At first I was of that opinion. Then I started with the z280 (Zbus mode)
and z8000 and looked back at the z380 and it looks worse than it is.
It's advantage is that it puts out advanced timing info making fast
systems possible while using less bus bandwidth.

< size set of bus control lines), Z-80 instruction set and match a DEC Alp
< performance (at a cheap price of-course), I would worship that company.

Why not find and Alpha and write z80 PALcode for it?

< (Oh yes, I want a 64bit data bus and a 128bit address bus). Is this ask
< for too much? Why can't we all just get along?

You don't know why that isn't done. There are things about the z80 that
do not scale well.

< My thoughts are this: If I can find some REALLY SIMPLE mirco-controlle
< that do just the basic microprocessor functions, I can parallel them to
< make them read-in and intrepret Z-80 code.

Like I said it's the sub 1nS memory that will stop you. A z80 at a
theorhetical clock of 100mhz would require the memory *system* to have a
M1 read cycle of less than 10nS. Try and find logic for decode and memory
taht can make that happen in the required time. The Z80 bus provides
little in the way of advanced timing to overlap operations so you need
really fast memory and IO stuff.

For example while z80s at faster than 10mhz are easy to get peripherals
for greater than 8mhz are scarce and some never got faster than 4-6mhz!

< and DEC Alpha) can reach clock speeds of 600 Mcyc and a really simple (o
< accumulator, bare instruction set) microcontroller can't exceed those sp

It's a study in piplelined operations. Simple machines have less to
pipleine so the individual elements have to be faster. You cannot
overlap as many operations as there only a few. Even with current
superfast logic sub 1nS gates are rather scarce. So you hit the speed
limit IE: how fast can you compare two numbers and branch based on the
result.

< If I got some of these micro-controllers and had two or three of them
< reading in instructions ahead of execution (looking for branches) I coul
< do half of the job and speed up the through-put.

Except that they arent avalable that fast. Your trying to discretely
do what a PII does internally. It's in esscence doing several things in
parallel assuming some will be thrown away (branch no taken, add not done
and so on) that take complex archecture so that you have more irons in
the fire and can be more speculative.

< For math, a bunch of stinking fast memory locations acting as look-up ta

That works but to get the speeds you talking about where do these sub
3nS rams/roms come from? Can you wire them on a card so that the lead
lengths are not a significant part of the timing (remember 1ft=1nS).
These become real things when the clock exceeds 100MHz. I know this
from doing a 20mhz z180 design on paper and I was looking at fast cache
rams chips to keep the memory inline, but for IO wat states were a must
as most periperal chips I could find were limited to 10mhz bus speed
range.

I know I'm a party pooper but, I'm also one of those wacky engineers
that has pushed the z80/z180/z280 to the edge and know what a design
must do to work.

On the other hand running CPM at 12.5MHz z180 is frighteningly fast
but also points out system bottlenecks like disk speed! I've been
putting time into overcomming that using disk caches and the like.

Allison
Received on Thu Oct 22 1998 - 11:36:45 BST