After 48 years, Zilog is killing the classic standalone Z80 microprocessor chip
Z80 powered game consoles, ZX Spectrum, Pac-Man, and a 1970s PC standard based on CP/M.
https://arstechnica.com/gadgets/2024/04/after-48-years-zilog-is-killing-the-classic-standalone-z80-microprocessor-chip/

On 2024-04-23, Jan Panteltje wrote:
> After 48 years, Zilog is killing the classic standalone Z80
> microprocessor chip Z80 powered game consoles, ZX Spectrum, Pac-Man,
> and a 1970s PC standard based on CP/M.

Yep, just got the EOL notice from Digikey yesterday. Shame...

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 23/04/2024 12:23, Dan Purgert wrote:
> On 2024-04-23, Jan Panteltje wrote:
>> After 48 years, Zilog is killing the classic standalone Z80
>> microprocessor chip Z80 powered game consoles, ZX Spectrum, Pac-Man,
>> and a 1970s PC standard based on CP/M.
>
> Yep, just got the EOL notice from Digikey yesterday. Shame...
>
Maybe China will make a clone...

--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

On a sunny day (Tue, 23 Apr 2024 11:23:32 -0000 (UTC)) it happened Dan Purgert
<dan@djph.net> wrote in <slrnv2f6hk.nch.dan@djph.net>:

>On 2024-04-23, Jan Panteltje wrote:
>> After 48 years, Zilog is killing the classic standalone Z80
>> microprocessor chip Z80 powered game consoles, ZX Spectrum, Pac-Man,
>> and a 1970s PC standard based on CP/M.
>
>Yep, just got the EOL notice from Digikey yesterday. Shame...

Well, I will get over it
https://panteltje.nl/panteltje/z80/index.html
Wrote a disassembler for it once
and a CP/M clone when I had no CP/M only a Sinclair ZX80, later a ZX81 ..
https://panteltje.nl/panteltje/z80/index.html
Build a lot of hardware for my Z80 system:
https://panteltje.nl/panteltje/z80/system14/diagrams/index.html
Dumped it all years ago.
People were still using the disassembler a few years ago it seems.

Very nice processor.

I think I had a Z80 simulator on some old Linux PC once?

But the world keeps changing...
Not always for the better, more bloat every day..
If you see Chromium on Raspbery Pi 4 8 GB taking sometimes minutes
to display a simple text based website...
cache...

You could probably use the FPGA Z80 version :-)
https://opencores.org/projects/a-z80

Jan Panteltje <alien@comet.invalid> wrote:
>On a sunny day (Tue, 23 Apr 2024 11:23:32 -0000 (UTC)) it happened Dan Purgert
><dan@djph.net> wrote in <slrnv2f6hk.nch.dan@djph.net>:

>>On 2024-04-23, Jan Panteltje wrote:
>>> After 48 years, Zilog is killing the classic standalone Z80
>>> microprocessor chip Z80 powered game consoles, ZX Spectrum, Pac-Man,
>>> and a 1970s PC standard based on CP/M.
>>
>>Yep, just got the EOL notice from Digikey yesterday. Shame...

>Well, I will get over it
> https://panteltje.nl/panteltje/z80/index.html
>Wrote a disassembler for it once
>and a CP/M clone when I had no CP/M only a Sinclair ZX80, later a ZX81 ..
> https://panteltje.nl/panteltje/z80/index.html
>Build a lot of hardware for my Z80 system:
> https://panteltje.nl/panteltje/z80/system14/diagrams/index.html
>Dumped it all years ago.
>People were still using the disassembler a few years ago it seems.

>Very nice processor.

>I think I had a Z80 simulator on some old Linux PC once?

>But the world keeps changing...
>Not always for the better, more bloat every day..
>If you see Chromium on Raspbery Pi 4 8 GB taking sometimes minutes
>to display a simple text based website...
>cache...

>You could probably use the FPGA Z80 version :-)
> https://opencores.org/projects/a-z80
The most difficult part is to put all into a 40 pin 300 mil package as
a drop in replacement. If all I wanted was a machinery to run Z80 software
my choice wuild be a RP2040 board.
https://github.com/djbottrill/rp2040_z80_emulator

