Dead 520STF

[Sassa]

Hello Atari ST Fans.

I'm currently trying to repair a 520STF and found that your forum is a great source of info and other users experience.


Being new to the forum let's begin with a small intro.

First, I didn't have an Atari in the good old days, but some friends had 520s and 1040s. I was at a friends playing with his 520 STF when it blew up. I guess it was 25 years ago.

Back then he gave his machine to a "professional", but this guy said it was beyond repairs. So he gave it to me and I kept it until now. The floppy drive and mouse worked great in other machines. It has a C103414-001 Rev 1 motherboard.

Since I'm now a bit more experienced with electronics, I'd be really happy to make it work again.
My point is to enjoy repairing it, and buy only the necessary parts.
I have some basic hobbyist tooling, I think it will help.



The first bad thing about this STF was the power supply.
Few months ago, I repaired the PSU (changed the common mode choke and the bridge rectifier). Both +5v and +12v are OK after the repairs.
However that didn't work beyond lighting the keyboard led. I also checked with a good PC AT PSU and it is the same.



The other thing was a missing shifter : the so-called "professional" had stolen the chip from inside the shielded part of the motherboard. A month ago, I bought a replacement off ebay.
No luck : keyboard led is still alive, and the TV complains about bad/unsupported signal.



I noticed that the 6 TOS roms were different from each other : not only the markings but also the "looks" of the chips. "the guy" replaced it with random TOS chips from his bin.
One of them is th C101633-001 (1.02 HI french of the 2chips-set) ; I put it in the right HI socket then tried to make the LO part using a 32pin flash chip (SST29EE010). I did it using the french TOS rom I found online, romsplit in an emulator, and flashrom on linux with a realtec NIC.

I connected this chip with the right bindings (connecting pins outside the socket, etc) to the LO socket, and soldered the jumpers on the motherboard for the 1Meg ROMs.
No more luck : still the same.



Following the ST and Mega ST service manuals, I found that the CPU is held in HALT mode, with VCC on most pins of the ROMs.
I checked the reset inverters chip (unsoldered and socketed it) and it is good.
Using a saleae logic, I confirmed that BERR goes low 0.3s after startup : see the attached file.

The second thing that I found is that when removing the socketed DMA chip, the CPU is running, there is activity on the ROM chips, and the reset button triggers the reset signal.

I checked the continuity of the CPU, Glue, shifter and DMA between each leg and the traces on the motherboard. Visual inspection is good according to me.



Now some of the many questions I have :
- The service manual says "Verify the clocks to Glue and Memory Controller and replace these components to verify them". Well, I'm struggling to find on which pin these clocks might be ?

- Could bad ROMs make the CPU to halt ?

- How to find if the DMA chip is good ? (I read about bad DMA chip but found only the topic about hard drive failures)

- It could also be that the shifter I got from ebay is bad...

- Bad solder joint.

