WIRING AND INSTALLING PARTS OF IBM 1130 CONSOLE PRINTER EMULATOR

ASSEMBLING IBM 1130 CONSOLE PRINTER (1053) EMULATOR BOX

I rough mounted my controls and digital display in the box while I work on the wiring of the SMS paddle card cables and other parts. I still need to mount the 7 segment BCD driver board underneath the display board, mount the adapter boards from the SMS cables, and the Arduino itself, before I can close up the box and have it ready for live testing on an IBM 1130 in a few weeks.

Face of the box containing the 1053 emulator, rough placement of buttons

The box has three buttons across the bottom in a row. From left to right, those are Tab, Space and Return functions. Above them is the digital display of the current column for the virtual carrier. To the left of the digital display are the tab setting buttons. The top of the two sets a tab stop at the current column while the bottom of the two will clear any stop at this column.

Junction boards to connect SMS cables into device

I used small breadboard PCBs to connect the SMS paddle card cables as a strain relief and means to ease the connection to my Arduino. Most of the signals are incoming and will go directly to the Arduino, but four of them are feedback signals that will come from a relay board which switches the 12V and 48V needed by the 1130 controller logic.

The inside of this box is going to be crowded, even though it is relatively large at 11 3/8 x 8 1/4 x 3", because of the five boards plus Arduino and all the wires between the parts. The key to construction will be mounting all the boards on standoffs inside.

By the end of the evening today, I had the first PCB fully wired to the header pins to take the 12 signals on SMS Paddle card 1 and route them into the Arduino. Tomorrow I will work on the PCB for SMS Paddle card 2, then start wiring the relay board into place. 

1130 Console Printer emulator working to spec, waiting only to connect to real IBM 1130

COMPLETED OFFLINE TESTING OF IBM 1130 CONSOLE PRINTER (1053) EMULATOR

I wrapped up my testing today, using one Arduino as a test driver to simulate signals from the 1130 going to the emulator device I built. Everything is working exactly as I intended, particularly when used with a terminal emulator such as PuTTY that supports ANSI colors and the ASCII codes for backspace, new line, return etc.

Test validating lower case characters in black and upper in red

This is as far as I can go until I finish wiring up the device and can plug it into a real 1130 system to verify that it works properly in actual use. I have holes to drill and cut, parts to mount to the box, wires to identify from the SMS paddle cards and cables to wire into place. Should be another day or so before this can be set in place near my 1130 until I can rearrange the garage to power it up. 

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. 

Improved version of IBM 1130 Console Printer emulator, plus work on possessed Diablo drive for Xerox Alto

WORK ON DEMONICALLY POSSESSED DIABLO DRIVE FOR XEROX ALTO

This Friday we put the heads back on the demonic drive, a Diablo disk we are repairing for a fellow Alto owner. This drive has not only fought long and hard against restoration, damaging heads, cartridges and egos, but has the uncanny ability to cause other, previously working, drives to fail when brought in contact with this evil device.

The heads were aligned and we confirmed the problems writing on this drive. It writes sectors which have a high chance of encountering read errors when the sector is read at some later time. Using my disk tool, if the exact same pattern were written to the sector multiple times, eventually the sector would read cleanly. Any variation in the pattern, even the nondeterministic variations on a real Xerox Alto due to other demands on the CPU, and there is no improved readability.

We examined the command signals for writing and turning on the erase head, which were all good. This makes sense because the drive would fail with swapped read/write PCBs from working drives, so the flaw couldn't be in the board itself.

We swapped a third read/write board into the drive, one from our working Diablo drive in our Alto. It produced much much better results in the demon drive. We brought the entire demon drive along with our good read/write PCB over to hook to the Alto, where we found that it was almost good enough.

We found it worked adequately most times when writing on the first half of the cartridge, but at high cylinder numbers it became much more prone to read errors after writing. Because the bit density increases as the arm moves to concentric tracks nearer the hub, we found the drive had circuitry that boosts the write and erase current when tracks from 128 to 203 are being addressed.

Again, this drive is right on the margin of working properly. Swapping among three seemingly identical read/write PCBs, we find that one of them produces behavior a bit better than the other two. We see a deficit in current through the heads, although the static resistance of the head windings are the same on all drives. Further, both the top and bottom heads work the same way.

True to the demonic nature of this drive, when we reattached our working Diablo drive back into the Alto we found that the contact had once again spread badness to the innocent drive. Our arm motor was no longer seeking.

