daver2
10k Member
Isn't it "OLD @1:" - the colon being significant (after selecting the desired file to load).
Dave
Dave
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
New Tektronix 4051 owner - needs help repairing his 4051
- Thread starter nikola-wan
- Start date
WaveyDipole
Experienced Member
Spot on! It is shorted. I know I checked these previously so its failed in the meantime.
Will be replacing all 4 of them: C668, C669, C671 and C672.
Will check the tape drive board as well just in case.
Yes that is what I had been doing and eventually did find a short between J24-8 and J24-7. Didn't spot it initially because I was looking at J22-4 and J22-1 but missed J24-8.
Ah, yes. The colon is significant and that works. Thanks.
daver2
10k Member
A pretty good set of guesses there 
!
Dave
!Dave
WaveyDipole
Experienced Member
Yes, absolutely. Someone did mention those four tantalum caps a while back on the thread and I did check them at the time and they were OK so I left them. There seems to be no tantalums on the tape board and everything looked OK. Those four tantalums on the display board have now been replaced and the display is back! Yey!
Now have to wait for the CPU to arrive. In the meantime will experiment a bit with the emulator.
Now have to wait for the CPU to arrive. In the meantime will experiment a bit with the emulator.
Attachments
daver2
10k Member
It was Monty last time...
They are always a pain. Even brand new (I have made 1,500 boards for work) the tantalum bead capacitors have a poor initial failure rate. Most of the 400 hour burn-in failures have been tantalum bead capacitors on the power supply rails. The cards have already been powered up at the manufacturing factory where they have been tested on an ATE (bed-of-nails).
Dave
They are always a pain. Even brand new (I have made 1,500 boards for work) the tantalum bead capacitors have a poor initial failure rate. Most of the 400 hour burn-in failures have been tantalum bead capacitors on the power supply rails. The cards have already been powered up at the manufacturing factory where they have been tested on an ATE (bed-of-nails).
Dave
WaveyDipole
Experienced Member
CPU arrived today. I tried the replacement but got exactly the same behaviour. I guess I probably have a good spare CPU, but unfortunately it brings me no closer to solving the problem. The signal on P1 on U153 in not quite as saturated with clock signal, but it is still there and it still looks weird. A capture of the databus on startup also exhibits the same weird behaviour. Not sure what to do next?
With regards to that, the circuit diagram does show some 2.4k pull-up on the address rails. They are contained in DIL packages U227 and U535.
EDIT: I just had a thought regarding what might be happening with the addressing:
The address bus is 16-bits wide but the data bus is 8-bits wide. When the CPU reads the ROM to get the jump to address for the start-up routine it reads the two bytes at FFFF and FFFE and gets each byte wrong by exactly 1. That appears to correlate with the problem on rail D0 on the databus as shown by the oscilloscope trace from p1 of U153 and which would correspond to bit 0 which is being mis-read. The question is, how do I determine whether this is a problem with the transceiver/buffer chip D153 or something else on the databus? I have already removed the PIA chips one by one and the two DRAM chips that are on the bit 0 rail of the bus and it has made no difference.
With regards to that, the circuit diagram does show some 2.4k pull-up on the address rails. They are contained in DIL packages U227 and U535.
EDIT: I just had a thought regarding what might be happening with the addressing:
Code:
Reading: BD 4C
Should be: BC 4B
-----
Difference: 01 01The address bus is 16-bits wide but the data bus is 8-bits wide. When the CPU reads the ROM to get the jump to address for the start-up routine it reads the two bytes at FFFF and FFFE and gets each byte wrong by exactly 1. That appears to correlate with the problem on rail D0 on the databus as shown by the oscilloscope trace from p1 of U153 and which would correspond to bit 0 which is being mis-read. The question is, how do I determine whether this is a problem with the transceiver/buffer chip D153 or something else on the databus? I have already removed the PIA chips one by one and the two DRAM chips that are on the bit 0 rail of the bus and it has made no difference.
Attachments
Last edited:
nikola-wan
Veteran Member
Any update on your troubleshooting?
I would think your logic analyzer could be used on the data bus buffers on the ROM datapath to the CPU to find where the lowest bit is stuck high for the first two ROM fetches.
I would think your logic analyzer could be used on the data bus buffers on the ROM datapath to the CPU to find where the lowest bit is stuck high for the first two ROM fetches.
WaveyDipole
Experienced Member
I have made some progress this morning. The replacement for the buffer chip U153 (DM8833) arrived yesterday and it has been installed this morning into a turned socket. It is a DS8833 which has a slightly different spec but otherwise the same function. The result is that all lights on the right hand side now go out except power! However, although this is a step further, the computer still does not start up properly. What I now get is the same display condition but with a faint cursor in the top corner. After a few seconds a sequence of characters starts to appear. The computer still does not respond to pressing PAGE.
It would seem that it is at least getting past the start-up sequence but something is happening subsequently. I will capture the address and data bus again with the LA to see how things look after the replacement.
I did notice an anomalous reading on U535 which is a resistor array of 2.4k resistors. Between pins 15 and 16 (page 04_02-07) of the service manual volume 2) reads OL in one direction and approximately 80ohms in the other. I checked the gate on U531 (pins 1,2 and 3) and don't see any obvious short across the pins of the gate itself there although it could be shorted to VCC. Going upwards leads to the expansion memory which is disconnected. Downwards leads to the buffer chip U153 which has already been replaced. In any case, the problem was still there with the IC removed. Unless anyone has any othe ideas I might remove U531 to see what happens.
It would seem that it is at least getting past the start-up sequence but something is happening subsequently. I will capture the address and data bus again with the LA to see how things look after the replacement.
I did notice an anomalous reading on U535 which is a resistor array of 2.4k resistors. Between pins 15 and 16 (page 04_02-07) of the service manual volume 2) reads OL in one direction and approximately 80ohms in the other. I checked the gate on U531 (pins 1,2 and 3) and don't see any obvious short across the pins of the gate itself there although it could be shorted to VCC. Going upwards leads to the expansion memory which is disconnected. Downwards leads to the buffer chip U153 which has already been replaced. In any case, the problem was still there with the IC removed. Unless anyone has any othe ideas I might remove U531 to see what happens.
Attachments
Last edited:
daver2
10k Member
One step forwards...
Before you do that however could I suggest using your oscilloscope to check that/those strange data line traces that we had to make sure they have gone away? Cause and effect... Has the original problem we observed gone away or not?
Then, sure, have a look at the start-up sequence.
Can you also check the /NMI and /IRQ signals to make sure these look partially sensible (i.e. not stuck LOW as one was).
EDIT1: I am thinking that the 6800 CPU is now working properly. This may be either a faulty keyboard PIA or faulty keyboard circuitry. There are a few TTL chips that are critical to the operation of the keyboard. I’ll give you a couple of points to monitor with your oscilloscope after lunch.
EDIT2: The <PAGE> key is read as a conventional keyboard key. So, if this interface is not working correctly, you won’t be able to ERASE the screen.
Will answer your PM presently.
Dave
Before you do that however could I suggest using your oscilloscope to check that/those strange data line traces that we had to make sure they have gone away? Cause and effect... Has the original problem we observed gone away or not?
Then, sure, have a look at the start-up sequence.
Can you also check the /NMI and /IRQ signals to make sure these look partially sensible (i.e. not stuck LOW as one was).
EDIT1: I am thinking that the 6800 CPU is now working properly. This may be either a faulty keyboard PIA or faulty keyboard circuitry. There are a few TTL chips that are critical to the operation of the keyboard. I’ll give you a couple of points to monitor with your oscilloscope after lunch.
EDIT2: The <PAGE> key is read as a conventional keyboard key. So, if this interface is not working correctly, you won’t be able to ERASE the screen.
Will answer your PM presently.
Dave
Last edited:
WaveyDipole
Experienced Member
Yes, the problem appears to have gone away. The wave is not a perfect square and there are kinks present, but this is far less chaotic than previously. The signal is full height for most part and on the CPU side the signals look the same as on the other pins.
Checked. Both stay up at startup and during when the light are all off except power. However after about 4-5mins, IRQ goes down and I get all lights on again. After a few seconds IRQ goes back up again but nothing changes.
Agreed. I also tried the spare CPU. Both gave the same result.
Fair point, however while I was checking things with the scope, the screen cleared spontaneously a couple of times. It would seem that graphics are OK as we are getting fonts getting drawn to the screen, and the display can be cleared to show text so it also appears to be working properly.
As it stands, things do indeed appear to point to the keyboard or its PIA.
Attachments
Last edited:
daver2
10k Member
Excellent - so the machine isn't 'terminal' then!
It looks like the tube and high voltage PSU circuitry etc. is OK.
Interestingly, the ROMs can print error messages out if they are 'unhappy' about something. Is it just possible that some of the text that is being output is a 'cryptic' error message. I can't quite read what is on the screen, but I think I can read the word 'BAD' - or am I making it up?
Things to check on the keyboard interface are:
KBCLK-0 - Keyboard U6 pin 9. This should be oscillating.
KBHALT-1 - Keyboard U6 pin 12. This should be 'low'.
KEY-1 - Keyboard U6 pin 3. This should be 'low'.
These signals are also present on J31 if it makes connections easier. They are also on the main logic board as well.
In this state, all of the outputs from keyboard U1 (74159 4:16 decoder) should be oscillating. All of the lines should be high, with one output going low at a time.
When a key is pressed, KEY-1 should go 'high' (signifying a key press) and KBHALT-1 should go 'high' in response to stop the counters U3 and U4 from counting anymore. The corresponding code should be 'latched' into KC0-1 through KC6-1.
Once the CPU has recognised the keypress, KBHALT-1 should go 'low' again.
I am not 100% sure of the state of KBCLK-0 through this (whether it stops clocking or continues). EDIT1: It should keep clocking (it is sourced from the refresh logic).
EDIT2: Hmmm, may not be quite as simple as I have described now I read the description again in the maintenance manual Volume 1...
Dave
It looks like the tube and high voltage PSU circuitry etc. is OK.
Interestingly, the ROMs can print error messages out if they are 'unhappy' about something. Is it just possible that some of the text that is being output is a 'cryptic' error message. I can't quite read what is on the screen, but I think I can read the word 'BAD' - or am I making it up?
Things to check on the keyboard interface are:
KBCLK-0 - Keyboard U6 pin 9. This should be oscillating.
KBHALT-1 - Keyboard U6 pin 12. This should be 'low'.
KEY-1 - Keyboard U6 pin 3. This should be 'low'.
These signals are also present on J31 if it makes connections easier. They are also on the main logic board as well.
In this state, all of the outputs from keyboard U1 (74159 4:16 decoder) should be oscillating. All of the lines should be high, with one output going low at a time.
When a key is pressed, KEY-1 should go 'high' (signifying a key press) and KBHALT-1 should go 'high' in response to stop the counters U3 and U4 from counting anymore. The corresponding code should be 'latched' into KC0-1 through KC6-1.
Once the CPU has recognised the keypress, KBHALT-1 should go 'low' again.
I am not 100% sure of the state of KBCLK-0 through this (whether it stops clocking or continues). EDIT1: It should keep clocking (it is sourced from the refresh logic).
EDIT2: Hmmm, may not be quite as simple as I have described now I read the description again in the maintenance manual Volume 1...
Dave
Last edited:
WaveyDipole
Experienced Member
Thanks. We seem to have identified another problem. There is no signal on KBCLK-0. I read as follows on U337 (page 04_02-06):
P14 - 52.068kHz (we have RCCLK coming in from the clock circuitry on page 04_02-02)
P1 - 26.034kHz (output to U431)
P8 - 2Vdc (output to U435)
P9 - 2Vdc (this is the output to KBCLK-0)
P11 - 0V
P12 - 26.034kHz (output to U431)
It looks like the chips is divided into two sections with the input clock signal (52.068kHz) being supplied to p14 for the DIV/2 divider and we can see the output at half that (26.034kHz) from pin 12 (Qa) as expected. In addition to feeding U431, this also supplies the input to the second half of the IC on P1. The DIV/8 output (approxz 3.25kHz) should be present on Qb, Qc and Qd at pins 8, 9 and 11 but no clock signal is present on any of those pins.
According to the datasheet, if R0(1) p2 and RO(2) p3 are high, the chip will not count. I checked and both pins are low so both sections should be active and counting.
I don't have one of those to hand so will have to order.
P14 - 52.068kHz (we have RCCLK coming in from the clock circuitry on page 04_02-02)
P1 - 26.034kHz (output to U431)
P8 - 2Vdc (output to U435)
P9 - 2Vdc (this is the output to KBCLK-0)
P11 - 0V
P12 - 26.034kHz (output to U431)
It looks like the chips is divided into two sections with the input clock signal (52.068kHz) being supplied to p14 for the DIV/2 divider and we can see the output at half that (26.034kHz) from pin 12 (Qa) as expected. In addition to feeding U431, this also supplies the input to the second half of the IC on P1. The DIV/8 output (approxz 3.25kHz) should be present on Qb, Qc and Qd at pins 8, 9 and 11 but no clock signal is present on any of those pins.
According to the datasheet, if R0(1) p2 and RO(2) p3 are high, the chip will not count. I checked and both pins are low so both sections should be active and counting.
I don't have one of those to hand so will have to order.
Last edited:
daver2
10k Member
It is just a remote possibility that U435/2 or the IC pin to which KBCLK-0 is connected is faulty and as dragging the signal down. This is a low probability though...
Interestingly, U337 pin 11 is used for the DRAM refresh counter - so your DRAM will be a little bit forgetful!
Two steps forwards...
Dave
Interestingly, U337 pin 11 is used for the DRAM refresh counter - so your DRAM will be a little bit forgetful!
Two steps forwards...
Dave
WaveyDipole
Experienced Member
Yes, I noticed that U337 p11 goes to 'REFRESH ADDRESS COUNTER" and subsequently cascaded to all the MAB signals so did wonder about that. I thought I had checked all of the clock signals based on the circuit on page 04_02-02 but hadn't looked at that section of the circuit because it is on another page. Hopefully replacing that chip will sort the matter out and both keyboard and memory will then function properly. It remains to be seen whether there will be any more hurdles to overcome....
I did think about temporarily snipping or de-soldering pin 15 of U535 to see if I can determine where the low resistance is. It is possible that the multi-meter is being fooled because the reading is being taken in circuit, however, the adjacent and corresponding gate on U537 reads rather differently and sensibly whereas the readings on this one don't make sense. To all intents and purposes the resistor between p15 and p16 on U535 is reading like a diode with very low resistance (about 80ohm). My suspicion is that the resistor between p15 and p16 is open or that particular gate on the U531 is faulty or both. Either will require attention so I might as well check it out while awaiting replacement parts to repair the clock divider.
I did think about temporarily snipping or de-soldering pin 15 of U535 to see if I can determine where the low resistance is. It is possible that the multi-meter is being fooled because the reading is being taken in circuit, however, the adjacent and corresponding gate on U537 reads rather differently and sensibly whereas the readings on this one don't make sense. To all intents and purposes the resistor between p15 and p16 on U535 is reading like a diode with very low resistance (about 80ohm). My suspicion is that the resistor between p15 and p16 is open or that particular gate on the U531 is faulty or both. Either will require attention so I might as well check it out while awaiting replacement parts to repair the clock divider.
WaveyDipole
Experienced Member
The replacement for U337 (SN74LS93N) has arrived and has been installed.
The screen still has the glow around the edges and I can't clear it with PAGE. However the display does now show a flashing cursor in the top left corner and all lights except POWER turn off a second or two after power up AND STAY OFF! Many keys respond with two or three random characters and some do not respond at all. The AUTO NUMBER key actually responded by printing '100 ' on a new line which shows that BASIC is working. However, most of the keyboard is not responding at all or as it should be.
Having checked the signals on we now have:
P14 [A] - 52.068kHz (we have RCCLK coming in from the clock circuitry on page 04_02-02)
P1 - 26.034kHz (output to U431)
P8 [Qc] - 6.5085kHz (output to U435)
P9 [Qb] - 13.017kHz (this is the output to KBCLK-0)
P11 [Qd] - 3.254kHz (output to U217)
P12 [Qa] - 26.034kHz (output to U431)
I must admit I expected to see about 3.25kHz on all three ouputs (Qb to Qd) but instead I am seeing 3.54kHz on Qd only and multiples thereof on Qc and Qd. Maybe I misunderstood that.
In any case, I traced the 13.017kHz square wave from p9 which is the KBCLK-0 signal to the keyboard on U6p9 as well as U1 p18 and p19. KBHALT-1 is LOW so things appear to look good up to this point. However here is where I ran into further problems. The KEY1 signal on U6p3 is HIGH. There seems to be no response to keys being pressed. Checking the outputs on U1 pins 1 to 11 are LOW (no activity), pin 13 is HIGH and pin 14+15 are also LOW. There is activity on pins 18+19 (G1 and G2) as well as 20-23 (A-D). There is activity on U4 pins 1 and 8,9 and 11 but pin 14 is HIGH.
I checked all the keys to make sure none are shorted and didn't find any problems. The only key that read short whas TTY LOCK which was pressed down but releasing it made no difference. I guess this must mean that U1 is faulty as you said the outputs should be oscillating?
Still, a further step forward.
The screen still has the glow around the edges and I can't clear it with PAGE. However the display does now show a flashing cursor in the top left corner and all lights except POWER turn off a second or two after power up AND STAY OFF! Many keys respond with two or three random characters and some do not respond at all. The AUTO NUMBER key actually responded by printing '100 ' on a new line which shows that BASIC is working. However, most of the keyboard is not responding at all or as it should be.
Having checked the signals on we now have:
P14 [A] - 52.068kHz (we have RCCLK coming in from the clock circuitry on page 04_02-02)
P1 - 26.034kHz (output to U431)
P8 [Qc] - 6.5085kHz (output to U435)
P9 [Qb] - 13.017kHz (this is the output to KBCLK-0)
P11 [Qd] - 3.254kHz (output to U217)
P12 [Qa] - 26.034kHz (output to U431)
I must admit I expected to see about 3.25kHz on all three ouputs (Qb to Qd) but instead I am seeing 3.54kHz on Qd only and multiples thereof on Qc and Qd. Maybe I misunderstood that.
In any case, I traced the 13.017kHz square wave from p9 which is the KBCLK-0 signal to the keyboard on U6p9 as well as U1 p18 and p19. KBHALT-1 is LOW so things appear to look good up to this point. However here is where I ran into further problems. The KEY1 signal on U6p3 is HIGH. There seems to be no response to keys being pressed. Checking the outputs on U1 pins 1 to 11 are LOW (no activity), pin 13 is HIGH and pin 14+15 are also LOW. There is activity on pins 18+19 (G1 and G2) as well as 20-23 (A-D). There is activity on U4 pins 1 and 8,9 and 11 but pin 14 is HIGH.
I checked all the keys to make sure none are shorted and didn't find any problems. The only key that read short whas TTY LOCK which was pressed down but releasing it made no difference. I guess this must mean that U1 is faulty as you said the outputs should be oscillating?
Still, a further step forward.
Last edited:
daver2
10k Member
Ever forward...
I have another thing to do first on the DEC thread - and then I'll have a look.
Also keeping an eye on what is going on (remotely) on one of our power stations. Big brother is watching...
Dave
I have another thing to do first on the DEC thread - and then I'll have a look.
Also keeping an eye on what is going on (remotely) on one of our power stations
. Big brother is watching...Dave
nikola-wan
Veteran Member
Wow - please post a photo of the screen with AUTO NUMBER 100 showing it has successfully powered on.
Interesting that the AUTO NUMBER key worked, but not the PAGE key.
I'll take a look at the service manual volume 1 description of the keyboard operation. I think the top keys work a little different than the other keys as you don't need to press any other key and BASIC reacts immediately to that key press.
Try the COPY key - you then should see a scan line cross the screen.
nikola-wan
Veteran Member
Ok, the keyboard is a straight row/column matrix (Service Manual Vol 2 pdf page 103), so some keys working means all keys should work.
I did notice I had several keys that did not work when I got my 4052 and 4054 working in 2000.
I propose you carefully press every key several times - it may start that key working. You could have a stuck key which would mess up that row and column.
I believe the Cherry keyboard switches have gold contacts - and they be a little dirty and cycling the keys should clean the contacts.
I did notice I had several keys that did not work when I got my 4052 and 4054 working in 2000.
I propose you carefully press every key several times - it may start that key working. You could have a stuck key which would mess up that row and column.
I believe the Cherry keyboard switches have gold contacts - and they be a little dirty and cycling the keys should clean the contacts.
nikola-wan
Veteran Member
4051 Service Manual Vol 1 starting on pdf page 143 shows the scan codes for each key.
daver2
10k Member
Looking better...
U337 (74LS93) is now working.
There is a divide by two between pins 14 and 12.
There is another divide by two between pins 1 and 9.
There is yet another divide by two between pins 9 and 8.
And, you've guessed it, yet another divide by two between pins 8 and 11.
So the frequencies you are reading are OK.
OK, over to the keyboard logic now...
Having a clock on U1 pins 18 and 19 is good.
Also, seeing clock activity on U1 pins 20 through 23 is good. This indicates that the KBHALT-1 is inactive and U3 is correctly clocking.
If you look at the frequency on U1 pins 23, 22, 21 and 20 (in that order) they should also be divided down by two from KBCLK-0 (in the same way as U337 - as it is the same device, so you can use your new-found knowledge).
The outputs from U1 should either all be high (this will be the case when U1 pins 18/19 is HIGH) or only ONE output should be LOW at any one time.
You indicate that the outputs don't follow this pattern.
Some things for you to check:
The output from U1 is OPEN COLLECTOR. The voltage source is via the resistors R2 to R9 (4.7k). Make sure that one side of each resistor has +5V on it.
You also need to make a distinction between 'no voltage' and 'a logic low'. It is also a possibility that something on the key side is connecting some of the outputs from U1 to ground (although you have checked this and it looks like you have discounted it.
With the power OFF (and no keys pressed) the outputs from U1 should not be connected to any of the input pins on U2 (use the resistance setting of your multimeter). Neither should they have a low resistance path to 0V/ground.
With the power ON, you should observe > 4.0 Volt on the D0 through D7 inputs of U2.
With NO KEY pressed - I would not expect you to read any voltage on the output side of U1.
I am, therefore, intrigued by the HIGH you are reading on U1 pin 13. This could indicate a shorted switch contact on that line somewhere.
If you scope the D0 to D7 inputs of U2 you should find all of these signals to be HIGH. If you find one with a clock signal on it - I would bet it is that key that is shorted out to pin 13 of U1.
It is, however, interesting that the AUTO NUMBER key works correctly - and that some other keys 'sort of' work (but produce incorrect codes). I can come up with a scenario where a shorted out key can produce this effect (but you would have to tell me which key you pressed and what it produces on the screen so I could work out the fault tree). It is easier (from my perspective) to get you to go probing...
Over to you...
Dave
U337 (74LS93) is now working.
There is a divide by two between pins 14 and 12.
There is another divide by two between pins 1 and 9.
There is yet another divide by two between pins 9 and 8.
And, you've guessed it, yet another divide by two between pins 8 and 11.
So the frequencies you are reading are OK.
OK, over to the keyboard logic now...
Having a clock on U1 pins 18 and 19 is good.
Also, seeing clock activity on U1 pins 20 through 23 is good. This indicates that the KBHALT-1 is inactive and U3 is correctly clocking.
If you look at the frequency on U1 pins 23, 22, 21 and 20 (in that order) they should also be divided down by two from KBCLK-0 (in the same way as U337 - as it is the same device, so you can use your new-found knowledge).
The outputs from U1 should either all be high (this will be the case when U1 pins 18/19 is HIGH) or only ONE output should be LOW at any one time.
You indicate that the outputs don't follow this pattern.
Some things for you to check:
The output from U1 is OPEN COLLECTOR. The voltage source is via the resistors R2 to R9 (4.7k). Make sure that one side of each resistor has +5V on it.
You also need to make a distinction between 'no voltage' and 'a logic low'. It is also a possibility that something on the key side is connecting some of the outputs from U1 to ground (although you have checked this and it looks like you have discounted it.
With the power OFF (and no keys pressed) the outputs from U1 should not be connected to any of the input pins on U2 (use the resistance setting of your multimeter). Neither should they have a low resistance path to 0V/ground.
With the power ON, you should observe > 4.0 Volt on the D0 through D7 inputs of U2.
With NO KEY pressed - I would not expect you to read any voltage on the output side of U1.
I am, therefore, intrigued by the HIGH you are reading on U1 pin 13. This could indicate a shorted switch contact on that line somewhere.
If you scope the D0 to D7 inputs of U2 you should find all of these signals to be HIGH. If you find one with a clock signal on it - I would bet it is that key that is shorted out to pin 13 of U1.
It is, however, interesting that the AUTO NUMBER key works correctly - and that some other keys 'sort of' work (but produce incorrect codes). I can come up with a scenario where a shorted out key can produce this effect (but you would have to tell me which key you pressed and what it produces on the screen so I could work out the fault tree). It is easier (from my perspective) to get you to go probing...
Over to you...
Dave
Last edited: