Implemented the Num Lock feature on my terminal

DATA ENTRY KEYBOARDS AND NUM LOCK

The 029 and 129 keypunches that would have been the data entry devices of choice prior to the arrival of these terminals created punched cards. The card was often divided into fields by a program drum or equivalent program card ready by the 129. 

Fields could be skipped over, automatically duplicated from the contents of the prior data card, and forced to be numeric (shifted). Thus, the operator would type away without having to hold the shift key for numeric fields and without having to space over any areas of the card that were not being updated.

Since the keyboard type I have, Data Entry Keypunch, is usually associated with the same type of tasks as were done by the keypunch operators, it makes sense that it would allow similar efficiency for typing - skips, auto numeric shift, etc. This explains the special role of a numeric & protected field in forcing a skip operation. 

A feature could be installed in the 3174 or other control unit, Num Lock, which would treat any numeric & unprotected key as if the operator had already held down the numeric shift key or set numeric lock. As soon as you tabbed or autoskipped into a numeric field, the terminal was in numeric mode to interpret key presses as the upper character printed on the cap. 

Implementation was simple, as I already had logic in place to identify the numeric field and display NUM on the Operator Information Area (status line). I only had to implement the equivalent of Numeric Lock to force it to be shifted. And, of course, I had to remove the shift when we exited the numeric field. 

Added auto-skip behavior to my 3178 terminal

AUTOSKIP DESCRIBED IN THE 3270 COMPONENT DESCRIPTION MANUAL

Autoskip is a behavior that the terminal exhibits as you type in the last character position of a field. It will skip to the beginning of the next field, or further, depending on the attributes of the next field. If the next field is both numeric and protected, it continues until it finds the next unprotected field. However, if the immediately next field is unprotected or alpha protected, then the cursor will be sitting at the start of that field. 

Essentially there are two types of autoskip that the terminal implements. Normally it just positions the cursor at the start of the next field, whether that can be typed into or not. The alternate is triggered by having a numeric+protected field immediately after the current one. In the alternate case, the autoskip acts like an auto TAB instead. 

IMPLEMENTATION

At the point that we have a character typed and ready to be placed into the buffer/screen in the last position of a field, I look forward to find the appropriate start of field position, either the immediate next one or the first unprotected one, using the rules above. I mark this movement, then proceed to process the typed character.

After the typed character is written to the screen, if an autoskip movement was requested, I move the cursor there. Thus when I key in the last position of a field, I see that typed character on the screen and the cursor is now at the first position of an appropriate field further down the screen. 

Implementing Cursor Select key functionality

LIGHT PEN CAPABILITY OF THE 3270 STYLE TERMINALS

One feature available on 3270 type terminals is the light pen. This is a pen shaped object on the end of the flexible cable (actually a fiber optic cable). When it is pointed at certain fields on the screen which are defined with the ability to be selected, the control unit (CU) sends a selection status to the mainframe indicating which field was selected using the pen. 

The attribute byte interprets its 2 bit display field as 

• 00 - Normal, not selectable
• 01 - Normal, selectable
• 10 - Intensified, selectable
• 11 - Hidden, not selectable

Fields that are marked selectable must also have a specific designator character after the attribute. There are two broad categories of these fields, selection fields and attention fields. The selection field allows the operator to select an item usually from a list but does not signal the host of this event. The attention field on the other hand does signal the host.

If the field has a question mark as the designator character, it is a selection field. If the light pen or CURS SEL key is used with the cursor in that field, the CU will change the ? to a > character which is a visual indication that it was selected. This field is marked modified so that the host can read modified fields at some later time and get this. The user can hit a selected field again and reset it to unmodified with a ? displayed.

There are two subtypes of attention fields. Both create an event (similar to when the operator hits a key like ENTER or PA1 or PF5). With a designator of space or null, what is transmitted to the host with that event is only the address of the field that was selected by the pen or CURS SEL key. If the designator is &, then the event sends back both the address and the rest of the data in that selected field. 

CURS SEL KEY ROLE

The CURS SEL key is provided for those who do not have a light pen attachment on the terminal or who wish to use the keyboard exclusively. When the cursor is in a field that is set up as selectable, if the CURS SEL key is pressed and the designator character is ?, >, &, space or null, then it behaves just as if the light pen had been touched to that field. 

IMPLEMENTATION

I added a test function in the Buffer object, isSelectable, to be used when the CURS SEL key is detected. When processing that key, I retrieve the first character of the field itself and interpret it as the designator. If not a designator, the keypress is ignored. If it is a ? or >, I toggle the character in the buffer.  If it is an &, space or null, I issue a print indicating that we had an attention selection event.

