Investigating the floppy drive interface of the IBM 3174

FLOPPY DRIVES IN THE IBM 3174

The IBM 3174 Controllers have been built with two capacities of floppy drives, either a 1.2MB or a 2.4MB version. Both of these use 5 1/4" media and are used to load the microcode and utility programs into the controller. The lower cost models of the 3174 come with a 1.2MB drive, while the higher end models implement the 2.4MB version. 

In addition to the single drive that comes in the base configurations, an additional drive can be added as an option; the smaller controller models can add either version of the drive. Another option installs a small hard disk in addition to the single floppy drive. 

The 1.2MB version is identical to the drive that shipped in the IBM PC/AT but did not catch on in the wider PC marketplace. The 2.4MB version is pretty unique to the 3174 controller as far as I know. Since these two versions were not widely used outside of IBM, relatively little is known about their specifications and interface.

LACK OF SPECIFICATIONS AND SCHEMATICS

In fact, the lack of specifications and other details is common to IBM products of the era, at a time when they had substantial competition from other companies building compatible versions of the IBM products and undercutting their sales. To help combat this, technical details were closely held and the microcode was protected under a licensing agreement that forbade any investigation or reverse engineering - terming it Licensed Internal Code.

Existing maintenance documents show the wiring of the cable between the floppy drive(s) and the motherboard, but don't help understand what signals are put on those wires or how it worked. I have to work from the compatible market for IBM PCs (and compatible floppy drive makers) that established the interface over the 34 wire IDC connector. 

Even though we have a defined interface that has a wire to cause the drive to step, it doesn't tell us how many tracks are available on the drive. The wire delivers the incoming data but that tells us nothing about the format of the data on a track, such as sector size, number of sectors, checksums or other formatting information. 

Fortunately, due to the use of the 1.2MB drive in the IBM PC/AT, we do know the details fairly well. The drive offers 80 tracks, two heads, and is formatted on the PC into 15 sectors per track of 512 bytes size. Thus the drive holds 2,400 sectors of 512 bytes for a formatted capacity of 1.2MB

IBM clearly states in the 3174 maintenance documentation that it uses only 77 tracks, not the 80 that the drive is capable of addressing. This in fact shrinks the capacity of the 1.2MB drive to only 1.155MB.

We know that the 2.4MB drive can read the 1.2MB written diskettes, which means that we have 15 sectors per track, two heads, and twice the total number of sectors. What isn't clear is whether the drive still has 80 tracks but could write up to 30 sectors per track, or whether the drive implements 160 total tracks. 

The IBM manual again asserts that the 2.4MB drive uses 77 tracks, thus it is physically capable of storing 2.4MB but actually stores 2.31MB. It must store 30 sectors per track per side. 

Floppy drives were built that supported dual densities. Mostly that meant 360K and 720K but the interface has a signal wire defined for density selection - pin 2. Some drives simply dropped the rotational rate in half for the lower density mode, based on this signal.

One other ambiguity is the presence of two wires in the interface that are listed as N/C- Reserved in the specs but both are wired to the motherboard of the 3174. Those are pins 4 and 6. I had no idea what use IBM might put these to for use with these drive versions. Turns out the definition of the interface I was reading is for more modern drives, those that have only driveA/driveB. 

 

The 2.4MB drives were built by two vendors for IBM - Y-E Data made the YD 803 and Hitachi made the 

I don't have the same certainty about the makers of the 1.2MB drive, but I do know that Mitsubishi made a 1.2MB 5.25" drive for use in some IBM products, the MF504C-342MN. Y-E Data made the YD-308 which is likely one of the drives installed in the 3174, since they chose the same maker for the higher density versions. Many other makes built 1.2MB drives, among them Teac, NEC, Epson and Mitsumi. 

I looked at the specs for the EPSON SD-800 and its 5.25" drive specifies 160 tracks, 80 per side, so that matches what I know. These earlier drives had four drive select lines DS0 to DS3 instead of the two (A and B) of more modern 5.25" products. This gives me the usage of pins 4 and 6. Pin 4 is a head loaded  signal, pin 6 is DS3. Pin 2 is unconnected on this drive. 

The Teac FD-55GFR is also a 1.2MB drive and it uses pin 2 to select between high density (1.2MB) mode and lower density. You can jumper the drive to determine whether the wire connected to ground asserts or deasserts high density. 

Internet posts by others investigating the 2.4MB drives show pin 2 as an input to the drive, which is not connected on the 1.2MB drive. I suspect that this line is used to switch the higher density drive between 1.2MB compatibility mode and full 2.4MB mode. 

Here are the pins of the interface and the usage that I suspect for the 3174, remembering that all odd pins are ground:

      2 - unused on 1.2 drive, some input probably density select to the 2.4 drive

      4 - output indicating that the head is loaded onto a diskette thus ready to read

      6 - DS3 select input, ignored by the drive due to jumpers set to DS1

      8 - Index pulse output

    10 - DS0 select input, ignored due to jumpers

    12 - DS1 select input, which is toggled by 3174

    14 - DS2 select input, ignored due to jumpers

    16 - Motor enable input

    18 - Direction of travel input

    20 - Step pulse input

    22 - Write data input

    24 - Write enable input

    26 - Track 00 output

    28 - Write protect output

    30 - Read data output

    32 - side select input

    34 - disk changed output

HOW DOES THE 3174 KNOW WHICH VERSION OF DRIVE IS INSTALLED

It appears to be wired into the cable harness. I assume this because the maintenance manual lists different cables for a controller with twin 1.2MB floppy drives and a controller that has a 1.2 primary and 2.4MB secondary drive. 

Physically, every pin is wired to the motherboard except for one \on each connector. The ground side is a black wire and the signal side (even pins) is a yellow wire for almost every pin position. Oddly, it differs between the primary and second drive positions. 

On my unit, which has the cable for 1.2 MB primary and secondary drives, the primary drive connector has no black ground wire on pin 13, instead that black wire is connected to pin 14 (DS2). For the secondary drive, the ground wire is not installed on pin 5 and instead is connected to pin 6 (DS3 select).  

