STe - Bad DMA Chip

[troed]

*sigh*

Just realised that the STe I'm going to work with as a little side project has the bad DMA chip. Never thought of it before since it's been used with a Megafile 30 without issues but when going through it in preparation for adding an UltraSatan I decided to have a look.

So, anyone with spare good chips still?

[troed]

So here's a crazy idea: The original chips are available for $45 plus postage from the US.

http://www.best-electronics-ca.com/custom-i.htm

There's also the work of Wolfgang Förster who's been reimplementing all the custom chips of the Atari into FPGA for the Suska computers.

http://experiment-s.de/en/progress

The ALTERA Cyclone II FPGA, while able to emulate a whole ST inluding all chips, is still only ~$12. It should be trivial to program it with only one of the custom chip modules Wolfgang has so painstakenly reversed.

http://www.buyaltera.com/scripts/partsearch.dll?PV-5=3

This would give us an up to date supply of fixed DMA chips for STEs, HD capable floppy controllers and other things I guess.

Comments? I'm just saddened about the fact that I need to go replace my DMA chip

Observation: Wolfgang seems to have based his reverse engineering on the bad-DMA version, CO25913, instead of the good: C398739

[Guest]

i may have one ill look thru the trays see if i have one left
dont panic!!!
dont start buying yet

[Guest]

the fault is like this when you boot up an ste it does see the drive but the second read/ write isnt made
{control register reset mapping issues i think??}
hddriver did have a work around for it
anyway i dont have a spare
try mr atari
or i can perhaps help with a plcc to dil converter and use the relevent plcc chip instead...
you can buy a clip in plcc to dil /dip {dma dil chip } converter for this task for about $8 inc postage international
the plcc type is a c398789-001 44pin plcc {used in TT rev d-k pcb2 and ste rev d-f pcb3}
i would check your machines suffers from issues before replacing it
as far as i know by using stuff not all of the faulty batch exhibit the issues some others complain of

its been a bone of contention before now here

[exxos]

Someone mentions about "nobody has a bad floppy drive so can't be DMA" type of thing some time ago, I do have a problem with the floppy drive and hard drive. All with those "bad" DMA chips.

Thing is, you can load any game and it will load and run fine, BUT, as soon as you try to copy anything, it random throws up CRC errors. I suspect TOS will auto re-try x amount of times before throwing up "data in disc may be damaged" message, but on "Ecopy" I guess it uses its own routines and as soon as theres a CRC error it reports it. Each time I try to copy agian, the fault shows up elsewhere on the floppy. Its random so clear there is a fault somewhere.

When I built the 1.44 floppy kits, I assumed at the time that random fails were down to "not very good 1772" chips which couldn't work on 16mhz. Its why I feed my kits with a new 16mhz clock which solved all the problems and in fact it was hard to find a 1772 which didn't work. At the time just about any 1772s would fail, after a batch of the 02-02 versions not working it made me look into it more. For whatever reason, I ditched the ST's clocks and used my own onboard clock and never had these problems again.

EDIT:
I have ran the ST clock on various voltages, lowering it, the first thing to stop working is the floppy drive. I guess this explains why I had to drive a clean 16mhz clock. Chances are the 16mhz clock on the board is borderline "good enough".

I have also cut the 8mhz output from the MMU and feed it with a new buffered clock, while the 8mhz is now looking more like a squarewave than a triangle wave.. the DMA issue is still there. Copying a text file to the hard drive seems to work ok, but copying a program always fails on load. As to why smaller files work and maybe larger ones don't, I have no idea.

EDIT2:
It seems small programs about 100K in size load fine, text files I have to hand are about that size, but larger than that it gets onto 300K programs and they crash. The smaller stuff works fine (tried several times) the larger program files crash every time. So a "bad DMA" , for me at least, actually will work with small files just not larger ones ?!

Actually "Ecopy" is smaller about 90K and that will not load, neither will HDDRUTIL. I tried a "master sound" demo, 276k and that loaded up and played fine from the hard drive. So it cant be based on file sizes as some programs load and not others. Only thing is so far, as games and other stuff work, it seems to be all the utils which do not want to run. I was going to say maybe its GEM programs only but, a small 20k GEM program loads... sysinfo will not work from hard drive either, pretty sure i have had that running from hard drive, along with Ecopy and HDDRUTIL. *confuzzled look*

