- The LaST Upgrade -

PART 8 - GIGAFILE HARD DRIVE

+ My experiment's with the "Buggy DMA" (-38) Skip to end for conclusion for the DMA tests.

Chris Swinson 2013

 

This is a STFM to which I fitted "Gigafile" Hard drive by inventronik.de It is a very nice and well built SD card hard drive for the Atari Series of computers.

It is worth noting that the Gigafile has a connector to which you need a adapter pcb to plug it into which ever Atari you want. For example, my STFM has a "gigafile to ACSI" PCB adapter. You can also get gigafile to SCSI for falcon etc. This makes it connectable to a lot of Ataris, Though I personally would have preferred not to have had a additional adapter PCB and had the ACSI socket on the gigafile.

 

Gigafile in this instance, needs a 5V supply. I took mine from the ST motherboard as indicated with the 2 red arrows.

I found that there is a small inductor next to the PSU connector ( L51 ) which unfortunately drops the 5V rail to 4.66 volts across that capacitor. I bridged this over to get a stable 5V across the ram and other parts of the motherboard. I have also swapped out the old motherboard capacitors in case you are wondering why there's is a radial capacitor there!

The 5V line I used a generic DC connection.

This will be fitted on the back of the STFM case so I can swap out the Gigafile to other Atari's in the future.

Upon installed HD8.44 by Uwe Seimet Was where the first problems started. HD8.44 will recognise the Gigafile but nothing else will work. After reading the manual it mentions you need at least version 8.45 in order for Gigafile to function correctly. At the time of writing I used V8.47 which is the latest version of HD driver. Formatting the drive went fine at this point.

I first setup HD8 on floppy and I could copy files to the Gigafile without problem. Reading a text file from the drive showed all was good. However when trying to boot a program it would crash with 2 bombs. Several hours later... I was trying to get the C: drive too boot with limited success. After a couple more hours of pulling my hair out I found that Gigafile would sometimes boot up and other times it would not. I reset the Atari with warm resets, cold resets and powering off/on the machine. It was hit and miss if the ST would boot from the drive or not.

I emailed the makers of Gigafile who said.

The problem is, that there are a various of chips with different timings. In principle it is possible to adjust the GigaFile individually but not for all together

It would seem this back tracks onto the infamous "DMA bug".

The numbers "C025913-38" have different timings to newer "C398739-001A" DMA chips.

It could be plausible that hard drives programmed with a 001A DMA will not function with a -38 DMA. I would also assume the inverse, where hard drives setup with the -38 will not function with the -001A. If anyone out there has a drive which works on the -38 but not the -001A DMA please let me know and I will make it official.

 

I do not know how many versions of the DMA there is, but looking though various DMA chips I have collected over the years they all appear to be the "bad" (-38) types. Its probable that most, if not all, of these were taken from STFM machines. It is also known that some of the early STE machines also have these -38 DMA chips, so its best to check on what version you have before adding any hard drives to your machine.

On the occasion the DMA decided to work, I was able to partition a 32GB SD card.

The next gotcha here, is my STFM has TOS104, which has a limit of 256MB per partition. I understand TOS versions previous have small partition limitations, though I am unable to check as I always use 104 in my machines.

256MB is pretty vast in anycase. The next gottcha is you soon run out of drive letters assuming C-Z, however TOS has a limit which only allows you to actually go up to drive P:

So C to P at 256MB a partition will give you 14 drives 256 x 14 = 3584MB or 3.5GB. I am told under MiNT or MajiC you can have up to 32 drives, using C-Z and d-Z presumably as lower case c: drive is the cartridge port, apparently you can also use numbers 1-9. Unless you are running in ST-HI you may run out of desktop space to have that many icons! Overall, any SD cards for TOS104 over 3.5GB will basically be wasted. A 4GB card will be plenty in this instance.

The falcon can operate with 1GB partitions with TOS404. I presume generic TOS404 will have the same drive limitations but I have not tested it as yet. Assuming 1GB partitions with C-P that gives you 14 x 1GB = 14GB of hard drive space.

 

.

