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

[jdaggett at gate.net]

Joel

You h ave to be very careful with DMA and the Coco. They use already a 
form of DMA called IDMA. That is Interleaved DMA. This allows the full 
memory map to be seen by both the processor and the video. When the E 
Clock is low is when the GIME chip or the 6847 chip gets data from video 
ram. When the E clock is high the 6809 reads or writes to ram. Coordinating 
ram access via a DMA chip has to take this under consideration.

james

On 21 Jul 2006 at 7:56, Joel Ewy wrote:

> My comprehension is admittedly feeble.  DMA under LI seems  straightforward.  Assuming you have appropriate hardware, you set  up the addresses in the DMA controller, and it does its job.
>   
>   In LII though, the device driver's buffers might be mapped out when the  DMA controller decides to write to memory, no?  I know that the  page containing the I/O addresses is always mapped in.  Is there  any RAM in that block?  Is DMA impossible in LII (with the  exception of block transfer instructions in 6309s, etc) short of very  complex hardware schemes, such as using a DMAC that can write directly  to memory blocks without respect to their being mapped into the CPU's  address space?
>   
>   I suppose one could build a device that integrates a DMAC, some I/O  devices that could benefit from DMA (disk controllers, and maybe  ethernet come to mind), and some SRAM.  The DMAC would fill up the  SRAM, then interrupt the CPU when it is full.  I'm not sure how  much benefit this would be, but it would doubtless reduce interrupt  load on the CPU, and allow it to get a lot done while I/O was going  on.  Disto's Super Controller II works something like this.
>   
>   JCE
>   
>   
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 
> 
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.10.3/394 - Release Date: 7/20/2006
>