EDIT3:
Now Ecopy has decided to start booting from hard drive.

EDIT4: This makes no sense, Ecopy will boot, but if I create a folder, Ecopy stops working, but if I delete the folder, Ecopy works again. I renamed sysinfo.app to sysinfo.prg and that started working, now ecopy does not work again. I wonder if some FAT issue somewhere as very small changes seem to allow or disallow programs to work..

I then found rebooting allowed sysinfo and ecopy to work, but if I load ecopy, then sysinfo , it crashes.

if I boot Ecopy, then quit to desktop, then boot Ecopy again, it crashes. So loading a program, then quit to GEM, then loading it again does not work. But it will load in a clean boot... Really need to get me a good DMA chip lol

[Guest]

sounds like a bad psu and on board current reservoir capacitors
and perhaps a flaky controller ic

wd ic' you can look for an ajax chip and replace it out

and add a clock patch for 16mhz clocks for 1.44 just reuse the shifters clock output

!!! you'll need to change the older buffer ic for a faster type also think its a 7406 or 74LS06 you need a 74 hct or 74 ACT chip for {06}

something no mod mentions but is really needed
i dont know why people change the controller ic then forget to uprate the buffer ic
after all your clocking the ic by 2 this means to me it needs a faster buffer ic
no wonder you have packet loss
and this too me is what it sounds like
for floppy drives in all machines look to the phosphor bronze bearings at the sled worm screw and use a drip of sewing machine oil on it
as for the drive motor you can really oil them and they do freeze up a bit
i can only use the method i use is to soak some thread in oil for a few hours
then work it into the center below the round casing {you need to strip off the metal case etc to allow access
and pull it out like a rip cord slowly this oils the whole bearing

[exxos]

From what I saw, some people already tried replacing buffer IC's and it did not solve DMA problems.... ?

But I did not really see if this was a STFM or STE machine, I assume it was all STE ?

I cannot find any reason to why the "bad" DMA is causing problems, you may not be aware, but the PSU is good, and caps all changed, same on motherboard, no power supply problems..

It cannot be a write issue as sometimes programs load, it seems to be a read problem. But making changes to the drive, IE crating a folder, causes random problems, deleting it, and some problems go away and others appear.

There is random problems with floppy too, at least on STFM there seems to be no other IC's involved, direct to 68000 bus... I like others, just conclude bad DMA....

[tokalash]

I setup my old 520STE a few days ago and connected a Satandisk device bought from AFS.
It still has TOS 1.6 and was expanded to 4mb RAM in the late 90s.
I prepared for trouble since I got the computer in December 1989 (the store claimed it was among the first STEs in Sweden) and thus should have a faulty DMA. Haven't opened it yet.
Anyway, after some tries to setup multiple TOS/WIN with an old HDdriver I read that it wasn't possible, so I finally made one 512mb which was readable from both my STE and iMac (OSX/Win7). Apart from some failed filecopy in TOS, which worked using Kobold, everything has went on just fine. Today I wrote pperas 2gb image to my SD card and I can reach all 5 partitions in OSX, only first 4 under TOS. This was mentioned in the textfile so I guess it's nothing suspicious. I've ran a great load of programs and made some file operations and everything's still OK.
However, I'm going to backup this working configuration, just in case. Also going to check what DMA version I have. I recall some kind of service in the early 90s (but don't remember much about it, might have had some video trouble) so maybe it was swapped back then. Anyway I'll stop my rambling, just wanted to share my progress in this matter.
Good evening all!

[exxos]

Be interesting to know which chip is in there, assume it will be the newer type..

I think as previously mentioned, the timings are different between the 2 DMA chips, I have got 2 ACSI interface leads which worked well for years on my hard drives. So I do not think its a "bad" DMA. I think its more of a problem in software or the interfaces itself which are not working correctly with the older DMA. It would be interesting to know exactly what the problem is, in thought of doing some patch for the hardware. New DMA are hard to find, so I think it would be good to see if there is any chance of patching hardware to work with the old DMA. From what I can tell, ACK isn't in sync with the data exactly, if thats true, then either ACK needs to be delayed, or the data buffered for a fraction longer time. It looks like thats what they did on the STE anyway.

[tokalash]

Update: There's a C025913-38 inside. So, time to start hunting for a good one, or maybe a more recent STE.
In the meantime, I'll just continue to use it until I see some sign of malfunction (doing frequent backups of the card of course).

