[ortek_service]

Yes, agreed all inputs to UC9 do look OK and that UC9 has to be faulty from the symptoms found.

At first I wondered why UC9-15 ('A') was staying high most of the time, after a few pulses, whereas other inputs appeared to go return to low state most of the time when keyboard wasn't being scanned. But I then realised it was due this line being a '1' in the last input code, and checking the datasheet's BCD input code table (plus rechecking the 'scoped UC9-12 ('D') also finding that stayed high most of the time) did tie up with 1001 input code which sets the last UC9 output ('9' line) to be active (Low).

And there was no point in the PET's Kernal setting the 74LS145 input-lines code back 0000 etc. at end of scanning period, as there is always one output active unlike conventional direct parallel (non-demultiplexed/decoded) matrix scanned systems.
I presume the scanning is all done via regular interrupt timing, otherwise it would slow programs down a lot if it sat constantly reading the other (column) side of keyboard matrix, for the whole complete keyboard scan time.


So Keyboard should then be all working again, once UC9 (Hopefully the last entry on the IC casualties list!) is replaced, now that track has also been repaired. And hopefully won't need to resort to repairs on the any of the key's conductive plungers. These could all be measured for resistance, between the appropriate row and column lines on the connector, in conjunction with keyboard map table I posted a link to earlier - Although if all keys do now produce some response (even if incorrect character) then that's a good sign, and probably much easier to just check all keys work when its all running.