Amiga 2000 UDS/LDS Failed in Diagrom

[Kepler]

Hi all,

I hope someone could help advise what I should do next to resurrect my green screening Amiga 2000.

Some background: Usual battery damage which I cleaned and then repaired a few tracks. The machine was briefly working at this point and then stopped - green screen.

I then replaced the processor and Kickstart socket for good measure. No change.
I then socketed the first four DRAM ICs. No change.

Diagrom produces the attached result.

What should I do next?

I have a scope and logic probe.

Thanks!

[Castellen]

The image shows random garbage being read back from the memory.  Is it even being written to?  Monitoring _WE (write enable) during the memory test will show if a write cycle is being performed or not, which will determine what fault finding direction to go in next.

The fact that it was working suggests it's likely to be caused by a cracked or open circuit track as a result of the corrosion damage.  The corrosion damage will generally be confined to a fairly specific area.  I'd suggest removing the DIP68 socket and the resistor network near pin 1 of the 68000, then measure continuity of the top side tracks from the via and pads onwards around the pin 1 area of the 68000.  It's fairly quick and easy to identify open circuit tracks this way as you can see where they go without the DIP68 socket in place.  Any tracks that look marginal should be repaired, a wire strand from a scrap of IDC ribbon cable is ideal for track repairs.

Also replace the resistor networks if they look corroded to avoid any future problems.  And check you've not damaged any tracks or pads when replacing the DIP68 socket, which can cause this type of fault as well.

Repairing obvious problems in the corroded area is usually the faster approach in this case, as fault tracing memory access problems can often be complex and time consuming.  Especially when you're trying to explain how to do it by exchanging messages on a forum.

[Kepler]

"Monitoring _WE (write enable) during the memory test will show if a write cycle is being performed or not, which will determine what fault finding direction to go in next."

I assume you mean by looking at _WE with my scope? What should I be looking for?

[Castellen]

I assume you mean by looking at _WE with my scope? What should I be looking for?

You'd be looking for a write cycle happening, which will be when DiagROM writes test data to the memory, which it does before it reads the same location (address) back to compare if what was read back matches what was written, which is clearly broken in your case.  _WE (Write Enable) at the DRAMs will only go active (low) when the system attempts writing something to the memory.  The write cycle will be very short, in the order of a few microseconds or so, so you'll likely need a storage scope to see it.

Just to state the obvious, when a signal name is written as _WE or /WE it means active low.  That means the signal will be high (at 5V) all of the time while it's inactive, and when it's active it will be low (0V).

That will tell if you if the system is actually trying to write something to memory.  If not, then it's likely to be some kind of addressing problem, which could be something like an open circuit address line somewhere, one or more open circuit lines with Agnus (which is the DRAM controller), or one or more open circuit lines with Gary (which is the system address decoder), etc.

If you are seeing write cycles, but the data being read back is garbage, that could also mean that the data written is also garbage.  Possible causes could be something in the data bridge being broken (U103 - U106), an address bus fault with one of the lower address lines, one or more open circuit lines with Agnus, connection problems with Gary, etc.  You could also look to see if you're getting constant activity on all DRAM Row Address Strobe and Column Address Strobe lines, which will of course need to include include the relevant activity on the DRAM address bus.

It's going to be a lot of work to diagnose where the fault is if you're not readily familiar with how DRAM access works.  Hence my previous suggestion of checking for physical damage to tracks/pads in the first instance, as that's where the problem is likely to be.