[SteveBagley]

Update: There's a C025913-38 inside. So, time to start hunting for a good one, or maybe a more recent STE.
In the meantime, I'll just continue to use it until I see some sign of malfunction (doing frequent backups of the card of course).

It's a really annoying bug -- my STe in the 1990s ran for good few months of heavy use before the DMA bug hit (right in the middle of my Physics A-Level coursework!). I wrote a report in Atari Computing about it, back in the late 90s if you want to read.

Steve

[exxos]

I have the AC mags, if you know what issue I will have a read, We are scanning the issues, but thats another topic..

I don't know what the bug is, its like its not reading the FAT tables correctly, but the actual data does save and load ok, it seems like the FAT isn't pointing to the correct locations on the drive.. but it could be anything.

I have seen posts of people where they say it works fine for years then simply stops working, but why...

http://joo.kie.sk/?page_id=250

Jookie says something about it too, He saying the first few commands sent work fine and its a write issue, but to me, the first few commands are not working as it will not boot from the drive.

Strange thing is though, I have now tried 2 Ataris, one Atari it does "sometimes" boot from C:, normally on a cold power up, but on the ST I am currently using, its never once booted. I have also tried about 10 of the "bad" DMA chips , all with same problem.

I think my first ST I was using, something must heat up and stop working, hence it only working from cold. Saying that, sometimes it will boot from C: simply pressing the rest button enough times.

Looking again at jookies page, there isn't any data there, so either the data isn't propagating fast enough, or the ACK line is simply going to fast. Its possible to slow ACK line down with a delayline or similar, but without knowing the ins and outs of it all, its just guess work really. It cant be that big of a fault as programs do actually load from the drive.

I think its confusing a little also, as I assume jookie was doing tests on a STE, as he mentions buffers, which I presume is on the DMA lines, which isn't there on a STFM anyway. As jookie says, he thinks it isn't the bus drivers, which I agree with, simply due to the STFM does not have them anyway. It does make me wonder Atari's motivation to add the buffers since the STFM though..

Jookie also mentions FAT corruption, which is probably the problems I am seeing.

[exxos]

I took my own readings from ACK and D0..

ACK line is yellow waves, .D0 is blue.

aewFile1.jpg

bewFile2.jpg

eewFile2.jpg

ccwFile2.jpg

fewFile2.jpg

gewFile2.jpg

[exxos]

jkwFile2.jpg

hewFile2.jpg

iewFile2.jpg

jewFile2.jpg

Below is a overview of ACK and Do. I can't make heads or tails of it. Yellow (ACK) seems to generally be at zero volts, but seems to sometimes go positive to 5 volts, and sometimes seems to go negative 5 volts!

aaaaaaa2.png

The 5Volt logic seems to be iffy aswell, seems to be more around 3.5volts. Supply rail on the chip is rock solid. Going by what I have seen so far, its a wonder I can get the file contents of the C: drive reliably. Still trying to get a new DMA to try out. Be useful to compare a hopefully good DMA to a bad one, then at least I can see what the signals are actually supposed to be!

[exxos]

I did ponder to put a 4K7 pull down resistor on ACK, it seems to be more stable, but ACK generally is low now, whereas before it was generally high.

1ewFile2.jpg

3ewFile2.jpg

Even so, it seems ACK is changing state as the data is removed from D0. How it looks, at least for the moment, there is something really screwy with the ACK line, putting that aside, it seems the data is being removed before ACK has finished changing state, which I presume is not correct..

UPDATE:

Ive changed the DMA twice now and things seem a little more logical now. ACK is HI and pulses low. D0 is actually pulsing at 3.3V which I assume GigaFile runs at. ACK is at 5 volts.. At this time I am not sure if Gigafile or DMA is driving the ACK line, I would assume its the DMA as its at 5volts. Even so , it seems like ACK is not in sync with the data. Sometimes it is, sometimes its close, other times its "out" totally.

aaaFile2.png

Theres no way to tell which are read and write cycles (only have 2 chan scope, need 3 chans!) There isn't any way to know if the ACK is supposed to be on the HI or LO part of D0 either. However, it can be clearly seen that ACK is trying to trigger on a LO, However, it can be also seen that its also trying to ACK on a rising or falling edge of D0. Something is out of sync somewhere. Though the OP of this thread mentions there is 2 timings for commands and data, its possible that is what I am seeing. There is not any way to tell which is a command pulse or data pulse (that I know of) But it would seem plausible that it could be a possible explanation to what I am seeing on my scope.