Since the DS2 and DS3 wires are inputs, they are essentially logically high if the motherboard looks at the ground wire in locations 5 and 13.  If it doesn't match ground level from the other pins, this cable is telling the motherboard that we have a 1.2MB drive cable for this position (primary and secondary). I would need to see the cable wiring for a 2.4MB drive to tell whether they use a different set of ground pins to make the determination of that drive version. 

FLASHFLOPPY SOFTWARE FOR EMULATING DISKS ON THE IBM 3174

I am using a Gotek floppy drive emulator box whose firmware was reflashed to install FlashFloppy into the microcontroller (STM 32). This software is known to work with 3174 controllers with the 2.4MB drives. It has a configuration option (IBM-3174). 

All the known cases where this is working properly are machines with the 2.4MB drives configured in the controller. Since I have the 1.2MB drive as my only unit, this may be the root of my issue trying to read.

There are a number of configuration files for FlashFloppy, where I can override the use of various pins and change behavior. It also allows me to override the geometry assumed for the image file, which may be important since I copied two of the 2.4MB images onto the USB stick.

When I changed the Gotek to point to those diskette images, I saw an E31 error which is FlashFloppy complaining that the format of the file doesn't match the drive it is emulating. I think I might have to explicitly adjust this file both for the 2.4 and the 1.2 images. 

One other possible incompatibility is based on the oddball grounding of DS2 and DS3 pins (6 and 14) by the 3174. I have to investigate whether the Gotek will have a problem with this. 

Built program to list contents of the floppy diskette images, in hex and EBCDIC

Since I know the format of the disk images, based on the floppy drives to which they are inserted, I was able to separate the 2,400 sectors of 512 characters and inspect them. I wrote a program that displays the hex values of each character in groups of 16 and puts the EBCDIC characters to the right of the line. This looks a lot like the familiar dumps of the IBM mainframe environment. 

Example of the output of my image dump program

At least one cause of the failure to IML - insufficient RAM

REVIEWING IBM MANUAL SA27-2573-4 3174 ESTABLISHMENT CONTROLLER MODELS 51R, 52R, 53R, 61R, 62R AND 63R MAINTENANCE INFORMATION

This document has a chart listing the minimum RAM requirements for various versions of the firmware (which IBM calls Licensed Internal Code). The versions I have access to are A5 and B5, with the A5 versions formatted for the 1.2MB drive that came in the machine. Version A5 requires 2MB of RAM.

My controller (model 51R) has a base configuration of 1MB of RAM and a single 1.2MB diskette drive. Unless I find diskettes for version A4, the firmware won't fit inside the paltry RAM installed on this model. 

There were two revisions of the planar (motherboard) in a model 51R, one has 512KB onboard and the other had 1MB onboard. For the machines that have the 512KB planar, a plug-in card was added to bring the total RAM up to 1MB. 

Since I don't know the history of my machine,  I had to do a bit of disassembly to figure out which revision I have. Turns out it was the 9021-03 planar, which has only 512KB of onboard RAM. I don't see an additional card that might host the other 512K. Frankly, I don't see a slot into which I might plug an additional board, such as a 2MB card giving me either 2.5 or 3MB total.

3174 planar (motherboard)

I have ordered a 2MB plug in module, which should bring my machine up to a level that can support the firmware. I am taking a bit of a risk since I don't see where or how this might be added to the machine, but I have attempted to contact someone whose comment four years ago to some reseller indicated that the reseller updated a 51R to 2.5MB, which is what I hope to accomplish. 

Still failing IML of the IBM 3174 with the replaced Gotek/FlashFloppy

IML PROCESS TO GET TO THE DIAGNOSTICS ON THE UTILITY DISKETTE IMAGE

First, the Gotek is set to mount the Utility image, which is image 1 on the USB drive in the Gotek. 

Second, I attached my 3178 terminal to port 0 of the 3174 controller which is where the microcode will communicate with me. 

Next, I held the ALT 1 button and press IML, which began an alternate IML sequence for the Utility diskette. A few buttons pressed to direct the process at my emulated floppy drive and the main utilities menu should appear on the terminal screen. It didn't and I got a failed IML error.

Selecting item 4 would perform hardware tests on the controller. Alternatively I can IML with other parameters to run the tests directly without requiring the terminal to be attached. Neither of these worked. In all cases, I saw the activity light on the Gotek flash 2-3 times but no seeks and the 3174 acts as if there is a blank diskette in the drive. 

NEED TO SORT OUT WHAT MIGHT BE THE CAUSE

I can think of a few possible reasons for the failure to IML at all:

• Something wrong with my configuration of the Gotek
• The disk image files are not in the proper format
• The floppy drive interface electronics in the 3174 are defective
• The RAM is defective in the 3174
• There is a problem with the processor or other circuitry in the 3174

Adding in or improving terminal behaviors for oec 3174 substitute

ENHANCING HOW THE TERMINAL ACTS WHEN KEYBOARD LOCKED

Several situations can arise where the 3270 style terminal will lock the keyboard, refuse any further keystrokes, and display a symbolic error message on the bottom line (Operator Information Area or OIA). It can occur after some screen of information has been sent to the mainframe but a response has not been received. It also can occur if the user attempts something invalid, like typing a character into an area of the screen that is a protected field. 

The terminal should refuse to honor any further keystrokes until the RESET key is pressed. That removes the symbolic error message from the OIA and the terminal begins accepting further input. However, the behavior of oec did not match that. 

With the released version of oec, when such a condition arose, the symbolic error message appeared in the OIA but the keyboard responded to any and all keypresses. Further, the error message was removed on the very next keypress, even though it wasn't a RESET. 

Andrew modeled it the way he did because it matched what he saw from TN3270 client software. He had noted that the arrow keys, TAB and other keys worked right after the lockup condition. I tried with Vista 3270 and reproduced the results.

