You can do a lot with the probe. Most probes have a pulse stretcher so yo cansee a blink even if the transition was very fast.Are your parts socketed or soldered right in?
We have been testing with a live operating system hoping it would come up.When you become desperate enough (serious enough) about finding theproblem, special purpose EPROMS, like one with a tight loop, and anotherthat continuously outputs a single character.There should be images of these around, and you can make them yourself,but if you have trouble locating them, let me know and I will help you find them.
Very low level questions need to be answered like...Is there a heartbeat at the CPU (CLK)?
Is the CPU reading bytes from memory?If bytes are being read from memory, A0, A1, A2... should be toggling as theycount up sequential memory addresses. If this isn't happening, then the firmwareis not accessing I/O ports at all.
Are the CPU RD MEMRQ and IORQ active.IORQ and MEMRQ feed into chip select logic that decodes addressesand determines whether they are ROM or RAM...
When the firmware first starts up, it begins accessing ROM, so the ROM CSshould be getting selected coming out of the decoder hardware. If there is noCS activity towards the ROM, there is a strong likelyhood the memory deviceselection process is failing.Check U15 pin 8 to see if it is moving
Below see pin 27 which should wiggle at the start of each instruction fetch. Once you come out of reset(assuming you are coming out of reset, this could explain a lot), /M1 should wiggle once for each instruction fetched.You should not be HALT or WAIT.If the CPU is healthy, the RFSH (28) should be wiggling like crazy too.
If you are not coming out of reset because something is wrong in your reset handler,you should be able to tell by looking at U7 pin 4. It should only be low when you are holding down the reset button.