• Zilog stopping Z80 production

    From Jan Panteltje@21:1/5 to All on Tue Apr 23 06:22:16 2024
    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/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Purgert@21:1/5 to Jan Panteltje on Tue Apr 23 11:23:32 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to dan@djph.net on Tue Apr 23 12:31:42 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Heitzer@21:1/5 to Jan Panteltje on Tue Apr 23 13:09:43 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don@21:1/5 to Peter Heitzer on Tue Apr 23 14:51:31 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Peter Heitzer on Tue Apr 23 13:40:13 2024
    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!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From boB@21:1/5 to blockedofcourse@foo.invalid on Tue Apr 23 14:40:34 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Edward Rawde@21:1/5 to Jan Panteltje on Tue Apr 23 20:08:06 2024
    "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/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Edward Rawde on Tue Apr 23 19:00:00 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to boB on Tue Apr 23 18:44:24 2024
    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!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to peter.heitzer@rz.uni-regensburg.de on Wed Apr 24 04:55:27 2024
    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 :-)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt@21:1/5 to Don Y on Wed Apr 24 21:22:07 2024
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From boB@21:1/5 to blockedofcourse@foo.invalid on Wed Apr 24 13:42:21 2024
    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




    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From boB@21:1/5 to All on Wed Apr 24 13:48:39 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt@21:1/5 to boB on Thu Apr 25 00:39:12 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to boB on Wed Apr 24 16:09:33 2024
    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 :> )

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to boB on Wed Apr 24 16:35:17 2024
    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).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Lasse Langwadt on Wed Apr 24 16:26:36 2024
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Lasse Langwadt on Wed Apr 24 17:57:40 2024
    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...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Edward Rawde@21:1/5 to Lasse Langwadt on Wed Apr 24 22:03:40 2024
    "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.



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Edward Rawde on Wed Apr 24 21:30:34 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From boB@21:1/5 to blockedofcourse@foo.invalid on Wed Apr 24 22:27:08 2024
    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 :> )

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Edward Rawde@21:1/5 to Don Y on Thu Apr 25 02:34:54 2024
    "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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to boB on Wed Apr 24 23:44:14 2024
    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?!]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Edward Rawde on Thu Apr 25 00:02:33 2024
    On 4/24/2024 11:34 PM, Edward Rawde wrote:
    "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

    My first processor was a Nova 1200. My first *embedded* processor
    was the i4004.

    The 4004 was about 2000 transistors; the Z80 closer to 8000. (The
    6502 splits the difference at about 4000). Your attitude/expectations
    as to what you can do with a given platform vary directly with the
    capabilities that platform makes available.

    E.g., the i4004 product required "factory initialization constants"
    in order to be operated. Moving to the i8085 allowed us to replace
    the in-house DEC mainframe's functionality with runtime code *in*
    the product. In practical terms not much of a performance improvement
    but a big psychological advantage (no need to rely on a service provided
    by the factory to *use* the equipment! What a novel concept -- and one
    that is quickly becoming obsolete! :< )

    The '09 (particularly the '09E) was pretty fast and easy to interface
    with. The software folks were always begging for a 2MHz '09 system
    doing video games (but, memory costs increase considerably in those days!)

    When vendors would pitch hardware to us, they would always cite
    "benchmarks". All of which were synthetic workloads. They'd be
    upset when we would normalize their results for "constant
    recurring dollars" -- if I have to specify more expensive components
    to get that increase in performance, then my product cost increases
    and I have to determine what the impact on sales might be!

    [It's amazing how good you can get at normalizing performance
    specs when you do it pretty regularly -- new processors were
    continuously being released, "back then". Sadly, there is
    comparatively little variety, nowadays.]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From albert@spenarnc.xs4all.nl@21:1/5 to blockedofcourse@foo.invalid on Sat Apr 27 12:39:30 2024
    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.).

    Groetjes Albert



    --
    Don't praise the day before the evening. One swallow doesn't make spring.
    You must not say "hey" before you have crossed the bridge. Don't sell the
    hide of the bear until you shot it. Better one bird in the hand than ten in
    the air. First gain is a cat purring. - the Wise from Antrim -

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gerhard Hoffmann@21:1/5 to All on Sat Apr 27 13:57:05 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to dk4xp@arcor.de on Sat Apr 27 14:32:57 2024
    On a sunny day (Sat, 27 Apr 2024 13:57:05 +0200) it happened Gerhard Hoffmann <dk4xp@arcor.de> wrote in <v0ip6h$1tn2$1@solani.org>:

    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

    I used 5 1/4 inch floppies in Kaypro2 format
    added a 256 kB RAM disk addressed by the Z80 I/O instuctions.
    Added a 'copy floppy to ramdisk' command, and could run from there.
    No seek and no r/w times times.
    https://panteltje.nl/panteltje/z80/system14/diagrams/index.html
    scroll down to
    Ramdisk card:
    diagram part 1
    diagram part 2
    component layout
    timing waveforms
    Wrote my own CP/M clone.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to albert@spenarnc.xs4all.nl on Sat Apr 27 11:49:08 2024
    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.).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)