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

[Steve Bjork]

As James point out, the color computer's Memory access uses two alternating 
mode of access (synchronous), with one state for  Video Processor and the 
other for the CPU.

But don't forget that the dynamic RAM refresh takes place during the Video 
Processor's side of the memory access.  (So you can forget about trying to 
use that part of the memory cycle for any true DMA transfer.)

This was the key to the color computer's overall high speed in memory 
access. Yes, I do mean HIGH SPEED.

At the time when the Color Computer 2 hit the market, there was a "Color" 
Computer from NEC that used 6847 Video Processor and the Z-80 CPU.  I was 
given the task to port Mega-Bug over to the NEC.  At first, it look to be 
an easy task.  After all, I've been writing programs for 8080 and Z-80 
longer than programs for the coco.  I soon learned how much somebody messed 
up the NEC and the computer's shared memory system.

In the NEC, there are two systems that fighting over access to the 
memory.  First there is the 6847 with it need to get memory on a regular 
and rigidly timed bases.  But the Z-80 memory access could happen almost 
any time because of the varying length (asynchronous) instruction cycle.

Because the Z-80 memory access does not synchronize like the 6809, it must 
wait till the Video Processor completed its current memory fetch before it 
get its turn.  This waiting got so bad that the over throughput of the Z-80 
was about half of the Color Computer's 6809.

The NEC "Color" computer was so slow that their version of Mega-Bug did not 
have the magnifying window!

The designers of the NEC computer must have known how slow the computer 
because of the Video Processor access issues.  Why else would they include 
an option to speed up the computer by turning off the video system?

Now you can see why I say that the color computer truly has a high speed 
memory system.

Steve 6809er Bjork



At 03:25 PM 7/21/2006 -0700, you 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