PCcard DMA (detailled!)

Date: 2001-04-11 02:41:27

On Tue, 10 Apr 2001 jbevren@starbase.globalpc.net wrote:

> Okay.  I can see some serious bottleneck problems, and will discuss
> alternatives this evening.

It's this evening now ;)

In the process of pondering how to hook the ISA bus up to the c64, I
imagined the following setup:  (get a pen and paper, there's a fair amount
of detail)

There would be a control unit at an as-yet undefined location,
preferrably one located in one of the I/O pages.  This unit has the
following functions (some optional, for later post-proof-of-concept

The addressing spaces (memory OR io) can be mapped in 256 bytes at a time
into one of the I/O pages.  My design assumes its the first non-cpu device
on the cartport chain, so enabling this map will override whatever page you
map it into.  So, to address io $340, you select I/O, page 3, and access
$de40. ;)  This triggers the 16bit read-latch circuit, which yanks RDY on
the CPU, and proceeds to immediately grab the data from the ISA bus.  Once
fetched (often <1cycle), RDY is released, and the c64 can have its data. 
This latch is only enabled when doing a 16bit read (selected in the control
circuit), so that 8bit I/O devices, or other deevices expecting an 8bit
read/write dont get too much data ;)

For DMA'ing, I followed the procedure set in the zilog documentation (and
used on the aforementioned Spartan interface for the amiga - plz check this
out, its very informative and helpful):  

(quoting): Zilog Z5380 SCSI controller - Doc PS97SCC0100, pg 15

PSeudo DMA mode
 <blahblah about making SCSI really slow by PIO'ing it like the CMD hd does>
 </SLAM> ;)

Often, external decoding logic is necessary to generate the z5380 /CS
signal.  This same logic may be used to generate /DACK at no extra cost and
provide an increased performance in programmed I/O transfers.

End quote.

On page 26, there's a nice diagram that shows the DMA read timing diagram,
which isnt the official one for ISA, but works perfectly with the 8237a ;)

It shows the folowing algorythm (pseudocode follows):

DRQ is asserted
We assert IOR, then DACK.  At this point the device posts its data bits onto
the 'bus'.  We release DACK, and IOR.  We again have control of the bus.  At
this point, however, I'd check the DRQ line to see if DRQ is still asserted. 
If it is, a block DMA is in progress, and more bytes should be read.

DACK and IOR can be or-wired, and decoded through a special virtual address
space on the ISA bus controller.  This way, we can map DMA "space" into the
IO page, and do PDMA whenever we see it fit. ;)

DMA protocol is very straightforward, and the ISA bus is quick enough, that
we could build some sort of DMA controller to grab data from ram after
DMA'ing to it via an 8237, or simply DMA'ing it directly to the c64.  I find
the idea of being able to do either rather handy, as we could end up with a
veritable 16M reu with a highspeed I/O bus attached to its ram ;)

Let this soak in, and ask me scads of questions. ;) Try not to ignore it and
hide behind your 6522's =)

This message was sent through the cbm-hackers mailing list.
To unsubscribe: echo unsubscribe | mail cbm-hackers-request@dot.tml.hut.fi.

Archive generated by hypermail 2.1.1.