Learning experiences and new tools

This project is difficult and far-reaching precisely so it will drive me to learn a great deal about a wide range of subjects and skills. As such, it involves the need to confront some entirely new protocol, type of device, tool or aspect of design. Forward progress slows to a snails pace, frustration can surge, but eventually each area snaps into some mental focus, confidence grows and correctly operating mechanisms are the evidence of my success.

Linking the FPGA to other devices, both those built onto the Nexys2 board and the many external ones I am using, generally requires studying some protocol and set of electrical requirements, production of both soft hardware (VHDL) and physical boards, and extensive testing. There are many link protocols that can be used and I have deliberately spread my work across different ones to impel me to learn each. Serial communications, USB high speed stream mode, SPI, I2C and a 2 wire protocol proprietary to the MAX7219 chips. In addition, I had to learn how to access the DRAM chips on the Nexys2, the flash chips, and of course all the interfacing protocols for the Selectric based console and other peripherals.

In order to ensure I know how to access the various chips, I made use of a neat tool called the Bus Pirate which lets me drive and investigate the devices until I really understand the protocol. ref -  Bus Pirate site

Bus Pirate board

The logic analyzer also lets me snapshot the activity on the lines and see glitches, timing errors and other anomalies.

For the PC side, where I will emulate certain peripherals like card readers and pass the card images down to the machine, I decided to build this with a graphical interface, since I have no background in Windows GUI, and code it in Python, as I don't know that language but it appears to be worth learning.

Researching the Electronic 50 prior to adapting it

The IBM Electronic 50 is not the same mechanism as the IBM 1053 (or 2741 terminal) from the 360 era, although roughly speaking it attacks the problem the same way. It uses solenoids and microswitches for feedback, just as does the 1053, but it was redesigned more fundamentally for electronic printing.

