Bad DMA

[AdamK]

It seems that infamous "bad DMA" problem has finally been fully debugged, and it seems it seems to be possible to mitigate it in software:

https://www.chzsoft.de/site/hardware/ne ... stigation/
https://atari-forum.com/viewtopic.php?p=446002#p446002

Can we have a fix for it in Hddriver?

[uweseimet]

I cannot tell yet. Even though I have no doubt that this issue also exists with HDDRIVER (because it is a hardware and not a software issue), in the last 30 years or so less than a handful of users stumbled upon it. The HDDRIVER website advises anyway to test the demo version before ordering the full version. So at least in theory there should not be any HDDRIVER users who cannot use their Atari with HDDRIVER because of this DMA hardware problem, because the demo version would have revealed this.
Most likely I will wait at least several months before even considering any kind of software change, if at all. There are so many active HDDRIVER users with all kinds of hardware combinations that I definitely cannot risk to break something that has been working reliably for a very long time. From the postings in the thread you mentioned, is it really clear that there is exactly one DMA hardware problem with exactly one software work-around that fixes it and has no side effects? To me things still appear to be a bit fuzzy. Time will probably tell.

Therefore, as far as the DMA hardware issue in particular and HDDRIVER in general is concerned, the rule of thumb stays the same as before: Don't purchase HDDRIVER if the demo version does not properly work with your hardware.

[AdamK]

This does not need to be a change for everybody, it might be just an option.

[uweseimet]

I´m afraid there are already enough options, and the more options there are, the more complicated the user interface gets. The existing options are relevant for regular machines, not just for the few with a hardware bug. In addition, just an option is not sufficient. You can only have one HDDRIVER.PRG in the AUTO folder of the HDDRIVER driver floppy disk (typically used as an emergency disk in case you cannot boot from your hard drive). Which HDDRIVER.PRG would that be, the regular one or the one with the DMA hardware bug work-around? And you need a working driver first in order to install HDDRIVER with HDDRUTIL. Further, HDDRUTIL´s ID check would also need the work-around, for the case where the ID check is run without HDDRIVER having been launched before. (HDDRUTIL´s ID check is always available, even when no driver is installed.) And I would have to provide two bootable demo/full version image files for ACSI drives, because depending on your DMA hardware (broken or not) only one of them might work. This would mean a huge overhead.

If your DMA hardware is not working properly, which means that the HDDRIVER demo does not work, do not use HDDRIVER. And don´t forget that other drivers (e.g. CD-ROM drivers) may also not work, even if HDDRIVER was offering a work-around. So you might still have an issue as long as all of the drivers you use deal with the DMA bug. From that perspective, the only foolproof solution is a hardware fix.

[dlfrsilver]

Hello Uwe,

I have registered in order to give some infos regarding the "DMA" problem.

Exxos has done in past research on the subject, and he has discovered that some STF had the DMA bug, the STe (with a precision from me : The DMA bug on STe computers concerns machines built from 1989 to Q2 1990. Machines made from september 1990 to end 1991 are factory fixed by Atari).

Ste Computers exists with 2 motherboards revisions : Beta (recognized by the date 1989 or 1990, and bodges soldered at the factory), and final revision. This motherboard type has no bodge and no DMA bug.

On the beta Motherboard, Hddriver will not work. It will on the Final revision motherboard.

* How HDDriver fails on a machine with "DMA bug" ?

Simple: HDDriver doesn't recognize the hard drive, in a first attempt, next, you will never be able to save the driver *.sys on the C partition. It will never work and the HDD will never boot.

* Is a patch enough to fix 100% the DMA bug or an hardware modification ?

There is no straight answer to this. Because STe motherboard are not homogenous. What would work for a user won't work for others and inversely.

I'm a registered HDDriver user since a long time now, and here is my own experience :

I had to buy up to 3 Atari STE computers in order to find one that support hard drive out of the box without the "BAD DMA". I could only use HDDriver on my STF computers with ultrasatan. So, i checked Exxos website, and did some researchs too.

What i discovered was that i had one STE made in 1989, one Q1 1990 and the last one 1991. I found that Atari only fixed the HDD Dma corruption problem from August 1990. so it matches. The First two have the "DMA bug". i would get either corruption or would loose my partitions if i used my ultrasatan with them. However, the 3rd one is the fixed version, and works straight with HDD with no corruption.

So, what i did first was buying what was called the good DMA that equip the latest STe. Bad luck, even STe with the said good DMA fail with Hard Drives (as Exxos found). In order to get a full fix, i had to replace the CPU by a CPU HC, with less power consumption and doing less noise on the bus.

This just to say that the "Bad DMA" story is in fact a multi factor problem and no simply a problem with the DMA chip. It's a mix of bus noise/CPU/DMA/Motherboard all wrongly interacting with each other.

In a more general manner :

For some users, using the fix made as a small PCB will work for some people, others will need the small PCB + a new CPU 68000 HC type. Otherwise they will never be able to fix the problem.

So yes, i fully agree with you, the only solution is an hardware fix. A software fix would not be foolproof (people would start arguing it works for me and some others will say no for me it does not).

Please note also that some MegaSTE also have the "DMA bug" (but not important considering the amount of machines sold and fixed by Atari Themselves).

[uweseimet]

Thank you for this information. This is a really nasty problem, indeed.

[fenarinarsa]

For some users, using the fix made as a small PCB will work for some people, others will need the small PCB + a new CPU 68000 HC type. Otherwise they will never be able to fix the problem.

So yes, i fully agree with you, the only solution is an hardware fix. A software fix would not be foolproof (people would start arguing it works for me and some others will say no for me it does not).

Have you read the article posted above? It states that while it's a hardware issue, a software workaround is possible (basically replacing one move.l by two move.w).
However this initial move.l seem to have been introduced as a software workaround for another DMA bug present in the very first STs.
So that means the driver would need to use this move.w workaround only for STE/MSTE, so to check for example the _MCH cookie in the cookie jar (introduced with TOS 1.06).

So this workaround would need to be applied only on STE/MSTE (to be sure it's not applied on the very first STs), which makes virtually no change for all other setups. But of course that would mean testing it on enough STEs to be sure it's okay to use. The article points out that on multiple STEs with "bad DMA", it worked flawlessly.

I don't think it has any use of looking for a hardware fix if a software workaround this simple is possible... but it need more extensive tests.

Unfortunately if no one even tries to implement this workaround in a mass used driver, we will never know if it's 100% stable and okay...

[uweseimet]

The previous postings have already explained in detail that unfortunately a software work-around results in numerous problems and a huge maintenance overhead. This is why I am not going to address this hardware issue.