mikro wrote: 13 Jul 2025 22:35
@dml you meantioned measuring the XRESET level on each IC, do you think it is still a valid start? Then I remember @Badwolf's advice for another user here, they were catching /AS and each of Dx to see whether there is something meaningful on the bus.
Yep I would start with the XRESET and XHALT signals.
Make sure XRESET reaches all the chips that use it and that the signal is in the correct voltage range at the relevant pin of each chip, not being pulled down/up significantly by any one of them. Chances are very high this is all ok but if not, you'll waste a lot of time on other things.
XHALT is output by the same U11 reset buffer, on a machine-reset but the shared HALT signal can also be asserted by the CPU (pin 129?). If HALT remains low after reset instead of following XRESET, it will most likely be the CPU - which could be an upstream fault or the CPU itself. It could be that the CPU is trying to work but suffered a error. This can even be an early clue to a working CPU.
Those are the simplest signals to check.
I would also look at the busmaster signals BR/BG/BGACK since these can stop the CPU accessing ram - the COMBEL and SDMA can take control (but not the VIDEL, given what ijor explained recently). It may be possible to tell if e.g. the CPU requested the bus but did not succeed due to a stuck component, so it will never fetch/execute the RESET instruction....
mikro wrote: 13 Jul 2025 22:35
So I don't know... what are the chances that both CPU and Videl are dead, right?
Unless someone powered the board in reverse or with 12v, they are not closely related so I think it is unlikely they would both fail together.
Remember also the COMBEL sits between all these things and any problem there is a dead Falcon - CPU can't access RAM, VIdel won't fetch... nothing. There are plenty of similar problems which don't need to involve COMBEL but statistically it's more likely to be faulty than the two other ICs together.
It does seem like a dead VIDEL can't cause the issue you are demonstrating on the scope. It is too far upstream. So I would ignore VIDEL for now and focus on the CPU/RAM/ROM/COMBEL, maybe also SDMA as potential bus master hog.
I have seen a couple of boards recently with randomly unsoldered legs on one or more of these ICs and it is completely invisible. You can't diagnose it by eye and it is difficult with just a microscope - you need to push each pin from the side or do a cont. check from shoulder to pad on every pin, to find them. It is very tedious but something you can rule out with some certainty and not have to repeat later.
A cont check on the MFP and some other peripherals is also a good idea while you are at it. Some of them can interfere in non-obvious ways. More likely you would be seeing more CPU activity first in this case but still worth just ruling all of that stuff out early. The QFP type of surface soldering for the MFP also has the unsoldered-legs problem, but under the IC.
There is also the DALLAS chip which sits directly on the data bus lines 0-7 with a chip-select from the COMBEL. There have been cases where a dead NVRAM can hold the machine on a black screen (not exactly sure how but it has pins on the bus - maybe just toggling RGB/VGA but could be more to it in some cases). I don't think I have experienced that one - more typically you get boot problems and bad settings - but its another thing which would be good to eliminate early, if not already.
I would also be tempted to do some easy stuff early - make sure there is no FPU present (but I think you did strip it down already), exchange the socketed ROM & the GALs with the working machine for a test. That gets rid of a few more simple things. Chances of damaging the ROM/GALs is low and you can always make more of them as a last resort.