--
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

Peter Heitzer wrote:
> Jan Panteltje wrote:
>> Dan Purgert wrote:
>>> Jan Panteltje wrote:
>>>> After 48 years, Zilog is killing the classic standalone Z80
>>>> microprocessor chip Z80 powered game consoles, ZX Spectrum, Pac-Man,
>>>> and a 1970s PC standard based on CP/M.
>>>
>>>Yep, just got the EOL notice from Digikey yesterday. Shame...
>
>>Well, I will get over it
>> https://panteltje.nl/panteltje/z80/index.html
>>Wrote a disassembler for it once
>>and a CP/M clone when I had no CP/M only a Sinclair ZX80, later a ZX81 ..
>> https://panteltje.nl/panteltje/z80/index.html
>>Build a lot of hardware for my Z80 system:
>> https://panteltje.nl/panteltje/z80/system14/diagrams/index.html
>>Dumped it all years ago.
>>People were still using the disassembler a few years ago it seems.
>
>>Very nice processor.
>
>>I think I had a Z80 simulator on some old Linux PC once?
>
>>But the world keeps changing...
>>Not always for the better, more bloat every day..
>>If you see Chromium on Raspbery Pi 4 8 GB taking sometimes minutes
>>to display a simple text based website...
>>cache...
>
>>You could probably use the FPGA Z80 version :-)
>> https://opencores.org/projects/a-z80
> The most difficult part is to put all into a 40 pin 300 mil package as
> a drop in replacement. If all I wanted was a machinery to run Z80 software
> my choice wuild be a RP2040 board.
> https://github.com/djbottrill/rp2040_z80_emulator

Thank you both for your contributions. Although STM is somewhat better
than BCM from my own perspective, both are appreciated by me.

Danke,

--
Don, KB7RPU, https://www.qsl.net/kb7rpu
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.

On 4/23/2024 6:09 AM, Peter Heitzer wrote:
> The most difficult part is to put all into a 40 pin 300 mil package as
> a drop in replacement.

The most common Zx80's were 600mil.

> If all I wanted was a machinery to run Z80 software
> my choice wuild be a RP2040 board.
> https://github.com/djbottrill/rp2040_z80_emulator

You can likely emulate a Zx80's *software* faster than even the
fastest devices, nowadays. But, for legacy software, you would
have problems supporting the I/Os -- even if you virtualized them.

One amusing anecdote re: MAME's nominal emulation of older games
is how they can't[1] ensure the same timing relationships that were
guaranteed in the original hardware. Getting the functionality
correct but the timing "off" can have visual consequences.

Part of that is a consequence of trying to get more performance
out of the hardware than was nominally available. And, part was
a lack of concern for "portability" (of which emulation is
probably the epitome).

[1] You could, of course, do so -- by dramatically increasing the
complexity of the emulator!

On Tue, 23 Apr 2024 13:40:13 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 4/23/2024 6:09 AM, Peter Heitzer wrote:
>> The most difficult part is to put all into a 40 pin 300 mil package as
>> a drop in replacement.
>
>The most common Zx80's were 600mil.
>
>> If all I wanted was a machinery to run Z80 software
>> my choice wuild be a RP2040 board.
>> https://github.com/djbottrill/rp2040_z80_emulator
>
>You can likely emulate a Zx80's *software* faster than even the
>fastest devices, nowadays. But, for legacy software, you would
>have problems supporting the I/Os -- even if you virtualized them.
>
>One amusing anecdote re: MAME's nominal emulation of older games
>is how they can't[1] ensure the same timing relationships that were
>guaranteed in the original hardware. Getting the functionality
>correct but the timing "off" can have visual consequences.
>
>Part of that is a consequence of trying to get more performance
>out of the hardware than was nominally available. And, part was
>a lack of concern for "portability" (of which emulation is
>probably the epitome).
>
>[1] You could, of course, do so -- by dramatically increasing the
>complexity of the emulator!
>
>