Continuing to test my 3174 substitute functionality and fix bugs

CAREFUL TESTING UNCOVERS SMALL FLAWS

I found a number of places where the code wasn't doing what it should. As an example, it is possible to enter characters past the right end of an unprotected field, wiping out the attribute character immediately following. It was necessary to identify these and flag them as protected.

I was also failing to handle Insert mode properly for space bar keypresses, as it was treated differently from the other characters, as if it were a control key. The Backspace key is a control function and I erroneously grouped them as if they were similar. I moved Space over with the other characters and that was resolved. 

My initial code for the Tab and Backtab keys just moved to the next or previous field, but it should have skipped over any protected fields. Thus, Tab means the cursor will go to the next unprotected field. Used a simple while loop that executes repeated movement to the next field if the field is protected, stopping when it reaches the next unprotected one. 

The terminal has a down shift key, which is used to temporarily cancel the effect of the Shift Lock key (actually not capital versus lower case letters but lower versus upper character printed on the key cap). However, I wasn't processing that properly nor was I updating the status line as needed.

Once everything seems totally solid, I will film a video using the terminal and upload it to YouTube. I set up a very simple form, entering name, ID number and some notes. It will demonstrate the various movement and data entry methods as well as the status line and appropriate validity checking. 

Wired second Relay Module to animate the R1 digits on the Apollo DSKY panel

WOOD PLATE (FINALLY) ARRIVES

I don't know what is going on with delivery services this week, but once again I had a bizarre elongation of a shipment occur here in Northern California. The plate was laser cut by Ponoko and ready for shipment by UPS Next Day air by midday Monday. Since I live less than 30 miles from Ponoko that should be an easy delivery for UPS. 

However, UPS never showed up on Monday to pick up packages. Tuesday they accepted the Next Day Air package but then absolutely nothing happened all day Tuesday and up until very late Wednesday, totally blowing the delivery 'promise' of next day air. Finally by late evening it began moving and was delivered Thursday, turning an overnight shipment into a three day shipment. 

Putting that aside, the plate was perfect as usual and I quickly mounted all the pins to allow me to enter five bit codes into five rows of relays, thus switching the segments on the EL panel to light up all five digits of the first (R1) register row. This adds to the Prog, Verb and Noun digits, the COMP ACTY light and the sign for R1 that were already being controlled by the first relay module.

WIRING THE NEW RELAY MODULE INTO THE EXISTING SETUP, PLUS A FEW ADDITIONS

I paralleled a number of lines between the two relay modules, such as the AC high and low wires and all the set and unset (latch/unlatch) connections. Therefore, when my Arduino activates a set for one of the five columns that encode a digit value, it will be present on that column of BOTH relay modules. Since both the set/unset and the selection lines must be active to actually operate a relay coil, as long as the select lines are unique to each relay module, this will work fine.

I did have to build five more driver circuits for the new select lines, hook those drivers to the Arduino and finish updating my firmware to allow me to put values into the digits. Fortunately the components arrived on time from Mouser today. These driver circuits were wired to the select lines on the new relay module. 

Before I completed wiring the new module up to the segments for the R1 register on the EL panel, I tested the latch and unlatch for the digits. I set a few test values and checked for switched AC on the output pins of the relay module.

Once all appeared well, I did the wirewrap connection of the 35 wires from the R1 digits between Relay Module 2 and the EL Display Panel Module. Some visual inspection and sanity checking were conducted before firing up the project. Mainly I wanted to detect dead shorts of the high voltage AC and insure there was no leak of the AC over into the low voltage DC control lines. 

DSKY EL PANEL WITH A TOTAL OF 11 DIGITS, A SIGN AND OTHER FEATURES ACTIVE

Here is a view of the panel working with everything I have wired up. If I wanted to take it to the next level, I would have to build a new PCB with 74 relays to take the place of Relay Modules 3 and 4, strictly to light the ten digits spread across R2 and R3 as well as the sign for those two rows. 

Leftmost digit of R1 intentionally blank

Since the relays would need to work safely with 275VAC on the contacts, I can't just grab the cheapest relays. In an ideal world, I would need 54 latching DPDT relays but that would make the cost and size extremely high, so I can settle for SPST relays with one per segment being controlled. 

Frankly, the additional cost and work goes up dramatically yet the incremental value of seeing the other two register lines is not commensurately high. Therefore, I will stop at this point and declare the project a success. 

Starting point for my substitute keyboard for the IBM 3179 terminal