I dug into this further, since it contradicted both my experience with 3270 terminals years ago and what the manuals said would happen. I discovered that TN3270 software, for the convenience of the user, will unlock the keyboard automatically, in effect pushing the RESET key just before whatever key the user had next struck. 

It was a configuration option in the Vista 3270 software and once I deselected that choice, the behavior strictly conformed to the IBM manuals and real 3270 terminals. No key would be accepted other than RESET once the terminal locked up. 

I then added code in oec that will set and remember the locked state, silently throwing away any keystroke other than RESET. When RESET was typed, it cleared the OIA error messages and turned off the locked keyboard flag. 

NUMERIC LOCK BEHAVIOR INSTALLED

The numeric lock feature or option operates when in any unprotected numeric field. Attributes that define fields can specify them as protected or not, numeric or available for any character, hidden or visible, and determine if the light pen can be detected when placed in the field. 

Numeric lock will behave just like having toggled the Num Lock key. When on, it treats each key as representing the character printed on the upper half of the keycap. For example, the keycap that has K on the lower half has the digit 5 on the upper cap. Without having to hit Num Lock or the up shift key, the keycap is interpreted as 5 anytime you press it while in a numeric field. 

The feature is more restrictive, however, than just forcing the upshift. Numeric Lock only permits the digits, decimal point, minus sign or DUP key.  For instance, the keycap that has E on the lower half has a right parenthesis on the upper half. Hitting the keycap will be rejected because the upshifted character is not valid in a numeric field. 

The hardware allows an override from this behavior while in a numeric field. If you push the up-shift  key (upwards arrow on the keycap), you can choose the upper half characters that are NOT numeric. Up shift and the E keycap will enter a right parenthesis. The downward arrow key, down shift, allows entry of any of the lower half characters. Down shift and E keycap will enter an E into that numeric field. 

I had previously mentioned  implementing this, but I gave more details on how it works and frankly had refined the implementation significantly. If not over-riding with up-shift or down-shift, whenever an invalid character is attempted, the OIA shows a symbolic error message and the keyboard is locked up until RESET is pressed. 

CLEAR FUNCTION NOT RESETTING ATTRIBUTES

The way that the CLEAR key (ALT plus CURS SEL keycap) is handled is unique within oec, being handled in a different module than all the other keys. It did clear the screen of all characters, but somehow the code still remembered the fields that were protected. A CLEAR should remove all attributes and fields, leaving the screen not only erased but consisting of a single long unprotected field with no attributes. 

I moved the implementation to a different spot, where it would leverage the code that ensures the fields and attributes are updated properly This produces the correct behavior in accordance with the IBM manuals and real terminal behavior. 

Debugging underway for the 3174 substitute TEST mode feature

TEST REQUEST KEY ON 3270 TERMINALS AND ROLE OF THE TERMINAL CONTROLLER

The terminal controller which supports multiple 3270 style terminals has a built in capability to display status and run tests. These functions are invoked by pressing TEST to request the terminal be connected to the testing function in the controller, rather than the mainframe system software. 

The bottom line on the terminal, the Operator Information Area or status line, will display TEST when the request is satisfied and the terminal is talking to the controller's test software. Pressing the RESET key will disconnect the terminal from testing and resume normal connectivity to the mainframe. 

Tests can be requested using a terse command line, entered on the screen and terminated by the ENTER key. To run test 0, for example, the operator will type /0 and hit ENTER. Some test categories have multiple subtests, thus they would be selected by an entry like /2,3 from the operator. 

In some cases, a test will display status about a specific bit of hardware such as a terminal port or hardware section (hardware group) inside the controller. For those, the parameters are added to the end of the command line. For example, to do basic terminal check operations for the terminal on port 4, the command line /0,04 is entered. 

The 3174 controller provides 15 major test types, many with subtests, and in addition provides a menu based interface instead of, or in addition to, the command line. Hitting PA2 or PF12 at any time while in TEST mode will bring up the main menu. PF3 is an alternative to hitting RESET, ending the testing. The operator can enter single digits at a menu to select the menu choice they wish. They can also enter the subtest (and even parameters) to avoid having to move through the subtest menus - e.g. selecting 5,3 in the main menu goes directly to subtest 3 of test 5. 

DEBUGGING MY IMPLEMENTATION

Working with Andrew Kay's oec and hardware, a 3174 replacement, I coded up a partial implementation of the TEST functionality. Certain tests or status displays are directly tied to the IBM 3174 implementation, such as displaying control blocks, which have no analog in oec. Some error logs such as communications line retries or port errors will always be zero with the oec implementation, so they are either displayed with static values or not implemented. 

This is invoked by holding down ALT and hitting the key which generates TEST. The screen clears and the terminal shows TEST in the status line. Hitting PA2 or PF12 throws up the main menu. From here I can start various tests either with selection values or the alternate command line format. 

Main menu of TEST mode

I have work to complete - the terminal shows system busy state, erroneously, and the cursor is not positioned properly for the selection digits. I will continue to work through the code to finish this up over the course of the next few days.

Found the problem with the power-down of my 3174

RESULTS OF MY INVESTIGATION INTO THE POWER-DOWN BEHAVIOR

I removed the signal cable and checked the ground side of the edge connector, the IDC connector and the Gotek. Those were all correct. I tried removing the signal cable entirely but the machine still refused to power up when the Gotek was connected to the power cable, but was just fine otherwise.

I then thought to check the voltages on the Molex power connector. This four pin connector had a red wire, two black wires in the middle and an orange wire. PC connectors for floppies are wired with a red wire, two black in the middle and a yellow on the end. In the PC red is for +5V and yellow is +12V. 

On the damned 3174, red is for +12V and orange is for +5V. If I had a proper keyed adapter cable with a male Molex and female mini power connector, all would have been well. Unfortunately, since I was using jumpers temporarily I had no keying to protect me and no idea that the color codes would be misleadingly close to the rest of the world's coloring for power leads. 

I had fed +12V to the Gotek power input. Obviously that blew out something and it now appears as too much of a short for the 3174 power supply, causing the shutdown. The connector on the Gotek presents 18 ohms, which would cause a draw of 278ma on the +5V rail. That is a consumption of almost 1.4W, way too high and indicative of catastrophic failure inside the Gotek.