I miss playing with my old home built S-100 CP/M computer around 1980.
Those were really the fun days of computing and digital logic
circuits.

The other day after hearing the demise of the Z80, I ordered 2 of the
20 MHz Z80 40 pin devices. I did not even know there was a 20 MHz
version. Not sure what I will ever do with them but who knows ?
Maybe I'll just look at them.

boB

"Jan Panteltje" <alien@comet.invalid> wrote in message
news:v07k2p$cki9$1@solani.org...
> After 48 years, Zilog is killing the classic standalone Z80 microprocessor
> chip

It must be trivial to get a VHDL/Verilog model and make your own by now.
The 6809 was my preference but took a few more years.

> Z80 powered game consoles, ZX Spectrum, Pac-Man, and a 1970s PC standard
> based on CP/M.
> https://arstechnica.com/gadgets/2024/04/after-48-years-zilog-is-killing-the-classic-standalone-z80-microprocessor-chip/

On 4/23/2024 2:40 PM, boB wrote:
> I miss playing with my old home built S-100 CP/M computer around 1980.
> Those were really the fun days of computing and digital logic
> circuits.

Nowadays, the Zx80's appeal would be in controlling things.
There's little that you can't now do *better* that you would
previously have used a CP/M box for.

> The other day after hearing the demise of the Z80, I ordered 2 of the
> 20 MHz Z80 40 pin devices. I did not even know there was a 20 MHz
> version. Not sure what I will ever do with them but who knows ?
> Maybe I'll just look at them.

Again, in the context of "control" (i.e., deeply embedded),
you would likely also need similar speed grade peripherals
to do anything.

I had a particular fondness for the '180 (and '7180!) as it
wasn't crippled by the tiny address space (64K memory + 64K I/O)
of the Z80. Over the years, I've come to realize that you usually
need more space for *code* than data!

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.

On a sunny day (23 Apr 2024 13:09:43 GMT) it happened "Peter Heitzer"
<peter.heitzer@rz.uni-regensburg.de> wrote in
<l8pq8nF5cteU1@mid.individual.net>:

>Jan Panteltje <alien@comet.invalid> wrote:
>>On a sunny day (Tue, 23 Apr 2024 11:23:32 -0000 (UTC)) it happened Dan Purgert
>><dan@djph.net> wrote in <slrnv2f6hk.nch.dan@djph.net>:
>
>>>On 2024-04-23, Jan Panteltje wrote:
>>>> After 48 years, Zilog is killing the classic standalone Z80
>>>> microprocessor chip Z80 powered game consoles, ZX Spectrum, Pac-Man,
>>>> and a 1970s PC standard based on CP/M.
>>>
>>>Yep, just got the EOL notice from Digikey yesterday. Shame...
>
>>Well, I will get over it
>> https://panteltje.nl/panteltje/z80/index.html
>>Wrote a disassembler for it once
>>and a CP/M clone when I had no CP/M only a Sinclair ZX80, later a ZX81 ..
>> https://panteltje.nl/panteltje/z80/index.html
>>Build a lot of hardware for my Z80 system:
>> https://panteltje.nl/panteltje/z80/system14/diagrams/index.html
>>Dumped it all years ago.
>>People were still using the disassembler a few years ago it seems.
>
>>Very nice processor.
>
>>I think I had a Z80 simulator on some old Linux PC once?
>
>>But the world keeps changing...
>>Not always for the better, more bloat every day..
>>If you see Chromium on Raspbery Pi 4 8 GB taking sometimes minutes
>>to display a simple text based website...
>>cache...
>
>>You could probably use the FPGA Z80 version :-)
>> https://opencores.org/projects/a-z80
>The most difficult part is to put all into a 40 pin 300 mil package as
>a drop in replacement. If all I wanted was a machinery to run Z80 software
>my choice wuild be a RP2040 board.
>https://github.com/djbottrill/rp2040_z80_emulator
>

Wow! did not know about that!
I downloaded the zip file :-)

On 4/24/24 04:00, Don Y 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)
>

how much memory can it address?

