Scoping the 3174 interface board to verify its operation

MAJOR BOARD ELEMENTS

The board is fairly straightforward. The coax connector is hooked to a pulse transformer that has two far side windings, one going to the receiver circuit and one to the transmitter circuit. The receiver circuit is a DP8341 chip and the transmit circuit is a DP8340. The output of the transmit circuit goes through a DS3487 tristate line driver chip so it is not blocking the transformer when listening for incoming traffic. 

There are decoupling capacitors, several resistors to isolate inputs, plus a crystal and cap to generate the 18.867Mhz clock frequency. This is build as a shield, a board the same size as the Arduino Mega 2560, with pins that plug into the Arduino. The serial protocol from the Arduino is carried over the USB cable to a COM port on the laptop. 

CHECKING THE CLOCK GENERATION BY CRYSTAL

No clock, no operation. Therefore, right after I verified power was provided to the three chips, I tested the clock out pin on the generating chip and the clock in pin on the other chip. The signal was correctly formed and on frequency.

WATCHING THE COAX SIGNAL

I put the scope directly on the coax pin to see if the transmitter was sending out the proper bit pattern to the 3178 terminal. It appeared so. Further, I could see a response coming back from the 3178, consisting of two words. 

The program still failed with the same message length error, so I need to zoom in and make sure that the receiver side of my interface board is properly detecting, decoding and delivering the two word response. 

LOOKING FOR DATA BITS FROM THE RECEIVER CHIP DP 8341

I then probed the signals on the DP8341 receiver chip to ensure that they were seeing, decoding and outputting the data I see arriving from the terminal. The pin Receiver Active should go high when a word is arriving, then when it is complete the Data Available pin should jump to high.

That is what I see, which indicates that the chip is seeing the word and is ready to provide it to the Arduino firmware for transmission up to the laptop. Next set of signals to monitor are the error detection pin and the output enable which controls when the chip outputs its received data. 

The Error pin never goes high, indicating that the receiver chip believes it has a properly formatted word that is ready to be presented to the Arduino. The data word received is a copy of the POLL command all bits zero except for 2 (and parity bit 0).

At this point I am going to exchange ideas with Andrew and then attempt some instrumentation to see what his software is seeing from this interchange and how it is dealing with it. Perhaps the 3178 behavior is different from the 3278 and would need some modifications in the code to work properly.

Discovered problems in my interface board to the 3178 terminal but still not working

NEW OLD STOCK (NOS) CHIPS AND PIN OXIDATION

The chips used on Andrew Kay's 3174 interface board are no longer in production; they must be procured through sources like eBay. Any chip you buy is either NOS or removed from equipment after use. I bought mine as NOS.

The DS8340 chip has noticeable grey oxidation on the pins of the chip. When I soldered the chips onto the PCB I visually checked every connection to see a bright properly formed solder surface, using a stereo microscope. However, when I tested connectivity I found that the +5V pin of that chip, while appearing to be soldered properly, was not in fact connected to the rest of the board. The oxide on the pin left a thin insulating area around which the solder flowed. 

I used some flux and resoldered the pins to make sure I had a good connection, after which I went back to testing. 

VERIFYING THAT SOFTWARE ON LAPTOP AND INTERFACE BOARD ARE COMMUNICATING

Andrew provides a simple script that issues a reset to the interface board. This produces a message back from the board giving the software version number. That worked fine. 

VERIFYING THAT WE CAN TALK TO THE 3178 TERMINAL

Alas, when I then tried to run other example scripts, such as to read the terminal ID string or to poll the terminal and see its response, the software again failed with an 'invalid message request' error. 

NEXT STEPS

I need to start probing the interface board, using my oscilloscope, to make sure I am seeing reasonable things occurring. This includes monitoring the coax connector signal and even the crystal oscillator that produces the clock for the chips. 

Testing out Andrew Kay's 3270 interface and control unit software - first unsuccessful try

TEST SETUP

I have my 3178 terminal set up on a table in the back yard, along with the interface hardware and a laptop. The terminal consists of a Monitor Element (CRT), Keyboard Element (doh) and the Logic Element that has the control logic and coax connector for a 93 ohm cable.

Normally the coax cable would be connected to an IBM control unit of some kind, such as a 3174-51C. The control unit connects to multiple terminals on one side and to a mainframe system on the other. Some connect via SNA or BSC communications links, others hook onto the channel of a mainframe. 

The interface I built from Alex's design is an Arduino Mega 2560 with a custom shield attached to implement the electrical and protocol details of the connection. It has a coax connector, which I hook to the cable coming from my terminal. The Arduino is linked by USB cable to a laptop which communicates to the interface using serial communications.

On the laptop, I am running Python code provided by Alex which finishes the protocol layers and provides useful tools to experiment with my terminal. Ultimately, the python code would communicate with a mainframe via some kind of link. As written it uses TCP/IP. 

I will test in three stages. The first is to use the Python based tools to check out the terminal and experiment with its functionality. The second stage will connect to an instance of Hercules running MVS 3.8J on my laptop, allowing the physical terminal to work with the running MVS code. The third state will connect to an instance of VM running on a P390, a PC Server box with a card that provides a 390 processor onboard. 

GETTING PYTHON WORKING ON MY WINDOWS 10 LAPTOP

