A500 plus black screen

[terriblefire]

Without a LA its going to get very difficult to diagnose from here. Address or Data bus is not making it to the ROM completely.

[Steve_w]

Thanks for a very informative response 🙂

Is dram used at any time very early on? When data is put on the data bus does that mean dram is used?

I'm guessing when the address bus is used the address points to a location in RAM, so if the RAM is faulty there is nowhere to write and read data?

Thanks

[stephen_usher]

Thanks for a very informative response 🙂

Is dram used at any time very early on? When data is put on the data bus does that mean dram is used?

I'm guessing when the address bus is used the address points to a location in RAM, so if the RAM is faulty there is nowhere to write and read data?

Thanks

Until the ROM tries to access an address that GARY knows is RAM then there's no RAM access. GARY is the arbiter here and will turn on the ROM (/ROMCS) or the RAM (via the buffers and transceivers and chip select lines). GARY is also driving the data acknowledgement line, so GARY is key.

In the Falcon thread, a way to test the data lines is to remove the ROM and look at each of the data lines after reset and triggered by /AS going low. With the ROM removed they should all float to about the same voltage as there's nothing to drive them. This can tell you if you have any shorts between them.

You can do the same sort of thing with the address lines. You know that the first read should be all zeros so if you look at the address lines at the ROM socket, triggered by /AS after a reset, they should al be zero, followed by A1 going high, then A2 going high and A1 going load, then both A1 and A2 etc.

If you know what the values in binary of the first four words of the ROM are then you can go through those methodically on the CPU to see if it's getting the correct data.

Basically you're manually acting as a logic analyser for the first four reads.

[Steve_w]

Ah excellent, I'll definitely take the ROM out and do what you suggest to test data lines. Is this method better than just testing for shorts with a MM?

I'm interested in testing the address lines. Is the ROM also out when doing this?

When you say if you know the binary of the first four words of the ROM and test the CPU pins, I assume the ROM is back in at this stage?

[stephen_usher]

With the address line testing it doesn't matter is the ROM is in or not, you just are trying to find out if the correct addresses are reaching the ROM pins.

Anyway, read this thread: viewtopic.php?p=118645#p118645

[Maximilian]

Excelent info from the pro's!!

Normally if I repair this kind of machine a visual inspection and measuring the connections should be enough to find the issues.
But as TF somewhat said, it will always be a repaired machine, and you will have to be very good at repairs and proactive to make it last.

Some things I haven't seen in the tread:
Can you show us a good closeup of the board?
(top and bottom)
Did you use this to double check all the connections of all the chips you worked on?
(Gary, rom, datapath, mem, cpu)
https://www.amigapcb.org/

[Steve_w]

Hi,

My process is as follows

1. Clean as much corrosion as possible.
2. Remove components effected by corrosion.
3. Visual inspection for other outlying bits of corrosion.
4. Use a fibreglass pen to remove as much tarnish from the traces as possible.
5. Use white vinegar to clean and also neutralise corrosion.
6. Use IPA to remove white vinegar.
7. Tin exposed traces.
8. Continuity test immediate and surrounding area, generally every Gary trace, all D and DRD traces and traces near battery
9. Fix any broken traces with inline fine wire soldered to trace
10. Continuity test again
11. Apply UV solder mask
12. Continuity test again
13. Replace sockets and components removed in step 2
14. Power up and begin any troubleshooting if required

I use amiga pcb explorer a lot and find it very useful, in fact I print out the diagram and use that to keep track of what I've continuity tested by colouring in each via I test (see image, all blue marks indicate where I have tested).

On the bottom of the board is still some small amounts of corrosion, this is in the audio area so I'm leaving this until I get the board working, also I have not replaced the trap door connector yet for the same reason.

Hope this helps

Steve

top.jpg

bottom.jpg

testsheet.jpg

[terriblefire]

The problem is the acid can get inside the FR4 board and it's just impossible to get out. It will make vias go
bad in the future... which is fine if you have the skills to hunt things down

[Steve_w]

The problem is the acid can get inside the FR4 board and it's just impossible to get out. It will make vias go
bad in the future... which is fine if you have the skills to hunt things down

Yes I understand it possibly will never be as stable as a new board, I think for me its a challenge to try and get these boards working again. I have one that had really widespread corrosion, I repaired this about 4 years ago and so far its still gong strong, I use it as my test board now.

I decided to to look for shorts on the control signals, I found LDS shorted to a the 7MHZ clock signal under the Angus socket so this will have to come off to check. (circled in the picture)

short.jpg

[Steve_w]

I want to provide an update to this thread, after removing the Agnus socket, fixing the short between the 7MHz clock and the LDS signal and replacing Agnus, the board is now functional and Diagrom loads to the menu screen.

Thank you to the members that helped me along the way, your help allowed me to narrow down my focus to the control signals, this in turn lead me to test for shorts for all control signals (I already knew I had continuity).

Thanks again.

Steve