I will open the unit and hope that I can find a failed component that would have protected the rest of the box from damage, but I fear that is unlikely. More likely, the over-voltage cause several components to fail and it won't be worth the effort to repair. 

Another Gotek is ordered and on its way. Drat.

First try doing IML with the Gotek/FlashFloppy emulator

TEMPORARY POWER JUMPERS TO HANDLE GENDER MISMATCH

I used a couple of alligator clip jumper cables to bridge the ground and +5V lines between the two female Molex connectors, as a workaround until the proper gender cable arrives on Monday. They barely gripped but did make contact, permitting me to try an IML.

WONT HOLD POWER WITH DRIVE ATTACHED

When I flip the power on for the 3174, with the Gotek connected, it begins to power up and immediately shuts down. This occurs in less than a second, just enough time to see the fan blades stir slightly. I need to sort out what is causing the motherboard logic to cut off power so quickly.

INVESTIGATIONS FOR TOMORROW

I need to check the signal cabling to be sure that we don't have the grounds and signals of the IDC connector reversed, or some other cabling issue. The motherboard doesn't like something it is seeing with the Gotek connected, that is the primary clue.

Tomorrow I will verify the ground side of both the PCB card edge connector on the adapter and the Gotek pins that are routed to the edges. I will then check the ground side of the card edge connector from the motherboard. It is possible that I need a cable in between the card edge adapter and the Gotek to 'flip' the wires. 

Peering inside my 3179 terminal monitor to find the CRT part number

WHY I MAY NEED A NEW CRT

When I power on my 3179 terminal, the monitor is exceedingly dim. As it sits, without a keyboard attached, I will only get a blue line across the bottom and a set of characters below that which indicate a defective or missing keyboard. Still, I should be able to get a decent brightness from those elements, but I don't.

The pictures of the terminal on eBay appeared nice and bright, but I realized that they were taken with long exposure in a darkened room. In fact, it must be night for me to see the characters below the line, even with the brightness dial rotated to full intensity.

The good news with this monitor is that there are no burned in images on the screen at all. If it were normal brightness it would be excellent. Alas, it is not. 

POSSIBLE CAUSES

There are a number of possible causes for the very low brightness of the monitor, the most obvious of which are:

• Low voltage at the anode (screen end)
• Low voltage at various control grids
• Exhausted cathode unable to emit sufficient electrons
• Defect in the brightness control circuit

I will set up a voltmeter and probe the various voltages to rule out many of the causes. Most of those can be corrected by finding defective components on the PCBs and replacing them. However, if the cathode is exhausted then I have to attempt a CRT Rejuvenation which applies high voltage to punch through oxide layers that are on the cathode. This process is risky, not guaranteed to work, and often yields a relatively short lifetime at decent brightness before the CRT fades away.

FINDING THE CRT NUMBER ON THE TUBE

A long term fix would be the installation of a replacement CRT in the monitor. It will cost more than the terminal did, but it has two big benefits. The brightness will be fully restored and the monitor will last in that condition for many years. Swapping the CRT involves making many adjustments to get the tube focused, in alignment and with the image properly oriented on the face, but it is achievable.

First, I would need to get a part number for the CRT, other than some opaque internal IBM part number, if I were to have a chance at locating a replacement. Even with that, there is no guarantee that an unused CRT can be bought. 

Luckily, there is a clear label on the side of the tube identifying its maker as Matsushita (Panasonic) and its part number as M34JDJ70B/G thus I have that to use for a search. The IBM monitor number is 5954150 but it shows up only listed as a 3179 terminal monitor. I had hoped it might be a shared monitor used with other products such as PCs which might mean that some properly working units can be found.

I did find an online shop that purports to be able to order the CRT for me at a cost of $441.12 not counting tax or freight charges from Illinois to me. That is a bit pricey since I could buy a couple more used 3179 terminals for less than this price, hoping that one of them would be adequately bright.

Almost ready to attempt IML (boot up) of my IBM 3174 controller

WAITING ON POWER CABLE ADAPTER FOR THE GOTEK EMULATOR BOX

The Gotek emulator box has the form factor of a 3.5" floppy drive, thus it is connected via a 34 pin IDC signal connector and a small 4 pin power connector. The 3174, on the other hand, uses 5.25" floppy drives which use a PCB card edge connector for signals and a 4 pin Molex power connector. I had ordered and received an adapter between IDC and card edge, thus solving the signal connectivity.

Alas, the existing adapter for power that I own has the proper small 4 pin female connector but the larger Molex side is female. Well, so is the power cable from the 3174. A new cable is on its way with the proper genders for both sides, but it won't be here until Monday and I am eager to go today. 

Studying IBM Binary Synchronous Communications (BSC) in case I need it to drive my 3174 controller

CONFIGURATION OF MY IBM 3174 CONTROLLER

The controller I own, a 3174-51R, is the basic model with no options. That means that its only link to the mainframe is a serial connection (V.35 or similar). It has only 1MB of storage onboard and a single 1.2MB 5.25" floppy drive. Up to 9 terminals or printers can be attached to the coax connectors of the box.

CHOICE OF COMMUNICATIONS PROTOCOLS

This unit is designed for remote operation, that is as a box connected by a communications line from the mainframe. It can use one of two protocols for that link, BSC or SNA. The richness of capability of SNA comes with staggering complexity compared to BSC which provides for a pretty simple point to point (or multipoint) link. 

BSC is adequately documented and examples of the code that drives the link are easily available from early, non licensed software such as MVS 3.8 or DOS/VS. I could dig into VTAM code from those same sources and build up a suitable specification for supporting the SNA link but I believe it to be at least an order of magnitude more work than BSC.

PICKING BSC FOR IMPLEMENTATION

