Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site amdcad.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!amdcad!phil
From: phil@amdcad.UUCP (Phil Ngai)
Newsgroups: net.arch
Subject: Re: insuring command recovery delays, etc.
Message-ID: <10040@amdcad.UUCP>
Date: Thu, 27-Feb-86 20:50:27 EST
Article-I.D.: amdcad.10040
Posted: Thu Feb 27 20:50:27 1986
Date-Received: Sat, 1-Mar-86 02:39:54 EST
References: <1475@seismo.CSS.GOV> <218@intelca.UUCP> <18@gilbbs.UUCP> <20@gilbbs.UUCP>
Reply-To: phil@amdcad.UUCP (Phil Ngai)
Organization: AMD, Sunnyvale, California
Lines: 28

In article <20@gilbbs.UUCP> mc68020@gilbbs.UUCP (Tom Keller) writes:
> To put it bluntly, Ken, judging on the basis of products shipped, the
> architectural design team at INTEL have their heads firmly entrenched anally.

I think you're wrong. Tell me about the wonderful 68020's MMU, huh?

> I am not surprised to see such a flippant response to a serious problem from 
> an INTEL uP designer.  The fact is that an I/O chip that can't tell you it
> isn't ready is a *BOTCH*, pure and simple.

As a matter of fact, most chips don't tell you when they are ready.
When was the last time a RAM chip told you it was ready for CAS after
you sent RAS, or even when read data is valid?  That's what you have
hardware designers for. The hardware designer is supposed to arrange
that you don't get data from a RAM chip before it is ready.

With a peripheral chip like the 8530, if the hardware designer decides
to pass the responsibility on to the firmware writer, that's his
choice. But it's not unusual that the 8530 doesn't tell you it's not
ready for another command.

By the way, Intel did not design the 8530.
-- 
 The Hyundai is faster than speeding molasses!

 Phil Ngai +1 408 749 5720
 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil
 ARPA: amdcad!phil@decwrl.dec.com