Need help fixing A4000

[Castellen]

And no there is no "romable diagnostic" roms.

There are diagnostic ROMs available for the A4000, I forget who wrote the software.  The French chap 'Cosmos' was trying to sell copies at one point.  I suspect they would generally not be useful as the hardware needs to be mostly functional to run the software from ROM of course.  The diagnostics appeared to perform some fairly basic functional tests on system I/O, video, etc.  The same kind of thing you'd be able to fault find with a blind monkey and an oscilloscope.

I developed my own diagnostic hardware and software for the A4000 a few years back to aid with many repairs.  It runs custom software from ROM which communicates over the system data and address bus to a piece of hardware that sends progress codes to the serial port of another Amiga that decodes and displays the information to show where the software fails to communicate with sections of hardware.  Works well and have used it many times for the repair of 'dead' boards.  Unfortunately it would be far too much time and effort to turn into a commercial product, given the extremely specialised use and therefore low sales volume.  And unfortunately I lack the time to write enough usable documentation for anyone to build a usable reproduction of the hardware, which is reasonably complex.


As for fault finding the said A4000... yes, certainly the first step is testing with a known good CPU board, even an A3630 is fine.  Of course make sure that the two clock source jumpers are set correctly according to the CPU board.  Check the ROMs aren't in backwards or the two ICs are swapped or anything stupid.  Check ROMs don't have any bent/broken pins.

Bad CIAs can certainly cause boot failure as described, but then again so can a failure of just about every other bit of custom silicon on the board.  CIA failure is unlikely if you know the history of the machine and nothing silly has been plugged into the Centronics port.

Check the status of the various reset lines, all of which are active low.  i.e. the system will only run when _reset = 5V.

Check that all of the various system clocks are present.  Check carefully for corroded/open circuit vias around the real time clock area.  If certain input lines are floating, the hardware can sit in an undetermined state.  Had an interesting fault recently where battery corrosion damaged the mouse data shift register U975 which caused the mouse data line to be floating, which caused Lisa/U450 not to generate the 14MHz clock, which resulted in Alice/U211 not generating the 7MHz clock which resulted in Gary/U150 holding the system in reset state.

Check the RTC/U178 is not getting warm.  When it gets badly damaged from corrosion it can go into a state where it just draws loads of current and causes a bus hangup and therefore a boot failure.  Remove U177 (RTC latch) if there's any signs of corrosion around the RTC circuit, this can cause an address bus hangup if damaged.  The system will boot normally without U177 and/or U178 fitted.

And yes, you should get an instant green screen with no chip memory fitted.  The hardware needs to have all reset lines inactive (5V) and clocks present for this to work.

In general, there's much that could go wrong.  I wrote a basic bit of fault finding info for A3000 non-booting issues here years ago that may help a little more.

Hope that helps.

[Castellen]

After seeing broken U975 and U976 I am not than eager to hot plugging or unplugging mouse or joysticks either. People plug and unplug them like USB ports for some 10 years which may cause damage eventually. If you disagree feel free to pass on your arguments.

The primary issue you're likely to run into when hot connecting mouse/joysticks is if the plug has a metal shroud on the connector.  It's very easy to misalign the 9-way connector and short the pin on the port that carry +5V to the chassis, which either blows the +5V_User fuse depending on what machine you have, or can cause open circuit tracks in A4000/A4000T due to the slow reaction time of the polyswitch fuse.

So that's why most joysticks, etc, have plastic around the outer edges of the mating part of the connector as opposed to metal.

The 25-way Amiga serial port carries +5V and +12V on two pins as well, and serial port connectors nearly always have the metal shroud.  So it's a good idea to power off the machine prior to connecting to the serial port.  The Centronics port isn't so bad as it has a female connector at the computer.

There's also the possibility of ESD (electrostatic discharge) damage to the port.  The ESD protection in C='s designs generally aren't great, so it's also possible to damage things by plugging in connectors even when the computer is powered off.  For this reason, always touch the computer chassis first to discharge yourself prior to messing with any connectors.

[Castellen]

What protection does modern computers have that Commodore missed?