Of course, once we took the drive out and did some detailed investigation we found that it was working properly again. We know of no mechanism that would leap across an air gap to a powered down drive and damage the arm motor solely because a card was in the demon drive earlier or the cables had been attached earlier to the demon drive.

This is once again a very striking coincidence. We suspect we may have a slowly failing rotary arm motor or drive electronics, something we will have to watch and fix once it stays broken long enough to track down.

As for the demon drive, we will continue with additional tests next week until we figure out the real issues and appropriate ways to resolve them. 

ENHANCEMENTS TO IBM 1130 CONSOLE PRINTER (1053) EMULATOR

I received a number of good suggestions from readers of this blog, almost all of which I incorporated into a new version of the PC1053 emulator device. One I chose not to add since it would give different behavior than a real 1053 console printer and one I dropped after testing because the effect was not discernable.

The device will not simulate the actual time that a long operation (tabbing or carrier return) will take place, rather than a fixed representative time as originally designed. It is based on the high speed return feature built into the 1053 console printers used with the IBM 1130. These will take a bit over a second to return from the maximum distance of 120 columns. Tabbing occurs at a rate of 40 columns per second.

Tab stops can be set and cleared by the operator at the PC terminal emulator by issuing new commands TS xxx and TC xxx to set or clear tab stops at column xxx. This allows the user to programmatically set the tab stops from a PC file such that they are remembered across sessions.

One suggestion was to mimic the autorepeat key behaviors found on newer Selectrics and modern terminals, where a key such as space initially fires once, but with an elongated push, it will begin to produce multiple repeating spaces until it is released. Since the 1053 console printer does not behave this way, even though it would be handy, I am not going to build this into the emulator.

My first take at the design would have the column indicator, a three digit display, leap instantaneously from the current position to the next tab stop. There was a suggestion to have the digits change at the rate of movement of the carrier, providing a ripple effect on the display as it moves.

At first I was building that into the device so that it changed the numbers on the column display as it sat in the state machine for the tab or CR movement. However, I discovered that the numbers changed so rapidly that one could not see much other than a blur. A tab of 60 columns occurs in 1.5 seconds, thus the one's digit changes in 25 milliseconds and the tens digit changes each 250 ms.

I relaxed the realism a bit, doing a quick blur of the column display after the tab operation has completed. It still gives the impression of quickly tabbing across, a flickering rather than instant change, but doesn't attempt exact timing on the display; only the feedback signal to the 1130 has exact timing.

On a real 1053, if a CR is requested when the carrier is to the left of the left margin, it will return all the way to column 1. I handle the left margin by spacing over after each \r is sent to the terminal emulator, such that the text prints at the appropriate offset from the left edge.

I mimic this behavior, where CR from a column before the left margin will return to 1, but once the carrier has advanced past the left margin, a CR brings us back to the margin. It took a bit more code to make this happen, but it is a more realistic behavior.

My testing showed all actions I could test with buttons and commands were working properly. Tomorrow, I will have to dummy up a way to inject tilt/rotate and other commands the same way that the 1130 will, to verify the rest of the code.

Build of IBM 1130 console printer (1053) emulator along with testing

BUILDING IBM 1130 EMULATOR FOR 1053 CONSOLE PRINTER

My parts all arrived allowing me to begin wiring up the emulator for the console printer of the IBM 1130. This printer is a 1053, an I/O or computer drive Selectric typewriter sans keyboard. The 1053 printer attaches to the 1130 computer via three SMS paddle cards - two for signals and one for power.

My device is wired with two paddle cards to plug into the two signal card sockets in the 1130. The device is built into a box, with the cables out to the paddle cards coming from the rear and a USB cable on the side to attach to a PC.

The feedback signals that are sent back to the controller circuits, which are expecting 48V and 12V. While I could build in two power supplies just for this need, it is probably easier to grab power from the 1130 via the third SMS paddle card that supplies the 1053 with 48V, 12V and 220VAC. I only need the two DC voltages and ground.

I first wired together two small boards, one holding 3 side by side 7-segment displays that will show the current print column. On the real 1053, a horizontal plexiglas strip on the front face of the printer has numbering across it and a small blue indicator attached to the typewriter carrier moves to show where the typeball will strike next.

These displays will be fed by my code in an Arduino Mega 2560 mounted in the box, which tracks the location based on spacing, backspace, carrier return, typing and tab activities to reflect where the 1053 carrier would have been at any moment. I output three BCD characters to 74LS48 chips which drive the common cathode 7 segment displays.