On Tue, 23 Apr 2024 18:44:24 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 4/23/2024 2:40 PM, boB wrote:
>> I miss playing with my old home built S-100 CP/M computer around 1980.
>> Those were really the fun days of computing and digital logic
>> circuits.
>
>Nowadays, the Zx80's appeal would be in controlling things.
>There's little that you can't now do *better* that you would
>previously have used a CP/M box for.
>
>> The other day after hearing the demise of the Z80, I ordered 2 of the
>> 20 MHz Z80 40 pin devices. I did not even know there was a 20 MHz
>> version. Not sure what I will ever do with them but who knows ?
>> Maybe I'll just look at them.
>
>Again, in the context of "control" (i.e., deeply embedded),
>you would likely also need similar speed grade peripherals
>to do anything.

Yes, I know. Address decoders are a dime a dozen (almost) and any
other peripherals can either be made or, I may actually have the
others laying around. I save old ICs and have since the 1970s.

>
>I had a particular fondness for the '180 (and '7180!) as it
>wasn't crippled by the tiny address space (64K memory + 64K I/O)
>of the Z80. Over the years, I've come to realize that you usually
>need more space for *code* than data!

Wasn't familiar with those 2. Yes, I would run out of code space with
many micro controllers. The was always programmed in assembler and
code was fairly smalll at that time. Amazing we were able to get
along with less than 64K !

boB

>

On Wed, 24 Apr 2024 21:22:07 +0200, Lasse Langwadt <llc@fonz.dk>
wrote:

>On 4/24/24 04:00, Don Y 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)
>>
>
>how much memory can it address?
>

64K
16 bits worth.

boB

On 4/24/24 22:48, boB wrote:
> On Wed, 24 Apr 2024 21:22:07 +0200, Lasse Langwadt <llc@fonz.dk>
> wrote:
>
>> On 4/24/24 04:00, Don Y 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)
>>>
>>
>> how much memory can it address?
>>
>
> 64K
> 16 bits worth.

so in something like and FPGA in is with range of internal ram and
memory speed is not really an issue

On 4/24/2024 1:42 PM, boB wrote:
> On Tue, 23 Apr 2024 18:44:24 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
>
>> On 4/23/2024 2:40 PM, boB wrote:
>>> I miss playing with my old home built S-100 CP/M computer around 1980.
>>> Those were really the fun days of computing and digital logic
>>> circuits.
>>
>> Nowadays, the Zx80's appeal would be in controlling things.
>> There's little that you can't now do *better* that you would
>> previously have used a CP/M box for.
>>
>>> The other day after hearing the demise of the Z80, I ordered 2 of the
>>> 20 MHz Z80 40 pin devices. I did not even know there was a 20 MHz
>>> version. Not sure what I will ever do with them but who knows ?
>>> Maybe I'll just look at them.
>>
>> Again, in the context of "control" (i.e., deeply embedded),
>> you would likely also need similar speed grade peripherals
>> to do anything.
>
> Yes, I know. Address decoders are a dime a dozen (almost) and any
> other peripherals can either be made or, I may actually have the
> others laying around. I save old ICs and have since the 1970s.

But those devices won't be of the same (fast) speed grade as the
processor. Remember, all "external (to the CPU) interactions"
happen at a rate defined by the system clock frequency. So, the
RETI daisy chain will have to operate "faster", the devices
will have to put data onto the bus -- and take it off -- quicker,
all rate generators (dividers) will have to be rejiggered for a
faster input clock, any software delay loops (explicit or implied)
will have to be rewired, etc.

>> I had a particular fondness for the '180 (and '7180!) as it
>> wasn't crippled by the tiny address space (64K memory + 64K I/O)
>> of the Z80. Over the years, I've come to realize that you usually
>> need more space for *code* than data!
>
> Wasn't familiar with those 2. Yes, I would run out of code space with
> many micro controllers. The was always programmed in assembler and
> code was fairly smalll at that time. Amazing we were able to get
> along with less than 64K !

The 180 gave you a seamless way to get to 1M of program+data.
(Keep in mind that const data is still data!)

