This has been "dead" for a while now. Simply due to lack of time more than anything. Though I hope at some point in the new year to start work on this project again.

This drive uses special hardware and software to max out the DMA speed. PP demonstrated some time ago about how fast it is over regular DMA drives. This was my main motivation to this project, speed, as always

As so many people are obsessed with IDE, I assume as its internal, it would be better to have a internal DMA drive like this one, use the DMA and get more speed than IDE, and any external drives like ultrasatan. I was also a bit reluctant to produce a drive as ultrasatan and gigafile etc was just coming on sale, so "another drive" on the market seemed pointless. I don't want to produce "another hard drive" either, that would be pointless. So as this one is fully custom with extra speed, I feel it would make a good project to start working on again. As many know, DMA issues distracted me for some time. But now I have those under control, I can debug this design better now.

This has been "dead" for a while now. Simply due to lack of time more than anything. Though I hope at some point in the new year to start work on this project again.

This drive uses special hardware and software to max out the DMA speed. PP demonstrated some time ago about how fast it is over regular DMA drives. This was my main motivation to this project, speed, as always

As may see, this is very old project actually. I need to add here some things, because there are some serious limitations with really usable cards, especially for fast mode. Before some people starting to have to big expectations.

All it started when I looked some Atari hard disk adapter speed tests. There was speed of about >1600 KB/sec for ICD Link2 adapter (if I remember correct). That just contradicts with claims in Atari ST Profibuch - 1MB/sec max possible on ACSI/DMA port. I asked some people, and they said that ICD speed is correct.
So, I decided to make test circuit to see what is really max speed, how many clock cycles takes 1 byte transfer with very fast logic. And it appeared that yes, it is faster than Profibuch says - all DMA chip revisions in different models.
Then came idea to make CF card adapter with fast logic and achieving that speed for real usage. I had 2 GB Sandisk card. Word Sandisk is very important here - not because I'm paid by them, but because that brand is actually only good for this project. The reason is that only Sandisk supports 8-bit mode in DMA mode. And ACSI port is 8-bit, DMA. There is still support for other CF cards, but then must use PIO mode of card and single byte mode of ACSI, and that's 5-6x slower. Things did not change in last 7 years - still Sandisk is OK, and nothing else appeared to be OK for fast mode.
Schematic and basic driver SW is online since 2010, and some people made it with success, some not (actually I know only 1 for sure, and he is not smart enough even to make flashlight 'circuit' ) .
Now comes the problematic part: the PCB boards. design of PCB is crucial, especially as newer Sandisk cards are faster, and that causes diverse signal interfacing problems with old, much slower and not CMOS logic chips. My experience is that line layout is crucial.
I really had not time and conditions for deal with that part of design last years. And SW needs updates too.

Now the idea what I just had: I think that there is way to use fast mode with non-Sandisk cards. at some price. And it needs only special SW.
Normal DMA mode is 16-bit, we have only 8-bits on ACSI port. One way would be to add extra logic to perform 16-8 and 8-16 bit translations by read and write, but that's not so simple. Since capacity of cards is bigger and bigger, we can sacrifice half of capacity, and accessing only every second byte.
So, you will have only 4GB from 8 GB card. 8GB from 16GB card - actually less, because TOS has its limits too (14x512MB partitions max) .
It will be not easy accessible on some PC - will need special SW for that. All depends from interest.

There is still support for other CF cards, but then must use PIO mode of card and single byte mode of ACSI, and that's 5-6x slower. Things did not change in last 7 years - still Sandisk is OK, and nothing else appeared to be OK for fast mode.

Now the idea what I just had: I think that there is way to use fast mode with non-Sandisk cards. at some price. And it needs only special SW.
Normal DMA mode is 16-bit, we have only 8-bits on ACSI port. One way would be to add extra logic to perform 16-8 and 8-16 bit translations by read and write, but that's not so simple. Since capacity of cards is bigger and bigger, we can sacrifice half of capacity, and accessing only every second byte.
So, you will have only 4GB from 8 GB card. 8GB from 16GB card - actually less, because TOS has its limits too (14x512MB partitions max) .
It will be not easy accessible on some PC - will need special SW for that. All depends from interest.

Interesting thoughts...

I think the problem with 16 bit transfer, they may need another packet of data to do the high and low byte switching.. I'm not totally sure about that..

But idea of doing to 8 bit reads to get the 16-bit data is a good idea. We can access the card 16 mode, but this does not mean we have to actually use all 16 bits, and like you say, the port is only 8 bits anyway, like you say it would half the capacity of the card but it would increase compatibility. And of course a side effect the cards would not be compatible with PC without special software.

So I guess the real question is, do we want card compatibility, or, PC partition compatibility..

For me, I think going with card compatibility better idea, having just one card manufacturer is a huge gamble I think.

For internal drives, the card isn't going to be removed anyway so I think PC compatibility isn't really needed there..

We are talking here about internal and external drives. A external drive may be more beneficial to have PC partition compatibility..

Of course if people want compatibility and removal external cards etc, then they just go buy ultraSatan. If people want a superfast internal drive, then they could build this project and just have to accept it will be some limitations. But on the good side, it will be the fastest internal drive ever created.

I already did 16-8 bit translations in 1992 - for Sinclair Spectrum IDE adapter. That was with 1 GAL + some latches, line transceviers. Schematic is at 8bitchip.info .
Since DMA in Atari works at fixed clock (8 MHz) it should be not hard to do that conversion - there is enough time for it. Without any extra cycles.
Considering PC compatibility with that 'crippled' variant - I already have special SW for Atari disks, which are not DOS/Win compatible. So, can add support for this, 'only every second byte' solution too in it.http://zx48.8bitchip.info/idehard.htmhttp://atari.8bitchip.info/drimus.php

I already did 16-8 bit translations in 1992 - for Sinclair Spectrum IDE adapter. That was with 1 GAL + some latches, line transceviers. Schematic is at 8bitchip.info .
Since DMA in Atari works at fixed clock (8 MHz) it should be not hard to do that conversion - there is enough time for it. Without any extra cycles.
Considering PC compatibility with that 'crippled' variant - I already have special SW for Atari disks, which are not DOS/Win compatible. So, can add support for this, 'only every second byte' solution too in it.http://zx48.8bitchip.info/idehard.htmhttp://atari.8bitchip.info/drimus.php

ok, I will look more later.

How is the HI/LO byte select done ? in the control byte of the DMA packets ? Latching data isn't a problem.. Just need to know exactly how select lines work.

There is no Hi/Lo select line. When you write parameters, commands to IDE it is all only 8-bit, upper 8 is unused. Only by data transfer all 16 bits are used. Of course, if using 8-bit mode, then even in data transfer only low 8-bits are used. On Atari byte order is opposite, but that changes nothing in how it works. Some even did byte-swap on cable

There is no Hi/Lo select line. When you write parameters, commands to IDE it is all only 8-bit, upper 8 is unused. Only by data transfer all 16 bits are used. Of course, if using 8-bit mode, then even in data transfer only low 8-bits are used. On Atari byte order is opposite, but that changes nothing in how it works. Some even did byte-swap on cable

I do mean using CF in 16bit mode.. So would use high and low bytes, would need to latch data and read 8 bits, swap latch read second 8 bits.. I thought that was what you was referring to ?

That IDE adapter for Spectrum uses actually reversed byte order in case of read and write - that made it little simpler. Of course, byte order swap then must be done in SW - so write is slower. May get GAL file here: http://zx48.8bitchip.info/zx.php
May see too, how simple is adapter for CF in 8-bit mode.
But, since we work on Atari not in PIO mode, but in DMA mode, whole logic in GAL must be different. Some may say, let's use PIO mode on Atari too on ACSI port. That's indeed possible, but I don't think that is good idea. DMA mode will be simpler.
In 16-bit mode, ACSI port will perform 512 cycles, while CF card only 256. So, you can not use/connect directly signals like DMARQ, DMACK. Logic needs to provide proper signals to target device. So, for DMARQ in case of write: it is activated by CF card. Then must activate DRQA - to ACSI port. It will activate ACK line, but that shall not go to CF card in that moment. You latch 8 HI data bits. Then after right time logic activates again DRQA, so it will put next byte on data lines . And activate again ACK line - only then you activate DMACK for CF card, which will read all 16 bits at once. Half from latch, half from line rec.
In case of read from card, you need to latch lower (LO) - first byte going on ACSI port, and to put next to CF card on HI part (D8-15) (to keep same byte order as by write) - that's why I reversed order for ZX . To save 1 line rec. chip. Indeed, it is really hard to follow.
Now, on Atari it can be that reversed byte order is just welcome - we know that we need reversed order for DOS/Windows/PC compatibility.
In any case, need to write almost complete new GAL logic since not PIO but DMA mode will be used.