Trying to call my A4000D back to life

[Castellen]

I agree, very unlikely that the ROMs are at fault.  If there was a data corruption problem within them, this would be picked up by the checksum test during early boot.

Unfortunately I don't have a reference machine to test the Chip RAM and the A4000 crashes as soon as I want to open any folder or program on the workbench... But I have plenty of other SIMMs which I'll try after work.?

As others have pointed out, this behavour is consistent with memory issues.  If you're able to boot without startup, run Memcheck from floppy, you may get results before it crashes due to memory issues.

Another problem which can cause this is clock synchronisation, which can happen if the A4000 is clocked from its own onboard oscillator while the external CPU board is running from its separate reference.  Though often this causes total boot failure, or failure during early boot.  With the A3640, both clock source jumpers on the A4000 main board must be set to EXT.

If there has been corrosion damage around U177 (RTC latch) this part should be replaced, else there can be issues with the latch causing corruption on the CPU address bus.  Likewise, if U178 is damaged, this can cause CPU data bus issues.  Though usually in this case, the machine just won't boot at all.  If in doubt you can remove U177 and U178, the machine will boot fine without them.  Use caution; if you had problems when removing F175 (below), then you're unlikely to remove these parts without causing more damage.

You're right, possibly the lines under the Chip-RAM sockets are dodgy. I'll solder out that socket to have a better look at them. But honestly said, the Amiga worked more or less stable before I began to change the IC's and caps - except it sometimes didn't identified all of the 16mb Fast-RAM - that was initially the reason why I began to replace all the elements... Which chips are involved in memory management?

In the A4000, half of U250/Bridgette forms the bidirectional bridge between chip memory and other devices on the chip memory bus.  But it's unlikely this is the problem.  Has there really been damage to the chip memory tracks?  This is the U261 socket.  There's nothing common in this area to cause much damage, aside from major leaking of C190, which is fairly rare, or worse than usual battery damage.  If there is visible damage to any tracks, these should be checked and repaired accordingly.  Most damaged tracks in this area will be picked up by the early chip memory test in ROM, which shows a green screen for chip memory failure.  Though this test isn't very thorough, it only does a simple write/read check at 16kB intervals.

There won't be soldering issues on the chip memory socket, but broken retaining clips or very dirty socket contacts are a possibility.  As others have said, you _MUST_ use a known good/working SIMM for chip memory, else you're chasing the unknown at this point.

The machine should run OK without fast memory.  But any fast memory access problems are usually caused by open circuit _R_W to pin 11 of the fast memory sockets and/or corrosion damage to U891 and/or damaged tracks/vias around U891.

Btw: When I replaced the Poly-Switch (F175) near the parallel-/serial-interface, I pulled out both VIA-connections :-/ Do you know if these are connected to an intermediate level of the multi-layered mainboard? I successfully bridged the lines on the upper- and lower-side, but I'll have a big problem if there are more connections inbetween... :-o

Why did you remove this for?  Anyway, one side of this connects to the internal +5V plane - specifically the side nearest U350.  The A4000D is a four layer board, the internal two layers mostly carry GND and +5V.  So measure it, and if the U350 side of F175 doesn't connect to +5V, then just run a small jumper on the bottom side of the board to the nearest convenient +5V source, which is practically everywhere.  If this connection is damaged, you'll just have no +5V_USR, so essentially you'll lose mouse movement.  The computer will boot fine without it.


If you can't resolve the issues yourself, feel free to contact me for a repair estimate.
http://amiga.serveftp.net

[Castellen]

@Castellen: First of all, many thanks for your generous assistance! Your knowledge on the Amigas is really impressing.!

I should hope so, I do Amiga repairs as a job.

I replaced U891 and U177 in a very early state with new ones. I also checked all via's and lines in this area several times.

Sounds as though your memory issues have been resolved, but also check continuity between U215 pin 12 and pin 11 of any fast memory socket.

I measured +4.92V between GND and F175 without any devices attached (except keyboard and mouse). Is this within the valid range?

Yes, this is normal.

Finally I removed U177 without problems and started the machine... wow - the Fast-RAM problems and the crashes were gone :-) ! So the problem is that RP5C01 uses a direct bus-connection to the CPU and if this element fails, the CPU shows up with undefined behaviour, resulting in system crashes ?

Yes, that was exactly my point.  U177 is also directly on the address bus and can cause problems if it's badly damaged.  But you've replaced this already, so no problems there.  I've written various repair guides on the subject.

You can buy new RP5C01 (U178) from AmigaKit, also I carry them in stock.  Try and get the correct variant, the RP5C01A as used in the A3000 is practically the same, but the capacitive loading of the crystal oscillator is a bit different, so it'll run too slow.  In saying that, the original 32.768kHz crystal will have aged to the point it'll be slow anyway, requiring recalibration.  You just need to connect a high impedance (>=10M Ohm) oscilloscope or frequency counter to U178 pin 17 and adjust VC190 to get the correct frequency.  Do this with the A4000 powered off as the oscillator runs fractionally slower while the RP5C01 is in standby mode.

The following two issues are still open:

1. When measuring CPU speed with SysInfo, it only reaches a max of 14.95 Mips  instead of the ~18 Mips measured in the past. Any ideas?

I wouldn't get too beat up about that.  System benchmarks are often seemingly random numbers or an approximate indication at best.  There's unlikely to be any hardware fault that "makes the computer go a bit slower then usual".  This kind of thing generally either works or it doesn't.  Other factors include any other patches you happen to be running when you first recorded the value.

2. The Amiga needs approx. 35 seconds from powering on until the boot  menu (the one with the hand & disk) shows up. My Amiga 1200 does the same within 1-2 seconds. Is this  normal for A4000's ?

Yes, as answered already, OS v40.xx waits about 30 seconds to allow any hard drives to spin up and become available.

[Castellen]

Believe me - I would already have sent my beloved motherboard to you for repairing if you wouldn't live that far away...!

It's no big deal, sending an A4000D main board doesn't cost a lot providing you use a standard surface or air mail service and not an international courier.  I have hundreds of regular customers all over the world; UK, Europe, USA, Canada, etc.

the hint with the diode between the transistor and pin 18 of the RTC chip. Wow - now the Amiga works very stable again and it's recognizing all memory all the time

That diode just provides a more direct 5V source to the RTC.  What can happen is if the battery is very depleted, it causes excess load on the power supply to U178, which does not operate correctly with a low supply voltage.  This can cause the system to freeze during boot.

Pleased that's fixed it for you.

What is the cause that U177 fails? I mean the battery acid has damaged the pins, but the case of the RTC is intact. Is this maybe caused by a excess voltage due to a closed circuit or similiar?

I don't quite understand your question.  U177 damage is almost always due to battery corrosion.  If the device appears visibly corroded then it should usually be replaced.  It can happen that it operates OK for a while, but can fail in the future, even after it has been "cleaned up".

the quest is not completed yet - I also have some audio problems for which I'll open a new thread. It would be great if you could take a "short" look at it

No problem, but have a look at the information I've already written on the subject.