Amiga 600, kept in reset

[hadoque]

Hi
I'm troubleshooting an Amiga 600 board which I recapped. There where capacitor leaks in several places and some corrosion damage, so the possibility is that my problem is due a short or open that I haven't found to fix. The problem is that the board is kept in reset when powered. I'll try to summarise what I have measured on the board:

1. _RST low, measured on CPU:20, GAYLE:40, U32:17
2. _HLT high, measured on CPU:19, GAYLE:39
3. _KB_RESET high, measured on GAYLE:63, Q511:3
4. VCC on GAYLE:20 between 4.8 and 5.2, depending on which PSU I use.
5. 7 MHz clock on CPU:15, 7MHz
6. 28.6 MHz clock on AGNUS:16, 28.6MHz

The low level on _RST seems a bit unstable. Sometimes it's rising slowly, and on occasion it seems to go over the high level of _RST, because I have seen the computer get to light grey screen, dark grey screen, red screen or green screen sometimes , when I touch randomly on the board or put a probe tip on _RST. I have also seen flickering between these different coloured screens.

I'm thinking that Gayle should drive _RST up, with _KB_RESET being high, but that something is driving it the other way. I'm considering to start lifting chip legs , connected to _RST, to narrow down the faulty candidates, but I'm not super happy about doing that, with the risk of damaging the chips.

So does anyone have any idea about other things I could do/check?

Is there anything other than _KB_RESET that can get GAYLE to hold _RST low?

[solarmon]

The CPU itself can assert _RST (and _HLT).

Have you checked the 555 timer (U14) and associated caps and resistors - C612/R612, and C611/R611? If these are faulty they can keep _KB_RESET low.

[hadoque]

Originally Posted by solarmon

The CPU itself can assert _RST (and _HLT).

Have you checked the 555 timer (U14) and associated caps and resistors - C612/R612, and C611/R611? If these are faulty they can keep _KB_RESET low.

_KB_RESET is high, so there shouldn’t be a problem with the 555 circuit.

[solarmon]

What revision is the A600? And what colour screen do you get?

Does the reset circuit assert _KB_RESET briefly on boot?

And what happens when you do a keyboard reset with CTRL-Amiga-Amiga?

You could also try to manually pulling _RST high by shorting it to VCC briefly and see what happens.

If something is shorting _RST to ground then it will get hot - so try to fing any unusually hot ICs or components.

[hadoque]

Originally Posted by solarmon

What revision is the A600? And what colour screen do you get?

Does the reset circuit assert _KB_RESET briefly on boot?

And what happens when you do a keyboard reset with CTRL-Amiga-Amiga?

You could also try to manually pulling _RST high by shorting it to VCC briefly and see what happens.

If something is shorting _RST to ground then it will get hot - so try to fing any unusually hot ICs or components.

Revision is 1.5.
I don't have a keyboard, just running the bare motherboard, but I guess I could do a soft reset by grounding the appropriate pins, the ones going into the NAND gate that controls _KB_RESET.

I am getting some heat from chips, I don't know if it is normal levels though. Nothing burning hot, I would guess around 40-45 degrees Celsius.

I will do like this: next week I'll take the board to work, there I can measure _KB_RESET and _RESET with a digital scope, during start and soft reset (only have an analog scope at home). I can also take a picture of the board with our IR-camera, to see if anything stands out.

A thought though, wouldn't it be odd if a chip with a _RST input failed shorted to ground? I mean, most chips don't have drivers on the _RST line, only inputs, and inputs usually fail as high impedance, or am I wrong?

Another thing, I measured resistance between _RST and GND when the board was unpowered. It was off the scale high, so there are no passives that are shorting the line.

[solarmon]

If you believe that no passives are shorting to ground, then the only thing I would suspect is the CPU, as this is the only other thing that can assert _RST. The CPU must have an issue, or it detects an issue - i.e. some issue with data and address signals to the memory chips, and to/from Gayle and Agnus.

I would also suspect U32, the 74HCT244 chip. That might be the easiest first thing to replace.

[hadoque]

Originally Posted by solarmon

If you believe that no passives are shorting to ground, then the only thing I would suspect is the CPU, as this is the only other thing that can assert _RST. The CPU must have an issue, or it detects an issue - i.e. some issue with data and address signals to the memory chips.

Yeah, that was what I was thinking too at first, but then I read the manual for the CPU, and the only normal way for the CPU to assert _RST is by giving it an instruction to reset, it does not seem to be able to reset on its own account. It seems unlikely that some other chip (other than Gayle, which already can reset using the reset line) is able to give it a reset signal when the system itself is already reset.

[tech3475]

Originally Posted by hadoque

Yeah, that was what I was thinking too at first, but then I read the manual for the CPU, and the only normal way for the CPU to assert _RST is by giving it an instruction to reset, it does not seem to be able to reset on its own account. It seems unlikely that some other chip (other than Gayle, which already can reset using the reset line) is able to give it a reset signal when the system itself is already reset.

