[Coco] DMA in (Nitr)OS-9 LII?

[Joel Ewy]

Actually, this gets back to my original question, which was not really  about the hardware so much as an operating system question, hence the  subject, which remains "DMA in (Nitr)OS-9 LII?" and not "DMA on the  CoCo3?"
  
  Assuming that we have a functioning DMA controller, on a daughterboard  mated up to the CPU, or integrated into an FPGA GIME replacement, is  there a sanctioned way for it to write into the device driver's buffer  memory?  Failing this, is there an obvious hack?
  
  Actually, it seems to me that if one cooked up a DMAC that was  integrated into the MMU, as in my second example above, then the  problem could be solved relatively easily, as the DMAC could have  address registers that span the entire physical address space, and the  timing could be coordinated with video and refresh functions.   (The DMAC itself could even be used for refresh.)
  
  But it's the first instance, where a DMAC like a 6844, with a 16-bit  address bus, is hooked up alongside the CPU, that I'm still curious  about.  My suspicion is that even if the timing could be made to  work out, you would have no way of guaranteeing that the device memory  was mapped in when the DMAC needed access to it.  Any thoughts,  NitrOS9 coders?

  JCE
  
Mike Pepe <lamune at doki-doki.net> wrote:  jdaggett at gate.net wrote:
> Joel
> 
> There is beside the internal clock generetor for the 6809 that the 6809E 
> does not have, that is circuit that allows the external DMA controller to  halt 
> the MPU for up to 16 Eclock cycles. Thus the DMA cycle works like this:
> 
> 16 cycles for DMA then one cycle for MPU followed by 16 cuycles for DMA. 
> 
> It keeps alternating t his for as long as needed I believe. There is no internal 
> cuircuit for the 6809E. To do DMA with the 6809E you are going to have to 
> do it by cycle stealing method. That is use the buss when the 6809E is not 
> using it. It will take a far more complex circuitry than with the 6809. YOu will 
> h ave to study ho wthe BA/BS lines function along with the AVMA, LIC, and 
> BUSY contrrol signal works. 
> 
> Again all this has to be done during the MPU cycle of the EClock. It is not 
> the cleanest or the fastest means of doing DMA but it is the only way with 
> the contraints of the Coco. 
> 
> james
> 

Actually, it's not that hard to do at least in theory. I was thinking 
about this long ago. If you multiplexed the DMA controller with the cpu 
on a daughterboard, it might actually work.

With the BA/BS signals and/or a circuit that looks for a read at $FFFF 
will indicate the cpu is not using the bus for that cycle. You could 
then switch over to the DMA for that cycle. Doing DMA in this way would 
not collide with the cpu, video, or refresh. the downside to this is 
that the DMA would appear to the hardware (MMU especially) as the cpu, 
and reads and writes would use the same translated memory map as the 
processor.

Maybe one of these days I'll build one. I think I have some 6844 DMAC 
chips in my junk box.


-- 
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco