The circuit is fairly simple to construct. It uses just a 74HCT221, 74HCT574, GAL16V8. However I used ABT logic instead of HCT logic simple due to it being a fraction faster logic.

I wanted a small compact solution so I set to work on a PCB layout. This proved more troublesome than I first thought. At first I wanted to have the drive sticking out of the back of the ST. Though I later thought I actually hate stuff which sticks out as its too easy to get knocked about and just takes up more desk space! Another problem is the limit of DB19 plugs. The only source I could find was straight solder types. So the PCB simply had to use those.

This actually resulted in the PCB being vertical, which actually worked out well as you have access to the CF card from the top of the ST, rather than trying to insert it in and out of the back of the ST where it isn't a ideal location anyway. I also later found that the PCB couldn't actually be wider than the DB19 socket due to other sockets on the back of the ST. This proved a real problem to solve. The only solution was to made the PCB narrow on the bottom and wider at the top where there is more space. This gives room to *hopefully* not get in the way of other connectors on the ST.

Of course it is not possible to enclose this design easily. Any form of case would get in the way of other sockets. However, there is no reason not to use a DMA cable and house the PCB inside a case that way. So if you wanted to , you could have a enclosed drive by the side of your ST etc. However this would of course add a lot of work and expense. So in order to keep costs down I will leave this up to the end user to decide :)

At the top there is 2 LEDs, one for power , one for HDD access. On the right is a DC power jack. Power either has to come from a external PSU, or a socket fitted on the back of the ST to give 5V output.

I also added on the 2 DMA fix capacitors. So if there is any suspect DMA issues, the 2 capacitors can be added which should fix the problems. If you have not seen my DMA tests click HERE

Technicals.

The hardware is very simple, and fast due to GAL logic. Driver software is custom by PP in order to utilize the faster speeds. It is faster than usual SCSI adapters because DMA needs 4 cycles instead 6 for 1 byte transfers. Using a CF card will greatly speed up handshaking, however due to the nonstandard of CF card timings the fastest speeds may not be possible with all brands of CF cards. We will list a range of compatible cards as we test them.

Software.

As this HDD uses faster custom protocol than regular HDD software, It will not work with this hardware. Special driver software is custom by PP and comes bundled with the hardware ready to use.

Features.

Driver/partitioning features: TOS/DOS compatible partitions, 14 maximum per media. No first partition special size limit. All partitions can be up to 512 MB ( TOS 1.04 and higher) . It means very easy data transfer with PCs - No need for special SW to access files. Low RAM usage. 100% ASM code.

Autoboot:
Is only possible with changes in TOS ROM. Mod for TOS 1.04 and 2.06 will be published soon. Autoboot from CF is also possible if loading the boot software from floppy.

Usage:
No need to open machine - while it is not turned on just connect adapter to ACSI port, insert CF card and ensure power to adapter. Then may turn on power on ST(E) .

After 2 years of not working on this project I decided to do a bit more to it. Currently PP's software finds the CF card, but so far I have been unable to partition or format the CF card. So currently waiting for PP to get back to me about this.

I have also been talking to Rodolphe about updating this design to use use a faster more modern PLD and he has kindly adapted the code for a newer PLD. Currently there are 2 TTL chips and a GAL. We have plans to replace all 3 chips with a single PLD.

The main problem was there was no easy method to make a monostable in a PLD. So I devised a "emulated" monostable.

So here when the ACK pin triggers the monostable by going LO, it enables IC1A which discharges C1 via R2. 50R is there as a current limiter as the PLD has a limit of 24mA per pin. So must be careful not to overload the specifications. Basically 5V / 50R = 100mA. Though a higher value will probably be needed. Though in my simulation circuit below, I limited the charge voltage to about 2.4V. This means the discharge current will be 40mA for the above circuit.

When ACK goes HI, the discharge cycle ends, and IC1A goes tristate again. Now C1 is charged via R1 where it takes approximately 250ns to charge C1 to 2V. IC2B is a buffer where its logic HI threshold is 2V. The blue areas actually indicate internal gates in the PLD.