Agnus is also a possible candidate as it's connected to reset:
https://www.amigawiki.org/dnl/schematics/A600_R1.5.pdf

[hadoque]

Originally Posted by tech3475

Agnus is also a possible candidate as it's connected to reset:
https://www.amigawiki.org/dnl/schematics/A600_R1.5.pdf

Bur Agnus cannot drive the reset pin, right? Only Gayle and the CPU can(?)


Is there any detailed description on how Gayle works? I haven't found one.

[tech3475]

Originally Posted by hadoque

Bur Agnus cannot drive the reset pin, right? Only Gayle and the CPU can(?)


Is there any detailed description on how Gayle works? I haven't found one.

I don't know, but I figured that with it on the reset line it wasn't beyond the realms of possibility if there is a fault.

Unfortunately this is the closest I can find so far:
http://eab.abime.net/showthread.php?t=35282

[hadoque]

Originally Posted by tech3475

Unfortunately this is the closest I can find so far:
http://eab.abime.net/showthread.php?t=35282

That’s great, thanks!

[hadoque]

Ok, I did some measurements at work. I'll adress them in a list:

1. tek00003.png: Blue (Ch1) VCC, Cyan (Ch2) _RST, Magenta (Ch3) _KB_RESET . We can see that something wants to pull _RST up when _KB_RESET is pulled up. Also there is a lot of noise on _RST.
2. IR00008.PNG: IR image of board. Highest temperature is 56 degrees. I don't think anything stands out. Gayle is could though, I don't know if that's normal.
3. IMG_3159.jpg: Reference of the board to be compared to the IR-image
4. IMG_3161.png and -64.png. Zoom in on _RST. There is a square wave noise with about 2/3 cycle and with a frequency of 700kHz.

So, it would be interesting to figure out where that square wave is generated.

Also, I tried doing a keyboard reset, but it didn't do anything new, just the same thing as when _KB_RESET was asserted/deasserted at power on.

[hadoque]

IR-image can be compared to thermal footprint of Amiga 600 from another thread: http://eab.abime.net/showthread.php?t=93782

Looks very similar to me.

[Hewitson]

Originally Posted by solarmon

You could also try to manually pulling _RST high by shorting it to VCC briefly and see what happens.

Do not do this without using a resistor to limit the current! You'll have a dead short between 5V and ground, otherwise.

[hadoque]

Originally Posted by Hewitson

Do not do this without using a resistor to limit the current! You'll have a dead short between 5V and ground, otherwise.

Good call!

[hadoque]

Ok, so now I have tried forcing _RST high. The board then goes through the black, grey, white boot process and then it’s stuck on white. I’m starting to suspect the CPU, am I on the right track?

[solarmon]

From your heat map, it looks like the CPU is the hottest. So I would still suspect this.

Was the A600 working before the recap? Was there any cap leakage damage that could have caused corrosion that could break a trace or cause a short? This could also happen underneath components which is not visible to the eye until you remove it.

What colour screen do you get when _RST is kept low?

You should really connect a keyboard and see whether CTL-A-A does anything and whether there are any LED flashes on the keyboard that could help troubleshoot.

[hadoque]

The computer had not been started for 6 years, and it had several places with corrosion, so it’s not impossible that there is damage causing these problems, though I’m really not seeing symptoms associated with the _RST problem that indicates a corrosion problem on traces, possibly that corrosion has damaged chips.
I did not start the computer before recapping, because of the corrosion, I didn’t want to ruin it with a short or similar on power on.


The screen is stuck on white when I keep _RST high, when _RST is kept low, screen stays black.


I don’t really need a keyboard to do a soft reset, I just trigger the 555, and that doesn’t give any other behavior. I have wired up LEDs to the LED output connector, so I can see if anything would be blinking, and I only get a steady power on light.


I guess removing the CPU is inevitable, any other ideas of tests I can do before that?

[solarmon]

I was suggesting the keyboard so that you can check whether the keyboard MPU (U13) is working OK, along with the other components that lead to _KB_RESET.

I've drawn up this diagram to summarise what components are associated with _KB_RESET and _RST:



This is obviously already detailed in the schematics, but I wanted a summarised view that showed everything, and in a form I could understand and annotate. So it may or may not help you at this stage.

You can see all the components that are connected to _RST, each one of these could be holding down _RST, for whatever reasons.

Or it could be a _RST trace that is shorted to ground. So I would use http://www.amigapcb.org/ to check those specific traces - that they have continuity and are not shorted to ground.

[hadoque]

The image is really low resolution, can you post one with higher? I can’t make out the text.

I don’t think there’s a short to ground, since _RST to GND is high resistance when power is off, but I will check against PCB layout to see if I can get any other clue. I didn’t know about amigapcb.org.