STe - Bad DMA Chip

[exxos]

oops, misread what you said , though all my tests were done between the DMA and ACSI port. I have not even gone back to the CPU. Though if you check alanh's thread, he had to place some capacitors on the CPU R/W lines due to noise problems ( I presume) so make of that what you will...

Repairs in notts ? Who was that then ? Seems to be a busy area around staffs of late with Atari activity... Though I been asleep for the past few years

I suspect anyway, as parts go leaky over time, that its not helping the issues anyway. I think the ST was "borderline working" as it left the factory. Age and faster devices being connected are really showing up the design problems..

[SteveBagley]

Repairs in notts ? Who was that then ? Seems to be a busy area around staffs of late with Atari activity... Though I been asleep for the past few years

This was back in the 1990s, C&P Rossiter was the firm IIRC (run out of the guys front room). I've also just got back into the swing of things as my old machines died -- although I did pick up a Falcon and MEGA back in 2007 (and a MegaSTE earlier this year). I suspect all of them will be pressed into service in the next few weeks when I start teaching Computer Architecture

Steve

[exxos]

Sounds like a cool course, was Z80 in my day, and I am not *that* old 2K ram dev board to play with, nothing but a numeric screen and basic keyboard to enter machine code into ram and run it. was great stuff. Probably forgot most of it!

Always remember a task to count from 0000 to 1111 on a LED 8 bit output port.easy stuff.. kinda.. Then the tutor said now we have to get it to count on the upper 4 bits of the port, not the lower 4 bits... needless to say everyone over thought it and basically couldn't do it! I think one of my programs I actually ran out of ram! Tutor gave us a hint that we only needed 1 command to do it... "AH...oops" good days

[hedning]

Oh, damn it. Here I am, wondering why my bad ass and beloved 4mb 2.06 STE always fights with me when playing around with my SatanDisk and my newly bought UltraSatan. Should have checked here first. I must have the bad DMA, right? It says "C025913-38 PH23-030 0A5 25". Picture added:



Now. Is it the bad DMA?

Second: Where do I get a good one?

[TheNameOfTheGame]

Yes, that is the "bad" DMA chip. Not sure where to get a good one.

[mikro]

It's not the DMA IC's fault but CPU's. Just buy this one: https://www.exxoshost.co.uk/atari/last/storenew/#0092, replace and you'll be fine.

More info here: http://exxoshost.co.uk/atari/last/DMAfi ... htm#LATEST

[ijor]

I think it is fair to say that there is some kind of controversy about the whole thing. Changing the CPU to an HCMOS part might fix the problem, but it might not. Similarly, changing the the DMA to a "good" one might solve or not the problem. Ideally, try both.

[hedning]

It's not the DMA IC's fault but CPU's. Just buy this one: https://www.exxoshost.co.uk/atari/last/storenew/#0092, replace and you'll be fine.

More info here: http://exxoshost.co.uk/atari/last/DMAfi ... htm#LATEST

Interesting read! Thanx! Will try the CPU. Thankfully I have Troed in the same town, so I will force him to change the CPU for me so I don't burn down my house.

Will be interesting to se if my random failures on my STE will be solved with the new CPU. I'll keep you posted.

[hedning]

I just installed the new CPU, and after reformatting my SD-cards (one could not be used again, btw! :O ) the UltraSatan gets recognized at every boot (that was not the case before), and the hangups in PARCP when copying stuff is gone. Will do some more testing, but it looks good!

I'd go with the CPU theory from now on.

[siriushardware]

I don't want to rock the boat, but what happens when you combine a 'Good' DMA IC with a 'Good' CMOS CPU? Anyone tried that?

[ijor]

I don't want to rock the boat, but what happens when you combine a 'Good' DMA IC with a 'Good' CMOS CPU? Anyone tried that?

Probably somebody tried, possibly without knowing, an probably is not a problem.

It is almost obvious to me that the the DMA problem is caused by a combination of factors. You can't blame just the CPU because otherwise the problem would be present on all the computers. It is also not the "bad" DMA chip alone, because it is known to work without problems in some cases. Actually most STf/ST (pre STE) computers come with that version of the DMA chip. And probably there are other factors as well, including exactly which kind of device you have at the ACSI bus. Sometimes modifying only one of the factors fixes the problem, sometimes it doesn't.

[hedning]

What fascinates me is that both my SD-cards from when I ran the old CPU seems completely useless now. New unused SD-cards work fine on the new setup, but the old ones won't work even if I reformat them lowlevel on the PC or do anything else. The STE can't partition them anymore. Seems the old SD-cards were severlely corrupted somehow.

[siriushardware]

