Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!oliveb!amiga!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.sys.amiga
Subject: Re: DMA controllers and 32bit RAM
Message-ID: <7162@cbmvax.UUCP>
Date: 28 Jun 89 19:19:53 GMT
References: <311@amgraf.UUCP>
Organization: Commodore Technology, West Chester, PA
Lines: 76

in article <311@amgraf.UUCP>, huver@amgraf.UUCP (Huver) says:
> Summary: No DMA for LUCAS

> I dont' know how the DMA controller in question works, but a "fully
> functional" Amiga 1000 DMA controller hanging off the expansion connector
> must look for XRDY or *DTACK signals as memory response -- from expansion
> and CHIP memory, respectively.

A DMA controller should only look at DTACK*.  XRDY is used by a slave device
to delay the automatic DTACK*, OVR* can be used by a slave to remove the
automatic DTACK* and let it terminate the cycle, but the bottom line is that
it's the slave's responsibility to see that DTACK* is asserted at the 
correct time, the master's responsible to sample DTACK* appropriately (as
well as the valid data 1 cycle after DTACK*).

> None of these signals are asserted by LUCAS.  XRDY is only on the A1000
> expansion connector, not available inside the machine.  And LUCAS uses
> *DTACK from the 68000 socket as an input signal, not an output.

At the very least, an "plugs in the 68000 socket" accelerator would have to
use the automatic DTACK* for it's memory cycles to support DMA, since it
doesn't have access to either OVR* or XRDY to modify that DTACK.  This could
be done on an A2000, and I suspect an A1000 (not 100% sure), but it might
make the memory board design more complex.  When the A2620/30 32 bit memory
acts like a 16 bit slave device, it's pulling OVR* and generating it's own
DTACK*.

> More, Brad had said, in his FRANCES announcement mailing, that he did NOT
> design the memory for 16-bit DMA support (FRANCES is designed to be a fixed
> 32-bit prot).  So all theories aside, no DMA is possible for the 32-bit RAM.

As I suspected.

> Suppose we redesign LUCAS for this.  [Stuff Deleted]  But wait..
> LUCAS interfaces with A1000 via the 68000 socket so it appears as a 68K to
> Amiga.  We can't assert *DTACK because no 68000 ever asserts *DTACK.

If you could assert OVR* with an extra wire or something, I think you can
drive DTACK* out of the 68000 socket.  Like I said, it'll definitely work
that way on an A2000, but I'm not 100% sure how DTACK* is wired on the A1000.

> The only way is negate *DTACK and hook it direcctly to XRDY ...

No, the other way would be to sync your memory cycles with the default DTACK*.
Basically, that makes the memory completely synchronous, which means you'd
always have to hide refresh, since you can't possibly wait for a cycle or two
if you get caught refreshing during an intended memory cycle.  It would be much
more difficult to do things this way, though I think it could be done.

> With 16 MHz LUCAS, a driver code sitting in 32-bit memory doing programmed
> I/O can run as fast as DMA -- once you step off LUCAS the speed drops to
> max 7 MHz trasnfer.  Nothing can help.

IF you buffer things.  16 bit DMA would still go faster than a 32 bit CPU 
reading an 8 bit SCSI chip or something, but if you get the SCSI section to
buffer up 4 bytes and read the thing 32 bits at a time (or better, buffer up
a whole block and read with the CPU a block at a time, like GVP's controller),
you could go faster than 16 bit DMA.

> The best answer is a 32-bit capable DMA for LUCAS (same is true for the
> A2620 in an Amiga 2000).

Unless you're counting on using existing DMA hardware, as we were in concert
with the A2620/30.

> ------
> Asking "Why can't I run UNIX on my Amiga?!" is like asking "Why can't I put
> wife and four kids in my Porche?!"

Great quote!

> -huver ...!uunet!amgraf!huver
-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
           Be careful what you wish for -- you just might get it