Re: AP-67 82C37 Application Note


Hans "HT-Lab" wrote:

Does anybody have, or know were I can find a copy of the AP-67
application note . I googled for a few hours but failed to find it.
This appsnote describes how to interface an 82C37 DMA controller to
an 8086.
IIRC I once saw it in the appendix of one of the Intel books (~1979).
This books will not be available anymore, but Intel may have 'AN-67'
(they called it "AN-.." rather than 'AP') in their archive.

Thanks, I will try to find the 1979 Intel databook (anybody has a
copy?).

I may still have all those old books somewhere in my cellar ...
please don't ask me to clean up the mess down there yet :)

I am particular interested in how to add a page register for
the memory-to-memory transfer option,

I'd add one (three for 32 bit) HC374 or similar to it.

What I am after is how to select the latches. During normal IO-2-
memory transfer I can use the DACK signals as latch enables, however,
for memory-2-memory DACK0/1 are not asserted. The only indication that
a memory-2-memory transfer is in progress is that AEN is asserted but
none of the DACK signals. I can use this to select 1 latch/page
register but I need one for both the source and destination.

I see, of course it would need two page latches for mem<->mem transfer.
was it AEN+IORD and AEN+IOWR to select the associated page latch ?

I suspect that you can only transfer a blocks of memory within a
single 64KByte/128KWord page.

I should be possible to access the whole memory with it, the
transfer-size is limited by 8237 capabilities and by page ranges
even several 8237 could be cascaded. I once saw an x286 accompanied
by an Intel-chip (82380) with 32-bit capable 'legacy' DMA, it used
four ports per channel, on ill distributed I/O-addresses (as usual).

I think there were a problem with mem<->mem on cascaded 8237's so
this option disappeared in later chipsets. I don't have the 8237
data*** in front of me yet, but I think to remember that some
output pin combinations (DRQ/IOR/IOW/AEN ?) indicated a memory or
I/O access for both the source and the target.

OTOH, CPUs are usually much faster than the RAM, so DMA-cycles may
not be any faster than REP:MOVS and the CPU cannot do very much
during it anyway, so the question is: why ?

__
wolfgang


.

Quantcast