I had a look around and it seems I no longer have a ICD ST type cable I was going to hook up my older drive which I used for years, though I must have sold them years ago in favour of using SCSI on my falcon. It will be interesting to see what a new DMA timings will be like, I assume all the out of sync timings will not appear in the new DMA. I will post back when a get a new DMA, I cant think of any more tests to do.

How it looks to me though, I would assume, that again assuming the OP is correct with timings between commands and data, that its a hard drive software related problem, not so much the DMA. But its impossible for me to say at this time. I am just going to assume the new DMA has the same timings for commands and data, which is the reason it works as that's the way the hard drive firmware is programmed. I do not think many use a STFM for testing, all probably later STE machines, so the older DMA gets classed as buggy as it does not work with new hard drives and is replaced.

As for the STE having data buffers, I still wonder if Atari buffered the data simply to add a small delay so ACK becomes in sync with the data on the bus. Though it must not have worked as they updated the chip, Well, assuming that is the reason the DMA was updated in the first place. I suppose if the data is out of sync then a buffer would delay it, or if the commands are out of sync then it would need a buffer to slow down the data so it becomes in sync again, though it would involve some pretty complex logic to monitor whats going on in hardware, and only activate the delay buffer when its needed. Overall, easier just to get a new DMA I guess,

http://www.atari-forum.com/viewtopic.php?f=15&t=23228 OP comments there about commands and data timing issues...

UPDATE
I took my STE to bits and tried the tests again, new DMA chips works great, but the timings for D0 and ACK look pretty much the same.

sewFile2.png

sswFile2.png

sssFile2.png

so.... ????

[SteveBagley]

Remember the 25913 chip is successfully used in the Mega and STFM lines. Also, switching just the DMA chip on my STE fixed the issues with the HDD -- the driver and scsi controller (both GESoft -- a top link controller and their driver) worked fine for over a year until I switched to HDDriver which also worked fine for at least another year. My first thought would be that the problem might be the interaction between the 25913 and the GSTMCU chip, rather than necessarily the DMA chip alone.

Steve

[exxos]

It does not work in the STFM though, thats the problem, it works fine with the STE and updated DMA, but I do not see any timings different. I want to try the new DMA in my STFM to see what happens. Thing is, ive tried 10 DMAs so far, all the -38 ones, and they all suffer from similar problems, Most people seem to be talking about the STE, I dont think theres been any reports of the -38 working in STFM's, at least to what I have read around so far.

[Dio]

ACK is at 5 volts.. At this time I am not sure if Gigafile or DMA is driving the ACK line, I would assume its the DMA as its at 5volts. Even so , it seems like ACK is not in sync with the data. Sometimes it is, sometimes its close, other times its "out" totally.

The ACSI bus protocol is described in this document. Timing examples are provided at the back (B4).

To write, R/W is low; the ACSI device generates a DRQ and holds it; the DMAC puts the data on the bus and 20ns later drives /ACK low for 250ns, then removes the data within 10ns.

To read, R/W is high; the ACSI device generates a DRQ and holds it; the DMAC responds with a 250ns /ACK and places the data on the bus within about 100ns; the data must be latched by the ACSI device as /ACK goes high; the data will be held for 20ns more.

In both cases the source device must remove the DRQ within 180ns of /ACK going low.

What's your sample rate? I've found even at 100MS/s it's pretty hard to see the fine nuances of timing: even though in theory I should have aliasing only to 10ns boundaries, that's a surprisingly large quantising error when you're looking at signals in the 100ns region (10%).

[exxos]

1 GSa/sec max sample rate

I will look into DRQ when I have a bit more time, I have a Atari which "sometimes" boots so just need to work out why that one does when another ST with 10 DMA's tried will not boot.

[exxos]

88888888.png

Yellow is DRQ and blue is ACK.

Its hard to tell if thats supposed to be right or not

I tried my STFM where the hard drive boots sometimes, and I swapped the DMA with one which never booted, and on my other ST it booted up! Even though the DMA's seem iffy at the moment, I find it very curious it boots in one STFM and not in another.

