Atari 520ST help (glue chips?)

[Spirantho]

Hi people,

Was wondering if you might be able to help...

I have two Atari 520STs. One works, the other doesn't. I'm trying to fix the broken one....

This is what I get on the screen:

AtariST_BadScreen.jpg

The working Atari is a very early one. It's a revision 2 motherboard, expanded to 1MB.
Here's a picture of the motherboard (gratuitous Atari pr0n):

Atari520ST_Issue2.jpg

The non-working Atari is actually an STm, even though the case says Atari 520ST. The motherboard is a revision H:

Atari520STm_IssueH.jpg

Now, here's what I found.
The issue 2 has a CO25915-38 glue chip.
The Issue H has a CO25915-38A glue chip.

If I put the -38A glue chip in the issue 2, it behaves identically to the broken Atari.
If I put the known good -38 glue chip in the issue H (the STm), it doesn't change - it's still broken.
Swap them back again, and the issue 2 springs back to life, and the issue H is still dead.
(incidentally, for those who are concerned, yes, I do have the correct PLCC chip pulling tool!).

This leads me to some possibilities:
1) The -38A chip is dead (Which is why it doesn't work in the issue 2), AND there is something else wrong (which is why switching them doesn't fix the Issue H).
2) The -38A chip is not entirely backward compatible (which is why it doesn't work in the issue 2) and the -38 is not forward compatible (which is why the issue H is still wrong).

Can anyone provide me with any insight to what's wrong? I don't know much about fixing Atari STs (yet).

Thank you for any help!

[Nikolas]

I think your rev H is more dead then just faulty glue..
Try swapping mmu, maybe cpu too...

[Spirantho]

Sorry - I completed neglected to mention one important fact:

The machine works fine. It just doesn't display anything. It (appears to) boot fine from a floppy, and if I don't insert a floppy then after a while I can press keys to get the "beep" noise you should here in the GEM desktop.

Hence I very much doubt it's CPU or RAM. I tried switching MMUs too, didn't do anything. Also tried the video shifter, no change there. Only changing the glue did the issue 2 stop working.

[Spirantho]

A little update:

I dug out my Atari ST Test Kit.

First thing it says is
"I6 Bus Error Handling Failed". Which I believe means it didn't read the trap vector correctly.

Then the menu comes up, as it should.
It runs through all the tests ok, except one:
"T4 Video Counter in Memory Controller"

Obviously that sounds like the memory controller is bad, so I pull the CO25912-20 from my issue 2, and stick it in.
Try again, exactly the same error. Which implies the MMU isn't bad, it's something else - or the -20 revision isn't completely compatible.

Can anyone help?
Thanks to anyone who can!

Edit: Just tried the DMA chip - it's fine. So the MMU, Shifter, DMA and Glue are all fine....
Edit2: I think the I6 is a clue. It sounds like the addressing is wrong. Maybe the CPU is bad even though it appears to be good.... unless something else is borking the addressing somehow...

[Dal]

RAM?

[Spirantho]

Would that not show up in the RAM test? All 520KB checks out just fine...

[Nyh]

Interesting.
It looks like there are no video timing signals and the mono output signal is constant high (or white) as you can see the vertical retrace.

The video timing signals are all generated by the GLUE as is the DE signal.
For video output the DE signal should be high but then the video counter in the MMU should be running which is not according to your test equipment.

What does the computer do on an RGB monitor?

Hans Wessels

[Spirantho]

Thanks for all your help, everybody.

I don't have a colour monitor but I did try and connect it to a TV with the SCART lead - the TV just said "NO SIGNAL".

I agree about the timing being the problem. If the Glue is what generates the timers, what is the 32MHz crystal for?
The service manual I have doesn't have full schematics I don't think, so I don't know what the circuit does. I'm thinking perhaps one of the 2N3904s has gone bad or something...? The chips all check out (not tested the CPU but that seems fine) so it's probably something solid state.

[Dio]

The 32MHz crystal generates a master clock which is nudged into phase with the colour clock (on modulator models) and subdivided via the Shifter, MMU and Glue to feed the various chips on the board. I would have thought a failure in the clock chain would result in a completely dead machine.

[Nyh]

Thanks for all your help, everybody.

I don't have a colour monitor but I did try and connect it to a TV with the SCART lead - the TV just said "NO SIGNAL".

I agree about the timing being the problem. If the Glue is what generates the timers, what is the 32MHz crystal for?
The service manual I have doesn't have full schematics I don't think, so I don't know what the circuit does. I'm thinking perhaps one of the 2N3904s has gone bad or something...? The chips all check out (not tested the CPU but that seems fine) so it's probably something solid state.

The 32 MHz crystal generates the master clock. The shifter uses the 32 MHz to shift the mono pixels (16 MHz for medres pixels and 8 MHz for lowres pixels) and divides the 32 MHz into a 16 MHz signal. The MMU divides this signal further into a 8MHz (the 8 MHz for the processor, GLUE, BLITTER, DMA) and a 4 MHz (MFP) signal. The GLUE uses the 8MHz signal too for all its timing, the Hsync, DE and Vsync signals are derived from this clock. The GLUE also generates a 2 MHz (soundchip) and 500 kHz (ACIAs) clock.

One of the transistors could be gone indeed. If you have an oscilloscope you could see whether the GLUE generates the VSYNC, HSYNC and DE signals (when not GLUE bad) and where they cease to exist.

Hans Wessels

[Spirantho]

Right, back to work on this.

First off, we can forget about the I6 error - it does that on my working ST.

Now, I measured the pins on the working ST (issue 2) and compared to issue H. The main difference was in the pins 21-26. On these, I measured (in volts) 0.15, 0.14, 0.02, 0.16, 0.16, 0.04 on the working, but on the bad one they were all 0 or just above (0.01 or 0.02).

However, I can't find the pinout for the chip so I don't know what these lines do! Can anyone help?

Edit: I bet those lines are the data or address lines, probably the data lines....
I also measured the transistors, they all seem the same between the two, and I think as the clock goes into the shifter before anything else, the whole machine would be dead.
I'm still confused by why putting the CO25915-38A into the issue 2 makes the issue 2 behave like the issue H - EXACTLY like the Issue H. The machine does the same thing, and fails the same test - T4 Video Timing Counter failed. Put the -38 into the issue H, though, and it's the same - T4 counter failed.

I think the next step is to bring in an STfm from home and try the -38A in that...

[Spirantho]

Pardon my replying to my own post, but I'm getting desperate now so need it bumped.

I have now checked all the MMU/GLUE/Shifter/DMA chips. The MMU was bad, but is now changed with a working one.
I have changed the 74LS244 chips with new 74F244 ones (which should be fine, they're just a bit faster). I changed the 74LS373 chips.
I changed the electrolytic capacitors.

I'm kind of stumped now. I even tried changing some of the transistors around the shifter.

The only thing I can see that's odd is on my issue 2, the clock input to the shifter is clearly doing stuff. My oscilloscope is only a 10Mhz one so can't show the signal correctly, but there's clearly a signal. On my broken issue H, I can't see the signal, it looks like no clock... but the chips are all working, the CPU is running, and the MMU is chucking out what looks like a 4MHz signal on pin 19, as it should, so I think that's a red herring.

Can anyone give any further advice? Is it worth changing the CPU (wish it wasn't soldered down!)? The test ROM executes perfectly so it shouldn't be that at fault. If the CPU was having troubles I'd expect the DMA test to fail too.

I just don't understand why the counter in the MMU is wrong, but then I don't know much about the ST architecture (still learning!).

Thanks to anyone who can give me more advice! This is getting really frustrating!

[Nikolas]

You can check ram lines, maybe one of broken resistor.
Check psu +5v +12v (put other psu) voltages on mainboard -5v -12v etc..

Even try with resoldering suspected areas...

[Spirantho]

Could the voltage have that effect? All the RAM checks out just fine, 520K ok. I don't recall -5V/-12V being used in the video circuit.
Have tried reflowing the solder on the Glue and the MMU, and various other parts...

Thanks for the ideas, though!

[Nyh]

Can anyone give any further advice? Is it worth changing the CPU (wish it wasn't soldered down!)? The test ROM executes perfectly so it shouldn't be that at fault. If the CPU was having troubles I'd expect the DMA test to fail too.

Check the following pins on the GLUE:
I assume a 50 Hz ST low screen (just connect nothing to the monitor port and you have it)
36: BLANK, high low with a frequency of 15625 Hz, port is used to ground the RGB channels during the HBL and VBL
37: HSYNC, high low with a frequency of 15625 Hz
38: VSYNC, high low with a frequency of 50 Hz
39: DE, display enable, high low with a frequency of 15625 Hz, when DE is high, the MMU starts feeding the shifter with screen data and the shifter starts outputting screen data instead of the border color.

All these signals are generated by the GLUE. If they aren't available here on GLUE either the GLUE is broken or the signal is short circuited to 0 or 5V somewhere.

Hans Wessels

[Spirantho]

Here's my oscilloscope readings... All seem to have a signal on them....
Apologies for the picture quality! I tried to at least get something visible...

[Nyh]

Here's my oscilloscope readings... All seem to have a signal on them....
Apologies for the picture quality! I tried to at least get something visible...

I don't like your HSYNC signal. It should look like this:

HSync.png

From your picture it looks like it oscillates. Note: I measured this signal on pin 9 of the monitor port, but it should be the same on the GLUE.
I also measured the VSYNC signal on pin 12 of the monitor port (note, this computer is running in 60Hz mode):

Vsync1.png

And zoomed:

VSYNC_zoomed.png

Hans Wessels

[Spirantho]

Yes, your display looks like what I would expect.

HSYNC should be triggered each time a new row starts... yet I'm only getting groups of 4 or whatever at a time.

What generates the HSYNC? I believe the GLUE chip does, what makes the GLUE trigger an HSYNC? It must have a timer of some kind....
I still can't understand why the oscillator going into the shifter seems so low compared to the working ST, but at the same time the machine appears to be working, so it must be getting a signal, and the 4MHz out of the MMU looks fine.

There must be something which the GLUE is using as a basis for its HSYNC - maybe the MMU, as the test kit says? It's difficult to know which is cause and which is effect.

Thanks very much for those pictures, it's appreciated! I think tomorrow I'll be comparing against my Issue 2 again.

[Dio]

The HSYNC is entirely internally generated by the Glue, every 508 8MHz clock cycles in 60Hz and 512 in 50Hz.

[Dal]

Maybe the clock input into the glue chip is weak?

[Spirantho]

So could the GLUE require a stronger signal than the other chips, perhaps...?

This would explain that I'm seeing the weak signal from the 32MHz crystal (which, of course, I've already tried in the issue 2 and it's fine). I also tried changing some of the transistors next to the crystal.

What could be causing the signal to be strong enough to trigger the MMU, CPU and Shifter, but not the GLUE? All the electrolytics have already been replaced...

Edit: Thought: On Issue 2, both sides of the crystal give an oscillating signal. On the resistor/coil->ground side, there is a faint signal. On the transistors->Shifter side, the signal is noticably stronger. On Issue H (the broken one), there is a strange signal on the resistor/coil side and very little on the Shifter side. Now resistors and coils very rarely go wrong, but if the inductance had changed...
I tried using the capacitor from Issue 2 which connects the resistor/coil to ground in place of the diodes - no change, so it's not the diode at fault. Maybe I should try testing the coils from issue H in issue 2 and see if anything happens...

[Nyh]

I still can't understand why the oscillator going into the shifter seems so low compared to the working ST, but at the same time the machine appears to be working, so it must be getting a signal, and the 4MHz out of the MMU looks fine.

There must be something which the GLUE is using as a basis for its HSYNC - maybe the MMU, as the test kit says? It's difficult to know which is cause and which is effect.

I don't believe the problem is in a weak GLUE clock. Your DE and BLANK signals are OK and they are generated from exactly the same clock. The blank signal is (HSYNC AND VSYNC) and that signal is OK.

Either the GLUE is broken or something else is messing up the HSYNC signal and the GLUE cannot cope.

The counter in the MMU is the video address counter. It counts when DE is high. The counter is reset to the video base address by the VSYNC signal. The MMU uses the counter to fetch screen data from memory and feed it to the SHIFTER.

Hans Wessels

[Spirantho]

The GLUE is definitely OK, it's from a working ST. I've checked by switching the GLUE, DMA, MMU and Shifter with an STfm and they're all fine.

I'm going to compare the signals with my working STfm next....

[Spirantho]

Interesting...

I think the HSYNC is OK, actually - when I put it on the same parameters as yours, I get the same picture. It's just a lack of resolution on the scope at the settings I had that made it look like that.

The interesting bit, though, is that the VSYNC looks right timing but is MUCH weaker. On my STfm, when I move from pin 37 to pin 38, it goes from lots of troughs, to one trough of the same amplitude. On my broken ST, pin 37 has lots of troughs, but pin 38 has a sporadic trough of a much lower amplitude. You can see on the photo above that the VSYNC pin is a quieter trough than the HSYNC - and you'll notice it's already set to 20mV instead of 50mV so it should be much bigger.

Could this be a clue...?

[Nyh]

The interesting bit, though, is that the VSYNC looks right timing but is MUCH weaker. On my STfm, when I move from pin 37 to pin 38, it goes from lots of troughs, to one trough of the same amplitude. On my broken ST, pin 37 has lots of troughs, but pin 38 has a sporadic trough of a much lower amplitude. You can see on the photo above that the VSYNC pin is a quieter trough than the HSYNC - and you'll notice it's already set to 20mV instead of 50mV so it should be much bigger.

Could this be a clue...?

Yes. That is a clue. Now why is this signal so weak? What is pulling down this signal so hard (it should be 0-5V, I used a 1:10 probe and the scope was on 200 mV/div). There should be a 22 pF capacitor to 0V and a diode (IN914) for the composite sync on the line.

Hans Wessels