Severe Graphics Issues - A500 Rev6A, DiagROM 1.2.1

[Castellen]

Great fault description, I need to use this as an example for customers who love providing especially unhelpful descriptions such as "Not quite working right" and "Stuffed".


Q: Could a faulty Paula cause this level of graphics corruption alone or is it related to Denise and the video path?

Probably not.  But since Denise (video output) and Paula (UART, audio, disk drive, etc) share the same data and address buses, then a data/address bus problem would affect both subsections.

I'd suggest looking at the serial output from DiagROM to begin with, you need a null modem cable from the A500 serial port to another computer running a VT100 terminal.  If that's looking OK, then register bus address and data lines are at least working.


Q: Is it normal on Rev 6A boards for Denise pin 36 (CCK) not to connect to U41 pin 6? - I don't have that connection.

They're two different signals, so they won't be connected.  Same clock but _CCK_B is 180 degrees out of phase with CCK.


Q: I'm getting 0L while testing GND-X and GND-OUT connections on transistors E402-E405 and E434, around 0.8V from E431-E433 - Are any of those video path transistors faulty? Could they be causing these issues?

Not sure what you're measuring here, the Exxx parts are ferrite beads (low pass EMI filter), not transistors.  Essentially they're a direct connection between pins 1 and 3, while pin 2 (centre) connects to ground.


Q: I'm getting 1.07kΩ from R402 (4.7kΩ ±5%) and 3.69kΩ from R403 (4.7kΩ ±5%) - Are they faulty?

No, you're measuring these components in-circuit.  If you want to check them correctly, you need to disconnect one side since there will be multiple parallel resistance paths.  That said, it's extremely unlikely for a resistor to develop a 'low resistance' problem in this situation; that's the least likely cause of problems.


Q: Would you recommend reflowing Paula and Denise sockets before replacing them?

No, the solder joints are into plated through holes and rarely cause problems.  The socket contacts themselves do create a lot of issues however.  If the sockets appear to be damaged/corroded or are doubtful in any way, you should replace them.  Likewise, the IC leads need to be clean and not corroded or heavily oxidised.

Don't rule out a problem with the PLCC84 socket that holds the Agnus IC, as problems with this socket or contact between the socket and IC leads can also cause these kinds of symptoms, depending on which signal(s) are open circuit.  The reliability of these sockets isn't terrible, but are more likely to develop issues when the IC is removed/re-inserted, especially if the correct PLCC removal tool isn't used.  If screwdrivers, etc, are used to try and lever out the IC, it often cracks the corner of the PLCC socket, which then usually causes contact connection problems.


Q: Did you stumble upon an issue like this before?

Plenty of them, but that doesn't mean that everything that looks similar will have exactly the same root cause.  I'd start by checking the integrity of each line of the data bus (DRD) and address bus (RGA) at the Denise pins.  There should be 0-5V activity on each line, all of the time, which you need to look at with an oscilloscope.  If that looks OK, then check the three clock inputs to Denise, and _CSYNC all have valid 0-5V AC signals present.

[Castellen]

When I was buying the DiagROM, I saw the serial and parallel port diagnostic tools that DiagROM uses. I will definitely look into it more because it would make searching for a faulty data/address bus much easier.

DiagROM sends a lot of detail out the serial port at boot time while the monitor shows nothing, so that would be a good starting point to collect more information.  You can easily make a 3-wire null modem cable: TX, RX, ground - there should be plenty of guides on the internet of how to do this.  You just need another computer with a VT100 terminal (I use Term 4.8 on my A4000T), the main thing to configure is the serial speed of 9600 and disable flow control.

Essentially at this point, you're just looking if the serial data out is generally working or not.  If it isn't, then there's probably a common register data/address bus issue that's also affecting your video output.

You are right, I was trying to look for a faulty transistor and measured the ferrite beads instead. I was thinking that maybe I could check for a faulty transistor on the video path that is causing graphic issues, but couldn't find them on my mobo other than the ones in the Audio Filter and next to the Even CIA so I started to measure the ferrite beads for some reason lol. A faulty transistor probably isn't a cause of these issues.