KEYBOARDS USED WITH THE 3179 TERMINAL

There were three IBM part numbers for type M keyboards for use with this terminal - 1385151, 1389160, 1693640 - with the latter having a very similar Data Entry Keypunch key arrangement to my 3178 keyboards while the others are typewriter style arrangements.  

These use a 5 pin DIN connector but not the same as used on PC/AT keyboards, having a bidirectional serial protocol using a data and a clock line. The protocol is known to be the same as used with newer terminals such as PS/2. That also means the protocol is well described.

Serial protocol with the 3179 keyboard and terminal

Presumed commands from terminal to keyboard

A GOOD STARTING POINT FOR MY SUBSTITUTE

Whether I will attach one of my 3178 keyboards through a converter or just build a converter that talks to more modern systems, I can start with the open source code and documentation of the TMK keyboard project. It includes kicad PCB designs for converter boards as well as the firmware. 

This will not be a direct use since the purpose of the TMK code is to make use of physical keyboards such as what I am seeking, using them with modern systems via PS/2 or USB connections. In a sense, the reverse of what I want to do, which is use something modern to pretend to be the physical keyboard.

STILL SOME UNKNOWNS

There are still some unknowns even with everything I will know after reading over the TMK project information. It would be easiest to simply capture the dialog between a keyboard and a logic element, but I don't have the keyboard so that is moot. 

The Logic Element of my 3179 terminal will either interrogate the keyboard for its keyboard ID or will do a Reset which expects the keyboard ID to be returned. I don't know what to return that will satisfy the Logic Element, but I might be able to find out from others who have converted real keyboards to use with their PCs as they may have captured or be able to capture the returned ID. 

The keyboard is sent a request to adopt a scan code set, basically a mapping of physical keys to the returned code. Many modern type M keyboards will only speak one set, the modern one, but my keyboard may have worked with an earlier set. I don't know what it was or how to respond to the scan code set request message.

The 3179 Guide document mentions the need to set eight dip switches on the bottom of the keyboard to a particular configuration that matches what the Logic Element expects, or they will suffer a mis-configuration error. Perhaps this eight bit code is the terminal ID to be returned?

MISSING PROTOCOL SPECS FOR MY TYPE F KEYBOARD (IBM 3178 KEYBOARD)

I have a connector layout for the keyboard but it has much more than just the power, data and clock lines that are analogous to the 3179 keyboard. I see the additional signals

• Reset
• Data Available
• ACK
• CMD0
• CMD1
• PE
• PE

Unverified pin assignment for 3178 keyboard

Since the scan codes are purported to be unidirectional, keyboard to logic element, the additional lines may be to transfer requests to the keyboard. On the other hand, Data Available sure sounds like a signal going to the logic element. 

I may have to wire up a logic analyzer and capture some traffic between my 3178 Keyboard and its Logic Element in order to understand these pins more fully. The keyboard enclosure contains a clicker that can be switched on or off by the host, which may account for some of the commands that could come. Further, I would expect that there is a way to ask for the keyboard ID which is decimal 9 in this case. 

First test of 3179 terminal in darkness

STATUS LINE VISIBLE IN DARKNESS

The Operator Information Area (status line) across the bottom had a symbol and the number 3, which the User Guide for the terminal gives as the error "Keyboard not attached or functional". That is indeed the condition here as I don't have a keyboard to attach. The three keyboards I have are the type with a rectangular connector to fit to the 3178, while this terminal uses a circular DIN style connector. 

Test mode but failing with keyboard missing error (3)

RECOGNITION OF THE TEST SWITCH

When I put the terminal into TEST mode using the Test/Normal switch, it beeped a few times and showed the word TEST on the status line. No characters were displayed above the blue line. Upon reading the Guide for the terminal it became obvious that the keyboard error message above stops any further testing or action. Until I bypass that error or substitute a keyboard, I won't get any further.

ACTION PLAN

I do have documentation of the pin assignments for the keyboard connector, essentially it has +5V, a clock and a data signal. I imagine I can work out the details of the protocol and enough to at least convince the Logic Element that the keyboard is present and working, although it might require a microcontroller or small FPGA. 

An interesting possibility is if the keyboards I have for the 3178 use a compatible protocol, even though they have a different connector, I might be able to bridge one to the other. This is a bit more unknown that the paragraph above.

Finally, I still have an extraordinarily dim CRT at full brightness. As you can see from the picture taken with flash, with the terminal illuminated the blue line is swamped, same as with daylight. 

Blue line almost invisible in bright lighting