Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!sri-unix!ctnews!pyramid!uccba!hal!ncoast!crds
From: crds@ncoast.UUCP (Who Am I)
Newsgroups: comp.sys.m68k
Subject: Re: DTACK*
Message-ID: <4904@ncoast.UUCP>
Date: Sun, 18-Oct-87 23:16:05 EDT
Article-I.D.: ncoast.4904
Posted: Sun Oct 18 23:16:05 1987
Date-Received: Tue, 20-Oct-87 23:44:48 EDT
References: <4215@pyr.gatech.EDU>
Reply-To: crds@ncoast.UUCP (Glenn A. Emelko)
Distribution: comp
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 54
Summary: I believe your friend is correct, assuming... (hehehe)

Jim,

According to what I understand on the 68000, as well as what I see in my data
books, your friend is essentially correct, assuming some things.... Although I
would not recommend that you assume these things!  Let me explain...

First of all, /DTACK is a level sensitive input.  The reason why your single
stepper worked is because you only asserted /DTACK long enough for the 68000
to execute a sngle instruction, and then removed it again.  When /DTACK was
true (low), the processor started it's cycle, and completed it, then sensing
that /DTACK was gone again.

Quoted from my data manual: "... The /DTACK signal, like other control
signals, is internally synchronized" (which means buffered by a D type flip-
flop in my book) "to allow for valid operation in an asynchronous system.  If
the required setup time (#47) is met during S4, /DTACK will be recognized
during S5 and S6, and data will be captured during S6.  The data must meet
the required setup time (#27)."  Now, #47 in my book is t[ASI], or the
Asynchronus input setup time, and is a minimum of 20ns for the L8 and faster
parts.  All that this means is that the Asynchronous inputs, specifically
/BGACK, /IPL0-/IPL2, and /VPA are STABLE 20ns before the falling edge of S4
when /DTACK is found to be low -- it implies NOTHING about when /DTACK went
low!  In other words, if you are going to hold /DTACK low, you must be 100%
sure that the other Asynchronous inputs are stable 20ns before the falling
edge of S4 (otherwise you will violate t[ASI]).  As well, the DATA must be
stable (per #27, t[DICL] on L8) 15 ns before the falling edge of S6.  There
is more, though....

And I quote: "If an asynchronous input does not meet the required setup time,
it is possible that it may not be recognized during that cycle.  Because of
this, asynchronous systems must not allow /DTACK to precede data by more than
parameter #31."  Well, there we go with the previous assumption -- if we DO
meet the required asynchronous setup times, then we CAN allow /DTACK to
precede data by more than #31 (which, by the way, is 90ns on a L8, and 50ns
on a L12).  I support this with another quote.....

"Asserting /DTACK (or /BERR) on the rising edge of a clock (such as S4) after
the assertion of address strobe will allow a MC68000 system to run at its
maximum bus rate." And here is the IMPORTANT clincher: "If setup times #27
and #47 are guarenteed, #31 may be ignored." As I just said, if you are 100%
sure that you can guarentee that the asynchronous inputs are stable before
the falling edge of S4 and the data is stable before the falling edge of S6,
then /DTACK can precede the data by ANY amount, or in fact, be tied directly
to ground, and the MC68000 system WILL run at its maximum bus rate.

Oh yes, for those who notice that time is measured to /DTACK going high in
their data sheets, I think you will find that it is simply showing the
MINIMUM time that /DTACK must remain low PRIOR to it returning to a high,
I find no evidence (in theory or operation) which says that /DTACK "must"
return high.

Glenn A. Emelko

"When all else fails, read the book"