Therefore, if I require a working BSC link to allow the 3174 to work with my terminals, I will have to implement this protocol and drive it over a suitable serial link. Perhaps I can link the Hercules mainframe emulator to the 3174, but that will still require some coding as Hercules carries 2703 (the communications controller) traffic encapsulated in TCP/IP. I would have to unwrap the BSC data and control a serial connection wired as a null modem to my IBM 3174.

Progress on 3174 restoration, beginning check out of my TEST mode for 3174 substitute, and fighting Hercules weirdness

PREPARING THE GOTEK FOR ATTACHMENT TO THE IBM 3174 CONTROLLER

The Gotek is a floppy disk emulator box that uses a USB drive to hold diskette images and serves them up over the 34 wire IDC connector used by PCs for floppy drives. The firmware that comes with the Gotek is inadequate to handle the needs of the IBM 3174 controller, but the open source FlashFloppy code can replace the standard firmware.

In order to flash a new version of firmware into the STM32 processor inside the Gotek, I needed to set up the drive and connect it via a USB-TTL Serial adapter, then use the ST loader software to write the new firmware. The Gotek comes with locations for header pins to use the serial adapter to reflash code, but it is shipped with holes on the PCB. I had to first solder in header strips before I made the connections. They are shown inside the red circled area below.

I then  installed the covers but had access to the header pins for my flash update connections. One jumper provides 3.3V to the flash chip on the board for reprogramming. Tx and Rx pins were connected by cables to my USB Serial device, and the drive power connector was used to provide +5V to the unit.

I did the wiring, plugged in my USB serial adapter, then started the ST imaging software. It was straightforward to select the .hex file with the new firmware image and write it to the board. I knew it worked properly because upon power-up the board displays F-F to indicate that FlashFloppy is the active firmware.

I set up the USB drive with the diskette images (Control and Utility) that the 3174 Controller needs for its operation. I can see that the Gotek sees the two, numbered as 0 and 1. They can be selected by the buttons on the front of the Gotek drive. 

I have one more hardware modification to make to the Gotek, soldering a diode across two of the 14 pins on the header strips in the upper middle of the picture above. That provides a drive ready signal when this drive (S1) is selected by the 3174. 

I must wait until the PCB card edge to 34 pin IDC adapter arrives, so that it can be hooked up and accessed for IML of the controller. I expect this Monday evening.

TESTING BEGINS ON THE TEST MODE FOR 3174 SUBSTITUTE

IBM's 3174 Controller provides a suite of tests that can be requested by an attached terminal. Some help test the terminal starting the tests, others examine the controller or other terminals it is handling. These are invoked by holding the ALT key and pushing the TEST key. 

The status line (Operator Information Area) should switch to show TEST in columns 3 to 6, the screen is cleared and simple commands issued on the terminal invoke the various tests. It also has a menu based system that can be invoked to select the tests.

The general format of the commands are /T,S,1,2 where T is the test number, S is a subtest for those that have multiple functions, and the remainder are parameters for those commands that require them. For example, a test might need the specific hardware group (HG) and port number (PN) to localize the test to one device.

I made changes throughout Andrew Kay's oec code to implement a portion of the test functionality. Many tests pertain to internal implementation details or hardware components of the real 3174 that don't have relevance for the oec 3174 substitute. However, I can provide some of the tests with simulated results. The main purpose here is to replicate the experience of using test mode. 

To test, I have to fire up a copy of MVS 3.8 on the Hercules mainframe emulator and connect to it with my 3178 terminal using oec, all before I can put it into test mode and debug. I discovered a few small issues as it initialized, but I was unable to connect to MVS at all which frustrated further testing. 

HERCULES - WTF

Hercules runs on my Windows 10 laptop and has been acting increasingly erratic. Tonight, multiple tries to start up Hercules resulted in spurious permission errors, each time on different files that represent virtual 370 peripherals. 

I also saw alerts that a file TUNTAP32.DLL was not found, which I have to deal with. The result of all of these errors was that I couldn't get the virtual mainframe to come up and wait for the tn3270 connection from my testing setup. 

Google searches don't show errors similar to his newer than 2010 in the early days of running Hercules on Windows 7. Therefore this isn't a known widespread issue but also not a known issue with a quick fix. 

Preparation work for bringing up a physical IBM 3174-51R control unit for testing

MY 3174 CONTROL UNIT

A friend was given a 3174 controller, model 51R, which he in turn gave to me recently. This is a 

controller with nine coax ports that can control up to nine 3270 series terminals. It is the base configuration, absolutely no options added. All the card slots in the cabinet are empty, since all the functions of the base configuration are implemented on the large motherboard (planar in IBM speak). 

Therefore it has 1MB of storage, quite small if I really had many terminal attached. eBay sellers do offer memory modules which I could buy to boost the capacity but this doesn't seem warranted at the time. I has a single communications adapter that provides a V.35 link, 56Kb speed, which can operate in either BSC (IBM bisync serial) or SDLC (IBM SNA synchronous data link control). 

It does not have cards to implement other connectivity such as Token Ring or ethernet. Nor does it have the Async Emulation Adapter card that will hook to ASCII terminals. Fairly bare bones but adequate for my purposes. Many of those cards are available, albeit at somewhat inflated prices, if I need them.

The base configuration comes with a single 5.25" floppy disk drive. While the larger models of the 3174 made use of high density 2.4MB drives, compounding the challenges for hobbyists, the low end models 51R and 53R used the same 1.2MB drives that were used in early PCs. Options existed to add a second floppy drive and/or a hard disk. 

ARRANGING FOR DISKETTE FILES

As is so often true when finding these controllers today, they did not have the diskettes that are essential for proper operation of the controller. A Control diskette holds the code that is loaded when the controller is started up - a process called Initial Microcode Load or IML. A Utility diskettes has tools including those needed to build the customized configuration file that describes the terminals and the controller, such as the models and options installed. 

I am very fortunate to have a friend who is a hobbyist working with these controllers who had the contents of the Control and Utility diskettes available in digital form. I have in hand the contents which could either be written to a real floppy diskette or put into a modern floppy disk emulator. I chose the latter route as it is easier and faster for me to pursue.