I did notice the problem ST had a VL floppy IC, I did change it out for a WD one, but still same problems...

I did notice that the HD reset line does not seem to trigger correctly, it goes via a LS inverter, but while the input is triggering, the output does not, but this line is one way from the hard drive, so i cant see that being the issue...

It could be the problem STFM just simply has chips which are just a few ns off the working ST, preventing it from working, it would be nice to find out what lines are actually causing this though..

[exxos]

Does anyone have a iffy STFM with a hard drive which "sometimes" boots from C: ? I have found a interesting "fix" which had just made both my ST's boot from C: when one of the ST's has never booted from C:, and now it reliably is... need guinea pigs who can solder

Need to do more testing, but a step in the right direction finally

[exxos]

aaaaaaa2.png

Image above is the before "problem" waveforms where voltages seem to be going negative.. Also notice there is much noise on the ACK line too.
yellow = ACK

Below is the new modded lines with no negative pulses.

aaaaaaa3.png

..and D0 in relation to ACK

ffffffff.png

DRQ & ACK seem to vary in timings..

d1.png

d2.png

Overall things seem to be more stable now. My initial thoughts are there must be close PCB traces running close to the DMA lines. Its possible that is one line is at zero volts and has enough coupling capacitance to a line which is at 5 volts, then goes to 0volts, that it could cause negative pulses. Aside from that, there does seem to be a lot of noise generated from somewhere. The power rails are rock solid so that is not the issue. I suspect its just coupled capacitance between pcb traces on the ST PCB itself. I don't have much time to look into this more, but thats my initial thoughts on the matter. The new DMA which seems to fix these issues, it may just simply have better hysteresis on the pins. I have not yet seen any real timing differences between the 2 DMA chips.. More testing would have to be done though.

I will try and produce a guide to my fixes, My tests were done with the Gigafile, I do not have any other hard drives to try on my STFM, so I cannot say for sure if it will fix "all" the DMA problems. I will try and buy a STE and put a older DMA in there to see what the results are aswell, it may take some time to finish all the work though.

[SteveBagley]

Along these lines, this post from Frank Lukas way back when caught my attention… Frank pretty much comes to similar conclusions to you.

Specifically:

Another problem occured with the DMA-chip (see my other post). A long time ago, in this computer the two ROM chips were replaced by six EPROMs with TOS1.4. Later, I added a FPU board. Addition of this Alt-RAM board seems to have been too much on the data bus for the poor DMA chip which obviously does not have enough bus-driving power and started producing data errors (btw. this is the CO25913-38 chip which was reported to produce disk errors in STe computers). I found out that by removing either the new TOS 2.06 EPROMs or any two (out of six) of the old TOS 1.4 EPROMs, the errors disappear.

Frank Lukas also finds a fix similar to yours solves problems.

Further tests showed that the frequency of disk errors was significantly reduced (but not completely eliminated) if I placed a very large (several uF) decoupling capacitor immediately next to DMA chip, and reduced even more if power supply voltage was increased to cca 5.10 V.
Checking the part number of the DMA chip, I found out that it was the CO25913-38, which was reported to produce exactly this type of errors in some STEs (and MegaSTEs?).
My conclusion is that the CO25913-38 version of DMA chip simply does not have enough bus-driving capacity and is thus producing erroneous data on the bus. It seems that it was running near its limits from the start, so that in the original state of my MegaST this made no problems, but since then the data bus in this computer has been loaded more and more with:
- replacing the original two ROM chips with six-chip TOS 1.4;
- adding the FPU;
- adding the TOS 2.06 EPROMs;
- adding the bus transcievers for Alt-RAM;

which, apparently, was just too much for the DMA chip. I suspect that a STe, having a different hardware design than a ST, presents an even higher bus load which he CO25913-38 chip can not handle.

Perhaps putting a buffer between the DMA chip and the CPU data lines might be an alternative fix for the STE DMA issue?

Steve

[exxos]

Perhaps putting a buffer between the DMA chip and the CPU data lines might be an alternative fix for the STE DMA issue?

Steve

Thats the thing though, the STE does have DMA buffers.. Its what made me think Atari thought there was bus problems and added the buffers on the STE, but as everyone knows, it didn't work, so Atari produced a updated DMA.

I do think the entire ST design is iffy, i am actually amazed it even works at all considering how bad all the signals are. Some signals have 1K pulls ups, so some outputs from GLUE etc must be open collector types, but even adding another 1K resistor (500R) does not help.