The 7180 was a microcontroller variant -- 16KB EPROM (OTP)
and 512B of RAM with a smattering of useful I/Os in a
PLCC package.

There were a couple of other 180 variants that offered
specialized capabilities but I never had a use for those
(*too* sole source; the 180 was eventually second sourced
BY ZILOG :> )

On 4/24/2024 12:22 PM, Lasse Langwadt wrote:
> On 4/24/24 04:00, Don Y 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)
>
> how much memory can it address?

It's not a question of how much DATA CAN BE STORED but, rather, what
type of addressable devices can it support.

E.g., I would often put a relatively high impedance pullup/down on a
signal input -- high enough that it wouldn't affect the intended loading
of the signal driving it. Yet, low enough that -- in the absence of that
driving source -- would let the processor exercise the input, programmatically.

So, drive the line high and examine the input to verify that state.
Repeat for low. There's some C on that line and you're driving it
through a relatively high impedance so it's going to take some
finite time to change state. But, you "know" how long an instruction
takes to execute so you don't need to have a hardware timer to
ensure you have waited long enough to examine the input. Just do
a tiny bit of work between driving the output and sensing the input
and you know the hardware should have settled to the new input level.

[Brief (TmReg) was my favorite text editor in the early PC days.
But, relied on timing loops in the code for things like keystroke
autorepeat. Use it on a modern processor and you can't get
your finger off the key fast enough to get a single character
per keystroke! Hit an "arrow key" and the entire file's contents
fly by in a fraction of a second. (Thank You, Borland, for killing
that product :< )]

A drop-in CMOS Z80 at 20MHz could probably be coaxed to work in
an existing circuit with only minor tweeks (as that's only a factor
of 2 or 3 beyond nominal). At *200* (possible in an FPGA) you would
have to rethink the hardware (and/or software) entirely. Why
would that ever be worth the effort?

How would you handle the dual ported memory interface to a frame
buffer? Would you expect the (1980's) display to run at a 200MHz
dot rate? Would all of your serial ports run at 20X their intended
bit rates? What happens when that Z80 (CP/M, MP/M, ZCPR3) wants to
read from or write to the *floppy* disk drive? Etc.

If all you want to use the memory bus for is storing/retrieving data+code,
why use a *physical* Z80 at all?

On 4/24/2024 1:48 PM, boB wrote:
> On Wed, 24 Apr 2024 21:22:07 +0200, Lasse Langwadt <llc@fonz.dk>
> wrote:
>
>> On 4/24/24 04:00, Don Y 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)
>>
>> how much memory can it address?
>
> 64K
> 16 bits worth.

*Directly*. But, many Z80 (and 68xx) devices augmented the normal
memory (+I/O) capabilities to overcome the limitations of the
processors (of that generation).

Or, bastardized memory in ways that we would consider unnecessary,
today. (E.g., reading from memory gave you the CODE but writing
actually modified the contents of the frame buffer in many video
games -- there's no need to OVERWRITE your EPROM-based program
and no need to READ the contents of the frame buffer!)

I would typically route 8 higher address lines to row-drivers for
a key matrix and *read* the column data to detect switch closures.
Wasteful of address space but 64K of I/O space was rarely needed
to be completely decoded!

So, you could quickly check to see if ANY key was depressed
(drive ALL rows, look for ANY column) before deciding if you
had to be more deliberate in your choice of row drives (to
identify the specific key closure).

On 4/24/2024 3:39 PM, Lasse Langwadt wrote:
> On 4/24/24 22:48, boB wrote:
>> On Wed, 24 Apr 2024 21:22:07 +0200, Lasse Langwadt <llc@fonz.dk>
>> wrote:
>>
>>> On 4/24/24 04:00, Don Y 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)
>>>>
>>>
>>> how much memory can it address?
>>>
>>
>> 64K
>> 16 bits worth.
>
> so in something like and FPGA in is with range of internal ram and memory speed
> is not really an issue

A processor that can't talk to the outside world (using the interface defined
by the original device) is essentially a gum drop, sitting on a shelf...

