Hunting for documentation and moving forward

The Documation reader (model M600) is going to be easy to interface, the only unknowns are whether there are any physical problems with the unit due to age or disuse. I have all the information I need to proceed, however, and have ordered the special connectors already.

The Tally paper tape punch has some documentation available for similar models, but I still need a bit of research before I can design and build prototypes for an interface. I don't even know the electrical levels it needs, for example, but will start with 48V then fall back to 24V as the two most common from the other models. My unit has ten large power resistors, which the documented models do not, suggesting something is odd about the levels here. Also, this punch has nine pins across (plus the sprocket hole), more than the eight pins across of the 1130. First I will verify physical compatibility with media that will be read by my reader unit and with media for an 1130.

Finally, the most work will be needed for the Strobe model 100 drum plotter, as there is no documentation available for this anywhere that I can find. I have posted requests for documentation or insight to the Classic Computers mailing list and to the MidAtlantic Retro Computing Hobbyists forum on Yahoo Groups. I have already received some advice from one member of CCtech, although it was through the same sparse mentions on the web that I had already tracked down. What did seem overwhelming from those citations is that the plotter uses RS232 to communicate, with the communications settings clearly described in those few posts.

Nothing tells me what the commands are to request any action from the plotter, but I should be able to send strings of bits back and forth to it. Initially I thought it was more unique because it came with a 20 wire ribbon cable and a card for a S-100 bus computer (a standard for the pre-PC era machines in the time of Altairs and Apple Is), labeled Strobe 100 Parallel Interface. This made me think that RS232 was one option for connection but this one used a different parallel mode.