This is a bit off topic, but the subject of ESD protection applies to any piece of electronics.  These days we tend to use a wide range of devices that often uses a combination of resistor-capacitor networks and special fast acting diodes.  Good designs are tested with a 12kV human body model that simulates a human finger causing static discharge into anything you can touch normally, e.g. connector pins.  The usual aim is to meet or exceed European Standard EN301 489-34.

As for a basic diagnostic ROM; yes - it would be useful depending on the hardware fault.  The trouble is that a bulk of the hardware needs to be working properly in order to correctly execute anything from ROM.  Most of the things that a simple diagnostic ROM would verify can generally be done by physical measurements anyway.  And you'd often be in the situation where you'd want it to check something else, or go a bit further or whatever.  Ideally you'd have dozens of different ROMs to help diagnose a range of faults and test different areas, but of course you'd need quite a bit of spare time to develop and test it all.  But then you need working hardware to test it on in the first place.

If you have a 32 bit logic analyser capable of caputuring specific address bus events (and a spare day to connect it) then I can send you my diagnostic ROM which would do what you want and more.  The trouble is that it would still be complex to use without the special hardware to receive the debugging information sent out.

[Castellen]

Yes, I'm stuck here in Antarctica for the next 9 months or so; I expect to resume Amiga repair work when I return to NZ in November.  It's kind of sad being stuck here with no Amigas, just annoying windows boxes with no useful software and a 32kbps satellite data link.  Hence WinUAE gets a lot of use, no idea what I'd do without PageStream, CubicIDE, etc.

A test ROM could simple send it's output on the serial port.
Serial - OK
CPU - OK
ChipRAM - OK
Paula - OK
Denise - OK
etc..

Agreed, that would be incredibly helpful in the right situation.  Unfortunately the UART (the bit that makes the serial port work) lives in Paula.  And for Paula to work, it first needs valid clocks that are divided and generated by both Alice and Lisa, so the bulk of the video sub-system needs to be working.  And Paula lives on the other half of the Amiga sub-system on the chip memory bus side.  And to talk to that, the data bridge needs to be completely working in both directions (Bridgette in the A4000).  And to talk to that, the address decoder (Gary) needs to be working.  And to talk to that, the entire CPU subsystem needs to be working.  And... hey that's most of the computer already.

The best ChipRAM diagnostic is to remove the SIMM.  As we all know, quite early on in the standard ROM software, it does a basic ChipRAM write/read test and turns the screen green if it's unhappy.  So if that's not working, it's probably a simple but fundamental problem causing everything not to work.  Unfortunately because the operation of any one sub-system relies on most other sub-systems to be working, you can chase yourself in circles looking for the fault.  Sometimes the best approach is to compare various signals with a known working system.  This is extremely time consuming, but I've repaired many difficult non-booting faults in this way.

The other way is to replace various bits with known good bits - also known as the 'shotgun' approach.  The problems there are that you need a source of known good bits, and you need to make sure all of your soldering work is 100% else you'll introduce new problems which simply compond with the original one.  Also, this doesn't help at all in finding PCB related faults, which are fortunately rare except in case of battery and capacitor corrosion - unfortunately which are common in the A4000.

Sorry for possibly sounding negative, but that's the harsh reality of the situation.

One possibly useful piece of basic diagnostic ROM software you could develop if you had time, would be to toggle a pin in the Centronics port.  This only requires a working CPU sub-system, address decoder, CIA U350 and most system clocks.  i.e. the computer would only need to be about two-thirds working properly for the diagnostic software to run.

But seriously, if there's been any form of battery corrosion, start with removing both U177 and U178 - the computer doesn't need them to boot.  Replace both U975 and U976 and verify the integrity of all connections to these shift registers (primarily the clock and data lines) are all correct.  It's a bit of a blind stab in the dark, but this area is a very common cause of non-booting faults in the event of battery corrosion.  Even if everything visually "looks" OK.

Also check the analogue bias voltage is around +2.4V on U400/Paula pins 33 and 34.  Capacitor corrosion does bad things to the op-amp U402 which can ruin the bias in the entire analogue stage which can sometimes cause Paula to do some very unusual things.