STe - Bad DMA Chip

[Cwiiis]

Going on this thread: https://www.exxosforum.co.uk/forum/view ... 141#p15141

Are you talking about the DMA bus pull-ups, or about the floppy bus pull-ups (that go after the 7406)? I though you were talking about the latter. The former is recommended. Not sure it has any relation to your issue, but that always seemed a healthy fix to me since otherwise the DMA bus is kept floating for long periods.

Yes, the DMA bus pull-ups on the 1772.

[Cwiiis]

Just in case anyone sees this in the future, fitting the 1772 pull-ups fixed the issue for me. I still seem to have some instability issues, but they're more likely than not unrelated to the DMA changer (which seems to do a great job!)

[Cwiiis]

I happened to obtain a second STE after some unfortunate mishaps with my original (which I'll fix, eventually...) - This one also has a bad DMA and seems to be worse affected (though I've not done the CPU switch or bus resistor switches, so perhaps it could be better than it is).

While I could desolder the DMA chip, I had the thought that given the design of the DMA changer doesn't have an offset socket, presumably you could just solder it on top of the DMA chip instead? Is there any reason not to do that?

I guess it'd make sense to put in the pin headers upside down so as not to put the ICs up against each other if you did it that way too.

[12MHz]

Dear Cwiiis,

... presumably you could just solder it on top of the DMA chip instead? Is there any reason not to do that?

A very unusual idea.
But yes, it will also work that way.
You can solder the DMA-Changer on top of the DMA-chip.
The pins must be connected 1 to 1.

I guess it'd make sense to put in the pin headers upside down so as not to put the ICs up against each other if you did it that way too.

No, no. Not around the DMA-chip around. Connect the pins 1 to 1.

But the question: If you solder so much, wouldn't it be easier to just unsolder the DMA chip and put it on the DMA-Changer?

Best regards
Robert

[Cwiiis]

Dear Cwiiis,

... presumably you could just solder it on top of the DMA chip instead? Is there any reason not to do that?

A very unusual idea.
But yes, it will also work that way.
You can solder the DMA-Changer on top of the DMA-chip.
The pins must be connected 1 to 1.

I guess it'd make sense to put in the pin headers upside down so as not to put the ICs up against each other if you did it that way too.

No, no. Not around the DMA-chip around. Connect the pins 1 to 1.

But the question: If you solder so much, wouldn't it be easier to just unsolder the DMA chip and put it on the DMA-Changer?

Best regards
Robert

Ah yes, of course you couldn't put it upside down, that was a silly thought (it was late!) But looking at the board, only a few of the pins are actually not just straight-through, so presumably you could miss quite a few pins (eye-balling it, it looks like 1, 2, 26, 27, 38, 39 and 40?) which would save on quite a lot of work.

Desoldering of course is an option, but I had a pretty bad experience with pads lifting at one point, so while it'd likely be fine, if I can avoid it *and* do less work in total, that's a great benefit

[fenarinarsa]

Just out of curiosity, was there any news on the software workaround? People testing it on more STE settings for instance?
Or is there more to it on the hardware side that makes the workaround not stable/usable in real condition?

I was wondering if it would be a good idea to patch current drivers in a way that they use move.w on STE and move.l on ST/STF, for instance, so they would be compatible with both setups.