20 pin connector that 'could' be an RS232 link (but isn't)

The 20 pin connector could be an RS 232 interface, although connecting with a 10x2 header not a DB25 connector, running between the plotter unit and the S-100 card. However, the S-100 bus card does not have a serial chip onboard it is an 8255 (parallel IO interface to 8080), a few glue logic chips and a switch block which I assume is for addressing. Even more suspicious is the assignment of pins on the 10x2 header that the cable will plug into. Pin 3 is clearly hooked to ground on this card, but that would be 'receive data' if an RS232 link.

S-100 bus interface card and cable - a parallel IO board as it says

This continues the mystery, unless for some reason the Strobe S-100 Parallel IO card is unrelated to their model 100 plotter, and was put together with the plotter based on supposition not need. I will open the plotter and look to see if does have a UART (serial IO chip) and a compatible signal assignment on the pins. If RS232 then I at least can talk to it and see what it might do.

I found some web references to a product called Plastaid that seemed to be flexible enough to use as a filler to level out a keycap, hiding the slightly relief of the lettering for its previous role. I wanted something that would adhere to ABS, would be easy to work with, would create a reasonably smooth top, and would be just as easy to prime and paint as the keycaps themselves. This would allow me to erase old titles, producing blank keys to color. I will add titles for those that have a new role for the 1130.

My first attempt at filling in a spare cap wasn't that good, the surface is a bit rough and it certainly didn't set up and apply as I expected. I will attribute this to my unfamiliarity with Plastaid and a need to practice with it. Hopefully I can do a second, more successful test.

I received my MCP23017 chips this morning and have soldered one onto the Input Interface board to complete that PCB. Later tonight I will do a test to verify that this works correctly.

The perforated phenolic boards that will hold the LEDs had been built with a spacing interpolated from some photographs I have of 1130 light panels. After doing detailed measurements of a real 1130 this weekend, I found that my layout was so close to exact that it will work just fine inside the light panel. I am going to resolder and rewire the lights for two reasons - to increase reliability and to swap the 'digit' and 'segment' wiring to the MAX7219 chips. The current wiring requires awkward aggregation of signals in the VHDL, whereas the alternative will allow cleaner assignments.

For example, I want to be able to assign digit 0 of the first chip to IAR(0 to 7), creating a single string that will be sent to the chips to illuminate eight lights across on the upper left part of the panel; This means that those eight bits of the register become eight separate 'segments' of one 'digit' as the protocol transmits all the bits of a digit at a time.

My first wiring does not put the segments for a digit in a horizontal row; the digits run vertically not horizontally. One string sent as a digit will contain bits of multiple registers or output states. The VHDL now has to assign digit 0 of chip 1 as IAR(0) & SAR(0) & SBR(0) & AFR(0) & ACC(0) & EXT(0) & . . . with the next bit of those registers aggregated as digit 2. It is less elegant than digit 0 = IAR(0 to 7), digit 1 = SAR(0 to 7), etc. More error prone and harder to change, as well.

My keyboard had a malfunctioning photocell 10, which I planned to swap out for the photocell removed from channel 4 which is not needed for my implementation. I removed the cell in channel 10, which was physically broken, with cracked glass and loose insides, clear explanation for its malfunction. However, when desoldering photocell 4 for removal from its channel four home, I snapped off one of the leads, rendering the photocell useless.

I researched, selected and ordered a few photocells that provide illuminated resistance in the range of 10K to 20K ohms and dark resistance of at least 1M, compatible with the circuits I built and the behavior of the other photocells. They are smaller, but shouldn't be too hard to install in place of the two missing cells. This will give me a channel 4 and a channel 10. Should I ever wish to make use of channel four in the future (to implement the "Alpha" key that certain 1130s implemented to lock the shift status of the keyboard into LC), I can do that by adding this as a signal brought into the fpga.

Finally, I did the final tweaking of the pin block, reassembly, and tried it out on the typewriter. Results were definitely better than before but still not perfect. Still see R1 hanging partway in and out at some times. I see that it will cleanly shift to upper case, but after the last uc character is typed, it fails to shift down reliably.

Another test was to use timestamps to shadow the status reported by the print feedback switch, based on a cycle time of about 67 milliseconds, just to see whether results seem reasonable. No issues reported so not a case that the PFB is wrongly stopping the solenoids too early by a premature signal.

I investigated the erratic shifting between upper and lower case and realized it only occured when the rack shift of the prior character was selected (a negative rotation), since a shift is done with the rack shift off as it always moves 180 clockwise (positive direction).  I added a dummy print cycle selecting rack shift off in front of every shift that follows a negative rotation character and my problem went away. I don't know if the logic board of the ET 50 always does a dummy to turn off rack shift, selecting positive rotation, before doing the actual print cycle for a shift, or if this is a problem with the mechanism of my particular typewriter.

The other failures are much more consistent now that I have the machine so well cleaned. I see that I have failures to do any rotation in some cases, others are failures to select any tilt, thus it is not just one side of the pin block malfunctioning. Interestingly, the solenoid that doesn't select in all those cases is the one closest to the cams (the T1 or R1 solenoid). This is probably the spot that has bent in a way I can't detect or is rough or galled microscopically so that it hangs up. Since it is across the line at the bottom, it confirms to me that the root issue is a bad pin block.

I have ordered the replacement pin block and cam today, for international priority shipment, at which point I can continue putting this typewriter into service. In the interim, I will see if there are ameliorative steps I can take, such as programming a dummy cycle to move the rack in between every pair of letters that have different rotation directions. If that makes it behave better,although slower and with strange extra cycles, that will be fine while I wait for parts.

My last action of the night was to open up the plotter. The wiring of the connector in here is also inconsistent with any RS232 protocol. Further, there is no controller chip or UART or intelligence of any type here - it is a set of transistor drivers for the two stepper motors and the pen up/down solenoid, plus a few indicator lights, and of course the power supply. No possibility it speaks anything except direct signal lines driving the mechanism, which do go over the 20 lead ribbon cable to the parallel card into an S-100 based computer, where programming would handle all the details. Perhaps the other models, such as the model 200 plotter, have a processor and UART inside. I will trace the lines, verify they work and the appropriate levels (appears 5V TTL), then write the interface logic. Should be easy assuming it works on powerup - couple of electrolytic caps to check first and of course the possibility a motor or transformer is bad.

Plotter mechanism - two stepper motors and pen solenoid

Plotter power supply - producing clean 5V for active components

Active circuits - really just transistor power drivers for steppers, etc

Plotter cover