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.