The keyboard and the printing mechanism are separated in the E50, with the keyboard activating reed switches that are read by the logic board, not by pulling on links that select the typeball position and unclutch the print mechanism. The print mechanism is driven by the logic board, thus many actions like carriage return are done entirely differently. Shifting between upper case and lower case is done separately at the keyboard (to record in the memory whether the entered keystroke is upper case or not) and in the print mechanism (cause the typeball to rotate 180 degrees to the upper or lower case position, since printing is at a different time from entry of the text.

The most important difference for my implementation is that the position of the carriage across a line is tracked electronically, as are the tab settings. The carriage is moved right or left (called escapement) by a spiral grooved rotating rod and a photocell is used to count holes corresponding to 50ths of an inch of movement. Even when a single character is typed, the machine just rotates the escapement rod while counting holes until the carriage has moved 5 holes (for 10 character per inch pitch) or 6 holes (for 12 cpi).

Backspace is the same mechanism, but selecting 'reverse' gear and subtracting holes from the counter that tracks current carriage position. Tab is implemented by the escapement rod turning and holes being counted until the current position reaches the next 'tab' position in internal memory of the logic board. Carriage return is reverse gear, same escapement mechanism, subtracting holes until the left margin (effectively the zero position of the carriage) is reached.

The escapement rod runs at two speeds - low and high - both of which can be forward or reverse direction. Thus, carriage return or tab go into high speed mode as long as the carriage is more than 1.5" from its destination position, then drop to low speed for the final distance.

The E50 uses a 96 character ball, unlike the Selectric II type ball used in the 1130, thus is typeball incompatible. The codes for printed characters are different, necessarily, because you can't address 96 characters with the same number of tilt and rotate positions as the Selectric I and Selectric II. Thus, my adapter will have to translate from the 1130 tilt/rotate codes and commands into the appropriate codes for the E50 mechanism.

While the 1053 printer mechanism did not provide feedback to the 1130 adapter about whether it was in upper or lower case, the E50 provides such a signal using a reed switch. The 1130 adapter tracks the position it last set for case, ensuring that it does not do an upshift when the mechanism is already in upper case position, since that will jam the physical mechanism. On the E50, the solenoid for changing shift is a toggle, change to upper if in lower or change to lower if in upper, plus it reports the actual case of the mechanism via signal. Much safer design.

On the other hand, the 1053 has a microswitch to trigger the 'end of line' signal whereas the E50 depends on the logic board to track the carriage position compared to the right margin setting, not on detecting the actual carriage position. The E50 has failure modes where the logical position tracked in the counter does not match the real position of the physical carriage, and the E50 has no way of detecting that. It could type off the right end, attempt to backspace or CR past the left margin, tab to the wrong spot, mis-space, or other errant behavior.

The E50 uses two voltage levels - TTL compatible 5V for logic signals and 12V used for solenoids. Reed switches are used throughout, pulling down the signal to 0 when closing and letting pullup resistors yank it back to 1 when the switch opens. Little magnets are affixed to various mechanisms that will activate these reed switches as necessary.

The core switch in the E50 is the Print Feedback Switch. Printer actions are driven by activating the print clutch (PSCC) which rotates a rod 360 degrees, that rod powers all the tilting, hammering onto paper and other movements of the mechanism. At 85 degrees of rotation, it closes and it reopens at 300 degrees. It is used to block attempts to print another character or take an action like backspace while the mechanism is still in motion and could cause a jam. Various actions are performed at the 85 and 300 point, such as releasing the PSCC at 85 once movement has begun or turning on the escapement solenoids (plus low speed or hi speed) at 85.

The E50 supports variable velocity for the typeball striking the paper, producing more even levels of darkness by adjusting strike velocity to the character being typed. This is a fixed correspondence to the character code, which I will handle at the same time that I translate from Selectric II to E50 tilt/rotate codes.

The cables onto the logic board are well marked, thus I have already identified the wires to use to activate the PSCC (print mechanism), escapement low/high speeds, escapement reverse, index, toggle shift case, toggle ribbon color, escapement operation, photocell lamp turnon, and correction (erase character) solenoids.  I also know how to read the photocell output, shift state of the carriage, print feedback switch state, and even the switch (I won't use for the 1130) that changes between 10, 12 and proportional character per inch spacing. There is a solenoid to ring the bell which I will make use of, if there is a way for 1130 programs to activate this.

The 1053 printer has separate solenoids to upshift, downshift, go to red ribbon and go to black ribbon, while the E50 simply toggles shift and toggles ribbon color, so a bit of translation and state tracking will occur. The 1130 expects two signals, CB Response and Twr Interlock, generated to let the adapter know when it is safe to request the next character or operation. CB response will be generated by the print feedback switch, while Twr Interlock will be generated any time that Escapement is on (we are still moving toward some target carriage position).

I am building a driver board that will take 3.3V logic signals and emit the 12V to activate each solenoid, plus it will level shift the reed switch TTL values down to the 3.3V logic levels of the FPGA board. Once this is complete, I can begin debugging the FGPA code that connects the E50 mechanism to the 1130 adapter.

The keyboard mechanism looks like it is adaptable for use as the keyboard of the 1130! That is, it has interposers that lock it when one key is pressed so that a second key can't be simultaneously activated. A clutch causes a cam to rotate once when a key is pressed, the cam will reset the depressed key after its value is read. The key pressed activates various reed microswitches that yield a 7 bit keycode - the E50 tilt, rotate,   rack and shift bits - and these are read by the logic after it waits 5 ms from the first activation to ensure all of them have reached their stable final state. I need to look more closely at how the clutch mechanism works with the keyboard, as it may be possible to replace the clutch linkages with solenoids thus totally isolating the keyboard from the rotating motor driven parts. This would suit my needs perfectly.

Unfortunately, during my investigations, I created a tear on one side of a delicate ribbon cable that connects the logic board to the print carriage, bringing the tilt, rotate, shift, ribbon and velocity signals to that carriage. I will need to repair or replace that cable before I can proceed, but there are no spare parts or spare machines that I can locate, thus some form of repair or substitution will be necessary. This cable flexes every time the carriage moves across a line, thus the replacement or repair work needs to accommodate that hostile environment.

Designing the E50 interface to the 1130

First step was to work out how to use the power supply to drive the 12V for the solenoids, which was a question mark because the power supply board had an IBM MST logic module, multiple mysteriously marked regulators and other circuitry on it, which might have required a specific handshake before delivering full power. Fortunately, I discovered that a simple bridge across two wires was enough to convince the PS to deliver full 5V and 12V power. I intend to use the 5V for the LEDs and other circuit boards that run at TTL levels, as well as the reed switch, photocell and photocell lamp inside the E50.

Having measured the resistance of the solenoid coils, I know what currents and power levels they will require and based on that, designed the driver circuit. The input is 3.3V logic levels from the FPGA, which will drive the solenoids from the 12V supply. I will prototype one of the driver circuits, verify operation and then have a board built for surface mount transistors and resistors to fit compactly into the printer enclosure.

Meanwhile, I used a lab power supply to validate the operation of the solenoids for the basic motor circuit. It was erratic turning on when the power switch was activated, caused by lubricating oil that got into the motor switch and partially burned a contact due to arcing. It was unreliable even after cleaning so I replaced it with a switch from the Selectric II typewriter I originally bought.

At this moment, the carriage is jammed at the left margin and the escapement lead screw is not turning, manually or under motor power. This also needs some investigation but the basic mechanism is clearly suitable for use as the 1130's console printer.

It was my belief that the signal listed as PUC was a switch reporting the shift status, but it is all a bit confusing, since the connector to the carriage where that signal is included does not +5V, the voltage level used with reed switches. The cable only carries ground, +12V and some control lines. My working hypothesis is that the machine does not discrete upshift and downshift solenoids, but further investigation is necessary before moving ahead on the design. The extended theory of operation manual for the E50 explicitly mentions a shift mode switch used for reporting the position of the mechanism. The diagram shows it swinging between 0V and 5V, but indicates the status at the halfway point of the PSCC rotation. Not sure if the switch maintains its 'value' when the shift movement is complete. Commanding the carrier to shift appears to require only the R2 solenoid and PSCC activation. I need to see if downshift is the same code or a different one.

Further web research suggests that the ribbon cartridge on the later Selectrics (and the Electronic xx models) did not support multiple colors, so that the shift to red and shift to black cannot be implemented. I will have those commands seem to work correctly, signalling completion at an appropriate time, to preserve programming compatibility.

I am still unable to identify the purpose of the RSH solenoid in the carriage assembly. It appears I will need to fire the solenoids to see if I can identify what each does. The tear in the ribbon cable affects only the velocity and correction solenoids. This is underway now.

A bit more testing has to be done and I must repair the ribbon cable, then I can begin testing candidate logic for my interface module.

My module has to support the tab set, tab clr, space, return and tab buttons on the console printer, as well as offering a way to set left and right margins. I am also working on the assumption that the printer operates in 10 character per inch mode, thus the scale across the front suggests a 13" wide printable line with one division of the scale covering a single character on the paper at 10 CPI.

The Electronic Model 50 is a wide platen machine, 19", which will cause difficulties fitting it inside an 1130 sized printer cover. I am not sure what I will do to address this particular issue; might have to tolerate some distortion from scale.

Testing console printer interface

The testing plan for the console printer has three phases. First, I will use a test rig to validate the signals, timing and behavior I expect from the Electronic 50 Typewriter mechanism I leveraged, second will involve testing with the logic instantiated in the fpga 1130 but using a prototype driver board, then finally I will test the final production build of the board and connections.

Arduino based test rig to explore interface approach

Tuesday - My test rig was built with an Arduino microcontroller (Mega board) and the relay shield, giving me four relays to drive the 12V solenoid activations and a enough input pins to sense all the reed switch and photocell inputs from the E50. I put a pluggable breadboard between the Arduino rig and the E50, allowing me to change which tilt, rotate and other solenoids are selected by each relay, as well as changing other status signals from the typewriter mechanism.

Arduino microcontroller with relay shield to drive solenoids

The tilt and rotate solenoids seem stiff - dried grease from age affects many of these older machines. I will clean and lubed the entire mechanism to ensure more reliable operation. I have successfully shifted case and fired the typeball for simple characters, plus operated the mechanism that moves the carriage left and right at low and high speed. Everything is looking quite good.

Driving the mechanism with my test rig

Steve Cook, a typewriter enthusiast and former engineer repairing these machines for IBM, kindly provided me a few key pages from the service manual, which has resolved all the questions I had about the shift mechanism, the shift status switch (yes, it is a switch that reports whether the typeball is positioned with the upper case half or lower case half facing the platen), and the mysterious looking RSH solenoid. That is the rack transfer solenoid, which selects which side for rotation from the home position. I had correctly worked out all the other signals from the connections to the removed logic board.

Solenoids and grooved cam drum on underside of carriage

Logic board of E50 - not used in this project

I should receive the components for the driver board tomorrow, whence I can build a prototype single driver, verify the design and then fire off an order for a PCB to mount under the typewriter frame in place of the existing logic board. As an added bonus, the power supply from the E50 will give me all the clean 5V power I need to drive the LEDs in the console display panel and other places on the replica 1130.

E50 Power Supply - 12V for E50 and 5V for my other logic boards

The machine is quite messy, with excess oil in places it doesn't belong, sticky partially dried lubricant in places that should have fresh oil or grease, and the universal problem with the IBM typewriters of disintegrating foam inside. Soundproofing becomes a viscous tarry substance or shreds and floats into places it shouldn't be. I am going to clean it off with isopropyl alcohol then lubricate it properly - that should improve performance and reliability.

Wednesday - After about six hours of scraping off the soundproofing, then cleaning and relubricating the typewriter, I am ready to resume testing of my interface. I had to pick up the appropriate oil (Mobil 1 0W-20), grease (Mobile 1 synthetic) and cleaning supplies in order to finish the cleanup. I have my driver board parts, but they are very tiny surface mount parts (e.g. 0805 size resistors), which are harder to prototype without creating the board first. Will run tomorrow out to find some kind of prototyping board suitable for mounting the transistor, but use old school style full sized resistors for ease of construction. Should finish up the prototype and test Thursday, plus the design of the production board and send it off to be manufactured.

Circuit prototype for solenoid driver for E50

Friday - Prototype tested, works very well, thus on to PCB ordering. Having my set of challenges forcing the PCB design software to produce clean output - it keeps placing signal lines or vias (holes connecting signals on different layers of the board) on top of each other, touching components or overlapping the lettering/outlines of the silkscreen layer. Finally produced clean design files and shopping around for best combination of price and delivery time.

Sunday - finished and ordered the PCB boards to manage button and switch inputs and the LED outputs. It took lots of thought and hand routing to get the connections made among the fourteen chips and other parts. The automatic routing built into the PCB software was unable to converge on a solution, forcing me into manual mode. The other boards, for the LED panel and typewriter solenoid drivers, were easily handled by the automatic routing algorithm and needed just a few hours of tweaking to get into production ready state.

Bottom side of input control board PCB I designed

Top side of the input control PCB I submitted to the fab

   My boards are using surface mount components, which are difficult to solder by hand, so I have bought the parts to build my own solder reflow oven, where I can place all the parts into solder paste on the board at once, then heat it in the oven with the proper temperature ramp, causing the solder to melt, pull the parts into proper alignment and then cool to hardened high quality solder connections. I should have the oven completed by Tuesday evening. I am using a PID controller (proportional integral derivative) with a thermocouple, tied to a solid state relay to modulate the heat in an inexpensive toaster oven. It is essential to follow a specific heat profile, set by the maker of the solder paste being used, to produce good solder joints:

   - first, the board temperature is raised slowly to almost the melting point of solder, typical target rates are 1-2 degrees C per second.

   -  next it is raised a bit and held steady to boil off the flux and clean the surfaces that will be bonded, long enough to eliminate any voids that may form around air bubbles or liquid flux. A representative soak phase is about a minute.

  -  the oven should then move the temperature up quickly to a safe margin above the melting point of the solder paste being used, which then flows over the bonding surfaces. Surface tension of the liquified solder will pull the solder away from the gaps between pads and will drag components into alignment with the pad to which they are being attached. The time to complete this step may also be one minute long.

  - the board is then cooled at a moderate pace to minimize thermal shock, causing the solder to solidify. Once cool enough, it is removed and checked to ensure all joints are properly done, perhaps cooling at 2 C per second.

The solder is in a paste that is smeared on the pads, then each part is pushed into the paste where it sits waiting for the melting phase inside the oven. Because solder, flux and the components contain materials like lead that are unhealthy, the oven can never be used for food. I will mark it as contaminated by hazardous materials to avoid inadvertent misuse in the future.

After a bit of practice with the reflow oven, I will wait for my boards to come back from the manufacturers (Oshpark and Sunstone) then assemble them. All of the components to install on the boards are on their way from Digikey or already on hand. 

Great start on keyboard realism with ebay purchase

The keyboard used with the 1130 is the mechanical keyboard from the 029 keypunch, which has quite a different feel from the microswitch based keyboards of present day systems. The 1130 used the same shape and coloring as the 029 keys, with slightly differences in the number of keys and their assignment.

IBM 1130 keyboard

Keyboard from an IBM 029 Keypunch

I came across a keyboard on Ebay that was from a data entry system that competed with the IBM 029 and 129 products, thus it was modeled closely on the look and feel of the IBM version. This is an excellent basis upon which to build my 1130 replica keyboard.

Ebay keyboard I acquired for use with 1130 project

Another view of the keyboard from ebay

The keyboard does not use the mechanical bail switch decoding mechanism of the IBM versions, instead it uses photocells to detect keypresses. As you can see, the colors are slightly different, most obvious with the darker grey in my unit, but this is well within the bounds of human memory for absolute hues, meaning that it will be perceived to be the same as the 1130 version unless compared directly. This is especially true for most people who will have only a past memory of the actual keyboard.

I will need to do some investigation once it arrives to discover how to identify keypresses, then build my interface logic to translate this to 1130 keyboard behaviors. Fortunately, there is a patent for the mechanism that provides some insight into its construction and use. The interface looks super simple to create. Further, the mechanism seems to provide the latching, need to restore and other characteristics that I want my keyboard to exhibit, so as to be quite reminiscent of the IBM 1130 keyboard. I have included a diagram from the patent here to illustrate the suitability of this keyboard for my purpose.

Diagram from US patent 3,092,310 granted June 1963 

.

Creating reflow oven to build printed circuit boards

Printed circuit boards have evolved from using components whose pins or wire leads fit through a hole in the board, to use of surface mount devices that do not require any hole. These permit boards to be composed of many layers practically, because the pins/wires of the devices are not interfering with any of the layers other than the top one that contains the component. This has been accompanied by the continual shrinking of the size of these components, all of which makes hand-soldering more and more difficult. Since the mainstream uses these surface mount devices (SMD), manufacturers of chips and other parts have shifted to SMD. It is impossible to get certain chips in a traditional, non-SMD packaging. Such is the case for a few chips that were ideal for use in my project.

Factory production of PCBs make use of reflow, where all the components are soldered to the board in a single pass. In one method, the devices placed on their intended copper connection pads with a sticky solder paste, then heated in an oven with a careful ramp up and cooldown process that minimizes thermal shock to the parts while producing excellent connections. The boards are placed in a reflow oven to heat and cool them. Commercial ovens are many thousands of dollars, but hobbyists have found ways to produce workable ovens for under $100 - I took on such a project to deal with the boards I am creating for the 1130 project.

I leveraged an old case I had in my garage, placing the circuitry for my oven into it. I bought an inexpensive 1500W toaster oven to use - the boards and solders contain lead and other elements that are not good to ingest - even being absorbed from the fingers at low rates. This will never be used to prepare food, because it is now contaminated by lead, bismuth and other metals.

My reflow oven and controller

I inserted a temperature probe (thermocouple) into the oven and removed the power plug from the end of the cable. In the old case to the left, I inserted a PID controller, SSR and the power cable from the toaster oven. I wired them up and put on a power cable with plug. The PID controller is a unit that will get the oven to a selected temperature and hold it there very accurately.

The name PID stands for proportional integral derivative - but the essence is that this is a smart controller that looks at feedback from the probe and figures out how to provide power to the oven to reach and hold the temperature.

PID controller to hold the oven at a target temperature

The SSR is a solid state relay, a device that will switch the power to the toaster oven on and off as needed. In operation, the PID is usually pulsing or cycling the power to the oven, which you see by the light on the oven flashing on and off.

As the oven approaches the right temperature, the light flickers on for shorter and shorter periods. If it simply stayed on till hitting the temperature, the glowing heating elements in the over would keep adding heat as they cooled, pushing the temp inside the oven way over the target before the elements cooled all the way down. The controller autotunes itself, learning how to 'sneak up on' the right temp by lowering the heat of the elements at the right rate.

I put a thin layer of solder paste on the copper pads where devices should be soldered. The device plops into the paste and is held on the board by the stickiness of the gooey paste. The board goes in the oven and begins heating. When the paste gets hot enough, the goo part, which is called flux, melts and evaporates. This cleans off metal corrosion and dirt from the metal surfaces, ensuring that the solder can bond. The heat goes up gradually enough to make sure that the flux is fully evaporated before turning the metal part of the paste into flowing solder - otherwise air bubbles might cause poor solder joints.

The solder paste then reaches its liquification temperature and flows. Surface tension of the liquid solder causes it to form a bulging surface on the copper pads and device pins, while sucking away from the non metal part of the board. This puts the solder on each pin where it belongs and not bridging between the pins. As an added bonus, the power of the surface tension will pull the component into alignment, so that it does not need to be placed with extreme precision before soldering.

The designer of a PCB will usually have a 'stencil' made from the design of the top layer - generating a plastic sheet with openings where paste should be applied atop copper pads. This is placed atop the naked PCB, paste is then applied with a squeegee like tool (like a putty knife) to produce the right depth of paste on each pad. This adds $10 or more to each board designed, thus some will apply the paste without the guidance of a stencil.

I bought some junk circuit boards and surplus SMD chips at a local electronics shop to practice with, and have worked out the right amount of paste and timing for my oven. This was tricky to get right. Too much paste and a big ball of solder formed, which would bridge more than one pin if the SMD device had very small, closely packed pins. Too little and it didn't reliably form solder joints nor pull the device into alignment.  Fortunately, the minimum amount is not that sensitive, even pretty thin swipes yielded satisfactory joints as long as the device was fairly well aligned.

Not using a stencil produces some waste goo placed on undesired spots of the PCB, which yields teeny dots of solder to flake off after using the oven. Since a 5cc syringe of solder paste is about $15, waste costs money as well as inconvenience. If solder bridges do form because of too much paste, they can be fixed by a process called 'reword' where you place a copper braid onto the blog while heating it, the copper braid will suck off the excess solder (wicking it up the same way that the wick of a candle will draw molten wax up to the tip of the wick where it burns).  One tries to minimize the need for rework, as each application of heat shocks the parts and potentially could lead to some damage to teeny pins if I move them too much during fixes.

Another interesting problem concerns boards that are designed to mount parts on both the 'top' and 'bottom' faces of the PCB. If you solder one side, then flip the board over and solder the second face, the solder on the bottom is becoming molten again during the second pass in the oven. The parts might drop off or shift out of alignment. This is solved various ways in production, often by putting a tiny dot of epoxy glue under each component that will go on the 'bottom' face when the board is soldered a second time. The heat of the oven causes the epoxy to harden at the same time that the solder is molten, thus the part won't fall off even if the solder is melted the second time in the oven since the glue stays firm.

I have a different way to approach this, based on the availability of different solder pastes with different temperature profiles. My plan is to solder the 'bottom' face components using a paste with a higher melting point. When I flip the board to solder parts on the other side, I use a lower temperature paste. If the oven never gets hot enough to melt the solder on the bottom parts, then they will not fall off! Commonly available pastes have more than 200 degrees F difference in melting points, far more than the inaccuracies in my temperature control of the oven.

Now I am ready to solder the parts onto my 1130 printed circuit boards using the low temp paste, as soon as they arrive from the PCB manufacturer. With some practice learning how to use the normal (high) temperature paste, I can do the double sided component placement for my 'input controller' board since I put integrated circuits and other parts on both faces to simplify the wire routing.

My first PCB arrived today - it was a 2 day turnaround which skipped several steps that the others will include, such as the green colored 'solder mask' that insulates and protects all but the copper pads where parts are soldered, and it does not have the printed outlines and labels for parts (silkscreen layer). Functionally, it is fine for the purpose - it is a card that I will install inside the typewriter to interface it properly to my system. It has drivers that will activate the solenoids under control of the FPGA board.

My solenoid driver board as it came from the fab

I installed the parts (other than the connectors for the edge because they would make it hard for the PCB to sit evenly in the oven), using the solder paste, then put it into the reflow oven and presto - perfectly soldered board.

Parts pushed into solder paste and the board is being heated

Unfortunately I had miscounted my parts and was short two resistors, so when I pick some up tomorrow I will hand solder the remaining two onto the board. The resistors are about the size of a flea, very easy to lose and challenging to pick up with the tweezers and put into place - think about how hard it will be to solder it on.

Done with heating cycle, everything soldered down

The connectors were placed once the board cooled down, and soldered in, after which I did a full test of the connections. Everything looks great!

Board finished except for the missing two tiny resistors

After I bought some extra resistors, I hand soldered them and had a completed board. The resistors are the small rectangles you see to the side of the transistors which are the larger dark rectangles. They are normal size for surface mount resistors, a mere .08" long by .05" wide, but the parts can be as small as 1/100 of an inch long. Tweezers and a steady hand are necessary to work with them.

It was plugged into the typewriter and I am beginning to run some candidate logic sequences to verify that I am driving the operations correctly, such as carriage return, line feed, shift case, tab, and of course typing letters. So far, it is working exactly as I expected. Need to complete my fpga logic module then kick off detailed testing.

 Sometime this weekend I will spray the board with a protectant seal, using a silcone conformal spray, similar to the solder masks on modern boards but also protecting the components on the board. That will keep it in good order when mounted underneath the typewriter mechanism, subject to vibration, heat and grease/oil drippings.

Finished board with coating, ready for installation

The board is mounted on the underside below the space where the carriage travels, in the place that the IBM logic board was mounted before I began the conversion. Besides the cables connecting the board to the typewriter mechanism (most are connected in the picture below), there are several cables that will link this to the FPGA 1130 board and power feeds on the side delivering clean 5V and 12V power for use by other logic boards.

My board installed in place of IBM E50 logic board

Highlighting a similar project - 360/30 recreation

Recently, I received an email from Lawrence Wilkinson who discovered my blog. He has a similar project, building a replica 360/30 mainframe which is contemporaneous to the 1130 system and shares the technology and many design elements. View his project website for more on his effort.

We have made very parallel choices in design and approach for our two projects, almost eerie as I can easily imagine perfectly reasonable alternate selections that could have been made. He and I are currently wrestling with the console typewriters, a modified version of the Selectric typewriter, which is another unlikely coincidence.

His talk at the April OSHUG meeting ( Lawrence Wilkinson's talk ) shared the background and demonstrated the state of the machine. He is mainly working now on building out peripherals, such as the console typewriter and a disk drive emulation, with the aim of successfully IPLing (booting up) the DOS/360 operating system by April of 2014, although he is also slowly building a physical console to replace the VGA screen that serves the purpose today.

I expect we will be sharing ideas and designs on our respective projects and on related matters. With these older computing systems becoming historical artifacts, the real examples disappearing from the planet due to age, projects such as ours will be helpful both as examples of what the machines were like and as advisory resources to those restoring real machines in museums around the world.

Repairing a torn flat flexible cable on the typewriter

The Selectric typewriter and the computer attached versions (IBM 2741, IBM 1053, IBM 735 etc) attached solenoids to pull on the same mechanical linkages that activate various functions in the almost purely mechanical typewriters, as the only electrical items in a Selectric typewriter are the motor, power switch and power cord. A few microswitches provide feedback on what is occuring with the physical mechanism, necessary to ensure that simultaneous actions are not attempted that would jam the machinery - for instance if one were to attempt to print a character while the carriage was still moving as part of a carriage return operation, or even worse if one tried to shift the typeball to upper case when it was already in that condition.

The Electronic Model typewriters, although still based on the 'golfball' type element and basic Selectric approach, adopted some very different approaches within the machinery. The one example that is important in this project is how they accomplished the rotation and tilting and striking of the type element onto the paper. In the Selectric models, metal 'tapes' are routed around pulleys and connect the levers causing a tilt or rotate, situated on the stationary frame of the typewriter, to the carriage that moves left to right across the width of the paper. A lever will pull on a tape, that tape will move parts in the carriage, and the type element will be rotated or tilted. In the Electronic Models, miniature solenoids are mounted in the moving carriage itself, under the type element, and are connected by a flat flexible cable (sometimes called a ribbon cable). Electrical signals are sent over the cable to activate one or more of the solenoids in the carriage; those solenoids move levers that cause the element to rotate, tilt, and strike toward the paper.

Thus, there is a long brown cable, formed as a sandwich of two strips of polyester plastic with copper 'wiring' laid in between the layers. This flexible 'printed circuit' is roughly 1/2" wide and 19" long, allowing the carriage to move across the wide platen (I am using a 19" wide model of the typewriter) while remaining connected to a logic board in a fixed position underneath the machine. The end of the cable that connects to the logic board takes a 90 degree turn, with the plastic end curving just before the connector is attached.

Somehow, either due to repeated stress and age before I bought the machine on ebay, or while I was disassembling it, the cable was damaged.  At the inner part of the bend (small radius on the inside, opposite the large radius of the other edge), the cable suffered a tear, projecting about 3/16 of an inch from the bend inward and severing two of the copper conductors. These two conductors control two solenoids that determine the velocity with which the type element is hammered onto the paper (actually onto the ribbon which in turn strikes the paper). If the default velocity with both inactive were readable, this tear would not be a problem but sadly, that state of the solenoids corresponds to a space - the ball rotates and moves toward the ribbon but does not actually contact it so no image is typed on the paper.

Repairing these is tedious and challenging - the copper traces are buried inside the laminated pair of polyester strips, and the trace is just 1/50th of an inch wide. I made several attempts before I achieved a satisfactory repair, with the mandatory first step of exposing the copper traces in order to modify them. I had to sand off a layer of the plastic without sanding through the conductors in the middle -- and they are very shallow traces of copper printed on the face of one of the layers.  I bought some 800 grit sandpaper, extremely fine thus very minute amounts of material removed by each stroke. I carefully sanded to expose the area in which I had to make the repair, spanning the tear and enough of the conductors on each side to accomplish a successful bridging of the circuit.

Working on the torn cable end with magnifying lens

Any repair I make is going to be more fragile than the original cable, which has already suffered damage at this spot, so I chose to brace it first. I used epoxy and part of a cut up expired credit card, applied to the other side of cable from the face I had sanded open. I roughed up the surfaces but the epoxy bonded only to the polyester cable, failing to adhere at all to the credit card material. Many plastics, particularly polyethylenes like LPDE and HPDE or materials like teflon, are almost impossible to bond with glues; seems the credit card is not a polyester or acrylic that can be glued with epoxy.

I switched to a higher power glue, one based on methyl methylacrylate, and found another material for the stiffener to replace the credit card fragment. This time I got a high quality bond, with the critical section of the cable now well braced both for the repair work and for permanent operation afterwards.

Some have repaired these types of cables by using a pen containing a special silver ink - containing real silver to produce a good conductive path with low resistance. The pen tip is wider than the trace size, but I finally got the traces bridged with some silver ink yet not touching each other which could short the signals together. It was not, however, going to be mechanically reliable with all the vibrating, moving and flexing.

The most straightforward repair, I should mention, would be to have purchased a replacement cable from IBM, tossing the torn one in the trash, but they are no longer produced by Lexmark and none could be found. Repair was the only option to save this typewriter.

I would need to solder some wire or copper tape onto the copper traces to bridge the gap created by the tear. Polyester melts and twists if heated too much, thus this needs to be done very, very carefully to minimize heat. The trace width of 1/50 inch is also very tiny compared to most soldering iron tips and even to most wires or copper tapes.

Solder paste and wire to be applied to the connector

My strategy was to make use of a special low temperature solder paste, one that melts at a much lower temperature than ordinary solder, and set my soldering station to stay under 500 F. Coupling that with quick, careful application of heat and I would be able to make the soldered connections. For wire, I chose some thin wire used for wire wrap, a technique where wire is wrapped around pins on a backplace to make connections between pins - this was a common construction method in early computers.

Soldering station set at 500F to minimize heat damage

It took many tries to get the wire held in the right place and the proper amount of solder paste applied at the correct position. Too much and it would form a blob bridging multiple copper traces. The wrong place and it would put solder on unwanted traces. The wire had to align well and sit exactly on top of the trace, not touching the adjacent traces a less than 1/20 of an inch away. I had to apply the soldering iron quickly and accurately. Any time the wire, paste or iron was too far off, I had to abandon the try, remove everything and set it up anew. Ultimately, however, the two gaps were bridged by soldered wires with the ohmmeter proving I had good circuits with no shorts among the traces.

.01" soldering iron tip and the tinned wire

Wires soldered in place to restore the torn circuits

The cable will plug into the connector just visible on the board below

The final step was to cover the traces to protect them and I am now applying a stiffener on this face of the cable that will minimize flexing during subsequent operation of the typewriter. The completed cable will be attached to my circuit board,  in place under the typewriter mechanism.

Interfacing the keyboard mechanism

My keyboard arrived today! Excited because it is very close to the IBM keyboard in appearance and operation. I disassembled the unit, adjusted it slightly, and verified that it does what I want:

  - has mechanical interposer that forbids more than one key to be depressed at once

 - keys latch down and are released by a solenoid, thus the keyboard is 'unlocked' by XIO

 - all lamps work, so I should be able to interface the photocells that read the various key codes

Keyboard mechanism I will adapt as 1130 keyboard

I did some rough work to validate the voltage for the lamps and solenoid - lamps seem to work
well at 12V, distributed in series across the ten bulbs that illuminate the 10 photocells. The solenoid works cleanly at 24V, which is reasonable in concert with the 12V lighting circuit (which would be center tapped from a power supply producing +12V and -12V to yield 24 across the solenoid).

Lamps visible at bottom, interrupted by keys to encode character

I completed measurements of the resistance of the photocells when illuminated and when blocked by a tab on some key lever. The dark resistance is at least 3 Megohms and the resistance with light falling on the cell is about 10Kilohms, quite a swing and very easy to convert to a digital signal.  I will now design the detector circuit, and begin building a prototype for detectors, solenoid operation and microswitch debouncing, all multiplexed to the fpga, from which I can build a production interface board that will be used in the final machine.

Key levers that latch down and interrupt selected light beams

Still to do - validate each key cap legend against the 1130 keyboard, work out a plan for modifying those that are different, and adjust the keyboard to maximum fidelity. Certain 1130 keys activate microswitches rather than operate the mechanical levers, so I have to convert this by removing the latching bits and installing a microswitch. The two large end keys are not used on the 1130, for example, so that they will be removed and the key stem hidden under the metal plate into which the keyboard is installed.

Keyboard as it is now

Actual keyboard on an IBM 1130 for reference

This appears to be almost exactly the same size as a live 1130 keyboard. The key coloring is off a bit and the shapes of the keys is not identical to IBM, but evocative enough for my purposes.Once I remove the unneeded keys, adjust the legends on the keycaps and color one keycap blue for the upper left position, I will have my keyboard.

Planned changes to keyboard

The picture above shows the plan for converting the keyboard. The upper right blue keycap is removed and placed on the keystem to its left, with the legend altered to "int req". The upper left gray key has to be recolored to blue and have its legend changed to "rest KB". Several gray keycaps will have their legends removed to become plain. The large keys on the far left and far right are removed. The blue "alpha" shift key on the lower right will have its legend blanked. The blue keys on the right side will have their legend changed to "eof" and "erase field". The gray keycap to the left of the new "erase field" legend will have its legend changed to "<--". The blue key mechanisms will be altered so that they activate microswitches but are not part of the interlocking/locking/photocell mechanism. NOTE - after further research, only the Restore KB and Numeric keys are pure microswitch types, the rest participate in the interlock scheme. I will add microswitches to these two stems and try to disable their blocking of light beams, but will accept the potential error if Numeric or Rest KB is pushed while another key is already latched down. I could probably detect that situation and block it in my interface logic, which will eliminate the concern.

Since my typewriter is a wider platen than the real 1130's, I will have a scale problem with the console printer. By minimizing space from the sides of the cover to the mechanism, I can limit the total effect a bit, but likely I still have a wider printer cover than the actual 1130 features. My current estimate is that it will end up 24" wide whereas the 1130 cover is 20" wide, exactly the same width as the black portion of the display light pedestal and of the black metal which supports the keyboard, lights and buttons. Since the tabletop is about 26" wide in total, the effect will be noticeable. Below is a projection of what it might look like, with the actual 1130 console following it to allow a quick comparison. I will look into coloring the extended sides gray rather than black to minimize the effect of the change, allowing the extended width to blend into the gray flat areas to the sides of the printer cover. That design is illustrated as a third picture below.

How printer width might distort the replica

What a real 1130 looks like, for comparison

Concept of coloring to minimize distortion from larger printer cover

I will probably add an MCP23017 chip onto the I2C link that currently services the two providing my 32 button/switch inputs from the physical console, with the additional link offering me 16 lines to use with the keyboard. After reviewing the codes returned by the photocells, I will not need all ten photocell signals routed to the fpga. Nine are sufficient, as one is used for the Alpha key which is disabled in the 1130 model I am replicating and will have a blank keycap. The KB Rest key will directly drive the restore magnets in the keyboard as well as reporting as a signal to the fpga.

I have already removed the end keycaps that are superfluous and relocated one blue keycap over to its new position as the Int Req key.

Superfluous keys removed on keyboard mechanism

I discovered that a number of the keys were originally the blue color, but had been dyed or painted over partially to make them brown. If I can remove the dye I will have the blue key I need for Rest KB position and can potentially dye all the tan and brown keys to the IBM gray color.

'Aux Dup' key shows blue original color and recolored top

I brought a spare keycap to TAP Plastics for advice on the material type, dying, removing dye, and ways to fill in the etched legends on those keycaps that should now be blank. That also will permit me to etch replacement legends for the few that are changing or that are currently blank but should have text on them. They identified the material as injection molded ABS and suggested repainting with enamel paint rather than dying. ABS does not take dyes well. I bought an airbrush and good modeling enamel paints, will practice on the spare removed caps first to get the process and colors right, then fix the necessary keys.

If I had to change any key to stop it from participating in the mechanical locking (latching down until restored), I would only have to snip off the end of the keylever, as you can see in the closeup where the 'Alpha' key is so modified permitting it to be activated even when the remaining keys are latched.

Lever directly under centered blue key 'Alpha' has tab cut off so it wont latch

At this point, I don't expect to have to modify any keys to interface this to the 1130 system. After I have completed the key modifications and built the interface board, a modest bit of logic in the fpga will complete this. The fpga will need to start a timer when the first photocell signal is activated, waiting long enough for any other photocell channels to assume their final state before decoding them. It will have to translate from this keyboards encoding to the lines that would be produced by the IBM keyboard.

Certain of the keys are converted into separate signals for the 1130 adapter, among them are Erase Fld, EOF, Int Req, Space, Backspace, Numeric and KB Rest. Essentially, the blue colored keys get this special treatment, although backspace is an exception, colored grey but strobing its own signal rather than a data pattern.  The others will activate values on a set of data lines (12, 11, 0, 1 - 9) except for the numeric, which simply toggles a state to determine the mapping of key to the data line values. Since the IBM keyboard is a leveraged part from an 029 keypunch, it emits hollerith code (e.g. A is 12 + 1 signals, S is 0 + 2 signal, digit 4 is 4 signal). The keyboard I am converting produces a modified version of hollerith, but the translation is straightforward for most keys.

More typewriter work but progress is made

The typewriter mechanism I am adapting, an IBM Electronic Typewriter model 50, has one problem caused by solidification of the lubricants inside part of the mechanism. The oil and grease used on the Selectrics and on these models become a sludge after years of sitting still. If the machine is used regularly, this tends to re-liquify the lubricants and postpone problems, but it is extremely common for someone to haul a Selectric out of a closet, turn it on and find it jammed or malfunctioning. This is all caused by the lubricant issue. These machines were designed to be cleaned and relubricated yearly, something reasonable in an office environment when the typewriters were leased and under service contract, but not something most owners today get done. Dust and other contaminants add to the problem, of course.

I have relubricated and cleaned the machine, but problems remain in the interior of the "pin block", a mechanical binary to decimal decoder used to activate two plastic rotary cylindrical cams that tilt and rotate the typehead. To cut down on the need for expensive solenoids, and save space, the desired amount of tilt or rotate is commanded by two tilt and three rotate solenoids. The binary value determines the selected amount of tilt or rotate.

Pin block and rotary selection cams

For example, without a tilt solenoid firing the typehead is at tilt 0 position, with T1 fired it moves to tilt 1, T2 solenoid moves it to tilt 2, both T1 and T2 activated (a binary value of 11 - equal to decimal 3) choose the tilt 3 level. The pin block converts the two T values into three pins - decimal values 1, 2 and 3 - that will move the head from the default tilt 0 to tilt levels 1, 2 or 3.

Decoded request for a tilt pin to move to tilt 2 position

The rotate cam takes a binary value from the solenoids R1, R2 and R3 and from them selects one of six valid decimal values (out of 7 nonzero values that could have been decoded). This activates one of six pins, but the machine needed only three solenoids to select the rotate pin. The pin block is the mechanical logic that converts binary input (solenoid activations) into a single tilt pin (or none) and a single rotate pin (or none). The typewriter has a rotate 0 position when no pin is selected, as well as rotate 1, 2, 3, 4, and 5 levels. A separate solenoid (rack shift) sets the direction of rotation, as the rotate can be + or - those values, e.g -3 or +5. Five pins are needed for the five rotate steps, the sixth pin activates a case shift, flipping the ball 180 degrees to switch between upper case and lower case characters.

The pin block sludge means it does not reliably activate pins, particularly for rotation, and the solenoid does not snap back reliably when the activation signal is removed. I was unable to fix them by external oil application and hand movement, thus I had to remove the pin block from the carrier and clean it out by flushing and partial dis-assembly.

Half the problem was oil that had gotten into the barrel of the solenoids, the surface tension of the oil acted as a resistance on the slug sliding in and out. I removed them, wiped them down with alcohol, and repeated a few times until the motion was uninhibited. The pins themselves and levers are now clean, clear and well oiled. I reassembled and readjusted it on the carrier, before performing a few checks.

I seem to have a channel worn into the surface of the rotation cam for pins 4 and 5, from when the mechanism wasn't cleanly resetting the pins. The rotate 5 pin is jumping into that accidental groove, thus not moving the cam over, when it should follow the intended groove which would slide the cam over to cause rotation of the type head. Spare parts are almost impossible to locate, which means my options are limited. I have to either find a way of repairing the cam, find a way to convince the pin not to jump into the false groove, or find another electronic typewriter whose cam and pin block is in good working order; if not, it will be very difficult to make this work properly - certainly it will not be able to type any characters at the +5 rotate or -5 rotate portions of the type ball. Even if the remaining 80 characters are sufficient to fit the ones used by 1130, I would need to create a custom typeball to match the relocated positions.

Since the solenoids and pin block are still a bit fussy, I will make a more complete disassembly and clean it very thoroughly, then remove any burs or other impediments to smooth movement of every single part of the darned mechanism. Perhaps with these changes it will ignore the false groove and that issue will be moot.

Former IBM employees who repaired these models have provided plenty of help - in particular, they note that the cams are manufactured with those shallow false grooves, for some unknown reason. This does help swing the spotlight of suspicion more firmly on the pinblock, whose parts I will microscopically examine, clear up any anomalies, and then reassemble it. My intent is to get a very crisp, fast acting and smooth mechanism, which I can then test in the machine.

I used some waterstones (8000 grit equivalent) to dress the edge that slides along the 'bottom' of the pin block (the face opposite the open area where the solenoids are mounted), lightly oiled and reassembled. Action seems cleaner and crisper, will have to remount to verify.

I have found two sources with replacement cams, thus if the worn cam is any part of the problem I can switch out the bad part. I first need to complete my pinblock work, at least until the cause of the problem is definitively known. If all in the cams, a replacement is easy. If the pin block is bad, I need to investigate availability of replacement pinblocks. Other possibilities include misadjustment and defects in other parts of the carrier mechanism.

On another front, the driver logic for the 1130 display panel that has over 100 lights flashing the contents of registers and state of the machine is finally working perfectly. I had some strange issues including transmission line reflections, sagging power supply lines because my test bench connection to the board used thin wires (doh) whose resistance dropped the effective voltage whenever a bunch of LEDs drew current, and a default output signal voltage for the fpga of 2.5v even though it operates at 3.3, which was too low to be a valid 1 for many of my connected boards. I don't want to remember how many times I restructured my fpga driver logic or did research on the protocol with other devices, or made futile diagnostic changes, when the issues were the unsuspected analog electric effects.

Progress along a number of fronts - typewriter, LED panel, keyboard, PCBs

My LED panel driver prototype was not working well at all, one part of the machine that has given me far more trouble than its relative simplicity should warrant. This has been a long standing entry in my problems list, but the final breakthroughs came yesterday.

I have had times when the prototype seemed to be close to working, but it would all collapse as I tweaked elements. It was maddeningly illogical, on the surface that is, and led to considerable frustration. One minor cause was the default of the Xilinx toolset for the Spartan 3E, to use low voltage 2.5V CMOS logic levels when the Digilent board is running the fpga at 3.3V. That will work just fine for inputs, but the logic high voltages will be <= 2.5 volts, not the 3.3-ish level that I was designing for.

Interfacing different logic types and chips requires careful attention to the specifications for what constitutes the minimum voltage guaranteed to be treated as a 1 on input, the maximum voltage that will still be guaranteed to act as a 0 on input, and the corresponding guarantees for output of the minimum high voltage and maximum low voltage. Some combinations of chips may produce a 1 output that could be below the threshold for the input circuit of the next chip, which can lead to circuits that seem to work okay but sporadically misbehave, when small dips in the power level occur because of other gates conducting nearby.

The LED driver chip, a MAX7219, is a 5V powered chip whose input requirement is a minimum of 3.5V to guarantee detection as a 1. Many hobbyists report success driving this with 3.3V devices like the Digilent board, but they are in that twilight zone area where proper operation is a lucky gift, one that can be revoked by the whimsical gods of electricity at any instant. I designed the driver board with extra chips to shift the levels properly - the initial prototype used 74HCTxx chips, which have specifications that guarantee successful interpretation of the 0 and 1 voltages from 3.3V CMOS - my fpga - and produce output that is TTL compatible, meaning the 1 is high enough to be assuredly detected by the MAX7219 chip.

I built the first prototype on breadboard, soldering the components on but using discrete wire to connect them. I skimped a bit on filter capacitors, very important to shield the logic from noise produced elsewhere. In this particular case, the MAX chip itself produces a lot of noise and power fluctuation because it is firing between 0 and 64 LEDs at any instant. I added them in and put some hefty capacitors on the power lines to keep it steady in spite of the variable draw due to LED activity. Of course, I forgot that I was using thin wires snaking from my lab power supply to the board - the resistance in those wires would vary the voltage on the board in proportion to the power draw, swung by the LED activity. All that contributed to issues that I had to clean up with good practices. Those who have been hardware designers or proficient hackers for a long time will think of these things and do it right the first time; I, as a neophyte, had to be reminded the hard way.

Everything was cleaned up, my logic simulations kept showing me the protocols were done right with no signals having any close timing. I rewrote my code a few times. I finally built a second prototype board, using a better quality PCB and the components and remaining wiring done very carefully. Lots of attention to filtering, ground planes, and a completely different approach to level shifting. I wasn't sure if the 74HCT00 chip was muddling the signals somehow, so I went for a simpler method. I connected the inputs to the MAX chip through pull up resistors to 5V, and through a diode to to the FPGA output. That meant that the FPGA was not driving the high logic level - if it went to its 3.3V high level, the voltage drop (.6V) of the diode put the input at 3.9V, not 3.3V, pulled up by the resistor to my 5V supply. When the fpga went to logic 0 level, it conducted and pulled the MAX chip input down to less than 1V, but well above its threshold for logic 0. Seemed pretty straightforward, so I began debugging with this version but results weren't much better.

Yesterday when I clipped on my logic analyzer (another fpga board that records up to 32 lines and has a nice GUI on the PC to display it), and analog and scope gear as needed, I detected the problem with the 2.5V CMOS levels. A simple override in the constraints file converted this to the more appropriate 3.3V CMOS levels and I had adequate levels to work with the MAX. However, it was still flaky. One time I could bring it up and the display test function, a command sequence I would send, would light all LEDs and the reset sequence would turn them back off, but I had no data displaying. The next time, even with a very minor change, and I would have wild flickering or a completely dead panel staring back at me.

With the voltage at proper levels, I clipped on the logic analyzer problems to the connectors on my fpga, on top of the wiring heading out to the prototype board. Everything worked well! The display function was clean, the data was displayed, in fact I only had a few tweaks to make to what LEDs were assigned to 1130 functions. I was very pleased, shut it down, removed the logic analyzer and packed it away.

About an hour later I turned the panel on, no analyzer attached, and it was complete random behavior again! That was the clue - the logic analyzer probes were extending the wires between the prototype board and fpga, extending them in the opposite direction to the analyzer itself. Now, the fpga was in the middle of the line. It was reflections on the wires - transmission line effects - something I wasn't expecting for a few reasons.
   1 - I was operating that is 50Khz signaling rate, not very fast at all.
   2 - the fpga was set up to have slow slew of its outputs, meaning more gradual rise and fall of the logic levels. Fast switching, a very steep square wave appearance to the change, produces tons of high harmonics and these can ring like a struck bell and bounce back and forth on the wires if not absorbed.

However, that was exactly the problem. The fpga, itself clocked at 50Mhz, considered something to be a slow slew that was just too fast for the wire distance to the prototype. This was made worse by the design of the Digilent board I was using, whose "PMOD" connectors for I/O I was wired to include some protection by putting a 200 ohm resistor in series with the signals. I couldn't even attempt to terminate the transmission line with a 50 ohm resistor at the source, because the 200 ohm resistor was already there. My level shifter, a naked diode connection at the far end of the wire, didn't make things any better.

Fortunately, my 'production' PCB has higher quality printed circuit lines, ground planes and a different chip based level shifter, and I will make sure my cabling is handling the transmission line effects better. I also dropped the drive current on the fpga outputs, which should itself lessen the reflection problem.

On the typewriter front, I reassembled the fully cleaned and lubricated pin block onto the carrier and began hand cycling. It was obvious that when the R5 pin was fully released and sitting in the groove at the starting point of the print cycle, as the cam rotated it would very reliably hop into the worn 'false' groove and not do its rotation of the typeball. After lots of very close study, I decided to dig out the groove a bit to get the pin deeper before it hit the low spot in its sidewall (cut by the bad groove). I put in the time carefully reshaping the groove and moving the cam back and forth until I had it cut to reliably put the pin in deep before it hit the problem area  and to swing the pin along its intended groove.

I have put the solenoids back on, did some firing of them without the motor running so I could hand cycle the mechanism and check it out. It looked pretty good, but it appears to me that the rotate solenoids may need readjusting. They don't seem to pull in far enough to yank the selection vane over where it needs to be for a reliable selection. That is my task for tomorrow, then I can do some tests under power to see what I have achieved. I am guardedly optimistic, but my fallback is to buy a new rotate cam and replace it if the reshaped groove doesn't do the trick. First I have to ensure that everything else is working as well as possible, which means plenty of adjustments and checks.

I did the PCB design for my keyboard interface board, which will also hold the Hirose FX2 100 pin connector to the fpga that will give me the more reliable IO connections. I had connectors on the board to route the typewriter logic signals on and off the FX2, plus another MCP23017 concentrator that will multiplex the 9 photocell channel signals and the control signal to fire the keyboard release solenoid, all over one pair of wires using I2C protocol.

The photocells are several megohms when dark but drops to around 10K resistance when lit up. I am operating the MCP23017 at 3.3V to be logic compatible with the fpga, but the photocells are attached to the chip as part of a voltage divider network, +5V into the photocells, the output of the photocells dropped to ground through a 16.8K resistor and the junction between photocell and resistor will feed the MCP23017 input gate. That gives it logic 0 when dark and a 1 when lit up. When the photocell is at its normal 10K, the divider circuit provides 3.13V at the MCP23017 pin, whose minimum voltage for logic 1 recognition is 2.64V. Even if the light is a bit reduced and the photocell is at 15K, the gate will recognize the input value, and it won't rise over 3.5V until the photocell gets below 7.2K total resistance which it has never approached. The MCP chip has a safety margin above 3.3 supply voltage, abs max of .6 but my design keeps it well below the 3.9V drop dead level. Logic 0 level will be under .05V with this design.

Photocell channel 2 is activated only when the KB Restore key is pressed, so this is first connected to a 74HCT14D chip, a Schmitt Trigger inverter to give crisp swings but with slightly different required voltage levels to shift on or off - below .55V to shut off and above 2V to trigger. The same voltage divider works fine for this, although the minimum guaranteed resistance of the photocell for detection of 1 is an even more unlikely 6K.  The output of the inverter can be divided and delivered to the MCP23017 at its required levels by using a divider network with the output of the inverter going through a 4.2K and then a 10K resistor to ground. Providing the MCP23017 with a signal from the center connection of the two resistors will convert the 74HCT14 chip output, which is no less than 4.3V high but no more than 4.5V, to the target of 3.1 to 3.3V at the MCP input pin. Logic low output of the 74HCT14 is no higher than about .25V worst case, divided down the resistor network to .175V, while the MCP threshold for logic 0 switching is .66V; the network thus meets the requirements for both 1 and 0 detection at the schmitt trigger thresholds.

I found an old laptop power brick that produces 20V, perfect for firing the keyboard restore solenoids, and will use a fast relay on the board to switch the 6W used by those relays on and off. The 74HCT14 is feeding the voltage divider to the MCP23017 but also feeding the base of a driver transistor circuit, through a 2K resistor to produce about 2ma of current, which is amplified to drive the 33ma of a surface mount relay. The relay will switch the 20V line to fire the keyboard restore solenoids, which together will draw about 290ma (about 6W of power consumed when energized).

Thus, the KB Restore key acts locally through the board in addition to the photocell 2 channel signal that is sent to the fpga. The keyboard adapter logic of the 1130 expects to see the KB Restore key signal, which is why it is delivered there too. All other keys are decoded in the fpga from the results of the various photocell signals.

My LED driver board was flow soldered to put the surface mount components in place. The MAX7219 chips are through hole (DIP) devices, coming in the mail tomorrow, and I will hand solder them to finish this board. The input interface board has components mounted on both top and bottom faces, which adds some small complication for flow soldering in the toaster oven setup. I chose to use relatively high temperature lead free solder paste for the underside components, of course soldering them with that face physically upwards in the oven. Now that the 'bottom' parts are on with a solder that melts at a high temperature, I will place the top side components and use a low temperature solder paste for that side. By keeping the oven just hot enough to flow the low temp paste, those top side parts will be soldered while the components already in place on the underside stay firmly soldered. This board is all surface mount, 14 ICs, plenty of capacitors and quite a few connectors.

I hope to send the PCB design for the keyboard/typewriter interface board off to the fab tomorrow, once I prototype a few portions to validate the choice of parts values. Having to lay out the pads for a connector with 100 closely spaced pins in four staggered rows was pretty tedious, but it is now done. It is late now, time to walk away from the project for a while.

I have the new compressor for the airbrush and an adhesion promotion spray to improve the bonding of the paint to the keycaps, put on as a first layer once I rough the caps up slightly and clean off all dirt and greases.I will experiment with the airbrush and the spare keycaps until I am ready to recolor the selected keys. Part of the technique will be ways to fill in the shallow etched legends on caps that currently have wording but should be blank for the 1130 replica. I have not worked out how to form the new legends for keys whose wording has to change, for example Int Req, Rest KB, Erase Fld, EOF, and left arrow (backspace).

Friday - my components came and I worked on the LED driver board first. My first action is to carefully check all the connections, ensuring that the traces were produced correctly, the vias that link top and bottom layers are lined up and connected, and that any tight clearances avoided accidental corrections. While working through the board, I discovered that an assumption I made about the PCB design software has come to bite me, requiring a little wiring be added to fix the board. It is the only board where I let the software autoroute all the connections, otherwise I might have spotted this before manufacture.

It appears that C6, R1 and +5V are connected

Moved +V symbol, the gap is now visible

At the three major chips, resistors that control the max current into the LEDs are connected to +5V, as is a filter capacitor. I drew the connection but the PC design tool didn't actually connect the line to the +5V symbol for two of those chips. It appeared continuous, and each half of the partitioned net had enough parts and connections to escape any automated warning about unconnected links. Thus, I have to bridge that gap with wire hooked at some appropriate spot on the board.

 I completed that connection and soldered in the DIP package Max7219s (traditional IC packaging with a rectangle that has leads extending through holes, soldered on the opposite face of the PCB from where they are mounted) and the connectors for cabling to LEDs and the fpga. On Saturday I will finish testing it.

LED Driver board - LED connectors across top, white is signal/power

Adjusted the solenoids on the carrier of the typewriter, to give them max power and crispness doing selections. Finished adjusting the two tilt solenoids, very pleased with the results. However, in working on the rotate solenoids I find that R1 and R3 solenoids just don't snap over like the others. Something going on here that will need to be fixed. More study on Saturday.

Saturday - finished the adjustments and tweaking, the typewriter now reliably selects with all solenoids! Time to move on, finish the cabling to the fpga and my logic inside the fpga to do character translation and control signal timing. Very pleased.