Re: Zilog stopping Z80 production

On 4/27/2024 3:39 AM, albert@spenarnc.xs4all.nl wrote:

In article <v09p38$1uqd3$2@dont-email.me>,
Don Y  <blockedofcourse@foo.invalid> wrote:

On 4/23/2024 5:08 PM, Edward Rawde wrote:

It must be trivial to get a VHDL/Verilog model and make your own by now.

>
The problem with all the early/simple/trivial processors is getting
the rest of the system to run as fast as the core can.  E.g., running
a core at ~200MHz and expecting the same bus timing means < 5ns memory.
>
(for a Z80, that would be ~10ns as the bus timing is inherently slower)
>
The better option is to embed the core *in* a design to give you
the advantages of a programmable sequencer (instead of "junk logic")
>

The 6809 was my preference but took a few more years.

 Motorola was much better in this respect. Peripherals are accessed
by handshake. So you could  put a longer delay iff the peripherals
are slow.

The Z80 allowed the bus cycle to be indefinitely extended by
the assertion of WAIT.  As a bus cycle had many clock edges,
you could support devices that were "slightly slower" than
the nominal bus timing without having to allow "twice" as
much time for the access.
The WAIT feature was present on many MCUs of that era (I recall
NOT present on the 8x300)
The M68K was the first mainstream device to use "asynchronous"
memory requiring an explicit acknowledgement (DTACK) for each
bus transaction (by contrast, one could *wire* WAIT permanently
inactive if you had sufficiently fast enough memory; OTOH, DTACK
*had* to be stroked regardless of memory speed -- or even the
PRESENCE of memory in an address region!)
Implementing dual-ported memory was considerably easier on MCUs
with fixed bus timings (6502/2A03, 68xx, etc.) as you KNEW when the
MCU would NOT be accessing memory.  For procesors with variable
bus cycles (68K, Z80, etc.), you had to resort to introducing wait
states (in case the MCU wanted access to the memory while the
arbiter was giving access to the other "bus master") or playing
games with the clock stretching.
[*Single* writes could be cached in external logic and defered until
the arbiter returned access to the MCU to eliminate stalling the bus
in those cases; no such mechanism available for reads, though]
The 16032 had the cleverest pinout, supporting external coprocessors
(including the PMMU) without requiring superfluous bondout options.

I remember spending 2000 guilders in around 1980 for 16 K ram
for my Z80.
Just to discover that code in this ram couldn't run, because the
Z80 was too slow. Only useable for data.

Huh?  An opcode fetch takes the same amount of time as a data fetch.  The opcode fetch also has a bit of extra time in the cycle (4 clocks vs 3)
to squeeze in a DRAM refresh (damn near everyone recognized this ability
when designing memory controllers; stalling the MCUs accesses just
to steal a bus cycle would be a significant hit on bandwidth).
The abundance of clock edges in the cycle made designing a DRAM controller
out of discrete logic pretty trivial.  And, the processor's internal
"refresh register" eliminated the need for an external counter to
perform that function.
I have a Z80 system with 512KB of DRAM (huge for that era).  It
allows for 8 simultaneous MP/M users or a single CP/M user with
a relatively large RAM disk (blazing fast compared to the 8"
floppies of the day -- especially for software development where
multipass tools were common)

I managed to factor numbers of up till hundreds of digits,
using 1K of ram and 1K of videoram (that contained the digits)
before this extension. No restrictions on the size of the
factors! (Patience required.).