You may find it helpful to know how the keyboard works so here is my understanding.
Referring to the keyboard schematic, IC1 is a latch/counter. Most of the time, this is counting round in sequence, so the outputs QA to QD count up from zero in binary and then return to zero and do it again. This binary value is fed to IC3 which decodes the binary value so that, for any given value, only one of its output is active. That means each of the column lines gets activated (low) in sequence, then back to column zero and do it all again.
When a key is pressed, it connects the one of the column lines to a row line. There are two ICs monitoring the row lines. IC4 is an eight input NAND gate but you really need to think of it as an OR with active low inputs, i.e. it detects when any of the row lines has become active low and raises the interrupt line to the CPU. That's how the OS gets to know that a key has been pressed rather than the keyboard being idle.
IC2 is a multiplexer so, under the control of the OS, this can select a row line to check if it is being activated. Once the OS receives the keyboard interrupt stops the counter and scans the keyboard under software control, so it writes to both IC1 and IC2 to select a particular column and row and check if that particular key is pressed.
So, reading arg's post, what you are trying to establish is whether the problem is connectivity, i.e. a crack in one of the tracks, or whether one of the ICs is defective. When a row line is taken active (low) you should be able to see this on all the points along it, including the inputs to IC4 and IC2, hence testing IC4 pin 4 and IC2 pin 6 but compare with the equivalent inputs for a row that does work, as arg suggests, just to check your meter is capable of seeing the pulsing. If you don't see any change on the IC input for the faulty row, but you do for a working row, then it is probably a track issue. If you do see a difference on the input to the IC but no change to the output then the IC is probably faulty.
Referring to the keyboard schematic, IC1 is a latch/counter. Most of the time, this is counting round in sequence, so the outputs QA to QD count up from zero in binary and then return to zero and do it again. This binary value is fed to IC3 which decodes the binary value so that, for any given value, only one of its output is active. That means each of the column lines gets activated (low) in sequence, then back to column zero and do it all again.
When a key is pressed, it connects the one of the column lines to a row line. There are two ICs monitoring the row lines. IC4 is an eight input NAND gate but you really need to think of it as an OR with active low inputs, i.e. it detects when any of the row lines has become active low and raises the interrupt line to the CPU. That's how the OS gets to know that a key has been pressed rather than the keyboard being idle.
IC2 is a multiplexer so, under the control of the OS, this can select a row line to check if it is being activated. Once the OS receives the keyboard interrupt stops the counter and scans the keyboard under software control, so it writes to both IC1 and IC2 to select a particular column and row and check if that particular key is pressed.
So, reading arg's post, what you are trying to establish is whether the problem is connectivity, i.e. a crack in one of the tracks, or whether one of the ICs is defective. When a row line is taken active (low) you should be able to see this on all the points along it, including the inputs to IC4 and IC2, hence testing IC4 pin 4 and IC2 pin 6 but compare with the equivalent inputs for a row that does work, as arg suggests, just to check your meter is capable of seeing the pulsing. If you don't see any change on the IC input for the faulty row, but you do for a working row, then it is probably a track issue. If you do see a difference on the input to the IC but no change to the output then the IC is probably faulty.
Statistics: Posted by Coeus — Thu Jul 04, 2024 9:48 am