I installed Python on my Windows 10 laptop but immediately when I tried to do more than see it give a prompt, I discovered something was awry. The distribution comes with the package installer program PIP so I issued 'pip help' but python couldn't find it. 

I had to do some digging to find the cause of the problem. Windows 10 is absolutely refusing to let me turn off the 'read only' attribute in the Python folder and its children. So far, I have let the Windows dumbed down installer and then the official Python.org installer put it in the two places they suggested, neither of which can be set to be updated. 

Finally after I placed it outside of the usual Users hierarchy (e.g. not in Program Files (x86) or AppData), I could make changes and start in on the testing. I found and installed the prerequisites until the code was ready.

FIRST ATTEMPT

I powered up the USB module, turned on the terminal and ran the first test program. It would attach tot he terminal then write a simple message on the screen. It sat for a few seconds and then terminated showing an Invalid request message error to the attempt to poll the terminal. Basically that means that the first byte coming back is not x'01'. 

If the terminal were ignoring the requests, the poll would time out and I should see a string of period characters until it completes power on. Each poll is sent out and either gets a response or times out in one second, causing the period to be printed. 

At this point, I have to begin debugging the interface board I built, as it appears I have some defect either in components or my assembly work. 

Adding a 1202 in register 1

Commence landing - wiring up a couple of digits to indicate Program 63

Testing mini-WASP in and wirewrap method while waiting for my plates to arrive

HAND PLACED CONNECTORS AND TEST WIREWRAP

Building connectors with the mini-WASP (MW) connectors consists of pressing all the individual female or male pins into a plate, drilled with holes in an array with spacing .125". I am having wood plates constructed to hold the MW pins in place and support my wire wrapped cabling.

The plates are not going to arrive for a few days, but I did pick up the supply of female MW pins from Marc and therefore could do a feasibility test of sorts right now. The individual MW pins can be inserted onto the male pins of the power supply and other modules. If I wire wrap these to hook up a minimal circuit I can verify that the basis scheme is going to work.

I wired up the Power Supply Module with its 800 Hz input signal, ground, 14 and 28 volt power supplies, the resistor that stands in place of the dimmer potentiometer on the spacecraft, and a pair each of low and high pins delivering the >250VAC 800 Hz that will illuminate the Electroluminescent Panel Module. 

The results were excellent. It was easy to keep the MW pins on the modules and the circuit worked as intended. I believe I will double or triple the wires wrapped onto the ground, +14, +28 and the four AC pins, ensuring that the 30 gage wire is not an impediment to the currents expected when lighting many segments simultaneously. This will be done when the plates have arrived and I construct the final connectors. 

Checking out my 3178 terminal components

INVENTORY AFTER DIGGING OUT ALL MY TERMINAL PARTS

Using IBM nomenclature, the 3178 C terminal consists of a monitor element, a logic element and a keyboard element. The logic element is what I have referred to as a controller box. 

I have two logic elements, thus can have a maximum of two working terminals. I have three monitor elements and three keyboards.

Two of the keyboards are 75 key units, marked C1 underneath, while the remaining keyboard is marked C3 and has 87 keys. 

TESTING LOGIC ELEMENTS

Both logic elements power up and appear to work fine, given that I don't have a coax connected to a control unit and thus see only local functions. It goes into Test mode and paints characters across the entire screen. In Normal mode I have the horizontal green line between lines 24 and 25, with all nulls visible in the remaining locations.

TESTING MONITORS

One monitor is intact and provides adequate but not strong brightness. The second monitor is intact but has a quite dim level, only suitable for a darkened room. The third monitor has a hole punched in the top of the case and when operated has a decently bright horizontal line right across the middle at about line 12 position. 

TESTING KEYBOARDS

All three keyboards seem to operate, as I can type and see some characters show up on the screen when the terminal is in TEST mode. In Normal mode, nothing happens since the terminal does not see the control unit on the other end of the coax. 

The behavior is the same for all three keyboards and across both logic elements. Pressing the alpha character keys yields the capital letter on screen that matches that keycap. However, the special character keys above the alpha top row (QWERTY etc) show up as decimal digits rather than the value on the keycap.

Further, the cursor arrow keys don't move the cursor, they just put certain special characters on screen. Shifting to upper and lower case on the keyboard still generates the same capital alpha letter. 

I don't know if this is the behavior that would occur on a fully functional 3178 while it had no coax connection and was in test mode, or if this signifies some mismatch between the keyboard elements I have and the logic elements. I won't really know until I have the 3174 control unit project cabled up and active with the terminals in Normal mode. 

INVESTIGATING THE BROKEN MONITOR

I opened the monitor element that had a broken top and no apparent vertical deflection. Right away I astutely noticed the electrolytic capacitor laying inside, disconnected from any PCB. The base had oozing electrolyte. 

I examined the PCB inside the monitor and see the spot where this capacitor (C312) had corroded off the board. It is in the Vertical section of the board, quite consistent with the behavior I observed. 

I intend to buy a replacement cap and install it, after cleaning the corrosion off the PCB. If the traces and connectivity check out okay, I will power up and see if the vertical scan resumes operation. At worst case, I have a fully functional PCB on the other monitor, the one that is excessively dim. I also have a good plastic top that I can swap onto this unit. Therefore I expect I can restore this to working order and have two sufficiently bright, working 3178 terminals.