More supply bypassing was the first thing I tried. Its very possible the PSU as the caps dry out (and the motherboard caps) that the voltage can vary from 4-5volts as already proven by me. Though the supply on my test machine was solid. Adding 4700uF across the pin with 1uF ceramic did not help at all.

The DRQ line is driven from the hard drive itself, and it goes to a LS inverter, so even that is buffered anyway. So it would seem the hard drive is not giving correct signals, or has something very wrong with how its driving those lines, which hints to hard drive hardware/software issues. I cant find my ST (gesoft) DMA cable to try my SCSI drives to see if the problem pulses are still there so I cant say "where" these pulses are generated from.

ACK seems to suffer with PCB noise, which seems impossible as ACK is direct from the ACSI port to the DMA chip, but it does follow close to IRQ and maybe some others. I don't know the capacitance between those traces, but at 8mhz it could be enough to add serious noise with just a few pF. I am currently designing digital amplifiers, and getting stuff to run over 1mhz is not easy. Have a few mm copper in the wrong place and you can generate a lot of problems. Thing can work fine at 1mhz, but 1.1mhz and you get all kinds of crazy signals. It would appear so on the ST too. Maybe as the hard drives are so fast now, that these problems are showing up more. I am going to take a guess and say older slower drives may not suffer from such problems. I never had a problem with my DMA SCSI stuff on my STFM...

If you are bored enough check my UPDATE section here about half way down http://exxos.www.idnet.com/IMPULSE/atari/last/gigafile/index.htm I did some more testing, but pretty much came to the same conclusions as mentioned above.

Interesting about Frank's problems with "adding more stuff onto the bus". I don't think its a simple "bus buffer" issue though. I think its simply noise across the entire board. All kinds of signals running at all kinds of frequencies, increasing the current does not seem to help, 25mA on LS buffers ? and something is managing to swamp those out. Only thing left is harmonics and beat frequencies and resonances between various PCB traces. Adding more load onto the bus will simply add more switching noise and compound the problems. I will guess again that its why the STE had buffers but still had the same issues even though its a totally new layout at that!

I had a digital amplifier which ran at 200khz, manufactures demo board in fact. Was told strongly not to change the layout. I made my own layout of course and always had a slight distortion there. After several PCB revisions I found that just 5mm of copper was enough to throw out a otherwise stable circuit. I replicated this on the demo board also, simply lifted a capacitor up 5mm off the board and the extra leg inductance was enough to replicate the distortion. That was only at 200khz, never mind the 8mhz bus and 2mhz and 4mhz and random IRQ lines and the rest of it.

I think it needs investigation more with some serious test equipment, but its clear there are random voltages at random times, I think there could be a few factors causing issues.. People with bad power supplies don't stand a chance right from the start

[SteveBagley]

Thats the thing though, the STE does have DMA buffers.. Its what made me think Atari thought there was bus problems and added the buffers on the STE, but as everyone knows, it didn't work, so Atari produced a updated DMA.

They are on the ASCI port side of the DMA chip, I was thinking between the DMA chip and the rest of the STE's innards. Thanks for the link to your research, I'll go and read that.

It's also interesting because the problems you've been having are very different to what I had back in 1995 on my STE which was a lot more random. I got my HDD in August 1995, and while having a lot of issues at first due to a faulty TopLink cable (it was giving grief on my STE and two STFMs -- although both of the same design, even though they were made years apart…) after that was replaced the drive ran flawlessly on the STE for a good three or four weeks of *heavy* use (running IOSMail to process my FidoNET mail etc every day) before I suddenly got corruption on one drive. Booting was never a problem (however, my C:\ drive was only used for boot stuff! which probably meant it never attempted to wire stuff there).

After having the DMA chip replaced (the joys of having an Atari repair specialist in Nottingham), the machine ran perfectly for another three years before I moved to a PC so I'm fairly certain my issues were due to the DMA chip.

I'd love to know what the real cause is though… Thinking about it, I seem to remember a letter in ST applications (and I've no idea which issues -- could even have been the ST club newsletter) where someone had very similar problems with a MegaST which was solved by replacing the motherboard, which speculated if it might have been related to the STE DMA issue. I suspect you are very right about the iffy-ness of the ST's design

Steve