A real 1053 has three blue buttons across the bottom of the front face, to allow the operator to space, tab or return the carrier to the left margin. My device will have three red rectangular pushbuttons for these functions, placed below the digital column display.

IBM 1053 console printer

In addition, a real 1053 has a blue toggle handle on the left side of the front face which is pushed upwards to set a tab stop at the current column or pushed down to clear a tab stop at this spot. I installed two more red pushbuttons, mounted in a column on the left side of my box, to provide the set and clear functions.

The circuits inside an 1130 that control the 1053 effectively open collector drivers, although they have a snubber diode to absorb the reverse EMF when the solenoid coils are switched off. The solenoids inside the 1053 are attached to +48V and the other ends run to the 1130 driver cards.

Since these are open collector cards, I will be switching 5V instead of 48V. Further, with no solenoid coil involved, there is no reverse EMF. I configured the Arduino inputs to pullup mode, meaning that a resistor inside the Arduino keeps the line at 5V unless the open collector driver circuit activates and pulls it to ground. This makes the inputs inverse logic - high means not active, grounding them is a logical 1.

A 1053 printer has a number of microswitches inside that collectively provide four feedback functions. In the 1053, they take 12V from the CPU and switch it back to the 1130 to indicate when the print cycle is active and when the machine is busy doing long actions such as tab or carrier return. The other two lines indicate when the carrier it at the right margin and when there is no more paper. The 1053 has a pin feed roller and takes continuous form paper with pinfeed strips on each side.

Due to the 12V requirement, I control relays from the Arduino at 5V and those relays switch the 12V to the feedback lines into the 1130. Some resistors round out the component list for this device. Inside the box I have an Arduino, digital display board, 74LS48 driver board and a resistor board mounted.

Column display active

I had to carefully mark and cut out the locations for the five pushbuttons and the three 7 segment displays to be mounted on the board. Additionally, I had to mark and drill holes for the mounting screws for the various boards inside the box. Finally, the holes on the back for the SMS paddle card cables and side for the USB cable were drilled. 

I updated by Arduino code to provide for logical commands from the user terminal to the device, to set the left and right margins. Eventually, I could add support for switching the typeballs since the 1053 could optionally make use of an APL character set ball when the machine was running APL. 

Testing began with the commands from the PC, then proceeded to test the five buttons that provide SPACE, TAB, CR, TabSET and TabCLR. I tested them in concert with the margin commands to ensure that a CR took us to the left margin, that space moved us forward and that tabs were appropriately set and advanced to the proper stop. 

I discovered a few problems and cleaned them up. By the end of the day, I could set and clear tabs stops. tab reliably to the location, do carrier returns back to the left margin and space ahead. The space button will fire space cycles as long as the button is depressed. Since the Selectric will cycle at 15.5 characters or spaces per second, it is quite hard to get just one space. 

The solution will be modifying behavior of the buttons, which I will achieve electrically rather than trying to handle this in the Arduino code. I want the behavior to be reasonable for an operator. Therefore I want a one-shot that sends one short pulse to the Arduino then stays off until the button is released by the operator. 

Time to build three one-shots on a small PCB - the tab set and tab clear buttons are pushed while the column is not changing, and are idempotent, so multiple actions while the button is pressed are not an issue. 

Thus the remaining tasks are:

• Build and test the three one-shots
• Rewire existing device to use with one-shots
• Simulate various signals from 1130 and observe results on scope
• Mark and cut openings on box for displays, pushbuttons and cable exits
• Install and wire two SMS paddle connector cables into the device
• Mount Ardinuo, displays, switches and related boards
• Install and wire third SMS paddle connector for 48 and 12V power
• Install and plug in long USB cable to Arduino
• Test on an IBM 1130 to verify correct operation

Pictures of the recent conversion of a 9 track tape drive to archive 7 track tapes

CONVERSION OF 9 TRACK QUALSTAR DRIVE TO 7 TRACK FOR DIGITIZING FLUX

I recently posted an account of the installation of a 7 track head to a 9 track tape drive, allowing the magnetic flux reversals to be recorded by a logic analyzer and converted to tape contents by software postprocessing. Because I took no pictures during the work, the prior entry was pure text. A reader has asked for pictures (for the work in question and also for future posts).

Dual 9 and 7 track head (7 tracks on left)

