2262A terminal
The three possibilities causing the issues hooking the keyboard up to the monitor with my home made cable were:
- cable is wired wrong, has broken wire or short inside
- monitor circuitry is not working properly
- extended keyboard is not compatible with this terminal
A session with a VOM proved out the cable. I am certain of the pin assignments on each side and verified that the cable positively connects each pin to its counterpart without contacting any unintended pin.
The logic in the monitor cycles through all the row and column combinations using bits 0-2 for row and bits 3-6 for column, while watching the output pin to see if it goes to ground when the addressed keyswitch is pressed.
I used the VOM to see if the addressing signals from the monitor were being delivered across the cable. Power and ground were delivered and each addressing pin had a value somewhere intermediate between +5 and ground, consistent with it alternating on and off as the monitor tests for each key.
I then pressed a number of keys - some few displayed characters on the monitor, indicating that the monitor circuitry was watching for the keyvalue bit going to ground as I pressed the key. The displayed character never matched the keycap.
The value produced was consistent, for example the keycap 'w' produced the character '9' on the screen reliably. This implies that my problem is the third of the possibilities, incompatibility of the keyboards.
Some flaw inside the monitor circuitry could still be at fault, specifically if the correspondence between the keyboard addressing pins and the value to be generated is wrong, perhaps because one of the bits is dropped.
I need to study both sets of keyboard documents to check for disparate assignment of row/column to keycaps. I also need to study the bit patterns of the characters on the screen versus the keycap associated value to determine if there is a clear case of a dropped or hot bit.
I switched over to the newer 2262 that I bought from a recycler, hooked up the keyboard, and had similarly disappointing results. I suppose I should add one more possible flaw to the list of potential causes. Perhaps the logic in the keyboard is misaddressing the keys somehow.
My initial test of the keyboard while disconnected from the monitor chose only one key, 'return', and validated its proper selection and detection. Since the first terminal was waiting for a CR but never detected it, that argues against the flaw being inside the keyboard but I have to remain open to all causes until I find the culprit.
An added complication I discovered is that HP sets up the row/column matrix to have fixed diode connections at certain non-key locations, as an identifier of the type of keyboard attached. This implies it will properly detect the encoding by the keyboard type and work properly. If there is anything wrong with the row or column decoding, or the diodes for identification, then the monitor may interpret the key codes the wrong way.
I decided to bring the keyboard inside and run through all the row and column addresses, verifying each and every key and the fixed diodes. After this check I could declare the problem to be in the appropriate side, keyboard or monitor.
The answer is that the problem is in the monitor or an incompatibility. Since the manual refers to this keyboard as the standard attachment for the 2262A terminal, I will very tentatively rule out incompatibility since there are two different terminals from different sources that misbehave the same way.
The problem is not in the keyboard, except for the wild chance that having the speaker not connected (the source of the beep in the keyboard) is throwing off the terminal's identification of the keyboard type.
Tomorrow I will wire up a speaker, just for grins, but then move on to connecting logic analyzer probes to the monitor logic board just to see what it believes is happening. Nothing in the manuals or schematics shows a way to manually configure the terminal for the keyboard type being used.
running tape based diagnostics
Marc Verdiell loaned me 9 track tapes loaded with the diagnostics for the system. I should be able to boot from the tape, selecting my 2645A terminal as the console and run various diagnostics against all my I/O gear and the processor itself.
The two tapes had different versions of the diagnostics, but neither would load. I used my built-in loader ROM to load the program from the tape, but got different errors with the two tapes.
The first tape started motion when I ran the loader but never stopped. I let it wind through about 10% of the tape to be sure that it was past the point where the program would have concluded. I hit the Halt key but the tape kept moving until I hit Preset to reset the tape drive. That means it was in the midst of a read operation but the data wasn't streaming in to memory.
The second tape read a very brief time then stopped with a value in the processor's S register that signaled a tape error or invalid format. It did this consistently at the same point.
Something is probably wrong inside the 7970E tape drive such that it is not correctly detecting characters from tape and perhaps flagging false errors in the case of the second tape. I have to assume the two tapes are good, since the odds that both are bad is quite low.
This sounds like a job for logic analyzers, scopes and debugging skills. I had already cabled up my working 2645A terminal to the system in anticipation of using it as the console for the diagnostic programs. Alas, until I get the tape working I have no diagnostics to run and no use for the terminal.
No comments:
Post a Comment