The next gotcha is you need to have a option in the settings menu to enable "ICD Compatible Adapter" enabled to allow more than 1GB to be recognised. Fast ACSI seems to be a new option to allow a small speed boost of about 15%. How effective this is I do not yet know. Each time I do a bench mark using P. Putnik's hard disk performance tester I seem to get different results. At first I got around 1500kb/sec with the option turned on, turned off it dropped to 1400kb/sec, though turning the option back on again did not change the speed. I will retest this once I get a new DMA.

The next gotcha is , for example in a TOS104 machine with 1MB of ram, that with just 4 hard drives 256MB in size you can easily use 300K of ram. Which out of 1MB is a fair chunk. The problem being, if you (like I did) set up several drives, you actually end up with not enough memory to run HDDRUTIL! So you can end up pretty screwed if you need to make changes. Its not a problem if you have a 4MB machine, but I kept to 1MB as I will mostly use the machine for playing games on. Some games apparently do not like 4MB, so I stuck with 1MB. Either way, its something to keep in mind!

Other thoughts ? Well I have also noticed that the floppy drive seems to throw up random errors for no reason. In copying a floppy it would never complete a copy without some sector error. While the floppy is old, and it could be a age related issue, in investigating the problem sectors in ECOPY, the track number with the error was always changing. If it was a faulty floppy, the error would always be in the same place. As it appears to be random I also wonder if the DMA is causing floppy read errors.

Once I find a replacement DMA I will post my findings here,and hopefully I can get using the Gigafile in the near future :)

 

UPDATE

I spent a great deal of time in investigating why Gigafile did not work on the STFM with the "buggy DMA". Other people have had the exact issue, but changing the DMA to the newer type solved the problems. I do not know if this was on the STFM or STE computers though.

There was much talk on the forums about problems with this DMA so I looked for any reason which would make this a "bad DMA" chip. Tests were done on a STFM machine. The STE machine has data buffers, the STFM has not. It has been suggested the STE suffers problems due to the databuffers, though I am unable to verify this currently.

My tests involved serveral DMA chips on 3 STFM computers. The strange thing was, one of those STFM's would sometimes boot form the hard drive, but not always. Sometimes it would run programs from the hard drive but not always. It was also strange as if a program loaded, if you renamed a file or created a folder, the program which loaded before, would simply not work again. Though if you deleted the folder that was just created, it would allow the program to run again. I spent much time investigating this and can only assume it was a FAT reading issue. There was not write problems to the hard drive, but simply reading problems. Sometimes programs would work, sometimes not, so it proved the information on the drive was correct.

I took out the DMA which was working (sometimes) and placed it into a Atari I knew would never boot from the hard drive. As it is generally thought and known, that using the new DMA would solve the problems, then the idea was, a semi-working DMA, should semi-work on another STFM. So I changed the DMA and it never booted once even after many attempts. I place the DMA into the "semi-working" STFM and it booted about 50% of the time without too much problem.

I had already tried several other "buggy" DMA's and none of them booted once. So I tried one of those DMA's in the "semi-working" STFM and to my amazement it booted first time. So it was conclusive the problem was not the DMA but something else.

I had a STE with a good DMA in, I checked the signals on there but did not see any problems. In fact all the timings looked identical to the "buggy DMA" so it was strange why one DMA worked and another one did not. At this point I suspect the problem is not the DMA.

Tests below in Yellow, are the ACK line. Blue lines (if shown) are the DRQ line.

It is clear something is very wrong with these signals. The first image has a spike in the ACK line. The second image seems to have fluctuating ACK line, which almost seems random voltages. The 3rd image is simply bizarre. There is much noise on the ACK line (yellow) at zero volts. Even more bizarre the ACK line is going NEGATIVE by 5 volts!!

There are some people which blame "poor hardware" for the supposed DMA problems, While this could be so, I do not personally beleive simple hardware issues with hard drives can easily generate negative voltages.

After much testing on ACK and DRQ lines I found random voltages which simply looked like they were not supposed to be there. At first I tried resistors to pull down the voltages which did not "make it" to zero volts. but ran into the problem that I also had problems with signals going going fully to 5volts. So this idea failed. As there was negative voltages, I placed clamping diodes on the ACK line, but this just resulted in more problems.

