Deutsch   English   Français   Italiano  
<v1v13f$13e7$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!feeds.phibee-telecom.net!news.mixmin.net!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: Mon, 13 May 2024 23:41:48 -0700
Organization: A noiseless patient Spider
Lines: 51
Message-ID: <v1v13f$13e7$1@dont-email.me>
References: <v07k2p$cki9$1@solani.org> <v09p38$1uqd3$2@dont-email.me>
 <nnd$3f228473$0ded6ae7@798bd83aa8febda0> <v0jhbi$h25f$2@dont-email.me>
 <nnd$3800eb5a$23b7e0b8@f1338d23f484ce62>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 14 May 2024 08:41:53 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="67b4a6a3c0650e3d5db0e7ba195c29a5";
	logging-data="36295"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19NRIwmBmRNb5y9fWxAZMg8"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:QYBEdLWdxID1vNqTjvyKCkpd8gM=
Content-Language: en-US
In-Reply-To: <nnd$3800eb5a$23b7e0b8@f1338d23f484ce62>
Bytes: 3581

On 5/13/2024 3:26 AM, albert@spenarnc.xs4all.nl wrote:
> In article <v0jhbi$h25f$2@dont-email.me>,
> Don Y  <blockedofcourse@foo.invalid> wrote:
>> On 4/27/2024 3:39 AM, albert@spenarnc.xs4all.nl wrote:
> <SNIP>
>>> 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).
> 
> I'm pretty sure that was the situation. The machine served at a
> clair voyance test system, and the program (assembler) fitted in
> 1 K Ram and the testresults were stored in the 16 (maybe 32 ram).
> The idea was that you couldn't discriminate clair voyance for
> paranormal communication, unless the result were checked by
> a computer and not shown to any one.

Did the machine synthesize some random number, phrase, etc. and
the test subject expected to "guess" it?  I.e., enter his guess
on a keypad and the machine "scored" it?

Or, did the machine show a random number, phrase, etc. to a
"sender" who was intended to concentrate on that with the
idea that the test subject could "read their thoughts"?
(verified by entering them on a keypad)

> I bought a DEC writer (5 by 7) for 2000 guilders to print the
> test results, and use a black and white television for the
> monitor. Those were the days.

Yes, increasing levels of integration have taken a lot of the
fun out of most designs.  I built a two-player "Breakout"
(video) game, in hardware, as an undergrad for one of my labs.
Nowadays, I'd spend a few hours writing a piece of code
that would do the same thing -- but, much less satisfyingly.

[with a hardware implementation, you were sorely pressured to
do a lot with very little; with a software (or VHDL) implementation,
it's just a few more lines of code...]

> [There we no indications for paranormal happening.
> The circuit to generate random targets was hardware and
> pretty solid.]