CONVERTING FLOPPY DRIVE EMULATOR

I bought a Gotek floppy disk emulator box which arrived today. This box hooks up to the floppy data and power cables, sporting a USB port where a memory stick is inserted. The memory stick holds many diskette images, which can be selected by pushbuttons on the front of the emulator box.

While it has firmware on it that is adequate for many floppy attachments, a much more powerful open source firmware exists called FlashFloppy that fully supports the 3174. The process of flashing the new firmware is multistep but not that difficult. 

Attaching the emulator to the 3174 requires a small amount of hardware hackery. The 5.25" floppy drives have a PCB card edge onto which a connector attaches, but the Gotek comes with the standard 34 pin ribbon cable based IDC connectors that are used with 3.5" floppy drives. I have an adapter coming but I won't have it until Monday evening. 

There are also some signal wires to check and a diode to add that tells the controller that the Gotek is ready. Nothing very challenging but tasks that need to be accomplished before I could IML the controller from the diskette images.

BRINGING UP THE 3174 - PRIOR TO EMULATOR ATTACHMENT

About all I could verify without real diskettes or the completed floppy drive emulator is to power up the unit to check that it passes the very primitive tests and then indicates missing/empty floppy drive errors. 

It came up with all power supply voltages present and proceeded through its attempt to IML. I saw the display cycle back and forth between 57 and 58 a few times, then move rapidly through some numbers in the range of 1xx up to 113. The red access light on the floppy drive illuminated and blinked as it tried to read a diskette. It advanced to 114 for a bit and then to 130 where it remained. After two seconds at 130 it also illuminated the red Condition Check light on the faceplate.

The first two codes, 57 and 58, show the processor doing memory diagnostics on the 1MB of storage configured in the machine. The sequence starting at 1xx is the IML process itself. It is accessing floppy drive 0 during 113, but of course there is no diskette installed so that fails. It then moves to 114 which tries to access floppy drive 1. Eventually that will be my emulator but today it was not operational.

Status code 130 is the expected terminal state in this case. It tells us that an IML was not possible because the Control image was not found in the fixed disk drive nor in the two floppy drives. This hints that I have a working 3174 simply waiting for the microcode that I will install in the Gotek and hook up as drive 1. 

Implementing part of TEST mode for 3174 controller replacement - because I was bored

TEST MODE WITH THE 3270 TERMINAL FAMILY

IBM built in a test capability to the terminal system, activated by hitting the TEST key. The terminal switches into TEST mode, indicating that in the Operator Information Area (bottom line). Once in the test mode, the screen is cleared and commands can be entered to run various tests or status displays. These tests run in the control unit (e.g. 3174) and for the most part were used by the CE/FE doing maintenance or repair.

FOUND DOCUMENTATION OF 3174 TEST SCREENS

I found a fairly lengthy description of the tests with images of the screens that would be displayed. It is about 85% complete, sufficient to build a realistic emulation for my environment. Obviously with the oec 3174 replacement fielding only a single terminal of a specific type (3178 with Data Entry Keypunch keyboard in my case), it could only report on one terminal's state. Further, internal control blocks, status information, logs and traces don't make sense in this environment.

One could type a string of the form /test,subtest,option,option that selected the test by number and passed in parameters it might need. For example, the test might ask for a hardware group number and a port number to request the specific port whose data will be displayed. 

SCOPE OF IMPLEMENTATION

The 3174 offered 15 test categories, numbered 0 to 12 plus A and D. There is a menu of test choices available as well. For some tests there are several sub-menus, that is multiple types of test under the one category. 

The tests that I substantially implemented were:

• 0 - Terminal Check
• 2 - Display Configuration Panels
• 3 - 3279 Device Status Information
• 5 - Display Vital Data

The tests that I didn't implement were:

• 1 - Display event logs and response time log
• 4 - Reset logs and cable errors
• 6 - Display Control Block Areas
• 7 - Color convergence
• 8 - Extended function and programmed symbols test
• 9 - Token-ring tests
• 10 - Port wrap tests
• 11 - Trace control
• 12 - Asynchronous Emulation Adapter tests
• A - enter installation customized alert information
• D - dump distributed function terminal data to disk

I built a file to implement all the displays that would be written as tests were activated, then looked for how to hook into the existing oec code to drive the test mode. My idea was to have a state that is toggled to show whether the terminal is in TEST mode or normal mode, switched by pressing the TEST key on the terminal.

When the action oriented keys ENTER, CLEAR, PA2, PF3 or PF12 were issued, they would normally be presented onward to the host computer to which our terminal was connected. In test mode, however, they would cause the selection field input to be parsed and based upon that the test screens would be activated.

ENTER is the normal action, causing interpretation of the typed string /test,subtest,optionA,optionB. . . to extract a test choice and to set up the optional parameters. Then, based on what screen was active at the time, the appropriate test screen is displayed. PF3, PF12 and CLEAR will navigate among screens. PA2, CLEAR or PF12 will bring up the main test menu screen; alternatively the user can just type in the /test,option commands in a cleared screen initially. 

GIFTED A GENUINE 3174 CONTROLLER

I was offered a free 3174 controller, which I accepted since, as a friend suggested, at worst case it would make a historically accurate case for the Arduino and shield used with oec to act as a 3174 substitute. I might be able to get this operational, allowing me to double check the faithfulness of oec and other emulation of the 3174. Plus, its a fun project for down the road. 

Another take on the status line data

EXPERIMENTING WITH VISTA 3270 PROGRAM

I fired up Vista 3270, an excellent free 3270 terminal emulation program that I used to connect to Hercules rather than the oec system. I looked at the status line displayed on the terminal window for another take on the status symbols to display.

As we can see, the symbols in columns 2 to 6 are the same as the BSC or channel attached control unit, but the first character is an M. The right hand side shows a lower case a but will change to an up arrow or a lock symbol if the shift or Caps lock is hit. It also shows a ^ if the terminal is in insert mode. The right hand numbers indicate the line and column position of the current cursor. 

