Path: ...!weretis.net!feeder9.news.weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Don Y Newsgroups: sci.electronics.design Subject: Re: Zilog stopping Z80 production Date: Sat, 27 Apr 2024 11:49:08 -0700 Organization: A noiseless patient Spider Lines: 80 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 27 Apr 2024 20:49:23 +0200 (CEST) Injection-Info: dont-email.me; posting-host="9defdad57adf729292e9d08dfe27b1dd"; logging-data="559279"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/p661Fd12kGN75va1mur6C" User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Cancel-Lock: sha1:1bzwCGDKq98LQED2rmH38Zb6hGg= Content-Language: en-US In-Reply-To: Bytes: 5003 On 4/27/2024 3:39 AM, albert@spenarnc.xs4all.nl wrote: > In article , > 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) >> >> 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.).