Steady debugging work on IBM 1130 support devices plus improvements and design ideas

CONTINUING OFFLINE TESTING OF IBM 1130 CONSOLE PRINTER EMULATOR

Today I set up a second Arduino to drive the signals that would come from an 1130, allowing me to test out the correct behavior of my program. This is the most I can do until I fire up a real 1130 computer and test; it will take me some time to reorganize my garage before I can run the 1130 to accomplish this testing.

The IBM 1130 will pull the tilt and rotate lines low when it requests the console printer to type a character. There are four tilt levels on a type ball, selected by T1 and T2. There are five amounts of rotation to either side of the resting position of the type ball, plus the ball can rotate 180 degrees which on a typewriter separates the upper and lower case characters. Rotate codes are R1, R2, R2A, and R5.

An additional signal AUX is sent but is always 1 for printed characters and 0 for control commands (CR, LF, TAB, SPACE, BACKSPACE, UPSHIFT, DOWNSHIFT, PICKREDRIBBON and PICKBLACKRIBBON). This is consistent with the intended use of that bit, which is to fire the print cycle on the selectric when the values of T1, T2, R1, R2, R2A and R5 are all zero. It also fires a print cycle for any other tilt and rotation selection, causing no harm.

When the tilt and rotate values are all zero, they select the home position of the ball (the 0 for lower case side and | for upper case hemisphere ) but the machine won't activate unless one of the select characters is switched on, thus AUX  will be used to trigger a print cycle. If it were on with a control command, that would fire a spurious print cycle and type a 0 character, but the 1130 only uses it to print the tilt 0, rotate 0 home position.

The AUX signal is called the CHECK signal on other I/O Selectrics and its role is to institute a parity check on the value of the tilt and rotate signals, plus to trigger a cycle for the home position (0) if that is being printed. That is used when there are contacts on the I/O Selectric that route back feedback on the actuation of the tilt, rotate and check selection. Since the 1130 does not use the feedback switches, it doesn't do any parity generation or checking.

1130 console printer typeball characters

Selecting which hemisphere (upper or lower case side) is done by the upshift and downshift command signals which take their own print cycle to actuate. The controller logic in the 1130 recognizes when the ball must be shifted to the other side and institutes an upshift or downshift operation transparently before typing the requested character.

Whiffletree adder for rotating a selectric typeball

The Selectric mechanism uses a Whiffletree mechanism to tighten up on the rotate tape in five steps, twisting the typeball to one of five step rotations away from its rest or home position. The R1 lever pulls the tape to rotate a single character away from home. The R2 moves two steps. R1 and R2 together will move three steps away. When R2A is activated along with R2, the typeball is rotated four positions from home and when R2A, R2 and R1 are all activated, a maximum rotation of five is achieved. It is not valid to have just R2A active, nor R2A and R1 alone.

The remaining lever, R5, is used to reverse the direction of rotation. This converts the sum computed by the Whiffletree to a negative number, twisting the typeball 1 to 5 steps from home in the opposite direction from positive numbers. Thus, R1, R2 and R2A select one of five rotations and R5 determines the direction of rotation of the ball. Including the home position, no rotation, this gives 11 positions around the ball where characters can be positioned. .

Tilt whiffletree and tape

The tilt mechanism has a simpler Whiffletree adder which only has to sum two bits for produce 0 to 3 as a tilt amount. This selects one of four bands circling around the perimeter of the typeball. The combination of four bands with 11 rotary positions each allows for the selection of any of 44 type characters on the hemisphere of the ball.

A different mechanism will rotate the ball 180 degrees when the "Shift" key is pressed to move between the upper case and the lower case halves of the typeball. Including these two halves, a selectric typeball has 88 addressable character positions.

To select the letter V you would switch on T1, R1, R2A and R5 which select tilt band 1 and rotate position -3. The 1130 typeball has capital letters on both hemispheres, confusingly, so that the same code T1, R-3 will print a V on either the upper or lower case sides of the ball.

For non-alphabetic characters, unique characters exist on each side. The character 2 is on the lower case side only, with tilt code 0 and rotation +1, selected by activating only R1. If the ball is turned to the upper case side, the same R1 will generate a + instead of 2.

The tilt, rotate, aux and command signals are all inverted logic - high when off and pulled down to logic level 0 when activated. The 1130 uses open collector drivers for these signals, allowing them to float to whatever level they wish until activated by pulling them to ground. With a real 1053, the lines float to +48V through the solenoids and the act of grounding them energizes the solenoid coil.

In my device, the Arduino provides a weak pullup to +5V on these lines, allowing the 1130 drivers to pull them to ground when activated. Since I have no way to set up the second Arduino as an open collector driver, I must temporarily switch off the pullup behavior on my device to allow the second Arduino to drive it properly.

I stuck seven signal jumpers and bridged grounds between these two Arduinos, driven and driver, then rustled up two laptops to connect them to. My goal is to work through the various characters to assure myself that I decode the bits correctly and drive the emulated typewriter. As part of the test I put a scope on the feedback lines to watch the CB Response feedback for appropriateness.

Testbed to drive select codes

After validating the tilt and rotate codes, I began focusing on the decoding and printing part of the emulator, issuing all the various shift and rotate codes for typeball characters. Once these were reliably working, both upper and lower case characters, the commands such as space and backspace had to be tested.

Most of the commanded operations are working fine, but I have some problem remaining in the LineFeed and Tab commands which are hanging. Working fine are space, backspace, upshift, downshift, CrLf, ShifttoRed and ShifttoBlack. I had to pack it in for the night but hopefully tomorrow will see everything working properly.

Part of the design is some tolerance to minor variations in the arrival of the various select lines from the 1130, matching the mechanical inertia in the Selectric mechanism and thus permitting a bit of skew in the turn on of tilt and rotate codes. I will add some minor delay between flipping on signals to test this out when I continue tomorrow.

IMPROVEMENT TO IBM 1130 CORE LOADER DEVICE

Based on another good idea by Peter Vaughan of TNMoC, I added an activation toggle character to the device. It powers up inactive, but can be turned on and set to the first location to load words by a character, then proceeds as before to load words and change the address as desired, until the activation character is again issued which causes the device to surrender control back to the human operator.

RESEARCH ON SUPPORTING THE APL (987/988) TYPEBALL ON 1053 EMULATOR

The APL language was supported by a selectric typeball but the language required more than the 88 characters supported on one ball. The solution adds some challenges for my 1130 console printer emulator.  There are 18 characters which were formed by typing one character, backspacing and typing a second character, the combination of which represents a single new APL character.

APL characters that existed at the time of APL/1130

If I look back at the last two print operations in my emulator, I could match the 18 sequences of char 1, backspace and char 2 from the table. If writing a terminal emulator for the PC side of the emulator, I can replace those triple character sequences with the unicode representation of the intended single APL character.

There are at least two other ways to accomplish this with the emulator. I could watch in the emulator and when detecting the last of the three character sequences, I could backspace again and then emit the appropriate unicode. Or, I could create each print line graphically rather than as text, so that a backspace does not erase the pixels left with the printing of char 1. Then, the pixels from char 2 would be added to form the appearance of overstrike on a typewriter.

The problem with the last method is that the data is really graphical images, so that any stored file from a session would not be searchable for text and instead will print as a bitmap. This may or may not be acceptable to a potential user.

The middle method allows for any terminal emulator that implements the ASCII backspace by erasing the prior character and positioning the cursor back one column. The first method requires a custom terminal emulator be written to address these compound characters.