I've already test the pin 4 on ic 201 (the 765 controller) and it's indeed ~4.5Volt exactly like on the working cpc.
So if this means that 765 is probably ok (or at least can't cause the "no screen" symptom), could a faulty ic203 cause the "no screen at all" symptom?
In my case we have a very serious and fundamental problem: nothing onscreen!
So the most important thing to know is, if this can caused PRIMARY from a faulty fw/basic rom alone or if ANY (or all...) of the chips you mention above (I/O, FDC, buffers etc) are faulty, can cause the same symptom, even if rom is ok!
And if that's the case, could a logic map of high/low/pulsed on the pins of the above chips could reveal which one has the problem?
For the CPC to 'work' practically every chips has to function properly. Chips don't just have one mode of 'failure', they have many different ways in which they can fail especially the larger and more complex chips. That is why the manual suggests changing the larger chips first, diagnosing a complex failure mode with a complex chips is extremely hard even with very good test equipment. There is also the reasoning that the larger chips generate more heat and are therefore more prone to failure to a limited degree.
Your diagnostic process has gone well beyond the scope of faults the manual was intended for. The manual was intended for only the most basic faults and the fault you have in not a basic one.
In my case I could tell that 'some' of the chips were at least working to some degree. To get the box on the screen the Z80 has to be able to run code from the ROM and the data / address space needs to be clean. Or in other words, I had a rough point at which the failure occurred. ie the Z80 can run code, set up the 6845 Regs, write 0's to the screen buffer and seemed to fail when it first needed to run code from RAM.
In your case we don't have a point at which it fails and it appears to failing right from the very start. This is a very difficult fault to diagnose and especialy so with such rudermentery test equipment such as a multi meter.
If I had the equipment then the first thing I would test on your board would be to check the Vcc (5 Volt) rail with a scope looking for noise. Then I would test all the pins on the CPU (as it has the buses attached) and look for anything that is abnormal. In doing these things I am not looking for the 'fault' itself but I am looking for a lead that will take me to the 'fault'.
In your case we don't yet have a lead to follow.
The changing chips is almost certain to fix it. I say almost certain because when you have changed ALL of the chips and it still doesn't work then you know it's a short or fractured via in the circuit board.
You have almost exhausted the changing chips option by way of a logical process. You're more or less at the point where the fault can be narrowed down to being caused by "any of the chips you haven't changed" and there is not really any diagnostic reason to describe it better than that because you don't have a 'lead' to follow.
So in other words, yes the ROM(s) can cause this fault but there is not really any greater reason that it is a ROM over any of the other chips. To continue the chip changing the most (and minimally) logical path is to change the larger and more complex chips first. That would be the ROM's, 6845, 8255 and 765.
If however you can find a 'lead' then you will have a logical reason to change a particular chip and a very high probability that this will fix the CPC.
If you have a logic tester you can test each pin of the CPU and compare that to the other board. If there is a difference that you can see then 'perhaps' and only 'perhaps' that might point to a lead. I say perhaps because of two reasons. 1) Your eyes can see to frequencies up to about 20Hz and that is exceptional LOW compared to the 1MHz that most of these signals will be running at. and 2) Most of the signals are going to be different and that is simply a symptom of the fault and not the cause.
I suspect that what you WILL find is much more conclusive than a 'perhaps'. I suspect you will find a data or address or control pin that is stuck HIGH or LOW and even with something as simple as a logic tester this would be blatantly obvious.
The information that is most useful from a logic tester is status of the 'pulse' indicator. ie constantly OFF, constantly ON, constantly FLASHING. If you find a pin that is very different in this regard then the next clue is the status of the other leds ie constantly RED, constantly GREEN, mostly RED, mostly GREEN, both RED and GREEN. In any case it would be better to record both results to compare ie Pulse status and Logic status.
In my case I saw all pins (on the CPU) were as expected except the /INT pin. I didn't have another CPC to compare to and if I did then the results between the two would have been quite different in several ways. The key is in what you 'Expect' to see. I could list the 'expectations' here but it would take some time for me to do. It would be far easier for you to test and post the results.
If you want to save some effort then you can look for any pin on the CPU that is Pulsing on one CPC and not on the other. I you find one then report the levels (RED / GREEN).
If none of the above then compare the levels (RED / GREEN) of any pins that are NOT pulsing.
This diagnostic process cannot find ALL of the possible faults as it is (very) limited by the fact that you are using a simple Logic Tester. However for 'some' of the possible faults, it can provide a lead that is capable of leading you to the specific fault you have.