On the side of HDDRIVER, Uwe Seimet said he will not implement the workaround in any case because he considers it to be a pure hardware issue.
(I don't agree, we've been doing hardware bug mitigation in software for decades, even on ST, but well... it's his project)

[metalages]

This argument has value for more recent machines where it is easy to process to hardware fix.
For preservation phasis like this, it would have been great to have this option in hddriver to adapt to remaining hardware...
It could be an option of registered version only to motivate registering

[czietz]

Just out of curiosity, was there any news on the software workaround? People testing it on more STE settings for instance?

My biggest problem is that I don't know the reason for the MOVE.L in the first place. (Other than Atari saying it is required.) My hypothesis is that is has to do with the very first (-20) DMA only; and therefore it should be safe to use MOVE.W in an STE. But since I don't have a -20 DMA (and no one offered one to me, either, despite me asking), I cannot prove my hypothesis. Hence, I feel unsure about implementing the fix; even though it has been shown to work on several STEs in the meantime.

[troed]

tbh - if an STE owner has a bad DMA I don't think it's a problem to run a fix that seems to work even though it's not proven why Atari said not to do it.

I don't have a -20 DMA. @Gunstick might?

[czietz]

tbh - if an STE owner has a bad DMA I don't think it's a problem to run a fix that seems to work even though it's not proven why Atari said not to do it.

But I can't put the MOVE.W e.g. into EmuTOS with a good conscience, if I don't know the possible side-effects.

[troed]

But I can't put the MOVE.W e.g. into EmuTOS with a good conscience, if I don't know the possible side-effects.

Ah no, of course. I was more thinking about a patched HD driver available for manual installation. Or ... it could be a non-default EmuTOS setting.

[Cwiiis]

Just a quick update, I went ahead and soldered the changer on top of the chip - I can't say I'd encountered issues with this machine in the same way I had with my other one, but given the possible upshot is 'corrupts your hard disk', I don't feel too bad about some preventative maintenance I had a look at the PCB PDFs and snipped pins that weren't connected to anything - the pins that are soldered to the chip are marked on top.

[Cwiiis]

For what it's worth, this was a much, much easier job than desoldering the DMA chip - I think a revised version of the board that's designed for this could make it even easier and might be worthwhile to save some people possibly tearing up traces on delicate boards.

[fenarinarsa]

Ah no, of course. I was more thinking about a patched HD driver available for manual installation. Or ... it could be a non-default EmuTOS setting.

The issue is that a hard drive with a patched driver may be moved to another ST. So in that regard the drivers must be universal, that's why I suggested to activate the patch only on STE (if the STE detection is already available in a cookie when the driver is loaded), provided all STE work okay with the patch. That reduces a lot the scope of the machines to test for the patch.

But if I get you right, the first thing would be to get an ST with a -20 DMA? I might try to check the STs owned by the association I'm a member of. I just need to know what kind of machine/TOS/year of production I should check because they have a lot of STs.

[troed]

But if I get you right, the first thing would be to get an ST with a -20 DMA? I might try to check the STs owned by the association I'm a member of. I just need to know what kind of machine/TOS/year of production I should check because they have a lot of STs.

Only the very very very first 520STs might have that. I've hunted for ancient STs for some time and -38 is the oldest I've got.

Those with boot-TOS is where I would start looking.

(Agree with your STE detection)

[alanh]

For what it's worth, this was a much, much easier job than desoldering the DMA chip - I think a revised version of the board that's designed for this could make it even easier and might be worthwhile to save some people possibly tearing up traces on delicate boards.

I was thinking a castellated hole version would probably do the trick. Then it's easy to do both socket and solder blobs on the relevant pins without removing the DMA chip.

[metalages]

But if I get you right, the first thing would be to get an ST with a -20 DMA? I might try to check the STs owned by the association I'm a member of. I just need to know what kind of machine/TOS/year of production I should check because they have a lot of STs.

Only the very very very first 520STs might have that. I've hunted for ancient STs for some time and -38 is the oldest I've got.

Those with boot-TOS is where I would start looking.

(Agree with your STE detection)

So there is probably more st at large that have problem with move.l than st that have problem with move.w

[fenarinarsa]

So there is probably more st at large that have problem with move.l than st that have problem with move.w

Indeed, if the only STs where the move.l is needed are the very first 260 STs, there's chances they are all boxed in a few collectors' homes than used with a HDD

[axmandm]

A few notes from testing on my 520STE with the ST-DMA converter.

My STE motherboard is marked CA4003290 and is fitted with a C025913-38 DMA chip.

Prior to fitting the converter, I experienced corruption of partitions of SD cards when using a BBaN RPP HDC Emu. When creating or copying files, folders would become corrupted.

I do not see any difference in the behaviour of my STE since fitting the ST-DMA converter.

I have 3 different disk images which I tested:

1. EmuTOS 1.2.1
2. PPutnik ACSI Driver 0.9
3. HDDriver 8.13

All of these were configured with a small "boot" partition, and a larger "data" partition.

No matter the driver used, corruption of the partition was seen when copying files to a test directory. The files within the test directory occasionally appeared OK, but the PRG file (I was using Sweet 16 for my test) failed to run. I experienced the corrupted folder/file name issue occasionally, and the improbable number of bytes used issue occasionally too.

Overall, no change to how my STE performs.

[chronicthehedgehog]

I have 3 different disk images which I tested:

1. EmuTOS 1.2.1
2. PPutnik ACSI Driver 0.9
3. HDDriver 8.13

Overall, no change to how my STE performs.

I'm using the BBAN drive on my STE. I'm using ICD drivers as I couldn't get the latest PP or HD drivers to works. Others (on exxos forum) have reported that the PP/HD drivers work fine on an STE after installing an HC CPU.

This is all I know and it isn't much

[logronoide]

I have 3 different disk images which I tested:

1. EmuTOS 1.2.1
2. PPutnik ACSI Driver 0.9
3. HDDriver 8.13

Overall, no change to how my STE performs.

I'm using the BBAN drive on my STE. I'm using ICD drivers as I couldn't get the latest PP or HD drivers to works. Others (on exxos forum) have reported that the PP/HD drivers work fine on an STE after installing an HC CPU.

This is all I know and it isn't much

I have a 520STe equipped with 4MB RAM, an Exxos power supply, an HC CPU, and a C025913-38 DMA chip. I'm also using the PPutnik ACSI Driver 0.9 with a masteries HD. Unfortunately, it corrupts the microSD card during write operations, a common symptom of the DMA problem. Attempts to resolve the issue with a low-consumption CPU and a new power supply were unsuccessful. Next, I'll be installing an ST-DMA converter on top of the C025913-38 DMA chip. Fingers crossed that this will rectify the DMA issue.

[dlfrsilver]

A few notes from testing on my 520STE with the ST-DMA converter.

My STE motherboard is marked CA4003290 and is fitted with a C025913-38 DMA chip.

Prior to fitting the converter, I experienced corruption of partitions of SD cards when using a BBaN RPP HDC Emu. When creating or copying files, folders would become corrupted.

I do not see any difference in the behaviour of my STE since fitting the ST-DMA converter.

I have 3 different disk images which I tested:

1. EmuTOS 1.2.1
2. PPutnik ACSI Driver 0.9
3. HDDriver 8.13

All of these were configured with a small "boot" partition, and a larger "data" partition.

No matter the driver used, corruption of the partition was seen when copying files to a test directory. The files within the test directory occasionally appeared OK, but the PRG file (I was using Sweet 16 for my test) failed to run. I experienced the corrupted folder/file name issue occasionally, and the improbable number of bytes used issue occasionally too.

Overall, no change to how my STE performs.

On 2 of my STE,I had corruption happening no matter what. So my first gesture was to replace the DMA chip by the latest one (not the Ajax, the second DMA chip called 'good' and sold by Best Inc.).

It was not enough to fix the corruption on my ultrasatan. Everything got fixed when i replaced the 68000 CPU by the low consumption model. From there, all my ultrasatan problems vanished.

So if after applying the SD DMA converter the corruption is still there, try to swap the 68000 with low consumption one.

[axmandm]

So if after applying the SD DMA converter the corruption is still there, try to swap the 68000 with low consumption one.

This is exactly my plan of action - I will change the CPU to a MC68HC000FN16, and see if the problem persists. However, if it does fix the problem, I will retest with the converter removed, and report back my findings.

[czietz]

This is exactly my plan of action - I will change the CPU to a MC68HC000FN16, and see if the problem persists. However, if it does fix the problem, I will retest with the converter removed, and report back my findings.

By the way: Did you see my email about testing the alternative tentative software workaround?

[axmandm]

By the way: Did you see my email about testing the alternative tentative software workaround?

No - perhaps you didn't mean it was me that you contacted?