Severe Graphics Issues - A500 Rev6A, DiagROM 1.2.1

[poroxius]

Hello dear Amiga lovers! I am currently having weird graphic issues while testing my A500 with a DiagROM 1.2.1. I can't use DiagROM normally as I'm having severe graphic issues which I first have to resolve in order to fix my A500 that isn't booting properly.
I will describe the issues I'm getting below as best as I can and I'll gladly answer more of your questions about them.

Hardware setup

• Amiga 500 Rev 6A motherboard

• Kickstart 1.3 (currently testing with DiagROM v1.2.1 in ROM socket)

• Gotek switcher for Even CIA

• Gary resistor mod (4.7kΩ between VCC and EXRAM — measured 4.62kΩ) - I have a RAM extension, but it currently isn't connected to the motherboard.

• RGB to SCART cable → Sony TV that is used in the pictures below (also tested on 1084S with RGB-to-DB9 cable, getting same results)
  

Initial symptom (Kickstart 1.3)

• Power LED: 10 short + 1 long flash × 3 cycles, then yellow screen. (Sometimes reaches the Kickstart 1.3 screen after flashes, but no floppy/Gotek activity.)

DiagROM behaviour

• All of the images and videos below were taken when my A500 was connected via a RGB to SCART cable to my Sony TV. I'm currently testing with my 1084S-P1 monitor.

Main menu

• Getting a light green background with black (sometimes red) text, flickering black bars (in current testing blue). Navigating through the menu sometimes doesn't work as it doesn't recognize keyboard input.
• Video here - https://imgur.com/a/diagrom-1-2-1-main-menu-U3tbx0a

System info

• Appareantly Paula is bad, but I’m not getting any info regarding the $1114 being readable at the certain addresses - no text (YES/NO) next to them (due to graphics probably).
• It seems that it reads all RAM chips (512kB is read).
• Image here - https://imgur.com/a/system-info-BC2LMfp

Audio tests

• I’m only getting obnoxious buzzing while testing the songs in the menu. I’m not sure if it’s because of the RGB and Audio to SCART cable or something is wrong with Paula, as the System info suggests.

Memory tests
Test detected chipmem

• I'm not getting much more than this. I suspect that the whole test didn't go through or the graphics are so bad that much of the valuable info isn't shown.
• Image here - https://imgur.com/a/test-detected-chipmem-6eRu7on

Extended chipmem test

• I'm getting the same info as on the detected chipmem test.

Test detected fastmem

• Graphics on this test were so bad that I got nothing except “Press any key/mouse to continue”. Pressing any key or mouse button doesn’t work at all.

Fast scan of 16MB fastmem areas

• Again, didn't get much info because the test didn't go through fully or due to bad graphics.
• Image here - https://imgur.com/a/fast-scan-of-16mb-fastmem-areas-SBVLxHW

Slow scan of 16MB fastmem areas

• Getting the same info as for the fast scan.

Complete memory detection

• I'm not sure if it's supposed to be like this, but I'm not getting much info from this.
• Image here - https://imgur.com/a/Bc9Cj5H

IRQ/CIA Tests
Test IRQs

• Again, no info whatsoever.
• Image here - https://imgur.com/a/bVYn9Rr

Test CIAs

• I'm only getting a pitch black screen.

Graphic tests

• There is definitely something wrong with graphics, which you will see below (along with the previous images)

Testpicture in lowres 32col

• I'm getting wrong colors, flashing screen, but readable text. The graphics are way off.
• Video here - https://imgur.com/a/Ny5mybo

Testscreen 320x200

• First I'm just getting a white screen but then the green and purple graphics that suggest that something is wrong.
• Video here - https://imgur.com/a/testscreen-320x200-gJVQJKo

Test scroll

• Upon clicking it just sends me back to the Graphics test menu.

RGB test

• I'm getting wrong colors, mainly green and purple instead of red, green and blue.
• Video here - https://imgur.com/a/rgb-test-E7YfXDP

Port tests and drive tests

• I don't have a loopback connector connected to my A500, so I didn't do port tests. Also, I don't have a floppy or Gotek drive connected, so I'm not testing the drives yet.

Keyboard test

• While testing this a couple of days ago, I managed to get in the Keyboard testing menu and test my keys. They all seemed to work. I'll explain my A500's current state below.

Current state of my A500

• My A500 is currently connected to the 1084S-P1 monitor. When I turn on my A500, I'm getting a screen that blinks various colors before booting to the main menu that is still green. Now I can't click anything on my keyboard or test anything and the menu gets blue after a while. It appears frozen.
• I suppose that something is wrong with Denise and/or Paula.

My question for the experts

