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.

[poroxius]

Hi! 13 days passed since I last got back to you and I have an update.

I was about to order the USB to DB9 cable and have realized something that could cause issues.
I read several reviews in the product description saying that the voltages are TTL level, instead of ±12V that TX and RX signals are using. I think that the cable in the attached link isn't a RS232 at all and that I need to search for a genuine USB to RS232 cable. The seller is probably selling a USB to TTL logic DB9 cable marketed as a USB to RS232 cable.

Question:
I'm worried that the TTL voltages could damage my Amiga and that I won't get any data on PuTTY upon connecting the A500 to my PC.
Should I be worried about that and instead get a USB to RS232 cable that's verified as working by other Amiga users or could I order the one that I've attached?

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.

Got it! I was thinking about doing it like this:
USB M (into PC) - RS232 M (into DB9 F) -> null modem DB9 F - DB25 M (into DB25 F-F gender changer) -> gender changed DB25 M (now F) into A500's serial port.

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.

I'll do it myself, I found a couple of helpful guides on doing so online!

- poroxius, August 26, 2025

[Castellen]

I'm worried that the TTL voltages could damage my Amiga and that I won't get any data on PuTTY upon connecting the A500 to my PC.
Should I be worried about that and instead get a USB to RS232 cable that's verified as working by other Amiga users or could I order the one that I've attached?

The AliExpress product says it's RS232, which is what's needed.  If it's actually 3.3V or 5V TTL (seems unlikely), it will not damage the Amiga.  But it won't work either since the TTL data and RS232 data are also the opposite polarity.

If in doubt, just buy a USB to serial cable from your local computer shop, they're commonly available and aren't expensive.  Or use a computer that has a serial port.

Got it! I was thinking about doing it like this:
USB M (into PC) - RS232 M (into DB9 F) -> null modem DB9 F - DB25 M (into DB25 F-F gender changer) -> gender changed DB25 M (now F) into A500's serial port.I'll do it myself, I found a couple of helpful guides on doing so online!

Looks like a complicated way of doing something simple.  It might work if the signals and up in the correct place through the various cables and adapters, but it's going to cause confusion if it doesn't work since you won't know if you have a cable problem or the A500 isn't sending out serial data.  You could just make a simple 3-wire DB9 female to DB25 female crossover cable in a minute and $1 of connectors - you don't need to waste time/money on backshells for a quick test cable.  I think that video you referenced might have had instructions on how to do this, which should be pin 2 - pin 2, pin 3 - pin 3, DB9 pin 5 to DB25 pin 7.

[poroxius]

The AliExpress product says it's RS232, which is what's needed.  If it's actually 3.3V or 5V TTL (seems unlikely), it will not damage the Amiga.  But it won't work either since the TTL data and RS232 data are also the opposite polarity.

If in doubt, just buy a USB to serial cable from your local computer shop, they're commonly available and aren't expensive.  Or use a computer that has a serial port.

I guess I could try ordering it from AliExpress as it's much cheaper than the ones I've found in my local hardware store. I'm worried because I read several reviews of that cable saying that the voltages are TTL level. TX and RX wouldn't get needed voltage that way, and TTL & RS232 treat different voltages as different logical values - due to TTL's low voltage I probably wouldn't get any data from PuTTY.
I think it would be safer to buy the one from the hardware store as they definitely aren't marketing a TTL cable as RS232.

Looks like a complicated way of doing something simple.  It might work if the signals and up in the correct place through the various cables and adapters, but it's going to cause confusion if it doesn't work since you won't know if you have a cable problem or the A500 isn't sending out serial data.  You could just make a simple 3-wire DB9 female to DB25 female crossover cable in a minute and $1 of connectors - you don't need to waste time/money on backshells for a quick test cable.  I think that video you referenced might have had instructions on how to do this, which should be pin 2 - pin 2, pin 3 - pin 3, DB9 pin 5 to DB25 pin 7.

Unfortunately, my PC doesn't have a DB9 port - that's why I definitely need a USB-RS232 cable. However, I think that I could make things more simple and just replace the DB9 F-DB25 M's DB25 M connector with a DB25 F. That way I wouldn't have to use a gender changer.

I'm not sure if I understand what you meant - I should just take some wires I have at home (I have some Dupont's jumpers I used to mod an OLED screen with FlashFloppy for my GOTEK drive and a 16AWG wire, but I suppose I could find a wire with more appropriate AWG), connect the according pins between DB9 and DB25's connectors and that way make a DB9-DB25 cable from scratch?

-poroxius, August 27, 2025

[Castellen]

I'm not sure if I understand what you meant - I should just take some wires I have at home (I have some Dupont's jumpers I used to mod an OLED screen with FlashFloppy for my GOTEK drive and a 16AWG wire, but I suppose I could find a wire with more appropriate AWG), connect the according pins between DB9 and DB25's connectors and that way make a DB9-DB25 cable from scratch?

