TYPEWRITER
The typeball on the 1130 has its characters arranged around the typeball in the BCD arrangement, which is unlike the arrangement on typewriters which IBM terms the 'correspondence' arrangement. Most typeballs for selectric printers are the correspondence type, labeled with a font and size on the top. This matters
because the keys on the typewriter produce a tilt and rotate code that swings the ball to the position where correspondence balls have the character. If you put a BCD ball, then the character that prints won't match what keys are pressed.
Similarly, the codes used by an 1130 programmer are the tilt and rotate values that move the ball to where the desired character sits - in the BCD arrangement. Put a regular selectric ball on the typerwriter and the output won't match what the programmer intended. Thus the challenge I faced interfacing a typewriter
with its correspondence mode balls to the 1130 which believes it is driving a BCD typeball. The biggest problem is due to the fact that shifting between upper and lower case - one hemisphere of the ball with capital versions of the letters versus the other where regular case versions are placed - takes an extra
print cycle.
If the 1130 is printing three characters in a row that are all on one side of the typeball, but the correspondence typeball has the middle character assigned to the other side, then my typewriter would have to print one character, do a shift, print the next character, shift back, then print the final character - five cycles instead of three. Not only would it be slower, but the adapter logic doesn't know this is happening and is managing the timing on the assumption that the typeball is BCD type. I call this 'hidden shifts' and it is a complication that is challenging to address.
The ideal solution is to get a BCD typeball exactly like the 1130. No hidden shifts are needed and the tilt and rotate codes are passed unchanged to the typewriter mechanism. These are very very rare, thus I had been noodling around about ways to make my own typeballs. However, I got lucky.
I was looking at typeballs being auctioned on ebay when I noticed a type element (typeball) that didn't have a font name and number on the top. It was identified with a number - 952 - which is how many custom typeballs would appear. The custom typeball to support APL on an 1130 is type 988, for example, and
the typeball on one 1130 I examined closely used ball 805.
The picture of the typeball wasn't very clear and was only a single view showing part of one side, but it seemed that the character arrangements were not correspondence mode. They looked quite a bit like BCD mode. It had lower case letters visible, which means it is not the 1130 typeball.
IBM chose to equip the 1130 typeball with the capital version of the letters on both hemispheres - so that whether the typewriter were shifted to upper or lower case, what appeared on the paper is a capital letter. Lower case letters were not commonly used in that era, as the punched card codes were all upper case. Thus, the programmer could type alphabetic letters without regard to which way the type ball was sitting - saving the need to shift. It shaved some shift cycles off the time to print a string of characters.
My purchase arrived today, and I was overjoyed to find that it was an exact match to the 1130 BCD mode ball with the minor exception that it had lower case letters on one side, not capitals on both. Otherwise, it has all the special characters for the 1130 and their tilt/rotate assignments exactly match the codes
used on the 1130!
I can now pop that ball onto the Memory Typewriter mechanism and send it the tilt/rotate codes exactly as they are issued. No hidden shifts and no need to deal with missing characters.
The only irregularity will come if a programmer sends any lower case alphabetic characters, because they would be upper case on the real 1130 but will be distinctly lower case on my system. There may be output that is a strange mix of upper and lower case letters - each the proper alphabetic letter but with strange case shifts.
My shipment of parts from Digikey came in yesterday but one item, the transistors I use for driving signals into the typewriter, was a wrong part, apparently the shipping room picked from the wrong bin. Some two-terminal small component, not three terminal transistor in TO-252 case. The board is now complete except for that one transistor.
I have enough to put it into the typewriter and begin testing with the fpga adapter code. It required that I set up a number of quick disconnect wires to route from various signals inside the typewriter as well as ribbon cables to link the fpga to the various circuits on the card.
The first test was to hook up just the sensing lines and verify that the voltages produced for logic level 1, after shifting in the divider network on the card, did not exceed the 3.3V limit of the fpga input pins. They did not go too high, but the voltage out of the dividers for the 8.5V logic signals was too small - which was caused by choosing too small a value for the resistors. They were dividing some of the 8.5V supply across them, adding enough current that the node voltage was down to 6.7V with my card connected. The 24V signals were fine, giving me exactly the target voltage I wanted with minimum drag on the node voltage.
I worked out the values I needed, at least 168K total resistance across the divider and a ratio between the two resistors that would yield about 3.2 to 3.3V. I ended up choosing values based on my on-hand supply of resistors - 68K and 110K - forming the 110K with 100K and 10K resistors in series. After testing the result on the typewriter, I soldered the resistors on the board for all three of the 8.5V sensing circuits.
Having verified that the sensing levels were good, the next step was to hook the logic analyzer to the signals I am sensing, through my board, and record their behavior to validate the adapter logic that will generate the CB response and Twr Intlk signals read by the 1130 adapter logic.
Getting access to the various signals and solenoid voltages was a bit complicated - I found four holes in terminal blocks that I could insert the sensing wires for the four solenoids, although without some dis-assembly I had to make due with two alligator clips for the CR and Index lines. The three logic levels can be accessed at the switches generating the signal, with alligator clips used temporarily but a three way connector-extender essential to use in the final installation.
My logic analyzer showed all of the signals activating as expected, just based on the seven segment LCD indicators on the board that display the state of the inputs. I hauled out the RT Pro to connect to the analyzer and display the detailed traces. I found that I hadn't installed the tool on that machine and on my company issue laptop, recent changes had disabled the logic analyzer. After a bit of research to use this on Windows 8, I installed the software and began my testing.
The analyzer gave me the relative timing and occurences of key status information I needed during the operation of performing various functions on the typewriter. I watched feedback, overbank and shift mode signals plus the firing of solenoids for escapement, index, bell and carrier return. It appears I can use the feedback signal without change as the CB_response expected by the 1130 logic.
It appears I have sufficient information from signals I am able to sense to generate a reasonable interlock signal for the adapter and to drive the end of line status. End of line is detected by the activation of the bell magnet, which I verified during a long tab. I will latch the EOL signal when I detect the bell and unlatch it when the overbank switch is detected (from the carrier return that will be driven automatically by the 1130 adapter logic). While more generally, it could be turned off by backspacing, the automatic return of the 1130 renders that complication moot.
Tab works exactly as I had anticipated, but carrier return/line feed and index operations have some wrinkles I must work out before I decide exactly how to generate TWR Interlock. It is certain I have what I need to generate the signal, but not so obvious what it should look like or the relative timing.
I saw that the index magnet fires for 45 ms and the feedback signal doesn't begin until the end of the index magnet activation. That feedback signal lasted roughly 82 ms, suggesting that it is acting like the TWR Interlock on the IO Selectric, covering the time when mechanical movement is underway where typing a character should be suppressed.
The carrier return plus line feed operation was more complicated. The Feedback signal was activated for 27 ms at the start, then didn't fire off again until about half a minute later when it was active for about 160 ms. The escapement magnet fired for 50 ms just after the first feedback cycle ended and as it ended, both the carrier return and the index magnets activated. Index was only active for about 45-50 ms, the same as a pure index operation, while the carrier return magnet stayed active until the point where the second feedback cycle started at 495 ms. The overbank switch activated at 120 ms and was released at 200 ms, which indicates that the carrier had already reached the left hand side. It was nearly 300 ms after the overbank ended before the second feedback cycle took place - then that feedback took about 160 ms to finish.
I am not sure if a 'real' 1052 would present two different CB Response cycles, nor am I certain how long it might keep the interlock active. This may be the most difficult to work out, to keep the 1130 adapter 'happy' about the ongoing CR-LF so it stays busy until the right point and then signals operation completion. I will do some reading through my IO Selectric manuals, study the 1130 adapter logic and do some cogitating.
I then did a set of high speed snapshots to check for switch bounce. The Feedback signal didn't display more than 1 microsecond of bounce but most often had a clean single transition in both directions. The shift mode indicator which reflects which side of the typeball is facing the page bounced a bit, but had settled down in less than 11 microseconds for the worst case I observed. Overbank was similar but a bit longer, with an observed max of 15 microseconds. It won't take much of a cleanup to debounce these fully, perhaps 100 us to be very conservative. I can now finalize the adapter code for debouncing those signals.
I coded up a program for the Arduino Due that would exercise the typewriter mechanism, starting with the injection of various typing operations. It required me to solder the two ribbon cables from my interface board to headers that will fit into the Arduino, a slightly tedious but straightforward task.
As well, I am well along with the adapter VHDL logic and hope to test it out next week. I do have a trip out of town for most of the week as well as a charity event on Saturday that will limit my time on this project.
IBM 1054 AND 1055 PAPER TAPE READER/PUNCH INTERFACING FOR COMPUTER HISTORY MUSEUM
I am helping the 1401 restoration team at Computer History Museum to begin using a pair of peripherals they had sitting idle. This is a project for Doug Martin. I will build a suitable interface and then he can hook these units to various systems as he sees fit. The 1054 is a paper tape reader that operates at roughly 15 characters per second, the 1055 is a paper tape punch capable of the same speed. These were originally introduced as part of the 1050 Teleprocessing System which also introduced the Selectric typewriter mechanism as the 1052. Many are familar with the 1052 which saw broad use as the console printer on various S/360 mainframe systems as well as on the 1130.
I began with the 1054 reader, studied the mechanism and drew up schematics and wiring color codes for the box. I found many wires in the cabling went into the machine but were dead-ended and taped over. It appears that variants of this would support other capabilities and make use of those wires, but it would also require additional hardware (options I guess) that don't exist in this box, thus the unattached leads.
Some capabilities are not used with the 1130 but might be useful on other systems, particularly the 'reverse read' mode which has a clutch and solenoid already in place. My interface will expose all capabilities that exist in this hardware; some of them could be ignored by particular 'users' of the box but they remain available if others wish to take advantage of it. The 1054 was used with 14xx systems, not just the 1130 and 1050 that linked to 360s.
This unit has pins that make or break contact on a physical switch to signal whether a given channel on the tape has a hole or not. I found that none of the switch channels worked - it appears that the contacts have developed a heavy oxidation layer that turned a conductor into an insulator. I will need to remove the oxidation to restore operation. I began designing the interface logic with an eye to building it in the next week or two. Once the reader is working reliably I will move on to the punch (1055) unit.
After cleaning, I discovered that just about every mechanical adjustment on the machine is off, rendering it unable to read reliably. I had to partially disassemble the machine and even pull out and repair a few contacts in the main switch, but I now get the right signaling from the eight tape channels. The pins that detect the holes in the paper tape were sticking or hard to move on one side because of all the wrong adjustments, skewing the mechanism. It is a bit fiddly anyway, but I wrestled it into acceptable shape.
The reader includes a set of switches to detect when the paper tape has ended or is not present; this would form a 'reader ready' signal as they are serially wired and close when tape is under the reading plate and the plate is latched down. It has a set of contacts to identify when the mechanism is in 'reverse reading' mode, although that signal is only emitted during part of the rotation of the mechanism when reading.
I wired a permanent three pin power cord onto the unit and will begin hooking the signal wires to a suitable long cable and to my interface box. The main gears and clutch also need some grease. Now it is lubricated and all the mechanical adjustments are properly done. It runs tapes through and seems to be quite reliable. It will need a cover fabricated as a replica of the original cover, long since missing. I expect I will carefully measure this, build a 3D model and fabrication plans in Autodesk Inventor, in order to build it. The finish will be powder coating in an IBM like color and texture.
I am basing the interface/controller around an Arduino Mega 1280 plus a printed circuit board I am designing to handle voltage levels, power the solenoids, debounce the switches and possibly interface into the 1401 at the museum. My early version of the Arduino code is working well, but suffering from bounce since my PCB is not yet built.
The controller will offer RS232 links at both TTL and real RS232 voltages, plus a serial link over USB to PCs. I will build in various code conversion routines - such as PTTC/BCD to ASCII - and utility functions to read xx characters or read until some character pattern that is chosen as an end of file marker.
The wiring of the reader has the eighth channel emitting a 1 (hole present) continually when reading in the forward direction, it only delivering the actual state during reverse reading. I am closely examining the unit to see if this might be an error introduced by someone swapping wires, since I can't see the value of this as it sits, but will continue researching since there may be a subtle purpose I am missing so far.
In order to allow access to the eighth channel content when reading forward, I added an extra wire to bring that signal out to the Arduino. Now I can access both the reverse gated channel 8 and the direct channel 8, depending upon the needs of the user of the interface.
After some experimenting, I have the controller firing off read requests and reliably picking up the hole pattern (other than the channel 8 issue above). I found that the solenoid doesn't pick at all with a 5ms pulse and just chatters at 10 ms - all consistent with the machine specs of a maximum rate of 14.8 characters per second which must occur in less than 67 ms. My code leaves the solenoid selected for most of that interval.
I wait 30 ms from when the solenoid is first picked to allow the mechanism to get moving well, then start looking for the microswitch from the sprocket channel to tell me that the other channels are ready to be read. I wait another 5 ms to let the switches settle down in case they are bouncing slightly, then latch the value for delivery to the user. Finally, I wait until we have reached a minimum of 60 ms from when I initiated the read, before dropping the solenoid line.
The motor gets quite hot after running for a while, and there is no cooling fan inside the unit. This is probably due to lack of lubrication inside the motor or the bearings attached to the shaft. Someone speculated that the power might be switched on and off only when the reader was being accessed, but my research into the wiring of these on an 1130 system shows that the motor was always spinning when 1130 system power was on.
I have ordered a high power relay (contactor) to switch the motor on and off from the Arduino - it needs 12V for the relay which I will have to develop from my 48V supply and switch with a transistor on the PCB I am designing. This will allow me to bring the motor online only when doing reads - due to the latency and time to reach speed, I plan to have it continuing running for 2 minutes after the latest read request is completed, resetting the shutdown timer on each read. The expiration of the timer will cause the motor to shut down. Any command that arrives when the motor is not at full speed will cause the relay to be turned on, the unit will wait 5 seconds for spin up of the motor, then it will indicate full speed and set the shutdown timer to 2 minutes.
To get this ready for real use, I had to remove the alligator clips that temporarily connected it to the Arduino and install permanent cabling. It was a tedious task to solder all the connections on ribbon cables, set up quick disconnect terminals on the solenoid power lines, and dress the lines.
After fine tuning, it is reading long strips of tape perfectly - probably running a bit slower than its full rated speed of 14.8 cps, perhaps achieving 12 cps or a bit more, but given it is more than fifty years old, I would be satisfied with this performance.
With the core functionality for reading working solidly, it is time to build up the controller logic in the Arduino to define the overall flow, set up the protocols for communicating by serial and USB ports, and to establish some translation routines.
RECREATING SOUNDS OF AN OPERATING 1130
I received an unexpected surprise in my email inbox - a sound recording of the 1130 at The National Museum of Computing (TNMOC) in Milton Keynes, UK - sent to me by Peter Vaughn of the museum. He has been kind enough to allow me to record various sounds including power up and power down during my upcoming visit on November 23rd. He appears to be making steady progress on restoring every aspect of their 1130 system. I don't want to make any progress announcements about their machine that they have not made public yet, thus won't share the clip or describe it in detail.
I will place various sound files in MP3 format on a USB memory stick, which I will play at appropriate times from within the replica. I will use a VMusic3 device from FTDI to play these files on command sent over an SPI link from my fpga. At startup, it will emit the sounds of the power supplies and relays and fans energizing , the line signal routed through a power amplifier and internal speakers.
HUNTING FOR ROLLER WHEELS FOR DOCUMATION 600L ON BEHALF OF TNMOC
TNMOC have a card reader, an HP rebadged Documation 600L, whose rubber wheels are cracked. They have not been able to find replacements nor locate anyone who could manufacture a suitable replacement. I offered to help hunt for an alternative, and have begun leaving messages on various retro computing forums. Meanwhile, I will measure and examine the wheels on my Documation 600L in order to search for substitutes or parts that could be combined to make a replacement.
No comments:
Post a Comment