CHOOSING A PERSONA WHICH DICTATES THE STATUS LINE

There are a number of potential situations that I would be modeling in my setup. 

• Look like a terminal inside the data center, connected to a 3x74 control unit that is channel attached. 
• Be a remote control unit such as programmers or data entry people would typically use from a location away from the data center. 
• That remote control unit could be connected by BiSync communications or using SNA. The terminal may appear as a TN3270 connection made over TCP/IP directly to the mainframe. 

My personal choice is local (channel) attached 3174 and I will program in the status line behavior appropriately. I had also found a writeup of the TEST options and behaviors, so I will add that into the code. 

Answers to "how does it know"

MISTAKES IN PRIOR POST

I incorrectly stated the purpose of the column 2 character in the 3178 Operator Information Area (status line). The A with underline or B with underline are not associated with the A or B row of connectors on the 3174. 

THE STORY - HOW IT KNOWS

Instead, the B is shown when SNA connects to the terminal. The A will appear for either BSC line remote 3174 or channel attached 3174 systems once the first command is sent to the terminal since power-on or a terminal reset. These include Write, Erase/Write, Copy, and Read Modified commands. In other words, the first time that data streams are sent to the terminal, it illuminates the A character in column 2. 

The word TEST in columns 3 to 6 is switched on by the 3174 when the TEST key is pressed, and switched off by another press of that key. When the terminal is put in TEST mode, the A in column 2 goes away. 

When the terminal is accessed in A mode, the symbol in column 3 becomes the solid filled rectangle. It does away simultaneous with A.  SNA connections to the terminal set the B in column 2 and set column 3 to one of the three rectangles - solid, with ? and with stick figure of a person - depending on what kind of SNA activation was implemented. 

Thus, the 3174 control unit that is configured for SNA access will use the B in column 2 and the SNA symbols in column 3. It knows it is SNA and it knows what kind of connection it has. 

The 3174 that is either remote with BSC or channel attached will use A because it knows it is NOT SNA and it will use only the solid rectangle in column 3 (or TEST). 

Investigating a "how does it know" question concerning the status characters on the last line of a 3278/3178 etc terminal

OPERATOR INFORMATION AREA - STATUS LINE

The last line of any 3270 terminal is a special reserved area that cannot be addressed by the mainframe programmer or software. It shows status such as when the terminal is in Insert mode, shifted mode, pending print, and other indications which can be determined by the 3174 control unit (CU) and displayed on the status line of the terminal.

FIRST SIX COLUMNS SHOW CONNECTION TYPE

The first two columns indicate physical connectivity. In the case of a 3174 CU, the terminal displays a rectangle with a 4 inside. The second column shows an A or B with an underline to tell you whether the coax is plugged into the primary A row of connections on the CU or into the secondary B row positions. 

Columns 3 through 6 display one of four symbols indicating what software is driving the terminal. A rectangle with a stick figure person inside indicates that the terminal is being used by the operating system software, such as when I have it connected as an operator console. A solid rectangle indicates that an application program is driving the terminal; this might be a CICS application for example. The four letters TEST indicate that this terminal is connected to diagnostic test programs in the mainframe temporarily. Finally, a rectangle with a ? inside tells us that the terminal is not driven by either applications or the OS at this time.

Terminal hooked to 3174 A port and driven by the OS

MY QUESTION

What I don't yet understand is how the 3174 CU knows what software is driving the terminal. There does not appear to be any commands, orders or data that indicate these four states. There is no way to set the buffer address to the status line area in order to write to columns 3-6. 

My working hypothesis is that a particular sequence of commands and actions is detected by the CU to determine which of the four states we are in. There doesn't seem to be any documentation covering this. I may need to look at the source code for the driver code such as DIDOCS which handles system consoles, seeing if any comments at connect and disconnect time hint about the special sequences that might be sent. 

If any of my readers happen to know the answer to this or can point me to documentation/sources to help answer the question, I will be quite grateful. 

IPL and Operation of MVS 3.8 under Hercules using my 3178 terminal and the OEC package

WORKING ON BUFFER OVERRUN ISSUE

The initial error I had was due to two spots in the code that didn't handle wraparound of buffer addresses. Andrew already had a function handling this in most spots, thus it was easily added to the remaining code that incremented the address.

LIGHT PEN ERROR MESSAGE WHILE BRINGING UP MVS

I then fired up the Hercules simulator with the turnkey MVS 3.8J system, using oec and my terminal to connect as the primary system console at x010 and control an IPL that I began from the MVS sysres pack. 

Things proceeded decently for a minute or so until I had to reply to a JES2 startup message. I entered a valid reply - R 00,Y - but when I hit ENTER I saw an error message about invalid light pen selections. I had no way to bypass this problem so it had to be fixed.

RESOLUTION OF THE LIGHT PEN ISSUE

I worked with Andrew after enabling the debug logging he had in his code, collecting the results and interpreting them to figure out what was going wrong. Eventually Andrew spotted an issue with addressing mode and suggested a very tiny change. 

The 3270 systems can send buffer addresses in three different modes - 12 bit, 14 bit and 16 bit. The oec code was working in 14 bit mode however it appears that the MVS operator console expected 12 bit versions. 

Addresses are always transmitted as two bytes. In 12 bit mode, the bottom 6 bits of each byte are combined to form the full address. In 14 bit mode, the first byte uses the bottom 6 bits while all 8 are used from the second byte. Using all bits gives the 16 bit addresses. 

Terminals come in various buffer sizes - reflecting various numbers of lines and columns per line. Most of them are easily addressed with 12 bit addresses and that was likely the initial and only mode for 3270 terminals. My terminal needs to address 1,920 locations, well under the limit of 12 bit mode.

SUCCESSFUL STARTUP OF TURNKEY MVS 3.8

With the code changes put in place, I was able to successfully bring up and operate the MVS 3.8 system using my terminal. I created a quick video here to show the results. 

First connection between Hercules (370 MVS 3.8 emulator) and the 3178 terminal using 3174 replacement