See attached screen shot from the video you referenced above.  That diagram is correct, simply make a basic cable the same as that using two connectors and three short pieces of any wire.  That will work, whereas various combinations of cables and adapters might or might not work.

I've only spent a few seconds skipping through the video, though it likely contains all of the detail you need.

[poroxius]

That diagram is correct, simply make a basic cable the same as that using two connectors and three short pieces of any wire.  That will work, whereas various combinations of cables and adapters might or might not work.

Okay, got it now. I will order the DB9 F and DB25 F connectors from AliExpress and connect them according to the schematics with some jumper wires I have at home. I'll get the USB-RS232 from a local hardware store so I'll be sure that it's not TTL, but RS232.

Thank you for the info, I'll get back to you when I test it!

[poroxius]

Hi! A quick update:

I got a genuine RS232 M - USB M cable and made my DB25 F - DB9 F by connecting: DB25 pin 2 - DB9 pin 2 (TX), DB25 pin 3 - DB9 pin 3 (RX), DB25 pin 7 - DB9 pin 5 (GND).

I connected the RS232 M to DB9 F, the DB25 F to the A500's Serial Port and the USB M to my PC.

I opened up PuTTY, selected the serial connection type, selected the right serial line number (COM3), the right settings (9600 baud speed, 8 data bits, 1 stop bit, no parity and no flow control (tried also with XON/XOFF - same results)) and tested if I'm getting echo.

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.

I linked pins 2 and 3 on DB25 and successfully got the letters I typed back from the terminal - I see the characters I'm typing in the terminal, so TX and RX are working.