After monitoring the DRQ line some more, I found the input was to the LS04 inverter ( U51?) Was at a logic high, but pulsed regularly down by 1 volt. This "spike" was so fast that there was no logic change on the LS04 output. I imidiatly suspected the pulses were comming from the Gigafile hard drive itself. However it did not explain the negative pulses.

Some time later I realised that the voltages comming from Gigafile should have been 3.3volts, but I was generally getting 5volt signals. This added more confusion!

After much thought, I decided to try some small capacitors, 370pF on the ACK and DRQ lines in attempt to stablise the signals and clamp the "random spikes". At first I placed a capacitor in the input of the LS04 (DRQ) as it was clear there was a problem. I was shocked to see the STFM booted first time. I reset the STFM several times and it booted every time. I placed a capcitor on the STFM which never booted, and that booted first time. I was shocked since I had tried maybe 100's of times to get that ST to boot before, and it booted first time with a simple mod!

I was booting reliably to GEM from the hard drive every single time. Though when I loaded a program, again, problems :( I started to look back at the spikes on the ACK line. There never seemed to be a stable 0volts or 5volts. Even during switching cycles I could not work out if it was supposed to be a logic 0 or logic 1 pulse. So I placed a 370pF capacitor on the ACK line to see if this solved the problem pulses, and IT DID!

At that point all 3 of my STFM's were modded with capacitors and each one booted first time and now loaded problems every time with no problems. I spent some time doing tests and was not able to find any more problems.

I took a new screenshot after the mods and got this as shown below.

 

Now I could see correct 5volts and correct 3.3volts from the Gigafile. The negative pulses also vanished. I checked the waveforms and they looked more like how they should!

I experimented with capacitor values, 50pF and 100pF and 220pF. It would seem 220pF is about as low as you can go before the problems return. It is a little "naughty" loading lines with that value, but There is noting to say at a glance that any of the logic chips would have aproblem driving this load, just the signals may take a fraction longer to change. However at this point it suggests there is some problem other than the DMA itself being faulty.

My personal opinion at this time, is that for starters, the DRQ line travels right across the motherboard to get the to the LS04 buffer. The Datalines from the ACSI port to the DMA are much closer. As there are negative voltages being generated I can only presume this is generated by poor PCB layout. There are many close traces all switching in the mhz range. It is possible one signal is at 5volts, which is physically next to the DRQ line for example. If the DRQ line is at zero volts and next to a line which switches from 5volts to zero volts, then capacitance between PCB traces can forces the DRQ line to negative 5 volts. This would appear to be what is happening.

However I would have suspected that as there is some buffering involved that it would clamp such pulses anyway. Though if the GigaFile is using a CMOS device, then CMOS does not generally have enough drive current to counteract such noise problems. From what I Can tell the FPGA has 25mA of output current, so it should not be a problem.

So at this time there is still much investigating to do. I do plan to try my tests on a STE with the 2 DMA chip numbers to see if I can trace the problems on the STE also.

 

 

Above is the mod I did to the STFM ACSI adapter PCB which I purchased with Gigafile. The capacitors used are 220pF. I do not recommend using any other values. I also must stress this is not a offical mod! Though if anyone has problems they can try the mods. Anyone with DMA problems can also try capacitors on the ST motherbaord to see if that helps with problems or not. If anyone does try these mods then its ENTIRELY AT YOUR OWN RISK.

In semi-conclusion, due to really bizzare voltages being generated it suggests PCB layout issues on the motherboard. Much more testing needs to be done, though I hope others will investigate this and spend some time documenting results. Please send your findings to me, and I can include them here if appropriate.

I find it interesting the STE had buffers on the DMA, and yet it is clear that the older DMA still had issues on the STE. At this point I am simply inclined to stipulate that the new DMA simply has better hysterises over the older DMA. Considering the timings look identical at a glance, then it suggests the DMA itself is not the problem. However changing the DMA does solve hard drive issues. IMHO not due to the older chip being faulty, but the newer DMA simply being able to cope with higher bus noise levels than the older DMA.

There could be many issues linked to hard drive problems, but what I found and did, solved my troubled on 3 STFM computers. It is also worth noting that the STFM's were not identical. The ST which worked the best was in fact the type of motherboard where the MMU and GLUE were SMT parts, same with the DRAM, 8 SMT chips. The other 2 STFMs were socketed MMU and GLUE and the normal 16chip banks of DRAM, and neither of them worked. While the chips could be linked to that STFM working sometimes, its also worth considering it is a different PCB layout.

A interesting test would be to use a screened cable to replace the ACK and DRQ lines, effectivaly taking them off the motherboard and away from other traces...

Looking at the PCB layout a little more, the DRQ has the longest route so this was replaced with a direct wire. Traces were cut on the PCB from the ACSI connector to the LS04 buffer. On measuring the DRQ line it seems to be held at about 1.7volts and spiked once during boot to 5volts. Gigafile did not boot. ACK was constant 5V.

It would appear that there is a pull up resistor 1K on the input of the LS04 buffer, so a 4K7 resistor was placed to increase the pull up strength. The DRQ line now operated at 5volts. On turning on the STFM there was a single pulse on the DRQ line, but it only falled to 3 volts. This was similar to the issues I found before. I added i another 1K resistor so assume around 500R or so resistance. First time reset it crashed on booting from hard drive, second time it booted to GEM, 3rd time booted to GEM, 4th time no hard drive boot. I took some readings of the DRQ line to see what was going on..

The waveform is assumed at 5volts and switching down to 0 volts. However note that there are spikes down to about 3volts, as previosly noted, and now cycles from 3volts to 0volts. I suspect here the 3 volts is the gigafile switching DRQ and the 5volts is when gigafile is not driving the DRQ line. It is interesting to also see that the negative pulses on ACK are not present anymore since re-routing the DRQ line. This is strange since the ACK line has not actually been touched at this time. But this could be down to this particualar STFM board (will double check later).

The 200pF capacitors were added once again and the ACK line seems stable. The DRQ line still looks like the above image. However it , as expected, is booting fine from the hard drive again. The DRQ resistors were cut and the high voltage was about 3.3volts as expected and switching to zero volts. This time there was no switching to 5 volts. Not forgetting the capacitors are now in place. So the capacitors have prevented the 5V levels and now its held at 3.3volts. The capacitors were removed again, and the DRQ line again pulses from 5V to 3.3V to 0volts, and the hard drive does not boot again. ACK is still switching from 5V to 0volts.

Placing a capacitor on the DRQ line only, again makes the ST boot to GEM but not reliable on loading programs (ACK needs capacitor to fix that problem). At this point the ACK line is having some issues swtiching fully to 0volts. The DRQ line sometimes seems like it is wanting to switch but never fully does. It is also pulsing between 5V and 3.3V again. Either should be a logic high so assumed its not a problem.

So to round up something relating to DRQ, the signal does vary from 5volts to 3.3volts. Without the capacitor on DRQ, it never switches to 0volts and the hard drive does not boot. As to why the capacitor changes this is currently unknown. It also proves DRQ allows booting to GEM easy, but ACK is the line which prevents programs from loading correctly. A capacitor on ACK only results in same activity with DRQ and ACK stays at 5volts.

Something slightly related is that loading the RDY line with the scope probe is enough to stop the hard drive from booting again. There is a 1K pullup, I placed another 1K across it for 500R but still the hard drive would not boot with the scope loading that pin. It is interesting that a slight loading in the wrong place is enough to prevent the hard drive from booting. It could again suggest PCB layout could be a possible issue.

So far, I have been unable to notice any other way of getting the hard drive to function without the capacitors on the DRQ and ACK lines. There seems to be a lot of signals which seem to be random in voltage and timings. The capacitors solve these problems. It could just be that during some cycles the pins may be left floating causing random fluctuations in voltages. The capacitors will smooth that problem and keep the current state for a little time. They could also be acting as a slight time delay, but I have not seen currently any evidence of this. I have also tried a 1K resitor on DRQ from volts to 5volts and once it booted when tied to 5volts but not again. So its not a simply pull up or pull down problem. The capacitor will hold the pin at its current state which can be presumed to be acting like a tiny voltage buffer.

Going by how the scope probe can effect the operation of the DMA on the RDY pin, and how a small capacitance of 220pF can solve problems, it would suggest that there isn't much "drive" in the pins, its acting like CMOS logic without enough current to drive the scope probe. However adding capacitance will load lines more. So it does not really make much sense why loading some pins works and loading other pins does not. It does again suggest like a timing issue, Though in all my testing it just seems like "noise" being generated somewhere along the time which is causing bad voltage transistions causing hard drive problems.

It is unclear exactly what the problems is, and I urge people to do their own experiments. I hope to try my tests with Gigafile with the old DMA in a STE to see what happens, though I suspect similar results. Its possible my "fix" could help solve other hard drive related issues, but there is no way to know unless people try this out and report back to me. As it seems to date, the DMA isn't buggy, its more of how its being used which is the problem, the new DMA simply may take more abuse over the old DMA, but I have not seen any evidence that the older DMA is buggy going by timings seems identical between the 2. I need to check on this more, but that is my inital findings.

It is also worth noting that during all my tests, I updated the PSU and it is stable. As the voltage start to fluctuate on the motherboard as the PSU ages, it can effect different chips as it starts to fail. I would suggest people verify their PSU is working correctly before looking problems which may be related to the PSU and not buggy DMA chips etc. Click HERE for my PSU pages.

 

 

UPDATE NEW DMA October 4, 2013

I finally got hold of a new DMA to try in the STFM. As suspected the new DMA does not work in the STFM either. Doing the capacitor mods made the STFM boot right up once again.

I think it is pretty conclusive the DMA is NOT the problem , at least on the STFM. As to what the difference is between the old and new DMA is still unclear at this time. I suspect there is no real difference between both types. It could just be a different manufacture produced the new DMA, which just so happens to be a fraction better in some respect. I did not spend any time in scoping out the waveforms, I feel there is little point.

I tried the old DMA in the STE with and without the capacitor mods and the old DMA worked fine each time with and without the capacitor mods. I did some quick scope tests on the ACK and DRQ lines and they look a LOT better than on the STFM boards. The DMA chip used during all these tests (from day 1) has been the same "old" DMA. So the old DMA will work in the STE, but not in the STFM without mods. So it proves the DMA chip is not at fault.

I am starting to wonder if the early STE's had a different pcb layout than the later STE's and the new DMA number just coindidently came out with a later pcb revision. I suspect people who changed the DMA to the newer one and it started work was probably a fluke more than anything. Its possible the new DMA just had enough variation on spec's to allow it to work in some cases.

In conclusion, it is PCB layout issues causing hard drive problems. Slower TTL devices, along the lines of the 74LS series were simply not fast enough to respond to the PCB noise and worked correctly. Faster TTL devices or even cmos devices can react to the noise and generate bad signals causing problems. In none of my tests with DMA chips did I find any difference. I thus conclude the "Bad DMA chip" is nothing more than a myth.

It is probable early hard drives worked simply due to very slow logic gates which basically smoothed out the noise pulses so they never caused a problem. It could be possible to simply add slow logic buffers to the hard drive lines to solve the problems also, but it is not something I have tested. Capacitors solve the problems, while it may not be the best solution, it proves that the DMA chips are not at fault and the problem is with noise on the signal lines.

UPDATE February 20, 2014
Below are the 2 locations to solder the capacitors on the STFM motherboard. A value of 330pF to 390pF is recommended. Higher or lower values may not work.
Locate the DMA chip, in this case U31. The capacitor is soldered from pin 37 to pin 20. Pin 20 is actually GND so that leg of the capacitor can go anywhere on GND.

Locate U51 and solder the capacitor from pin 2 to GND (or pin 7 of the IC).

If I remember right, U51 capacitor solves auto booting problems with the hard drive. The DMA (U31) solves problems with loading programs from the hard drive , typically from GEM desktop.

For my short universal DMA fix guide please go back to the home index.

 

 

HOME