Seemingly possessed Diablo disk drive now working

DEMONS BEGONE! - DIABLO DRIVE FAULT FINALLY FOUND AND FIXED

As readers may remember, we have been battling this drive which reads just fine but has problems writing correctly. If we take a cartridge written on other drives, this one will read it perfectly. If this drive writes anything, it is very likely to have errors reading back on this or any other drive.

The problems occur with both top and bottom heads. The oscilloscope showed that the previous contents of the sector were not fully erased. We swapped PCBs with other drives but the problem remained.

Today we decided to swap out the heads on the drive with known good heads from another drive, just to eliminate the heads as a cause of these symptoms. Even with all PCBs and the heads from a good drive swapped into this unit, the problems continued. 

There was not much left that could be wrong - a cable from a PCB to the disk head connectors, the backplane carrying signals between PCBs, and the electromechanical drive and arm mechanisms. That is, if this is not a case of possession by malevolent spirits. 

We ruled out the backplane after checking that all the signals required for writing were reaching the PCB that connects to the heads. We ruled out the cable and connectors to the heads by using a Time Domain Reflectometer and also measuring the resistance of each line. The TDR would show us shorts, open wires or other anomalies that cause reflected signals which may impact the quality of recording. 

At this point, Marc began to closely examine the mechanism that loads the heads down onto the rotating disk surface. This is a pair of brass prongs that pivot to force the two heads together, pinching them against the disk surface as it rotates. The back of the disk head has a raised metal ball that sits under the end of the brass prong, through which the prong exerts the diskward pressure. 

Marc could see the ball because the prong did not extend over the ball. The prong was about 3/32" shy of the ball. Looking at our other drives, we saw that the prong sits right over the ball on correctly operating drives.

Prong does not cover small metal ball on disk head

We looked at the bracket holding the prongs and saw they were bent out a bit from the machined metal structure that holds the heads. Using pliers, Marc bent the bracket to compensate, putting the prongs back over the metal balls on the disk heads. 

Adjusting bracket holding prongs

The failure mode was failure of the prongs to press the heads down against the disk surface as fully as on a correctly working drive. Just as seriously, the point where pressure was applied is now offset compared to the aerodynamic center of the head. 

This would cause the head to fly at an angle, not parallel to the disk surface, and have reduced pressure to force them down. The spacing from head magnetic poles to the disk surface was larger and uneven.

Prong properly positioned over metal ball

With the prongs adjusted, we fired up the drive and tested again. First I wrote a known image on the cartridge using my FPGA based disk tool, then did a read of the cartridge contents back to the tool. Zero checksum errors and a perfect match to the image being written!

We swapped back all the PCBs to the ones from this drive, moved the drive to the Alto and booted up to ensure it was working well. Problem solved! All that remains is to swap the heads back between our drive and this one, run an alignment, and do a final set of tests. 

We believe this problem is related to the bad disk crash we experienced early on in the repair of this drive. It was shipped to us by the owner, who followed our recommendation to secure the disk arm from movement by using a cable tie. It is likely that the cable tie was tightened much too much, bending the bracket outward and shifting the prongs out of position.

Very slight gap of bracket against metal of disk head holder

Our early crash, after swapping out the original bad heads for a replacement set, was associated with bent prongs after the loud noise and scraping sound. We have to assume that the bending during shipping caused both the early bad crash and the continuing write errors. 

The misalignment was very small and subtle. Worse, it is not a position measurement that is called out for checking in the maintenance manual, so we didn't spot it in all these months. At least it is corrected now and the drive can go home to support its Alto system. 

Finished assembly of the IBM 1130 Console Printer (1053) emulator box

COMPLETION OF BUILD OF IBM 1130 CONSOLE PRINTER (1053) EMULATOR

I soldered the signal wires between the second SMS Paddle Card junction PCB and the Arduino. Four output wires run to the relay module,  which switches power from a third SMS Paddle card delivering 48V and 12V power from the 1130.

My initial connections to the Arduino used wires soldered onto header strips but it was too hard to control shorting side to side since the arduino has a double row of sockets. I then picked up a shield that plugs onto the Arduino and provides screw terminals for all the connectors. This gave me a more secure and reliable interconnect.

Given the tight quarters inside the box, I had to do a trial fit of the six PCBs (relay module, two junction boards, display board, BCD/LED converter and Arduino) to select the locations to mount everything. The display board and its converter mount on the inside of the top (face) plate, of course, stacked on standoffs.

Board stack for 7 segment displays and BCD decoders

The other four had to be arranged around the bottom in convenient locations and installed on standoffs from the bottom of the box. I needed a trip to Anchor Electronics to pick up the mounting hardware before I could wrap things up. I probed each SMS paddle connector and verified its destination inside the box. 

Boards installed and wired up inside the box

Before the final close of the box I plugged it into a PC and fired up PuTTY to check out some functions. The five pushbuttons on the faceplate and the digital display were easy to check. I also did some tests using jumpers on the paddle cards to trigger various 1130 signal inputs - actually using spare sockets I own into which I plugged the paddle cards.

Box closed up but not yet labeled

I was able to fire print cycles (printing .), line feeds, plus exercise the front panel buttons. I will need to wire this up to sockets to be able to present valid combinations of inputs for the other characters - only certain combinations of T1, T2, R1, R2, R2A and R5 are valid and my logic tosses away invalid codes. Perhaps I will do this on the weekend.

I will do some cosmetic improvement of the placement of the buttons on the faceplate - widening the hole and gluing them down to make them align better. Labeling of the button functions using my label transfer technology will complete the cosmetics of the unit. This work will occur at a future date.

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