💾 Archived View for uscoffings.net › retro-computing › components › PC › dma.html captured on 2024-05-12 at 17:02:06.
⬅️ Previous capture (2022-06-03)
-=-=-=-=-=-=-
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<HTML>
<HEAD>
<META name="GENERATOR" content="Microsoft FrontPage 1.1">
<TITLE>DMA</TITLE>
</HEAD>
<BODY>
<P align=center>
<FONT size=4><STRONG>DIRECT MEMORY ACCESS (DMA)</STRONG></FONT>
<P>
DMA refers to the transfer of data without involving the µP. The following
DMA transfer combinations are possible:
<UL>
<LI>
Memory to memory
<LI>
Memory to peripheral
<LI>
Peripheral to memory
<LI>
Peripheral to peripheral
</UL>
<P>
The DMA approach is to "turn off" (i.e. tri-state and electrically disconnect
from the system busses) the µP and let a peripheral device (or memory
- another module or another block of the same module) communicate directly
with the memory (or another peripheral).
<P>
ADVANTAGE: Transfer rates approaching that of the memory can be achieved.
DMA latency is <= 6µsec.
<P>
DISADVANTAGE: A DMAC is needed, making the system complex and expensive.
<P>
DMA requests have priority over all other bus activities, including interrupts.
No interrupts will be recognized during a DMA cycle.
<P>
<HR>
<P align=center>
<FONT size=4><STRONG>WHY DMA ?</STRONG></FONT>
<P>
The instruction <CODE><STRONG>mov [2],[9]</STRONG></CODE> is illegal.
<P>
should be done in two steps:
<UL>
<LI>
<CODE><STRONG>mov bx,[9]</STRONG></CODE>
<LI>
<CODE><STRONG>mov [2],bx</STRONG></CODE>
</UL>
<P>
Thus it is not possible to transfer from one memory location to another without
involving the µP. The same applies to transfer between memory and
peripherals connected to I/O ports. e.g. cannot have <CODE><STRONG>out
dport,[6]</STRONG></CODE>.
<P>
should be done in two steps:
<UL>
<LI>
<CODE><STRONG>mov ax,[6]</STRONG></CODE>
<LI>
<CODE><STRONG>out dport,ax</STRONG></CODE>
</UL>
<P>
Similar comments apply to the <CODE><STRONG>in</STRONG></CODE> instruction.
<P>
<EM><STRONG>Thus the real cause of limited transfer rate is the µP itself.
It acts as an unnecessary "middleman".</STRONG></EM>
<P>
<HR>
<P align=center>
<FONT size=4><STRONG><A HREF="http://www.lums.edu.pk/~rafay/UG/CS353/FILES/definitions.html"#definitions>Some
Definitions</A></STRONG></FONT>
<P>
<HR>
<P align=center>
<FONT size=4><STRONG>THE DMA PROTOCOL UNDER MAXIMUM MODE</STRONG></FONT>
<UL>
<LI>
Under the maximum mode, the HOLD and HLDA lines become two bidirectional
request-grant-release lines labelled -RQ0/-GT0 and -RQ1/-GT1.
<LI>
This protocol was designed to transfer control of the CPU local bus between
the CPU and (upto) two alternate bus masters which reside totally on the
local bus and share the complete CPU bus interface including the address
latches, data transceivers, 8288 bus controller and 8289 multi-master bus
arbiter.
<LI>
If the alternate bus masters in the system do not reside directly on the
8086 local bus, system bus arbitration is required rather than local bus
arbitration. To satisfy the need for multi-master system bus arbitration
at each CPU's system interface, the 8289 bus arbiter should be used instead
of the -RQ/-GT protocol.
</UL>
<P>
<HR>
<P align=center>
<FONT size=4><STRONG>-RQ/-GT PRIORITY</STRONG></FONT>
<UL>
<LI>
Each -RG/-GT pin of the 8086 supports the full protocol for exchange of bus
control. Thus each can be used independently.
<LI>
-RQ/-GT0 has priority over -RQ/-GT1 for impending requests that have not
yet been granted. e.g., if a request is received on -RQ/-GT1 followed by
a request on -RQ/-GT0 prior to a grant on -RQ/-GT1, -RQ/-GT0 will gain priority
over -RQ/-GT1. However, if -RQ/-GT1 has already received a grant, a request
on -RQ/-GT0 must wait until a release pulse is received on -RQ/-GT1.
</UL>
<P>
<HR>
<P align=center>
<FONT size=4><STRONG>-RQ/-GT USAGE</STRONG></FONT>
<UL>
<LI>
The cycle begins with the alternate bus master (coprocessor) requesting the
system bus by pulling the associated -RQ/-GT line low (for TCLCL nanosecs
maximum); and, of course, satisfying the setup and hold times.
<LI>
The 8086 completes the current bus cycle, in the same way as it does in the
minimum mode, and responds by floating the address/data lines, the status
lines (-S0, -S1, -S2), the -RD and -LOCK control lines.
<LI>
This action does not disable the 8288 command outputs from driving the command
bus and does not disable the address latches from driving the address bus
because the 8288 contains internal pull-up resistors on the status lines
(-S0, -S1, -S2) to maintain the passive state (performing idle bus cycles)
while the 8086 outputs are tri-stated. Thus the 8288 is unable to initiate
any commands or activate the DEN signal. If the device issuing the request
does not use the 8288, it must disable the 8288 command outputs by disabling
the 8288 -AEN input. Also, the address latches not used by the requesting
device must be disabled.
<LI>
A low -GT pulse is then output by the 8086 on the same pin where the request
occured.
<LI>
After receiving the grant pulse, and waiting for the "float delay" of the
8086 (TCLAZ), the requesting device may drive the local bus. This precaution
prevents bus contention.
<LI>
To return control of the bus to the 8086, the alternate bus master relinquishes
bus control and issues a release pulse on the same -RQ/-GT line. The 8086
may drive the three status lines, -RD and -LOCK control lines three clock
cycles after detecting the release pulse and the AD bus TCHCLmin after the
status lines. The alternate bus master should be tri-stated off the local
bus and have other 8086 interface circuits (including the 8288 and address
latches) re-enabled within this time.
</UL>
<P>
<HR>
<P align=center>
<FONT size=4><STRONG>TYPES OF DMA</STRONG></FONT>
<P>
DMA cycles are of two types:
<UL>
<LI>
<EM>sequential: </EM>the DMAC fetches a byte (a read operation) and then
outputs it (a write operation); in the same way as the µP does. So the
only advantage in this case is that the µP is not involved.
<LI>
<EM>simultaneous:</EM> the read and write operations are performed at the
same time. Both control signals are active simultaneously and data does not
flow through the DMAC at all. Thus this is the fastest way to accomplish
a transfer.
</UL>
<P>
In both cases the data transfer is done completely in hardware without involving
the CPU and thus there is no associated software overhead.
<P>
<HR>
<P align=center>
<FONT size=4><STRONG>OPTIONS FOR THE DMAC</STRONG></FONT>
<UL>
<LI>
<EM>BYTE or SINGLE MODE: </EM>release the bus after transferring a byte of
data and request control again when needed. This lets the CPU perform other
jobs also.
<LI>
<EM>BURST or DEMAND MODE:</EM> release the bus when the peripheral's buffer
is full. request control again when buffer becomes available. This mode is
intended for peripherals that have high-speed data buffers (i.e. internal
memory) or for memory to memory transfers.
<LI>
<EM>CONTINUOUS or BLOCK MODE:</EM> retain control of the bus until the entire
block of data has been transferred.
</UL>
<P ALIGN=Center>
<HR>
<BIG><B><A HREF="io.html#notes">Some Notes</A></B></BIG>
<P ALIGN=right>
<EM>(N1, N2, N3, N6b, N6c, N6d, N6e, N8, N9)</EM>
</BODY></HTML>