For the record. my STE has the 'good' DMA IC and standard CPU and has always 'just worked' both with an ICD based HDD unit (before that broke down with a fault on the ICD host adaptor) and with an UltraSatan, which is what I bought to replace it.

Between the two (A special IC produced only for a certain historic model of computer, and a CMOS version of a common microprocessor produced in far greater numbers and used in a wide variety of equipment) I would say that anyone having apparent DMA/HDD problems with an STE should probably try the CMOS CPU first, especially as it is always fitted in a socket - the DMA IC may not be.

[czietz]

Also for the record: my STE has the supposedly "bad" DMA IC and an NMOS CPU as well and still works fine with ACSI devices such as the Gigafile. This shows that even that combination is not guaranteed to fail as ijor already mentioned. (I really had hoped it would, because then I could have investigated the problem and maybe could have finally found the root cause.)

[hedning]

Still going strong. Copied 1gb files between the SD-carts and from PC-Atari through ParCP without a single problem. My life is so much better now, thanx to Exxos!

[ijor]

Also for the record: my STE has the supposedly "bad" DMA IC and an NMOS CPU as well and still works fine with ACSI devices such as the Gigafile. This shows that even that combination is not guaranteed to fail as ijor already mentioned. (I really had hoped it would, because then I could have investigated the problem and maybe could have finally found the root cause.)

Well, you might want to test with a SatanDisk or UltraSatan. They are supposed to be more sensitive to the DMA issue.

[joska]

I just installed the new CPU,

Out of curiosity - did you ever try {closure} with the new CPU? This demo fails on my STE with a HC CPU, but works fine with the original CPU. The same happens on another person's STE. My STE has the new DMA, not sure what the other STE has.

Edit: Both STE's have the good/new DMA.

Edit 2: In both cases the CPU is replaced with a 16MHz MC68HC000FN16.

[troed]

did you ever try {closure} with the new CPU? This demo fails on my STE with a HC CPU, but works fine with the original CPU

Now things got interesting I have an HC CPU myself in a drawer at home so I can also try. If it doesn't work then I'm sure I can figure out the exact cause rather quickly ...

[ijor]

This demo fails on my STE with a HC CPU, but works fine with the original CPU.

How exactly it fails? It doesn't load? Corrupted screen?

Yeah, interesting.

[joska]

Corrupted screen, jerky scrolling.

[troed]

Corrupted screen, jerky scrolling.

I might be able to diagnose it with just a still frame, or even better a video.

(I'm in the US for the week so cannot test myself atm)

@ijor Closure is syncing to HBL interrupt. What do you think - E-clock differences? I do analyze the E-clock jitter dynamically instead of relying on the fact that's it always the same on ST/STE [with the non-HC CPU]

[ijor]

@ijor Closure is syncing to HBL interrupt. What do you think - E-clock differences? I do analyze the E-clock jitter dynamically instead of relying on the fact that's it always the same on ST/STE [with the non-HC CPU]

Don't know. But doesn't seems likely, I wouldn't expect the E clock to be any different than the NMOS part.

That's the first time we hear a report about the HCMOS CPU to be not fully compatible. Although Jeff (HxC creator) did mention that some demos fail some time ago. We asked him which ones, but he never replied. I assumed then it might be a mistake and he was mixing up with the later 68000 SEC part.

@joska. Yes, please, post a picture if possible

[joska]

I'll see what I can do tonight, need to hook up the TV again first.

[joska]

Argh, I have managed to damage my STE when swapping CPUs It does not boot anymore. I'll try to describe the symptoms instead.

First of all, disregard my previous description. {closure} bombs out after displaying the "STNICC" opening text. Various number of bombs, sometimes a single red/white (flickering) bomb to the right of the screen, something a single white/orange flickering bomb to the left and sometimes five bombs to the left - one white, three red and one blue (IIRC).

It's the "We Where" demo that shows corrupted screen and jerky scrolling with the HC CPU. Both demos are working correctly with the original CPU. Strangely, "We Were" also has problems with my old STM, similar to the STE/HC problems but not identical.

Edit: I was of course wrong here, as We Were is an STE demo. It's {closure} that has some problems on my STM (some flickering and jumping while scrolling.) but this *might* be caused by a hardware problem in my STM. I will test again after fixing the STM.

[troed]

The bombs after the initial opening texts really does sound like the disk content hasn't been read properly by the bootsector TOS floppy sector read code. That's the only time the demo uses TOS btw ...

(I've seen exactly such symptoms during development when I screwed up the disk address table between disk generator code and the boot sector load)

Besides that, that's also the point in time where the demo does all the nifty initialization stuff (checking wakestate, syncing to HBL etc). There's definitely room for strange failures there.