• Could a faulty Paula cause this level of graphics corruption alone or is it related to Denise and the video path?
• 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.
• 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?
• I'm getting 1.07kΩ from R402 (4.7kΩ ±5%) and 3.69kΩ from R403 (4.7kΩ ±5%) - Are they faulty?
• Would you recommend reflowing Paula and Denise sockets before replacing them?
• Did you stumble upon an issue like this before?

I hope that my troubleshooting is helpful so you could tell me what is wrong with my Amiga. I can't wait to fix it in order to play my favorite games once again. Amiga forever!
- poroxius, August 10, 2025

[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.

[poroxius]

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".

I'm very glad that my description includes valuable information ! I was afraid that maybe it wasn't in detail and that I could have written more, and I'm open to any questions about it.

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.

You are right, there might be something wrong them as the graphics are pretty bad and System info suggests that Paula is bad, so it's not only Paula. I will definitely check their data/address buses as that is possibly the cause of fault.

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.

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.

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

Great! I was worried because I was using https://www.amigapcb.org/'s Rev8A schematic that shows a CCK signal connection between Denise & U41 and was worried that the Rev6A also has it, but that there is something wrong with it on my mobo. Turns out that Rev6A doesn't have the same connection.

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.

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.

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.

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.

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.

This was actually a big part that I did in my testing and didn't mention here.
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.
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.

Plenty of them, but that doesn't mean that everything that looks similar will have exactly the same root cause.

You are right, every Amiga is weird and beautiful in it's own way, so it won't be easy finding out what's wrong.

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.

Thank you so much for your helpful reply! It made ruling out what's wrong much easier! Now I'm one step closer to playing Shadow of the Beast again!
- poroxius, August 11, 2025

[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.

[poroxius]

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.

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?

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.

Oh, got it! I didn't keep in mind that most of the resistors are connected in a parallel circuit, it makes sense now! I won't consider them as a possible fault any further.

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.

Exactly, upon removing and re-inserting ICs nothing changed at all. I did that as it is one of the easiest tests I could do in order to determine what's wrong and potentially fix it that way. But, it wasn't the case for my A500 .

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.

I think that I was careful as I was working each end carefully and equally, and thankfully didn't bend a lead. Crowbarring them is definitely the worst thing I could have done to the ICs so I kept that in mind.

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.

Yes, especially if the PLCC extractor isn't a high quality one. The holes on PLCC's corners really make extracting Agnus easier.

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.

It indeed was very time consuming lol. 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?

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.

I will definitely make a null modem cable and test my A500 with the serial output.
I was thinking about making it like this:

• get a FT232 USB to DB9 M cable
• connect the USB to my PC and DB9 M end to the DB9 F end of a regular DB9 F to DB25 F cable that I will turn into a null modem one
• connect the DB25 F end to the A500's serial port

There is no point in testing just with DiagROM inserted to my motherboard as the graphics are so bad that I'm not getting much info from it apart that something is wrong with the graphics.
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?

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

It wasn't inserted into the RAM expansion slot but when I connected it now -  I got the same green screened frozen menu, but DiagROM read the additional 512kB and now I'm reading 1024kB of memory, which probably means that there is nothing wrong with RAM on my mobo and RAM on the expansion.
I went and checked if maybe the connections of jumpers JP2 and JP7A are causing issues - JP2 pins 1 and 2 are connected together and JP7A is left floating, their pins aren't connected. According to https://www.retrosix.wiki/jumpers-amiga-500, my Amiga should boot normally with those connections, which it does so none of the RAM expansion jumpers are connected wrong.

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.

Again, thanks so much for your reply! I will definitely get a null modem cable and test the serial output. Also, I will get an oscilloscope so I could test the data/address buses.

[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.

[poroxius]

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.

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!

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).

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.

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 are right, the sockets don't look corroded or oxidized so I won't worry about them any further.

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.

I'll do some research about the JP4, but if it isn't stopping my A500 from booting, I won't worry about it too. I stumbled upon some info that it has to do something with PAL/NTSC, but will look into it more.

Again, thanks so much for your help! Your tips are really helpful and will make the process of fixing my A500 much easier. I will order the cables and try to get my hands on an oscilloscope and test the data/address buses - they are really good tools that will make repairing easier. Until now, the progress of repairing was slow and the diagnostics I got from DiagROM and Kickstart indicated that something is wrong, but I would still need to do a lot of work to figure out what's specifically wrong with the tools that I have (DiagROM, multimeter and basic electronics knowledge).

I'll get back to you with the info I'll get from the serial testing when I get the cables and the results of testing the data/address buses with an oscilloscope.
Thank you!
- poroxius, August 13, 2025

[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.