The images you posted suggest that the RGB signals are likely being generated OK, and the video clocks/sync are likely OK, but the data getting to the video generator (Denise) is damaged or missing something.  A single missing bit (or two bits shorted together) in either the register address or data bus could cause this.

I was worried that maybe they were dead, but yes you are right they are just connected in a circuit. If they were dead, I would get 0L on my multimeter, not lower resistance readings like the ones I got now.

0L on most Ohmmeters means over-range, or open circuit in this case.  Even if the resistor was open circuit, which is extremely unlikely unless it was physically damaged, you'd still measure parallel resistances in the same circuit.  Meaning you'd not know if it was defective or not unless you took it out of circuit (un-soldered one end).  I'd suggest not wasting time with this as a resistor fault is very unlikely.

I pulled Denise, Paula, Gary, CIAs, ROMs and Agnus from their sockets more than a couple of times. I didn't pull the CPU out as I was afraid of breaking it with a screwdriver. A couple of months ago, while extracting Agnus from her socket with a PLCC extractor tool, I accidentally chipped one of her pins, so I bought a new Agnus (8372A). Maybe I damaged the PLCC socket while extracting her, but I'm not sure if I managed to do that in just 2 times that I was doing that. However, I might have accidentally damaged Paula and Odd CIA's (maybe even others) sockets because I was using just a flat screwdriver while extracting them.
As you mentioned, the Odd CIA socket looks worn off and I also broke a corner on Paula's socket and can clearly see that pin that is uncovered, so maybe they are causing issues. PLCC and IC sockets don't seem corroded or heavily oxidised, but I could check again with a microscope.

I gather the same fault was still present before you removed ICs and re-inserted them, etc?  i.e. Removing/re-inserting them made no change to the video issues?  That would make a socket contact issue less likely.  Though it's possible you may have introduced a secondary fault if there are bent/damaged IC leads that aren't making reliable contact with the socket.

Using a flat screwdriver to remove DIP (dual in-line package) devices is OK if you're careful.  You need to carefully work at each end to gradually lift both sides up.  I've seen cases where people have 'crowbarred' the entire IC up from one end, which bends all of the leads, and sometimes damage top side tracks on the PCB where the screwdriver gouges it.

It can be difficult to remove PLCC devices from sockets even with the correct tool.  That's why there are often holes in the base of the socket and in the PCB to push the IC out from the bottom side, sometimes the extractor tool can't grip enough in the IC corners, especially if they've been worn from previous extraction attempts.

However, I checked for a random connection between the mentioned IC socket's pins and a corresponding connected element and my multimeter showed that the IC socket pins were alright. But, maybe I missed on a connection that was actually faulty.
I also cleaned all of the mentioned IC sockets with 99% isopropyl alcohol, WD's contact cleaner and a toothbrush and also thoroughly cleaned the pins of those ICs with a q-tip and isopropyl alcohol a couple of times.

It's very difficult to check that the socket is reliably contacting all IC leads in this way.  Not only is it physically difficult and time consuming, just the act of a multimeter probe pressing on the IC lead can sometimes be enough to temporarily "fix" a poor/intermittent contact.  So it measures OK, but then goes open circuit after you remove the pressure from the probe.

I will now:

• check for faulty data (DRD)/address (RGA) buses
• check for faulty clock and _CSYNC inputs on Denise
• look into serial and parallel port diagnostic tools that would make checking for faulty DRD and RGA buses easier
• check for damaged/corroded IC/PLCC sockets and replace them (I will probably replace Paula's IC socket immediately as there is a broken corner)
• look into finer IC extractors that won't damage the sockets anymore - I have an IC pulling tool but it was too short for 40+ pinned ICs.

That's a reasonable approach.  A null modem cable is quick and easy to make if you happen to have the right D-range connectors, and will give you a few more clues before you proceed.

After that, it's quick and easy to check the address/data lines at Denise, which will determine where to look next.  Presumably you have an oscilloscope?  Else this is quickly going to get a lot more difficult.

[Castellen]

After I set up the null modem cable and the serial adapter like this (https://youtu.be/oGBFVtYDbM0?si=b5e1wQQPVQCGb6WZ&t=738 - starting at 12:18) to PuTTY on my PC, if there is a faulty data/address bus, I won't get anything or any info on the PuTTY terminal as there would be no serial output?

The null modem adapter cable in that video is correct, and it shows the normal/expected serial output at power on.  Follow whatever instructions they've provided.

With a new setup, you should quickly do a serial loopback test.  Set up the terminal as per the instructions.  Don't connect the DB25 connector to the Amiga yet.  Type anything into the terminal window, you shouldn't see any characters appear - if you do, disable local echo.  Now link pins 2 and 3 on the DB25 connector (use a pair of tweezers or anything similar) and type something, you should see the characters on the terminal window. That verifies TX and RX data are working correctly.

In the case of a data/address bus issue, you're likely to get garbage data out (or you've set the terminal serial speed to something other than 9600 baud). 

If you get good data on the terminal, it means the data/address bus at Paula is at least working correctly.

Could I do something better in order to test the sockets and is it even necessary or should I focus more on testing data and address buses with a serial port diagnostic tool?

It's less likely you've got a socket problem, as intermittent problems often change and sometimes get fixed when you remove/re-insert ICs; the sliding lead vs contact scrapes off thin layers of oxide.  You've obviously inspected the sockets visually, so you'd likely have seen a major problem such as physical contact damage or corrosion.

You need to look at the address/data bus signals at Denise to understand what's going on.  Once you do that, finding the cause of the problem suddenly gets a lot easier.  At the moment it's mostly guesswork.

I will have to get my hands on an oscilloscope because it would be much easier then testing the data/address bus connections with just a multimeter. I presume that I wouldn't get much info about them with a multimeter?

The multimeter won't help at all in this case.  You need an oscilloscope to view the AC waveform at each of the data/address bus lines, which can find an obvious problem very quickly.

By the way, I didn't mention much about my RAM expansion.

I'd suggest leaving it disconnected from the system for now.  The A500 should boot/run normally with the onboard 512kB of memory.  Adding the expansion at this point just adds more unnecessary complications.

However, I have a question about JP4. Something wrong happened to it while it was still owned by it's previous owner or during my testing.
For some reason, there is a hole in the mobo between JP4's two pins (Picture - https://imgur.com/a/AaE4yqK). I'm worried that it shouldn't be in that state and that there is something wrong with it.
I read that JP4 should be bridged for a NTSC output, but as my Amiga is PAL, I think that I should leave those pins unconnected and as they are - with a hole between them.
I'm just trying to be sure that I could leave it that way and that it isn't causing these issues.

The earlier Angus devices were PAL/NTSC specific, I forget exactly what the point of JP4 was, there's probably information on the internet about it.  In any case, that shouldn't stop it booting.

For reference, my A500 test board has a 8372A Agnus, and JP4 is open.  It's a PAL board - which has a 28.375MHz oscillator, as your does.  The NTSC boards have a 28.636MHz oscillator.

[Castellen]

Great, I'll order the cables then and modify the DB9 to DB25 to make it a null modem cable when they arrive. Thank you for the tips!
And if I don't get anything, at least I'll know that something is wrong with Paula's data/address buses too, along with Denise.

I'd suggest the approach of the DB9 to DB25 null modem adapter; keep the USB serial cable standard, not modified.  The main reason is that the USB - UART logic is usually in the moulded part of the DB9 connector.  So if you cut off the DB9 with the intention of adding a DB25 in place of that, the 4 wires in the cable will be the 5V supply and the USB differential data pair.  And that obviously won't work, the Amiga serial port needs RS232 data.

You can either make your own DB9 to DB25 adaptor, but if you're ordering connectors to do this, it's probably just as cheap/easy to order a pre-made DB9 to DB25 null modem cable to do the same job.  Be sure to get a null modem cable where the TX and RX wires cross over, as opposed to a straight-through DB9 to DB25 cable that will not work for this.