At first, I got the standard serial DiagROM output and got to the main menu.
However, the booting sequence was so fast that the part where you have to click your A500's RMB in order to control the menu with your A500 keyboard is so fast that if I click the RMB on my A500's mouse, I still can't control the menu with my A500's keyboard (as well as with my PC's keyboard).
Basically, I got to the menu after an alarmingly quick booting sequence, but couldn't control it.

Now, I'm not getting anything from PuTTY. I'm not doing anything different, I'm booting the same way as I did it previously, with the same cable setup, but am not getting anything from PuTTY.
I tried switching the TX on DB25 from pin 2 to pin 3 and RX from pin 3 to pin 2, but got the same results.

EDIT (September 15th, 2025):
I managed to get DiagROM's booting sequence and main menu for a while before it stopped working again and this time I copied the log it gave me (for some reason, it stopped during the Extra workareas chipmem test:

Testing ROM Address-access
  OK
Testing if serial loopbackadapter is installed: <> NOT DETECTED
    Checking status of mousebuttons at power-on:
            P1RMB P2RMB P1RMB P2RMB
    Set all Interrupt enablebits (INTENA $dff09a) to Disabled: Done
    Set all Interrupt requestbits (INTREQ $dff09c) to Disabled: Done
    Set all DMA enablebits (DMACON $dff096) to Disabled: Done

Testing if OVL is working: OK
- Parallel Code $fe - Test UDS/LDS line
  - Test of writing word $AAAA to $400 OK
  - Test of writing word $00AA to $400 OK
  - Test of writing word $AA00 to $400 OK
  - Test of writing word $0000 to $400 OK
  - Test of writing byte (even) $AA to $400 OK
  - Test of writing byte (odd) $AA to $401 OK
- Parallel Code $fd - Start of chipmemdetection

Addr $00080400   OK  Number of 64K blocks found: $08
Startaddr: $000▒0  Endaddr: $0007FFFF
- Testing detected Chipmem for addresserrors
   - Filling memoryarea with addressdata
.......
   - Checking block of ram that it contains the correct addressdata
.......   CHIPMEM OK
    - Checking status of mousebuttons for different startups, if still pressed
      we assume not working and ignore those in the future.
      Green newly pressed, Yellow pressed at startup - Startupaction taken.
      Red = Pressed at both poweron and now so it is stuck and being ignored

            P1RMB (red) P2RMB (red) P1RMB (red) P1RMB (yellow) P2RMB (red)
  The following special action will be taken:

  - Fastmemcheck skipped as we found chipmem
- Parallel Code $fb - Memorydetection done

  Using $0006C47A as start of workmem (Base)

- Testing Workarea Address-access
   WORKAREA OK
- Parallel Code $fa - Starting to use detected memory

Testing if serial loopbackadapter is installed: <> NOT DETECTED
Detecting if we have a working raster: DETECTED
Detected Chipmem: 512kB
Detected Motherboard Fastmem (not reliable result): 0kB
Basememory address (Start of workarea): $0006C47A
As a very fast test of variablearea working this SHOULD read OK: OK!
- Parallel Code $f9 - Detected memory in use, we now have a stack etc
 - Doing Initstuff
 - Setting up Chipmemdata
   - Copy Menu Copperlist from ROM to Chipmem
   - Copy ECS TestCopperlist from ROM to Chipmem
   - Copy ECS testCopperlist2 from ROM to Chipmem
   - Fixing Bitplane Pointers etc in Menu Copperlist
   - Copy Audio Data from ROM to Chipmem
   - Do final Bitplanedata in Menu Copperlist
 - Initstuff done!

    Set Start of copper (COP1LCH $dff080): Done
    Starting Copper (COPJMP1 $dff088): Done
    Set all DMA enablebits (DMACON $dff096) to Enabled: Done
    Set Beam Conter control register to 32 (PAL) (BEAMCON0 $dff1dc): Done
    Set POTGO to all OUTPUT ($FF00) (POTGO $dff034):Done
- Parallel Code $f8 - Starting up screen, text echoed to serialport
Amiga DiagROM V1.3 - 21-Apr-23  - By John (Chucky/The Gang) Hertell



Doing ROM Checksumtest: (64K blocks, Green OK, Red Failed)
$CED3BA58 $98C6080B $3980DA0F $003EC000 $003F0000 $003F4000 $003F8000 $00DFBCEA

CPU: 68000  FPU: NONE  MMU: NOT CHECKED

Checking for fastmem
Pressing left mousebutton will cancel detection (if hanged)

Checking if a 24 Bit address cpu is used: YES
 - Checking for Memory in 24 Bit area (NON AUTOCONFIG)
 - Checking for Memory in Ranger or Fakefast area

Extra w

The reason I can't boot properly and control the main menu with my keyboard is probably due to "stuck" mouse inputs during the booting process. If everything was alright with mouse inputs, I should have gotten nothing beneath the "Checking status of mousebuttons for different startups" message and upon clicking the RMB at the right time, I should have been able to control the menu with my A500 keyboard.

Also, I have tried testing with RealTerm. I set up RealTerm according to the right settings (9600 baud speed, the right COM port, no parity, 8 data bits, 1 stop bit, no flow control, Ansi display with scrollback) and got nothing except a red light from the BREAK signal ("Break is when the RXD line is broken) and a red light from the Error signal

I have also tried testing for continuity between Paula pin 40 (TXD) and DB25 F pin 2 (TX) - no connection, Paula pin 41 (RXD) and DB25 F pin 3 (RX) - no connection, Paula pin 8 (GND) and DB25 pin 7 (GND) - there is a connection. I'm not sure whether this is important or not, but I gave it a try as well.

Q: How can I fix the issue with the stuck mouse buttons during boot-up?
Q: Should I try another terminal, such as RealTerm, as PuTTY obviously isn't working right, or is something still wrong with my cable setup, even though that the loopback tests shows that TX and RX work? It obviously was working as I got to the main menu, so the connections on the DB9 F - DB25 F are right and the RS232-USB is fine.
Q: Maybe there is something wrong with Paula's busses after all?


- poroxius, September 15th 2025

[Castellen]

Q: How can I fix the issue with the stuck mouse buttons during boot-up?

The stuck mouse buttons are a valid clue and something solid to work with.  The report shows that both middle and both right mouse button inputs are active, which is definitely not normal.  The common factor is that these are all analogue to digital inputs on U3 (Paula).  Check the DC voltage on all of these lines to start with, U3 pins 32, 33, 35, 36.  They should normally be around 4 to 5V when in an idle state.  What you find will determine where to look next.

Q: Should I try another terminal, such as RealTerm, as PuTTY obviously isn't working right, or is something still wrong with my cable setup, even though that the loopback tests shows that TX and RX work? It obviously was working as I got to the main menu, so the connections on the DB9 F - DB25 F are right and the RS232-USB is fine.

The output you've copied above shows that the serial data and terminal is working, and the A500 is fundamentally alive.  I've no idea why PuTTY was working and now it isn't.  There is no hardware or software flow control with DiagROM, so configure the terminal to Flow Control = None.  Maybe something related to the USB serial port, I've seen instances where they randomly stop working, or they do something unexpected such as transmit data working but not receive data; then it starts working again when you disconnect/reconnect the USB cable.  I mainly use Term 4.8 on the Amiga, which works reliably.

Q: Maybe there is something wrong with Paula's busses after all?

It's not completely broken because you're getting valid serial data out.  The UART (serial port communication) is a function of U3/Paula, so if the data or address bus had a problem there, the serial output will usually not work, or be corrupted.

You could sanity check that the data looks valid on each of the 16 data lines and 8 address lines at U3 if you wanted to, that's quick and easy to do with an oscilloscope.

You could always try exchanging U3 with a known good 8364.  It's the same part between A500, A1000, A2000, A3000.