"Lasse Langwadt" <llc@fonz.dk> wrote in message
news:v0c1mg$2is8l$1@dont-email.me...
> On 4/24/24 22:48, boB wrote:
>> On Wed, 24 Apr 2024 21:22:07 +0200, Lasse Langwadt <llc@fonz.dk>
>> wrote:
>>
>>> On 4/24/24 04:00, Don Y 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)
>>>>
>>>
>>> how much memory can it address?
>>>
>>
>> 64K
>> 16 bits worth.
>
> so in something like and FPGA in is with range of internal ram and memory
> speed is not really an issue

Yes. That's where I'd put a Z80 in the unlikely event that I wanted to use
one these days.
Along with RAM, ROM, and anything else it needs.

>

On 4/24/2024 7:03 PM, Edward Rawde wrote:
>> so in something like and FPGA in is with range of internal ram and memory
>> speed is not really an issue
>
> Yes. That's where I'd put a Z80 in the unlikely event that I wanted to use
> one these days.
> Along with RAM, ROM, and anything else it needs.

You'd be better served to use something like a 6502 core as
the bus is cleaner and the core can run considerably faster.

On Wed, 24 Apr 2024 16:09:33 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 4/24/2024 1:42 PM, boB wrote:
>> On Tue, 23 Apr 2024 18:44:24 -0700, Don Y
>> <blockedofcourse@foo.invalid> wrote:
>>
>>> On 4/23/2024 2:40 PM, boB wrote:
>>>> I miss playing with my old home built S-100 CP/M computer around 1980.
>>>> Those were really the fun days of computing and digital logic
>>>> circuits.
>>>
>>> Nowadays, the Zx80's appeal would be in controlling things.
>>> There's little that you can't now do *better* that you would
>>> previously have used a CP/M box for.
>>>
>>>> The other day after hearing the demise of the Z80, I ordered 2 of the
>>>> 20 MHz Z80 40 pin devices. I did not even know there was a 20 MHz
>>>> version. Not sure what I will ever do with them but who knows ?
>>>> Maybe I'll just look at them.
>>>
>>> Again, in the context of "control" (i.e., deeply embedded),
>>> you would likely also need similar speed grade peripherals
>>> to do anything.
>>
>> Yes, I know. Address decoders are a dime a dozen (almost) and any
>> other peripherals can either be made or, I may actually have the
>> others laying around. I save old ICs and have since the 1970s.
>
>But those devices won't be of the same (fast) speed grade as the
>processor. Remember, all "external (to the CPU) interactions"
>happen at a rate defined by the system clock frequency. So, the
>RETI daisy chain will have to operate "faster", the devices
>will have to put data onto the bus -- and take it off -- quicker,
>all rate generators (dividers) will have to be rejiggered for a
>faster input clock, any software delay loops (explicit or implied)
>will have to be rewired, etc.
>

The interface isn't that complicated with parts that are available
today to build something. OR I could just run the part at 4MHz.

>>> I had a particular fondness for the '180 (and '7180!) as it
>>> wasn't crippled by the tiny address space (64K memory + 64K I/O)
>>> of the Z80. Over the years, I've come to realize that you usually
>>> need more space for *code* than data!

I am not THAT interested in using an obsolete part. Just wanted one. I
may never even use it.

boB

>>
>> Wasn't familiar with those 2. Yes, I would run out of code space with
>> many micro controllers. The was always programmed in assembler and
>> code was fairly smalll at that time. Amazing we were able to get
>> along with less than 64K !
>
>The 180 gave you a seamless way to get to 1M of program+data.
>(Keep in mind that const data is still data!)
>
>The 7180 was a microcontroller variant -- 16KB EPROM (OTP)
>and 512B of RAM with a smattering of useful I/Os in a
>PLCC package.
>
>There were a couple of other 180 variants that offered
>specialized capabilities but I never had a use for those
>(*too* sole source; the 180 was eventually second sourced
>BY ZILOG :> )

