Path: ...!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: Wed, 24 Apr 2024 16:26:36 -0700 Organization: A noiseless patient Spider Lines: 53 Message-ID: References: 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: 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?