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.
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...
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>:The most difficult part is to put all into a 40 pin 300 mil package as
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 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 :-)The most difficult part is to put all into a 40 pin 300 mil package as
https://opencores.org/projects/a-z80
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
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
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!
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/
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.
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.
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 :-)The most difficult part is to put all into a 40 pin 300 mil package as
https://opencores.org/projects/a-z80
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
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)
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/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 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.
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 !
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.
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 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/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
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 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 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.
"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/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.
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.
Am 27.04.24 um 12:39 schrieb albert@spenarnc.xs4all.nl:
Motorola was much better in this respect. Peripherals are accessed
by handshake. So you could put a longer delay iff the peripherals
are slow.
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.
The other way around. The RAM cycle time was too slow for the
Z80 because of the DRAM refresh cycle after the instruction fetch.
And there was a /wait input on pin 24 if your bus logic was
unable to keep up with the Z80. Looks like handshake for me.
My first 64K*1 DRAMs did cost DM 64,00 each - which was quite a
sensation (NEC or Hitachi). And of course, my system got
the the first usable 8" DSDD floppy drives and ran CP/M.
I'm pretty sure that the instructions were in DRAM.
There was no ROM after booting at all.
I did the CP/M port with a friend. It later turned out that
the Altos computer was near identical, just patching the
I/O addresses would have been enough.
Later I even got a 1MB RAM floppy, powered by 8086.
(really to do a paid CP/M-86 port :-)
regards, Gerhard
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.
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.
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.).
On 4/27/2024 3:39 AM, albert@spenarnc.xs4all.nl wrote:<SNIP>
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 internalMaybe the restriction was particular for this design.
"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.).
In article <v0jhbi$h25f$2@dont-email.me>,
Don Y <blockedofcourse@foo.invalid> wrote:
On 4/27/2024 3:39 AM, albert@spenarnc.xs4all.nl wrote:<SNIP>
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).
I'm pretty sure that was the situation. The machine served at a
clair voyance test system, and the program (assembler) fitted in
1 K Ram and the testresults were stored in the 16 (maybe 32 ram).
The idea was that you couldn't discriminate clair voyance for
paranormal communication, unless the result were checked by
a computer and not shown to any one.
I bought a DEC writer (5 by 7) for 2000 guilders to print the
test results, and use a black and white television for the
monitor. Those were the days.
[There we no indications for paranormal happening.
The circuit to generate random targets was hardware and
pretty solid.]
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 418 |
| Nodes: | 16 (1 / 15) |
| Uptime: | 02:12:02 |
| Calls: | 8,786 |
| Calls today: | 13 |
| Files: | 13,296 |
| Messages: | 5,965,491 |