"Don Y" <blockedofcourse@foo.invalid> wrote in message
news:v0cm9k$2qh0i$1@dont-email.me...
> On 4/24/2024 7:03 PM, Edward Rawde wrote:
>>> so in something like and FPGA in is with range of internal ram and
>>> memory
>>> speed is not really an issue
>>
>> Yes. That's where I'd put a Z80 in the unlikely event that I wanted to
>> use
>> one these days.
>> Along with RAM, ROM, and anything else it needs.
>
> You'd be better served to use something like a 6502 core as
> the bus is cleaner and the core can run considerably faster.
>

One reason I liked the 6809 was that it had 16 bit registers like the first
CPU I ever used.
https://en.wikipedia.org/wiki/National_Semiconductor_SC/MP

On 4/24/2024 10:27 PM, boB wrote:
> On Wed, 24 Apr 2024 16:09:33 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
>
>> On 4/24/2024 1:42 PM, boB wrote:
>>> On Tue, 23 Apr 2024 18:44:24 -0700, Don Y
>>> <blockedofcourse@foo.invalid> wrote:
>>>
>>>> On 4/23/2024 2:40 PM, boB wrote:
>>>>> I miss playing with my old home built S-100 CP/M computer around 1980.
>>>>> Those were really the fun days of computing and digital logic
>>>>> circuits.
>>>>
>>>> Nowadays, the Zx80's appeal would be in controlling things.
>>>> There's little that you can't now do *better* that you would
>>>> previously have used a CP/M box for.
>>>>
>>>>> The other day after hearing the demise of the Z80, I ordered 2 of the
>>>>> 20 MHz Z80 40 pin devices. I did not even know there was a 20 MHz
>>>>> version. Not sure what I will ever do with them but who knows ?
>>>>> Maybe I'll just look at them.
>>>>
>>>> Again, in the context of "control" (i.e., deeply embedded),
>>>> you would likely also need similar speed grade peripherals
>>>> to do anything.
>>>
>>> Yes, I know. Address decoders are a dime a dozen (almost) and any
>>> other peripherals can either be made or, I may actually have the
>>> others laying around. I save old ICs and have since the 1970s.
>>
>> But those devices won't be of the same (fast) speed grade as the
>> processor. Remember, all "external (to the CPU) interactions"
>> happen at a rate defined by the system clock frequency. So, the
>> RETI daisy chain will have to operate "faster", the devices
>> will have to put data onto the bus -- and take it off -- quicker,
>> all rate generators (dividers) will have to be rejiggered for a
>> faster input clock, any software delay loops (explicit or implied)
>> will have to be rewired, etc.
>
> The interface isn't that complicated with parts that are available
> today to build something. OR I could just run the part at 4MHz.

Running a 20MHz part at 1980 speeds seems kinda silly...

Also, note that the Z80 peripherals weren't as trivial as,
e.g., generic devices (like a 6402 vs. a DART/SIO). They
were designed to understand the specific details of the Z80's
bus timing whereas generic devices didn't have such logic.

(For example, the roles of IEI & IEO and the monitoring of the
bus for the RETI opcode to "adjust" the interrupt priority
resolution logic).

>>>> I had a particular fondness for the '180 (and '7180!) as it
>>>> wasn't crippled by the tiny address space (64K memory + 64K I/O)
>>>> of the Z80. Over the years, I've come to realize that you usually
>>>> need more space for *code* than data!
>
> I am not THAT interested in using an obsolete part. Just wanted one. I
> may never even use it.

After a while, all of those "collectibles" just start to look like
dust collectors! :> But, they're still hard to part with...
(all of those white ceramic packages with gold foil traces on top!)

What time teaches is that most of the "significant projects" done
in ASM on these early processors are ORDERS of magnitude less
"complicated" when a modern HLL (and other programming tools) is
used.

E.g., I spent a few months building a LORAN-C autopilot (trivial
hardware) and suspect I could do the same thing in a *weekend*,
nowadays (I'd layout a PCB and have the board fabbed instead of
wire-wrapping it on perfboard, and building an appropriate power
supply; the main functionality would take less than a page of
code -- a bit more to add the display logic, etc.)

[Why write a floating point math package when I can just write a
few expressions in *infix* notation?!]