dose anyone get the mag. nuts and volts?, it may help with some of this. greg ----- Original Message ----- From: <jbevren@starbase.globalpc.net> To: <cbm-hackers@dot.tml.hut.fi> Sent: Tuesday, April 10, 2001 7:41 PM Subject: PCcard DMA (detailled!) > > > 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 > 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 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. > - 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.