(c)  Copyright 1989-1999 Amiga, Inc.   All rights reserved.
The information contained herein is subject to change without notice, and 
is provided "as is" without warranty of any kind, either expressed or implied.  
The entire risk as to the use of this information is assumed by the user.


               
	   Using the IO Space In Time Critical Applications

                           
			by Robert V. Welland


Preface

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 application would be a hard disk controller with a disk buffer
in the IO space.  This engineering update is relevent 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.  

Introduction

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

Generating DTACK

Their are two things the designer must do to generate 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 following PAL equations (in
CUPL form) demonstrate the generation of DTACK.

/* Inputs */

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

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

/* DTRACK 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 the 68000 is asynchronous so it
will automatically sync DTACK internally.  This can make DTACK
generation much easier.

A Few Notes On OVR

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.

Uncontested Accesses

OVR tri-states 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 aspace has been given to one
device during auto-configuration.  This 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 bus error (BERR).  This should never happen
however.  

Contested Accesses

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 generate 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 corollary to this law would be:

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


Summary

If you are going to use IO space in a time critical manner, use
OVR and DTACK instead of XRYD.  Never try to use OVR to gain