2622 terminal
It was definitely time to hang the logic analyzer and scope on the interface between the keyboard and the monitor, to figure out why the keypresses are scrambled. My attempts to find a mapping from press to displayed character, in the anticipation that there may be a dropped or hot address bit, came to nothing.
I noticed, for example, that pressing the F5 key on the keyboard produced an 'f4' character on the screen. but other Fx keys didn't display anything. Thus, the assumption that the A0 bit is stuck off didn't work out. Further, since I saw intermediate voltages on all the address pins, they aren't sitting at a steady voltage.
It was easier to bring the monitor and keyboard into my house, near the logic analyzer, since I was pinched on space out in the workshop. I didn't hook up all the address lines, just A0, A1, A2, A4 and A5, but already I could see a problem in the scan coming from the monitor.
 |
| Signals on line 13 is frozen at 1 |
The fact that the low bit (bit A2) is frozen high would convert my F5 keypress into a F4, and after I monitored the other lines, I found that only A2 is stuck. Besides the effect it may have selecting rows improperly, it would report an identification bit not only at 7F but at 7E which may be confusing the monitor decoding keys.
Next up, I identified the pins on the monitor logic board that correspond to the row values being emitted, checking with the scope to see at what point in the circuitry the bit becomes stuck high. The first traces did show that the line stayed high with only the slightest bit of noise present, while bit A0 cycled properly.
I moved the scope over to the monitor, saw the same values on A0 and A2, then pulled the keyboard cable and exactly the same results pertained. Totally localized to the monitor. The row lines (A0, A1 and A2) are driven by inverters, thus not dependent on pullup resistors in the keyboard which is why the signals are valid with a disconnected cable.
First stop is to test the input and output of the inverter gate driving pin A2. That would be a hex inverter chip at U214, with this signal on pins 12 and 13. If the input is still bad, it is produced by a complex chip U412, which is an National Semiconductor 8367 CRT Controller chip. Not only unobtainium, but even the documentation seems to be unobtainium. Sure hope it isn't that chip that is failing.
The structure of the terminal presents only the non-component side of the board to me when hooked up. This makes it hard to get probes attached anywhere but I mapped out the locations in advance and stuck markers on the bottom of the board to guide my probing. It was right at an edge near the keyboard connector.
The outputs of the inverters were correct! The pin I thought was the connector pin for the signal was not. Turned out I had miswired my cable after all and was permuting the address bits. I cut open the cable I made and swapped around the affected wires.
Works perfectly now! My original 2262A terminal and the keyboard work well. I brought them into the workshop, switched to the second 2262A (actually named a 250 terminal for use with a newer HP system), hooked up the keyboard and tested again.
The keys worked properly with the terminal, however once I got past the configuration status and initial test, the display blanked out and no key would awaken it. This may be a configuration setting, dip switches somewhere or something else I don't know, but for the time being, I put the 250 terminal aside as spare parts or a future project.
I did grab the monitor base from the 250 and put the 2262A on it, so that I have a usable terminal now. All that remains to clean this up is to build a bottom case for the keyboard and to install the right kind of speaker inside for the beeps.
 |
| HP 2262A terminal working with keyboard |
7970E tape drive
I did a boot load of the diagnostic tape, which halts with 102000 in the S register, indicating a format or data error. I examined the A register, which had been rotated one bit to the right in order to test bit 0 for a 1 (which originally was bit 1 and indicates data error or timing error). The shifted value was o042003 thus it had been o104006 when read from the tape controller.
Bit 15 indicates 1600 bpi tape, which is the format of the tape we are trying to read. Bit 11 indicates that there were an odd number of bytes read, which is suspicious for a binary boot file since the HP is a 16 bit word machine and should have an even number of bytes. Bit 2 indicates that the write ring is not in the tape, which is correct. If bit 4 had been on along with bit 1, it would have meant a timing error - the absence of bit 4 means it was a pure data error.
Both tapes get this error now, which I believe indicates some problem reading in my drive, rather than the much less likely situation that both tapes are defective. This may require some scope and logic analyzer work to figure out.
I put in some work to enhance my hand code, in the hopes that I could get to successfully write my special 2 word record to a blank tape and then read it back in successfully. There is conflicting information about the need to set the control bit in the tape data channel once you start a write or read.
Several places it was written that when you start a read or write, the control bit for the data channel is switched on automatically. However, I did spot a place where it was being set manually, so I added that into my code.
Eureka! My hand code to write two words, o123456 and o050505, as a record at the load point of a blank tape stopped successfully on its halt code 102000. The tape started, moved and stopped.
Next, I entered my hand code to read two words and load them into the A and B registers before halting. Manually rewinding the tape to load point, then hitting RUN brought me to my successful halt 102000. More importantly, the registers held the values from the tape.
I thoroughly cleaned the tape heads and tape cleaner block, after which I was able to get the diagnostic tape to boot successfully. That is signaled by a halt from the boot loader of o102077. Next up was to run the pretest which validates correct operation of the HP 1000 F and the facilities needed in order to have the diagnostics run.
My pretest ran but ended with a halt code of 102066 - this signifies that some test failed. No terminal output or simple code to show what failed, thus I have to look through the pretest code to see where it tossed in the towel.
Great progress. I collected the pretest code in preparation for running the diagnostics again and checking the register contents to tell me what component is not working properly. Alas, the tape drive chose this time to have its small incandescent bulb burn out, thus it won't recognize the load point reflective strip. Can't load tapes or use it until I get a replacement bulb and install it.
7906 disk drive
I put a VOM on the line that I expected to clarify whether the chain of fault interlocks was open, expecting to see something either close to +12V or -24V, but the reading was -4V. There is a voltage divider consisting of three resistors from the high side to the low side, which add up to 36K ohms to divide up the 36V differential.The point where I was measuring is about 1/6th of the range up from the low point, therefore it should have been about -18V rather than -4V. That suggests I have some problem but certainly not an open circuit which is the usual means that a disk interlock fault is signaled.
That suggests my low voltage is about -7 instead of -24V, which would be sufficient to cause the OR gate input to be positive and trigger the IFL condition. The voltage divider up from the -4V to the +12V high side would put about 5.6V on the gate input, but if the low voltage was at its proper level the input would be down around 0V and the gate would not emit the IFL.
I still should trace back through the chain of interlocks, starting of course with the -24V source, as it is possible that somewhere there is a significant resistance instead of a closed circuit. Nothing is easily accessible but it is the way forward.
No comments:
Post a Comment