TYPEWRITER
I hooked the logic analyzer onto the typewriter to validate the codes and polarity of the signals from the keyboard card to the main logic board. These matched the correspondence tilt/rotate values exactly and were as I expected. I took the opportunity to figure out what keys would rotate my BCD typeball to the desired letters - then did a test, typing a message. I determined that the ball would type Carl 1130 if I keyed in Fgsv 113z, popped on the type ball and gave it a try. That was successful too.
As I was deep into the IO Selectric manuals, wiring diagrams from the 1130 print adapter and my logic analyzer charts, trying to figure out the most effective way to generate the TWR Interlock signal, I was struck with a thought. I believe that the Memory Typewriter buffers keystrokes, allowing the entry of text faster than the mechanism is printing it. That same capability would theoretically be buffering keystrokes while the machine is moving the carrier - for returns, line feeds and tabs in particular.
If true, then the machine already understands the interlock and the 1130 adapter logic doesn't have to hold off submitting the next character. I can set the TWR Interlock to be permanently off and everything will work out well. I plan to do a test, placing the carrier at the far right, hitting the return key and a character key immediately afterwards. If the typewriter holds the character until the return is complete, the hypothesis is confirmed and life got easier. The CB Response signal wont activate until the character is actually printed, which might cause some timing issues, but it also guarantees that I wouldn't see more than one character buffered ahead.
The buffering protects me from having to build a perfect TWR Interlock signal - the line that tells the 1130 to wait before submitting a command to the typewriter. I have worked out some conditions I can use to keep the interlock on for most of the time during a long carrier return or tab movement, or an index (line feed), even if it is not exactly the same as would be returned by a 1052.
When a carrier return command is detected, I wait until I see the CR magnet activate, then begin emitting the interlock signal. When the CR magnet is released, I drop the interlock. I was going to watch the overbank switch which reacts to the carrier reaching the left margin, but it appears the duration of the CR magnet activation is longer with overbank a subset of that time. When a tab command is detected, I wait until I see the escapement (movement) magnet activated, then emit the interlock until the escapement shuts off. For a line feed only operation, when I detect the command I wait for the Index magnet to activate, emit the interlock and drop the interlock as the index magnet shuts down.
On another front, I thought of a possible complication. The typewriter strikes the paper with two different velocities depending on the letter being typed - some would punch through the paper or appear darker if all were struck with the same force. My use of the BCD typeball means that the logic board of the typewriter thinks I am typing a different character than is actually striking the page - the character in the same position on a 'normal' (correspondence) selectric typeball.
It may activate low velocity on letters that should be normal, and vice versa. I need to determine which positions on the normal typeball get low velocity, then compare the two typeballs position by position. Right away, I found that the low velocity character '.' on a regular typeball is the place where my 1130 typeball has a 'k', which will make every 'k' fainter than other letters. I will either accept some print quality issues or I will need to override the velocity choice myself.
I believe the best solution is to unhook the low velocity magnet, forcing the machine to type every character at the same velocity, just as the original 1053 printer worked. This may be the most elegant way to handle the problem.
I have already addressed the complication that the 1130 can request a change of ribbon color - the older selectrics could use a fabric ribbon divided horizontally into a black and a red area. By moving the ribbon lift mechanism to one of two positions, the machine would place either the black or the red portion in front of the typeball. Commands to the typewriter caused it to move the ribbon mechanism to black or red as desired.
No such option exists with the Memory 50 typewriter; these requests must be ignored. However, the 1130 adapter logic expects to see the typewriter working when it commands the ribbon shift. I now fake the signals, to make the 1130 believe the typewriter is active, but I will not send any command to the M50 leaving it physically idle. That code is built into my interface logic.
Certain buttons on the Memory 50 are directly wired to the planar, not sent as keyboard codes. The ones relevant to me are the tab set, the tab clear, and the combination of buttons that sets the right margin. The tab set and the tab clear button are buttons built on my replica that are directly wired to the M50 in place of its switches. The right margin is accomplished by holding down the Code key and pushing the Par Adv button. Left margin is a purely mechanical setting, I believe and will verify when I get home.
To implement this, I need to activate three wires that are hooked to these switches on the M50. Once again, these don't involve the keyboard but they cause a dummy (no print) print cycle to be taken. For example, it may advance on space and then backspace to the original spot.
I need to monitor the machine to confirm the dummy cycle, also to monitor what feedback is presented back to me. I should also block these at certain times so they don't get presented while other keystrokes are being fed to the machine. The 1130 adapter won't know there is a tab set, tab clear or right margin operation, because these are purely mechanical with no print cycle on the 1052 printer. Since they are do involve a cycle on the M50, the 1130 adapter should not be presented anything that might confuse it since the designers knew nothing of dummy cycles for these operations.
The adapter will latch up any of six button signals from the console printer of my replica - Return, Space, and Tab are buttons on the face of the typewriter, Tab Set and Tab Clr are the two states of the toggle switch on the face of the typewriter, and a small microswitch inside the top of the enclosure labeled Set Right Margin causes that action to happen electronically. The left margin is controlled by a physical slider that is reached by opening the top of the printer enclosure. These latch until we are processing one of them, then they are reset. Specifically, when we are midway through a print cycle on behalf of a button (see paragraph below) we reset all button latches. Of course, if the button is still held down, it will latch again.
If any button on the typewriter has been pushed, as soon as the printer mechanism is idle, we turn on ButtonCommandActive. This causes the buttons which were latched on (see above paragraph) to drive commands to the main processing logic, otherwise the commands are driven by the 1130 adapter logic. The ButtonCommandActive state is turned off when we reach the final stage of a print cycle. Meanwhile the button requests were switched off earlier in this print cycle. If no new button is pressed, we look to the 1130 again for commands.
My adapter logic to set the right margin has to activate the Code line, then after it is recognized to be 'pushed' I have to activate the two wires whose status switches when Par Adv is pushed. I have added that logic into the adapter as well. My electrical interface board was designed to inject these three signals, in addition to the signals that normally would come from the keyboard PCB.
I updated the adapter logic based on the above reasoning and the documentation I had, prior to my return home from my business trip. Once home, I did some machine validation and experimentation in order to make adjustments to my adapter code. I discovered a few things.
No dummy print cycles occur for the tab set, tab clear and set right margin buttons, so that they can be passed through more directly to the typewriter. The machine will only handle one character of type-ahead, such as a printable character entered while the carrier is moving on a long operation, after which it ignores the keyboard, i.e. it is interlocked. Most interestingly, it will throw in hidden shift cycles if the character being requested is on the opposite side of the typeball from the side where the ball is currently positioned. These shouldn't happen with the BCD ball and my plan for how this adapter works, but the functionality is built into the typewriter and just won't be used.
I substituted my board for the keyboard PCB in the typewriter and injected some typed characters using the Arduino Due. I did this with the correspondence ball in place, to minimize variables in debugging. This involved a tedious effort to solder all the signal lines from the ribbon cables to pins and hooking them to the Arduino. I discovered a poor solder joint but once that was fixed, it commanded the machine just as I expect.
Somewhat more complex than simple letters was testing of tab, cr, index, space and bspace operations. I completed all but the backspace on Friday. I then padded the programming to do a more extensive test, as I had discovered an error in the encoding for tab operations which I corrected immediately. This will run on Saturday.
I have been fortunate to receive help, advice and spare parts from a typewriter enthusiast who operates a business in Switzerland selling and repairing typewriters and supplies. Lukas Tschudi has scanned and uploaded hundreds of pages of technical documents I needed for both the Memory Typewriter model 50 and earlier Electronic Typewriter model 50 I own. He had some key parts for the ET50 and now for my M50 and has offered great advice in diagnosing issues with the machines. I hope to help him by repairing two power supplies for similar typewriters that he has on hand.
Saturday I ran the expanded test code, working all the functions triggered by the keyboard to check for correct operation. So far so good - it worked with text, shifts, spaces, backspaces, line feeds, carrier returns and tabs. I began substituting my board for the physical code, tab set, tab clear, and paragraph advance buttons and updating the Arduino program. The goal was verifying I could set tabs, set the right margin, and emit code+key combinations properly according to my understanding and strategy.
It went very well for everything except setting the right margin. The bell didn't ring when I tabbed out past
the margin. Once I resolve this, I am sure I can successfully command the typewriter to do everything the 1130 processor can ask it for. I did some investigating to be sure I understood how the physical switch was wired and that the circuits on my PCB that handle the signals are working.
My suspicion is that the Arduino is too fast and confusing the planar (logic board) of the typewriter. The way the key works that activates right margin setting is that it removes ground from the 'line' signal and grounds the 'access mode' signal. As a physical switch, it would break the 'line' circuit instants before it made the 'access mode' circuit, but my test code did it in the opposite sequence and very fast.
I have changed the test code to break 'line', pause one millisecond, then make the 'access mode' circuit.
Sunday morning I began the round of testing to figure out the issue with set right margin commands. I did a quick check by connecting each signal line control to 3.3V on the Arduino, observing whether the actual line hooked to the typewriter dives down to 0V from its idle state of 8.5V.
I discovered a bad connection and now that it checks out okay, the new code was run to see if it fixed the issue. My retest proved out the set right margin function, the bell ringing as I tabbed past the margin, and the detector logic lighting the LED signalling we had an end of line. Even better, it reset as the carrier return finished, just as I plan for it to reset in my fpga adapter logic.
I did a final run trying the signals in the old sequence and found it worked right even in that case. This means my fgpa logic won't need to finely sequence the two signals switching state during the set right margin command. Time to move on to validating my status signal generation strategy, seeing what my adapter would produce for various commands to the typewriter. Once that is concluded successfully, I can wire up to the fpga board and debug my logic circuits in the adapter using programs running in the 1130 processor.
The final set of test programs on the Arduino walked through the sequence of steps that I had built into the fpga adapter logic, so I could watch what occurred on the typewriter and what CB Response and TWR Interlock signals I would have generated. I altered the test code for the Arduino to perform key actions that
would allow me to watch the status I return and its timing relative to the command and operations of the typewriter.
Using the one LED built into the Arduino to watch each of the three status lines - CB Response, TWR Interlock and End of Line - I verified that they blinked during the relevant commands and at a reasonable level. This was gross level timing, next I had to hook up the logic analyzer and watch the signals on a millisecond scale, or even shorter if there is any question about precedence of certain signal pairs.
Once I was comfortable with the reasonableness of the behavior as recorded by the logic analyzer, it was now time to move on to my adapter logic in the fpga, replacing the Arduino tester. The adapter logic (M50Adapter) coding was finished, desk checked and ready for testing. I have some rewiring to do in order to hook the cables from the typewriter into the fpga connections board.
As well, it is time to dress up the wires between my PCB and the typewriter circuits, with the board mounting below the keyboard PCB of the typewriter. I found some pins that fit the connector blocks used on the typewriter, so that the four wires that sense activation of the four magnets (escapement, carrier return, index and bell) are well secured. In a day I will wire up the T connectors that allow me to hook into the lines from three switches on the typewriter and the typewriter's circuit board (planar).
1054 PAPER TAPE READER CONTROLLER CODE
I wrote up the code translation routines for PTTC/BCD (also called PTTC/6) and PTTC/EBCD (also called PTTC/8) as well as ASCII. The machine emits 16 bit unicode characters in order to render most of the special characters that were assigned in other codes but not in straight ASCII. I had to decide how far to implement the intent of the control characters of the PTTC codes - what to do with a delete, backspace, and so forth. There is a code named Reader Stop that I did implement, although I suspect there is some kind of an 'escape sequence' that would pass along that bit pattern without it triggering a stop. More research is needed.
1055 PAPER TAPE PUNCH STUDY
I have the wiring diagram and adapter logic from the 1130, which helped me understand what I would find in the punch. It seems pretty straightforward, so the first step is to validate that the machine in front of me matches the diagrams. Then, check that everything appears to be working - nothing obviously missing or broken, nothing jammed or rusted, no bare wiring.
No comments:
Post a Comment