STARTING HERCULES WITH MVS 3.8J WAITING FOR THE CONSOLE

Volker's turnkey MVS 3.8J system with Hercules was the basis for my test today. I modified the configuration file to remove the other 3270 terminals, leaving only the main console at x010 which I would connect with on port 3270. 

CONNECTING WITH THE 3174 SUBSTITUTE AND TN3270

I fired up the oec code pointing it at localhost and port 3270 where it established a session connection. I saw the confirmatory text on my physical 3178 terminal. Further, I could move the cursor around with the arrow keys. However, the NewLine key was not working properly. Not sure if this is an issue since I had more serious challenges ahead.

IPL ATTEMPT ON MVS

This configuration of MVS has the sysres volume on drive x148 thus I did an IPL from it to begin the process of bringing up MVS. Very soon after it began, when the boot time code began to write to the console, I received an index out of range error in the oec code which crashed. 

This appears as if it were trying to write beyond the end of the buffer which in my case is a 24 line by 80 character terminal thus 1920 characters. I need to instrument the code a bit more in order to discover exactly what is happening and why. 

There is a decent chance that this is caused by some misconfiguration of the Hercules/MVS environment leading to the IPL code writing bad data streams to oec. I need to play with the system a bit using ordinary tn3270 client software on my laptop in order to ensure that my setup is correct. 

Challenges running 3174 substitute under Windows

MOVING ON TO OEC SOFTWARE BY ANDREW KAY

Once I had my own code running to my satisfaction, it was time to move over to the full 3174 controller replacement that was developed by Andrew Kay. I had a few tweaks to make to the code since he built and tested this with just two terminals, a 3278-2 and a 3848, not the 3178 or 3179 terminals that I own.

The keyboard I have is a Data Entry Keypunch type while his terminals have the Typewriter arrangement The consequences of that are subtle in one way, the existence of a downshift key which he doesn't have, and simple due to extra keys PA3 and SKIP. 

On the typewriter, there are two upshift keys and a caps lock, since the typewriter has both lower and upper case letters. The IBM keypunches (026, 029 and 129 for example) only have upper case letters. They use the up shift key as a numeric shift, not capitals. 

That means the same in many ways - select the upper character on the keycap while upshift is pressed - but on a keypunch there are programs that force a field to be numeric. Therefore, the down shift key is needed to select the lower character when the keyboard is in numeric mode. Also, caps lock is called numeric lock on my keyboard. 

I had recorded all the scan codes emitted by my keyboard when pressing the keys, embodied it in a terminal key map file along the lines of his existing 3278 and 3848 files, and adjusted his software to recognize the keys he was missing on his keyboards. 

Finally, I tweaked the logic to recognize when the keyboard is in Caps Lock mode, now logically Numeric Lock mode, so that if the down shift key is pressed we ignore the Numeric Lock state. I was ready to fire up the system and test my keyboard. I would need a mainframe to connect to, which I handled by running an instance of Hercules the 360/370/z emulator. 

BRICK WALL ENCOUNTERED

Alas, one of the deficiencies running Python in a Windows environment is that some OS related functions that are commonly used by Python coders are Unix based. For example, fcntl is used to manage files, but on Windows the win32 API does only roughly analogous functions and is not code compatible. 

The VT100 capability included in the oec product, although not something I will be using, make extensive use of fcntl and many other OS functions for its pseudo TTY implementation. Thus, when I fired up the controller product, it couldn't find those functions and promptly quit.

ADDING A LINUX ENVIRONMENT FOR MY TESTING

I have hit this enough that I need to reestablish a Linux environment for software such as this that fails to run under Windows. As a quick and dirty solution without the small risk and effort of partitioning my laptop to be dual boot, I am setting up a USB stick based Ubuntu system with enough persistent storage to place Python its libraries, Hercules and oec. The large capacity USB stick arrives later today and by tomorrow I will have the alternate environment running.

WORKAROUND TO TEST UNDER WINDOWS

Andrew confirmed that only the VT100 functionality attempts use of the OS specific functions that are missing on Windows. Thus, I only had to comment out the include for VT100 at his suggestion and could bring up the software to begin my testing.

Quick demonstration of the functionality of the 3178 terminal

WROTE A FORMATTED SCREEN WITH FIELDS

I set up a sample screen, simple but exhibiting a number of important features, which appears when I start up the terminal. This divides the screen into twenty fields, some unprotected to allow operator data entry and the others supporting labels and light pen select fields.

The top two lines are for entry of the Name and ID. The ID field must be numeric. The third through fifth lines are available for entering Notes. The first field of a line is the protected and intensified text label, followed by the unprotected field for the operator to key in a value. 

Immediately after that value field, there is a numeric & protected blank field which signals that the terminal should, when the last character of an input field is entered, autoskip to the next unprotected (input) field. If I did not use the numeric & protected field, it would have simply advanced to the next sequential field which is protected and won't allow input. 

There are three selection lines for the light pen - using a ? character to define it as selection. While I don't have a light pen, if the cursor is positioned in the field and the CURS SEL key is pressed, it acts as if the light pen were used. Each time I select the field, it toggles the field between ? and >, with the later character indicating it was selected. 

Below those three lines I have two action type light pen fields. Using the CURS SEL in either of them will send an event to the mainframe indicating that the operator has requested an action. They differ in how they present to the mainframe, but otherwise are similar.

My final input field is on line 24 of the display and it wraps around to the first few character positions of line 1; this was chosen to stress the logic needed to handle wrap-around buffer addresses. 

At the end of the work with the formatted screen, I hit the CLEAR key which wiped away all the fields and characters on the screen. It became a single 1920 character unformatted expanse that I can type into in any location. 

SHOWING OFF THE FUNCTIONALITY

This video IBM 3178 Operation and Use on YouTube shows me taking the terminal through its paces, moving around, entering data, watching it ensure protection and proper formats, and many other operations. 

YouTube video of the project to animate the Apollo DSKY panel

I uploaded a six minute video that discusses a high level version of the work I did in lighting up the panel.

Click here to launch it. 

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