- Bad capacitor on the motherboard (I found a correct voltage on all the ones I probed ; I'll need to unsolder them for test)



I read several topics on the forum about similar symptoms (on a STE/ mega ST...). Too bad, I don't have another ST to swap parts, or a diagnostics cartridge.


Thanks.

[mlynn1974]

Have you checked this thread?
viewtopic.php?t=23151

This is a suprise to me:

Check (2) by observing pin 22 of the CPU (BERR) as the unit is powered on. It should be high always. If there are logic low pulses, some component is malfunctioning and Glue is generating the error. Verify the clocks to Glue and Memory Controller and replace these components to verify them.

In Page 14 of Atari ST Internals there is the Glue pinout. Pin 34 is 8MHz in, pin 43 is 500Hz out.
GND=35, Blank=36, HSync=37, VSync=38.
Probably best to check all these things before replacing chips.

Try all you can to save this ST! If anything to show the "professional" repair man that it *can* be fixed.

[Sassa]

Hello mlynn1974

Sorry for the late reply. I might have missed the notification of your reply, if any.

Thanks to your info I found a pdf of the very interesting "Atari ST Internals" guide that I wasn't aware of. I still have to read it

I just checked the signals you mentioned, with the DMA chip plugged in, ant they all seem good to me :
8MHz is connected to CPU and receives the 8MHz clock
500MHz is also 500 MHz according tho the analyser
Gnd is connected to the GND of the board
Blank is a 15.78KHz signal with a 10,44microsec low pulse, and stays low after VSync
Hsync is also a 15.78KHz signal with 5 microsec low pulse
Vsync is 60.02 KHz

All the signals stay OK from power up to the end of my capture, ~6 seconds after power up. There is no visible change to them when the BERR is triggered, around 0.32s after boot.

Thanks to you, I think the next step I have to do is to check the two TOS ROMs. From the few pages I read form the guide, I understand that BERR can be triggered if there is something wrong with them and their code makes the CPU access wrong addresses ?

I'll update the thread when I find something new.

Sassa

[mpattonm]

I noticed that the 6 TOS roms were different from each other : not only the markings but also the "looks" of the chips. "the guy" replaced it with random TOS chips from his bin.
One of them is th C101633-001 (1.02 HI french of the 2chips-set) ; I put it in the right HI socket then tried to make the LO part using a 32pin flash chip (SST29EE010). I did it using the french TOS rom I found online, romsplit in an emulator, and flashrom on linux with a realtec NIC.

I am struggling to understand what is your TOS ROM configuration. Is it 6 chip config, or 2 chip config? Since it has been messed with, are motherboard jumpers set accordingly?
Are you sure TOS ROM chips are all right? I can donate you working original TOS 1.02DE ROMs I have no use for, if you are interested. They could help you rule out TOS ROM chip issue.

[Sassa]

The board was using 6 chips.

After I saw that the TOS roms were messed up, I changed the 3 solders to 2 chips.
In HI-0, I used one of the chips that was in there : the C101633-001. Ut is the "TOS 1.02 2Chip AZERTY High" according to https://www.forum64.de/index.php?thread ... n-rechner/
In LO-0, I used a custom flash chip that I programmed with the TOS 1.02 2Chip Franch LOW rom image.

Actually, I have built the "meprommer" http://www.ichbinzustaendig.de/dev/meeprommer-en using an arduino pro mini.
It is starting to work in read mode (only the arduino part works for me, the java app doesn't want to launch). So I'll use it to read the C101633-001 that I have to check that it works and that it matches the HI part of the custom flash rom that I made.

[mpattonm]

I see. Is the flash memory chip you used _pin_ compatible with original chip? Provided that you used it as direct 1:1 replacement.

[Sassa]

Hello,
Sorry for the late reply.

The replacement chip is a SST29EE01 EEPROM, it is 32pins so it needs the rewiring to fit in the ST socket (found on other posts in the forum).

I have read both the HI rom and my LO eeprom using the meepromer (I couldn't make the java part to work so I used it by direcly sending commands on the serial port using linux).
I found that their content both match the HI and LO part of the rom I downloaded. The only difference is that the end of the data is padded with 0 on one whereas it is padded with FF on the other one. I am confident it should not be a problem.

I reinstalled it in the ST and used the logic analyzer to check the address and data lines, see the capture.

Capture A_D_BERR.png

The address and data lines start toggling 320ms after the power up. What I find intriguing is that it is just a few cycles before BERR is triggered.
I'll try to investigate it this week-end.

[troed]

When going from 6 chip to 2 chip you might need to populate a missing logic chip (74LS11) as well, was that done?

See "6 CHIP TO 2 CHIP CONVERSION" here: http://www.exxoshost.co.uk/atari/last/tos/index.htm

[Sassa]

Thank you Troed.
Actually, the 74LS11 was already there on the motherboard.
You are true that it is important, so I checked that it is working :

ROM0.png

"ROM" is the output from the 74LS11 that is fed to the 2 ROMS, and "ROM0",1 and 2 are the output from the GLUE (numbers might be exchanged on my probes).

Since the last time, thanks to the PDF guide, I checked that ground and power are connected to all the chips.

And I've started to check few signals from the CPU that do not look bad for me for the fist clock cycles, before it stops and berr is triggered after that :

CPU1.png

CPU2.png

By the way, I'm sorry for the delay... I've been working for a few projects at the same time.

Sassa

[Sassa]

Hello,

Today, I managed to burn two new 29C010-70 flash chips, so I tried replacing the old flash that I used, and also the rom chip that I salvaged.
To program them, I used Tos 1.02 that I dumped and splitted from an emulator using the TOS ROM splitter.
The symptoms are exactly the same as before.

I also checked that I get all the data signals from the roms on the CPU during the few cycles when they toggle before BERR.

Rom on CPU 2 new flash chips.PNG

Too bad but it seems that the problem is somewhere else.

I read that Glue might trigger BERR when it does not receive DTACK so I put a probe on it ant it pulses low 4 times, as the same time that it reads the ROMs.
The doc also says to check the clocks on MMU and they are all there (even though the 16Mhz from the sifter looks like the 8Mhz since my logic analyser is too slow for it).

[czietz]

Check the address bus; both for continuity between CPU and Glue and for the absence of any shorts. After reset, the CPU will fetch the first four words from addresses $0-$7. This is probably what you see on the logic analyzer. Then the CPU will jump to the address read from $4-$7, in case of TOS 1.02 $FC0030. If this address is not decoded properly by GLUE, it will generate neither the chipselect for the ROM nor /DTACK for the CPU. Any bus access lasting more than 64(?) cycles will be terminated by /BERR.

Another possibility would be that the CPU reads some wrong data from locations $0-$7. But you said you checked the data bus to be OK, right?

[Smonson]

Following the ST and Mega ST service manuals, I found that the CPU is held in HALT mode, with VCC on most pins of the ROMs.
I checked the reset inverters chip (unsoldered and socketed it) and it is good.
Using a saleae logic, I confirmed that BERR goes low 0.3s after startup : see the attached file.

These are exactly the same symptoms that I had when I repaired my 1040STFM after I bought it on ebay - the problem was a RAM fault. Having one megabyte of memory, I was able to confirm it by booting the machine with 512KB at a time... I think I lifted a couple of resistors somewhere in order to alternate each half into the address 0 space, so one half booted, one went into HALT after a short burst of bus activity.

[czietz]

Although if there really just are four bus accesses after power up and before going into bus error, then I don't think it's the RAM. First use of RAM occurs after way more than just 4 bus transfers.

[Sassa]

Hello czietz, Smonson,

Your help is great !
I connected the logic analyser to D0-D7 then D8-D15 of the CPU, then here are the four words that are read (D0 being the LSB) :
602E
0102
00FC
0030
At least they are the same as in the rom file and the address $00FC0030 is here

CPU Data D0-D7.PNG

CPU Data D8-D15.PNG

Then in the captures I counted about 62 (maybe I missed one or two of the 64?) clock cycles between the last word of data and berr.

As you said I now check the address bus of Glue and the CPU.

[Sassa]

I checked the address bus and found something interesting !

CPU Address A1-A8.PNG

CPU Address A8-A15.PNG

CPU Address A17-A23.PNG

The A23 pin stays low.

There is only 44.6 ohm between A23 and ground at the CPU and 44.7 ohm at Glue.
So as you said, there seem to be a short here. And it might be on the CPU side ?

On the 1040SFT schematic that I have, A23 is connected to CPU, Glue, and a resistor network. Did I miss something ?
The resistor network is connected only to +5V so I doubt it is the culprit.

I'll inspect the board more closely.

Could it be the reason of the failure...

[czietz]

It's hard to measure meaningful resistances in circuit since your meter will see all the input circuitry of the ICs. Of course if you had found for example 0.2 ohm, you would have a short for sure. But with 44 ohm, it's hard to tell.

However, A23 staying low at least explains the bus error, because the Glue will then see an access to $7C0030 and will thus not select the ROM.

[Sassa]

I am replying to myself again.

I forgot to mention that the motherboard has the footprint for blitter and that A23 is connected there, but it is not populated.

I cut the trace near glue and the input of glue is not shorted.
I the desoldered the pin on the cpu and managed to remove its contact to the motherboard : the short is inside the CPU.
On the now disconnected trace, there is a 10k ohm pullup to +5v.

Well, Now I guess I have to find a replacement CPU ! (Or maybe you can tell me if it is a feature, not a bug ).

However I am quite surprised that such an address pin that is not connected to the outside world can blow ? Could it be an overvoltage on the +5v through the pullup resistor network when the PSU died ?
I hope that Glue or any of the other chips is not burned the same way !

[Sassa]

Hi,
Some news after a long time !

I finally received the new used CPU today, and I installed it as soon as I came home. I used a socket so that it it can be easily removed if needed.

I put back everything and powered it up, but it seems it will need some more help to work.

Here is the first capture from the logic analyzer.

New CPU 1.PNG

The good point is that it goes past the beginning of the ROM addresses and does something for the first 30 ms (wow, that's a lot of clock cycles compared to before !). But then BERR triggers.

When looking at the end of the capture, I can see that some addresses are accessed after the BERR signal. What dou you think about that ?

New CPU 1b.PNG

[czietz]

When looking at the end of the capture, I can see that some addresses are accessed after the BERR signal. What dou you think about that ?

The CPU is doing its bus error exception handling. But then another critical fault (address error, maybe) occurs, the CPU double-faults and halts.

[Sassa]

Thanks czietz,

I checked that the captures are always the same at every reboot, even when using other ROM chips. I'll check that all CPU pins have continuity to the motherboard.

[Sassa]

Here is a combination of four captures including all address lines of the CPU and DTACK. Just before BERR.

NCC.PNG

I'll try to decode the last addresses it's trying to reach, maybe it'll show something...

[czietz]

At first glance the last address looks like $FCxxxx. That's good because it pinpoints to the last instruction in ROM that is executed. Do you still use French TOS 1.02?

[czietz]

If I decode that correctly, the last read word from ROM comes $FC01D4. In TOS 1.02 this is in the beginning of the loop that clears RAM. This loop starts clearing RAM 2 bytes below phystop, then all the way down to $400. One can also see from your trace that the bus error happens while accessing $FFFFFE. So my theory is that TOS on your computer does not detect any RAM, settings phystop to $000000. Thus the clear loop starts at $FFFFFE, causing the bus error.

[czietz]

PS: I can reproduce the error when -- using the Hatari debugger -- I force the amount of RAM detected by TOS to be 0. (And I might have discovered a Hatari bug in the process.)

However, what causes this for you is hard to diagnose. RAM access problems can be caused by the RAM itself, the MMU, the buffers between the RAM and the CPU data bus... Now that you got the CPU to work, a diagnostic cartridge would surely be helpful.

[Sassa]

Wow, czietz, I admire your knowledge ! I am quite embarassed because you did all that hard work. Thanks again.
Yes, it is still the french Tos 1.02.
I'm back to work. First I'll check the supply voltages from the buffers and ram chips, then probe the signals on them : maybe I'll find another dead trace there.