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.
Archive generated by hypermail 2.1.1.