This page is made after many years of experience with Atari ST computers, making, designing diverse adapters for it, writing hard disk driver/partitioner SW .
Unfortunately, Atari official DOCs are not up to level in this case too.  And other sources contain some errors, I found some in Atari ProfiBuch from 1987 too.
This is not complete ACSI_DMA documentation, and no intention to make such in 2021 end. I will focus only on some errors, not enough detailed descriptions in DOCs available in years when Atari ST(E) was used a lot (like 1985-1992), and most of them is now accessible online. And there are lot of pages by diverse people, which usually just copied other sources, and sometimes added own errors, bad explanations :-(

Atari DOCs and other ones state max possible transfer speed of ACSI port to 1 MB/sec, or some to 10 Mbit/ses (1.25 MB/sec).  Later is in Atari ST ProfiBuch 1987 edition (what I bought together with my first ST, and was very useful for programming, diverse HW projects).  
However, I saw diverse speed tests in years 2005-2009, which claim about 1.6 MB/sec with some ICD brand ACSI-SCSI adapters . So, someone must be wrong.  I decided to make myself test about that max speed, and had diverse Atari machines at hand.  Made some test circuit with GAL for DMA port, and analyzed DMA handshaking with logic probe.
And yes, it appeared that max speed is actually 2 MB/sec in peak.  Or that 1 byte transfer on 8 bit ACSI port takes 4 cycles of DMA chip (clocked with 8 MHz) . Of course, it may happen only during pure sector data transfers (length is limited) and with very fast logic and response from target.
Then I decided to go further, and try it with real storage device - something capable for 8-bit DMA handshake transfers.
And it is called Sandisk Compact Flash card. In 2009 I had only 1 - 2 GB Sandisk Ultra II. And it worked. With real transfer speed about 1900 KB/sec !  With all Ataris, including TT .
And that led me to design ACSI-CF adapter.  I used some solutions which I created by cartrigdge port IDE adapter (CATA), what works in PIO mode. With ACSI port of ST DMA is only way to achieve high transfer speeds. Single byte transfers are possible, but then max speed is about 300 KB/sec.  Not interesting, especially now, when CF cards are harder to find and cost more than SD cards.  It appeared that only Sandisk CF cards support 8-bit DMA mode transfer, others only 16-bit. Well, even then it could work, but at price of extra logic, chips (I did 16-8 bit conversion in IDE adapter for Sinclair Spectrum, in 1992 -  ZX48 IDE adapter ) . But since Sandisk is overall most spread CF card brand available and appreciated    did not find that is worth to support other ones at price of more chips on adapter.

Most important is to solve reliable and fast work of so called DMA (SCSI based) handshaking by sector transfers. I used timing diagrams in ProfiBuch 1987, which were most likely based on some Atari DOCs.

This is from 1991. ACSI DMA Guide by Atari:





In short, handshaking works like: target gives low to DRQ (DMARQ) line (all it is after DMA transfer command is given), and waits that ACK signal becomes low, what means that host is ready to read it (read case, data is already on bus) . In case of write to disk, DRQ active means that target is ready to read data, active ACK means that data is on bus, so target can read it.
However, no detailed description of work, there are some timings - see diagrams below, and it was a bit confusing.

I included in my logic both signals - ACK and DRQ . Added some delay (about 150 nS,  adjustable) after DRQ active end (what normally ends when ACK low is detected. And it worked fine with my prototype and 2 GB Sandisk card. Read and write too.
I published it: ACSI-CF page
Some people designed PCB for it, and most of them did it not really good. I already had problems with some PCB designs of simple IDE adapters - too tiny and interleaved lines, what caused unreliable work, especially with faster CF cards. And there was really lot of stupid talk - worst was some electro engineer from CZ, who claimed that my SW code is bad, while I clearly said that it works fine with my build, and it was obvious that he don't know how ACSI port, DMA works -  by his writings. I was really sick from all it, so whole project went aside, and I even did not buy other CF card over many years.
Somewhere around 2017 it emerged, some new people built it, and some even reported reliable work. With my original logic design. Some reported errors by write. So, I bought 4, 8 and 16 GB Sandisk cards (prices were good then) and made tests. And yes, I noticed write errors - in most cases latest 2 bytes of each sector had couple bad bits.  It was more frequent with longer lines, for instance. Whole thing was pretty confusing.  Then I was busy with some life, family related things, and it went aside.

Until someone went in deep analizis of whole transfer thing - tOri/Poland . He found that DRQ signal is much shorter in case of last 2 bytes of 1 sector than by others, and of course shorter than what is on diagrams shown here and in DOCs.  And solution was simple - just don't use DRQ signal by logic. He made adapter with 1 CPLD . I corrected my GAL logic, and it worked well, write too, with all Sandisk cards I had - 2-16 GB range. It was end of year 2020.   Here to add that all this does not mean that it will work with every Sandisk CF card. Nope, there will be for sure interfacing problems with very fast ones, same as it is with newer SD cards and diverse ACSI-SD adapters - I bought some half year ago 32 GB SD card, slowest in shop, and UltraSatan don't detect it at all.
It went into camera, and works fine. Ah, and here to add that most of older USB readers has very low success rate with CF cards - and with older ones too. So, my CF adapter org. design is not so bad afterall.

What to say about this "last 2 bytes timing problem" ? It seems that Sandisk CF cards just give shorter DRQ signal then. But bigger problem is lack of detailed description in Atari documentation.  My idea by logic design was to use all involved signals, and that it will give more reliable work. It appeared that effect of using all signals was just opposite - because inconsistent timing of DRQ signal .  What was confusing is that on all diagrams DRQ ended at about middle of ACK active signal.
 
And as last flaw for now: there is ASM code example of programing DMA/ACSI port for hard disk transfers. Present only in ProfiBuch 1987 ed. In later ones it is removed. Reason unknown. May be following error:
Giving read command:
   move.b  d7,d0   * d7 holds ACSI target # in 3 most upper bits
   or.b #8,d0   * Read command (used by 6-byte SCSI command set)
   swap  d0
   move.w #$0088,d0   * and this is the error
   bsr  wcbyte  * sends 2x 16 bits to DMA registers

Value $0088 above works, but only in case of single ACSI device attached.  Correct value is $008A - and that's necessary in case of 2 or more ACSI devices attached (Atari says max 4 at once), I'm rather for max 2, especially now, when machines are very old.
I checked above in App_Notes_ACSI from 1985 (Atari), and there it is $8A when giving command (like read), so error is in ProfiBuch only.  ASM example in Atari's APP_Notes is little hard to follow, though.

Photos from Atari ST ProfiBuch 1987 ed.  On pages 641 and  648  :









This will be updated soon ...
 

    PP,   December  2021.