Above I show 2.4V zener to clamp the charge voltage. Capacitor was reduced to 50pF as this reduces the discharge current.

Above images show a charging and discharge cycle. The red line charges when the blue line (ACK) goes HI. After 206ns the voltage would be higher enough to trigger a logic HI on a buffer.

The blue line then goes LO to simulate another monostable trigger where it discharges the capacitor via a 100R resistor. The peak current is 22mA so good enough for the PLD which has 24mA maximum. It then takes approximately 60ns to discharge to 0.5V. Of course 60ns discharge time may be to long for this design. If so, then a small mosfet might be needed to discharge the capacitor faster. Mosfets generally have a high peak current capability. Even so a bad mosfet would only need to switch 1A or there abouts anyway. So almost any low cost mosfet will be suitable.

ATMEL Programmer http://www.kanda.com/products/Kanda/ATDH1150USB-K.html
AMTEL Software http://www.atmel.com/tools/ATMISP.aspx
AMTEL PCB By Rodolphe Pineau

I did not have anything but ATF1504 to hand, so I used that to do a blank check and all seems good :)

The software had issues after installing, it seems a common problem :-\

So I wrote a small program to test IO..

Device f1504plcc84;

PIN 33 = OP1; /* OUTPUT 1 */
PIN 34 = OP2; /* OUTPUT 2 */
PIN 35 = IP1; /* INPUT 1 */

OP1 = IP1;
OP2 = !IP1;

So this just turn on/off a LED depending if the input (red wire) is connected to 0V or not. Here is the PLD and JED file.

Some more testing was done. P.Putnik sent a beta driver to test in PIO only mode (about 300k/sec) and that seemed to basically work. So currently it is looking like the CF cards do not like 8bit DMA mode :( PP is still working on this problem.

Meanwhile, I have took measurements of the ACK and MONOSTABLE signals.

So ACK (yellow) goes LO and about 30ns later the monostable goes LO. ACK then goes HI about 40ns later. This is great news as it means I can use ACK to trigger my PLD version of monostable. So it should be fully possible to convert the CF circuit over to PLD code. We have also been talking about 16bit mode. This will not give any speed boost, but it should help a lot with CF compatibility. Though at the moment nothing solid has been decided or tested.

After some investigation, it seems the CF card needs a very stable voltage supply. After some test, it seems just 20mV of noise on the 5V rail is enough to cause stability issues. I connected a 7805 regulator to the 12V rail and got the noise down to about 5mV and this helped a lot. I was able to reliably read data from the drive, but write issues still remain.

I tried to save desktop and while the file contents were accurate it corrupted other files. One test file had double letters. For example "hello" would become "hheelloooo". After wiping the card to start over, I found even my Falcon was having issues even seeing the CF card. Sometimes it would let me partition the drive, but then it wouldn't let me open C: drive on desktop even though it had been worked a couple hours before. After about 2 hours of buggering about, I managed to partition a CF card which the Falcon was happy with, and it worked on my PC also, but the CF interface refused to see the partition, despise it had been working previously for a few hours.

Due to there being so many issues with the CF cards, its pretty much impossible to build a interface when the CF cards just seem unreliable to start with. I don't know if the CF technology is simply bad or they just do not like being hooked into a Atari. I know when I tried hooking a CF card into the IDE cable on my PC, it refused to even boot up. Later I used a USB CF reader which seemed a lot better. Though as the Atari is trying to work in IDE mode like my PC, both have issues. As to why the CF card reader works , no idea. Maybe they fixed some odd issues or use PIO modes instead of DMA modes. PIO did seem more reliable than DMA, so that could be some clue.

At this point I am probably going to abandon this project. For whatever reason, CF cards are just screwy! I am not convinced they are stable to start with. So there is little use in trying to build a interface based on iffy CF technology. There must be better storage solutions which can be hooked up to a 8bit bus other than CF cards. As to what, no idea. While flash memory is available, it still needs some type of control logic to select sectors in the flash. While this could probably be done, its probably going to turn into a huge project as it would need a totally new hardware and software solution.