Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.10 $; site techsup
Path: utzoo!watmath!clyde!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!convex!techsup!mikey
From: mikey@techsup
Newsgroups: net.ham-radio.packet
Subject: Re: [Ralph.Hyre@IUS2.CS.CMU.EDU:]
Message-ID: <-56768541@techsup>
Date: Sat, 18-Jan-86 14:28:00 EST
Article-I.D.: techsup.-56768541
Posted: Sat Jan 18 14:28:00 1986
Date-Received: Wed, 22-Jan-86 05:42:30 EST
References: <926@mit-eddie.UUCP>
Lines: 22
Nf-ID: #R:mit-eddie.UUCP:926:techsup:-56768541:000:1115
Nf-From: techsup!mikey    Jan 18 13:28:00 1986




The setteling time on the 8530 is a certain number of t states +200nsec.
It depends on your clock as to what the setteling time ends up being.
It is actually called valid access recovery time or something like that.
Where it can really burn you is if you use DMA on the 8530, you must make
sure that DMA on read transfers are held up by the setteling time after a
normal access.  On DMA writes to the chip, you will probably have to 
generate waits.  If you don't use DMA, everything else can be handeled in
software.  Just make sure that any access to the chip isn't at the very
front or tail end of an ISR.  Usually, stack saves and restores are 
enough to take cake of this, but remember, an interupt can occur while you
are doing another access, so pad the ISR accordingly. 

Finally, I believe it is the secondary DMA pin on the chip has different
timing characteristics than the primary pin.  It has something to do with
the fact that it is really a status pin for the holding register and it's
status may lag behind what is really happening by a few hundred nsec.

mikey  N1DVJ
trsvax!techsup!bbimg!mikey