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:35:17 -0700
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <v0c4vu$2jf7f$3@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>
 <b0si2jp3q4tcurbp5p3tj36b4f2vd0rj3l@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 25 Apr 2024 01:35:28 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e2801f264f3aeaadf3cb6c507a341c09";
	logging-data="2735343"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+nil/2ct24EuKGiElTy3B2"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:tIB1C3b398Xy1X8o3AIK2u3wGek=
In-Reply-To: <b0si2jp3q4tcurbp5p3tj36b4f2vd0rj3l@4ax.com>
Content-Language: en-US
Bytes: 2824

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).