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

jdaggett at gate.net jdaggett at gate.net
Sat Jul 22 14:05:05 EDT 2006


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

On 21 Jul 2006 at 15:25, Joel Ewy wrote:

> So probably there isn't much time to get in there even if you had a  clear place to put your data.  But a dedicated I/O board with disk  and network controllers where a DMAC fills up an SRAM and interrupts  the CPU when the buffer is full might work.  Then the CPU can grab  data out of the RAM at its leisure. Hmm.
>   
>   JCE
> 
> jdaggett at gate.net wrote:  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
> > 
> 
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 
> 
> -- 
> 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
> 





More information about the Coco mailing list