Rubber wrapped cables from new head, plus existing wires from drive to its old head connectors

Anchor board during wiring, to adapt existing head connector to the new head's cable

Read board in the Qualstar drive, with 9 identical columns of electronics

Qualstar drive moving tape across head while we examine the signal from the head

Example of our pairwise tests with paper shim between head and tape, top channel declined first in this test

Enhancements made to the 1053 Console Printer emulator for IBM 1130

IBM 1130 CONSOLE PRINTER EMULATOR (FOR 1053 PRINTER)

I decided to improve the project I roughed out and coded a few days ago, adding more complete emulation of the 1053 console printer atop the IBM 1130. The 1053 is based on the IBM selectric typewriter, an output only version of the 1052 which was the operator console on the IBM 360 mainframes.

The 1053 attaches to the 1130 system through two SMS paddle cards and a power connector. The paddle card is a short printed circuit board that mates with the 16 signal SMS socket - using technology developed for IBM's transistor generation of systems such as the 1401 and 7090.

Typing a character involves triggering one or more of the tilt and rotate signals, which starts a print cycle on the typewriter and causes the print ball to tilt and rotate to bring the intended character to face the paper as the ball strikes forward through the ribbon to the paper.

In addition to typing a single character, the mechanism can be asked to space, backspace, tab, return the carrier, drop to a new line, shift to 'upper' or 'lower' case mode, and shift between red and black ribbon colors.

The typewriter has a series of microswitches that provide feedback on the status of the mechanism. Selecting the new character to type has to wait until the print cycle is nearly complete from the last typed letter. Letters shouldn't be typed while the carrier is still moving towards the left or moving to a tab or the paper is moving down to the next line.

My emulator will capture the requested letter or action, but also provide the appropriate feedback at the same timing as a real 1053. On the front of a 1053 printer are three pushbuttons and an up-down toggle lever. The lever will set or clear a tab stop at the current column. The buttons cause a space, tab or return to be performed. An indicator shows through a horizontal plastic scale to mark which column the carrier has reached. 

My initial design did not display the current column. It had no means of requesting the space, return or tab operation that is provided by the three buttons. More seriously, it made a naive assumption of tab stops a fixed number of columns apart, rather than allowing the setting or clearing  of arbitrary stops. 

Many programs written to use the 1053 would expect the operator to set up tab stops at suitable positions - using a simplistic tab scheme would distort the output. I therefore decided to model the tab lever and three buttons. Three seven-segment LED displays will show the current column number digitally. 

The Arduino had 26 unassigned pins based on my initial design. 9 pins were sufficient to drive three BCD to 7-segment decoders (the high order display wired to only decode 0000 or 0001). Five more signals hooked to five pushbutton switches will provide for the faceplate functions of the 1053.

I have ordered all the parts, other than a larger and more suitable enclosure to hold the emulator, its display digits and pushbuttons. I have SMS paddle cards and sockets to wire up everything, once the remaining parts arrive.

There are a last two dimensions of the 1053 that I was not fully reflecting with the emulator. Two of the characters on the typeball of the 1053 are not in ASCII. The cent sign ¢ and the logical not ¬ are those missing characters. 

A solution is the UTF-8 encoding supported by many terminal emulators, which would let me represent the two characters properly. Too, using a terminal emulator program with mono color type would not display the effect of programs choosing red or black ribbon colors. Thus I would need to adopt some color selection mechanism that fit with common emulator programs. If the terminal program supports ANSI color selection, I can make use of that. 

I can switch to UTF-8 and capture the two missing characters from their Unicode values, rather than my initial decision to type some artificial string such as {cent sign} which will distort spacing of the remainder of the typed line. It does not fix the ribbon color issue but UTF-8 would at least cause each letter to take up one column on the screen. 

The ANSI colors are selected by sending a sequence esc[##m to the terminal, where esc is 0x1b, and the one or two digits of ## are:

• 1 sets on bold mode (higher intensity)
• 0 resets intensity and other color selections
• 47 sets the background to white
• 30 sets the foreground (text) color to black
• 31 sets the foreground color to red

I therefore set the terminal initially with esc[0m esc[47m and esc[30m then process a shift to red with the sequence esc[31m and esc[1m while a shift to black is the sequence esc[0m esc[47m esc[30m sent to the terminal. 

My final bit of code converted the integer column number to ones, tens and hundreds digits, then wrote each out in BCD to the hardware that will convert BCD to 7-segment LED display drive signals.