From welland Mon Dec  7 16:51:17 1987
Date: Mon, 7 Dec 87 16:51:14 est
From: welland (Bob Welland)
To: boyer, daveh, gerard, porter
Subject: IO space problem
Status: R










      Using The IO Space In Time Critical Applications


                     Robert V. Welland



                          _A_B_S_T_R_A_C_T

          This  document  is   directed   at   hardware
     designers who are intending to use the IO space in
     a time critical way. An example of such an  appli-
     cation would be a hard disk controller with a disk
     buffer in the IO space.



_1.  _P_r_e_f_a_c_e

     This engineering update is  relevant  to  any  hardware
developer  who  is  intending  to  use the IO space (E90000-
EFFFFF) in a real-time manner. For example if you are  going
to  put  a disk buffer into this space and want to read from
it quickly, then this document concerns you.


_2.  _I_n_t_r_o_d_u_c_t_i_o_n

     In certain display modes the A2000 may not  give  reli-
able real-time response to devices in the auto-config and IO
space (E80000-EFFFFF) when the designer relies on the tradi-
tional  DTACK  mechanisms  (i.e.  either  generating XRDY or
allowing the system to generate  DTACK  automatically).   In
order  for  the  designer to get reliable real-time response
s/he will have to generate DTACK onboard.  The designer will
have  to  use OVR in order to gain control of the DTACK line
and then assert DTACK.

_3.  _G_e_n_e_r_a_t_i_n_g _D_T_A_C_K

     Their are two things that the designer must do to  gen-
erate DTACK:

          1. Generate OVR (override).

          2. Generate DTACK.

     To make this discussion simpler  we  will  assume  that
there  is  a  board  select  signal  (AM) that is an address
decode of the space allocated during auto-config.  The  fol-
lowing   PAL   equations  (in  CUPL  form)  demonstrate  the



                      December 7, 1987





                           - 2 -


generation of DTACK.

/*  Inputs  */

/* Address strobe from the 68000 */
PIN     xx      !AS;

/* Board address match */
PIN     xx      !AM;

/* DTACK enable signal from board */
PIN     xx      !DTACKEN;

/*  Outputs  */

PIN     xx      !DTACK;  /* DTACK */
PIN     xx      !OVR;    /* OVR - override */

/*  Equations  */

/* Assert OVR whenever our board is selected */
OVR     =       AM & AS;

/* Enable OVR whenever our board is selected */
OVR.oe  =       AM & AS;

/* Assert DTACK whenever our board is selected
 * and DTACKEN is asserted
 */
DTACK   =       AM & AS & DTACKEN;

/* Enable DTACK whenever our board is selected */
DTACK.oe=       AM & AS;


     Note that DTACKEN must be asserted at the  moment  when
XRDY would usually be deasserted. If you want one wait state
DTACK would be asserted after the falling edge  of  S4  (the
edge  DTACK  gets  sampled  on).  Remember that the 68000 is
asynchronous so it will automatically sync DTACK internally.
This can make DTACK generation much easier.

_4.  _A _F_e_w _N_o_t_e_s _O_n _O_V_R

     Commodore is generally cautious about the use  of  OVR.
The  reason  for  this  is  that it has been mis-used in the
past. I would like to clarify why we are cautious.

_4._1.  _U_n_c_o_n_t_e_s_t_e_d _A_c_c_e_s_s_e_s

     OVR tristates the DTACK signal. In the above usage that
is  ALL  it will do.  The reason for this is that any access
to our space is uncontested.  Ownership of such a space  has
been  given  to  one  device during auto-configuration. This



                      December 7, 1987





                           - 3 -


means that all other devices on the bus should  be  ignoring
this  cycle  (i.e. they will not try to respond). In fact if
they do, a collision will occur and the spec says that  BOTH
devices  are  supposed  to get off the bus and generate buss
error (BERR). This should never happen however.

_4._2.  _C_o_n_t_e_s_t_e_d _A_c_c_e_s_s_e_s

     Generating OVR outside of the expansion, IO,  or  auto-
config  space  (200000-9FFFFF,  E90000-EFFFFF,  and  E80000-
E8FFFF respectively) can lead to disaster. This  is  because
you  are  contending  with some other device for this cycle.
The results will be unpredictable.  For example if you  gen-
erate  OVR  in  the area of FC0000 you will be in contention
with the ROM.  What we are getting at is the following law:


     OVR does not give you exclusive access to the bus

A corrillary to this law would be:


     Any time you come in contention with another device for
     the bus, reguardless of the state of OVR, unpredictable
     things will occur.


_5.  _S_u_m_m_a_r_y

     If you are going to use IO space  in  a  time  critical
manner,  use OVR and DTACK instead of XRDY. Never try to use
OVR to gain control of another devices address space.

























                      December 7, 1987