Re: PCcard DMA (detailled!)

From: greg (
Date: 2001-04-11 03:14:24

dose anyone get the mag. nuts and volts?, it may help with some of this.
----- Original Message -----
From: <>
To: <>
Sent: Tuesday, April 10, 2001 7:41 PM
Subject: PCcard DMA (detailled!)

> On Tue, 10 Apr 2001 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
> implementation):
> 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
> 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
> 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
> 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
>  </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
> 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
> the 'bus'.  We release DACK, and IOR.  We again have control of the bus.
> this point, however, I'd check the DRQ line to see if DRQ is still
> 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
> space on the ISA bus controller.  This way, we can map DMA "space" into
> IO page, and do PDMA whenever we see it fit. ;)
> DMA protocol is very straightforward, and the ISA bus is quick enough,
> 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
> the idea of being able to do either rather handy, as we could end up with
> 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
> hide behind your 6522's =)
> -
> This message was sent through the cbm-hackers mailing list.
> To unsubscribe: echo unsubscribe | mail

This message was sent through the cbm-hackers mailing list.
To unsubscribe: echo unsubscribe | mail

Archive generated by hypermail 2.1.1.