Monday, November 27, 2017

Now have the 2621A terminal working with my HP 1000 F system


2261A terminal debugging

The code loop is watching for when the status word indicates the buffer empty status, but I don't see the prompt on the terminal. For some reason, that isn't occurring. What I believe has happened from the code side is that the prompt message was output to the 12966A card, it entered the buffer, but it is not clocking out.

That suggests that the UART clock is not working. Since it works with my 2645A terminal, it may be that the card is watching the blue wire, external clock, rather than generating some rate between 9600 and 110 baud internally.

That should be determined by a jumper in the cable connector that holds the P/Ext pin high to indicate internal clock. The wire is there, running from a source of +5V (pin 8) to the P/Ext pin (N). I am beginning to suspect that the sense of P/Ext is reversed from what I believed. That is, it should be set to ground to use internal clocking.

Somehow, the 2645A generates and emits the clocking signal that is used by the 12966A card to drive its output back to the terminal, and the 2621A was able to emit a clock on pin 50 as indicated by the cable jumpering. However, the 2622A terminal, which is the device I actually have, dropped this capability as I can tell from both the schematic and the lack of traces to the pin on the logic board.

Time to rewire the cable connector jumper so that pin N is no longer wired to pin 8, but instead ties to pin 1 or pin A (signal grounds). With that set, it is my belief that I can get the board to try to write out the buffer contents. Then, all I need to do is massage the communications settings in the terminal to match what the code is sending. 

My first test after modifying the P/Ext state made no difference in the CPU side - still looping waiting for the buffer to empty, and nothing appeared on the terminal itself. Next, I hooked up the scope to see if the signal coming from the serial card is behaving properly or not. It should be at -12V except when wiggling up to +12V forming the sent characters.

No movement. Just in case the terminal was pulling the incoming bit line down to 0 (-12V), I removed the wire from the terminal and monitored it separately. Still no characters transmitted. It seems like the serial card is waiting for something, but there are only five signal wires between the devices:

  1. Red TD for data bits from the board, hooked into RD on the terminal
  2. Brown RD for data bits coming from the terminal, hooked to that device's TD
  3. Yellow Ring Indicator on the terminal fed by the device's Terminal Ready signal
  4. Orange Secondary Channel SBA/SCA fed to the terminal's OCR1 optional input
  5. Blue External Clock feed to the board with no source on the terminal
If it is a missing signal, it may be an SBA/SCA value that is expected by the serial board. No documentation to explain what that might be, and the terminal schematic and manuals shows that to be an optional channel line that is by default low (-12V) but can be changed to a steady high (+12V). I can change that value by terminal configuration, so that was the next test. 

No joy - the signal didn't start even with that changes. The final inbound signal is External Clock, which should be ignored given the jumper wire I changed in the cable connector. I did try some other permutations of the wiring in the cable connector, forcing the connection to a fixed 9600 baud regardless of program choice, which should match the configuration I set in the terminal.

That did it! The terminal happily chatted away with the tape diagnostic configuration program, thus giving me two working terminals for use with RTE. 

Working with RTE IV B

Now that I have a second working terminal, it is time to complete my RTE IV B system generation giving me a disk image to boot which supports the twin terminals and my hardware configuration. I will continue doing this under the HP 2100 (simh based) simulator, then convert the disk image to use with HPdrive and my real machine. 


  1. Why on earth would HP have three similar terminals that need tyree different cables? I would expect better from an engineering company like HP.

  2. Hi Pete

    They had quite a few more terminal choices. Each of the terminals itself could be customized with an enormous range of options. You can stand in front of a long row of terminals with the same product number on the front, with no two of them identical.