Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: sci.electronics.design
Subject: Re: Zilog stopping Z80 production
Date: Wed, 24 Apr 2024 16:26:36 -0700
Organization: A noiseless patient Spider
Lines: 53
Message-ID: <v0c4fm$2jf7f$2@dont-email.me>
References: <v07k2p$cki9$1@solani.org>
 <v09ih8$bfo$1@nnrp.usenet.blueworldhosting.com>
 <v09p38$1uqd3$2@dont-email.me> <v0bm50$2g4or$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 25 Apr 2024 01:26:47 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e2801f264f3aeaadf3cb6c507a341c09";
	logging-data="2735343"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+tnIiAdFQ+kfnyjofZT3u1"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:HVVntoBtnlLY9wArRYudBptNQkM=
In-Reply-To: <v0bm50$2g4or$2@dont-email.me>
Content-Language: en-US
Bytes: 3838

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?