The adaption of the Electronic Typewriter Model 50 as the console printer requires me to implement some hidden shift cycles. These cycles handle the situations where an ET50 typeball has a character placed on the opposite side of where it is installed on the 1130 typeball. The 1130 adapter logic positions the ball in a discrete shift cycle it commands before printing a character, if the character is on the other side of the 1130 typeball (frequently these are called golf balls) from its current position.
When I receive the character to be printed and translate it to the location on the ET50 ball, I may need to shift the typeball to the opposite side from its current position. This has to be done as a hidden cycle since the adapter knows nothing of these details and believes it is doing a simple one character print.
The complication comes from the timing assumptions built into the 1130 adapter, which sets timers based on the known print cycle time of the selectric mechanism. Those timers won't account for the extra cycle I have to take for the hidden shifts. I believe I can handle this by manipulating the two status signals that are used by the 1130 adapter - CB Response and Interlock.
CB Response will flip to 0 and then back to 1 during the course of a print cycle, but those changes must be blocked during the hidden shift cycle. Interlock is turned on during long movement operations, such as carriage return or tab. I may need to use this signal to keep the adapter waiting and the typewriter appearing 'busy' to programs until the elongated character printing has finished, turning it on when I determine I have a hidden shift cycle and switching it off at the completion of the character print cycle that follows the shift cycle.
However, I have to be very careful here because some states may be changed solely by the expiration of timers, such that it could change program behavior. My debugging of the typewriter interface logic is centered on this topic.
Physically, I removed the front (keyboard) section of the typewriter in preparation for mounting it in an 1130-look-alike enclosure. I am designing the mount and enclosure for the mechanism, likely to fabricate it soon.
After the behavior of the FPGA seemed reasonable using the Arduino to emulate the feedback signals from the typewriter and the logic analyzer to watch the outcome, I gave it a brief live trial, with results that indicate the emitter output is not being received properly in the fpga - the unit typed the first character of my program and then began moving continuously to the right side of the paper. I am doing some experiments to validate the proper wiring and condition of the emitter output from the machine, then will make any necessary adjustments for the next run of the test.
I discovered and cleaned up some ground issues in the testbench, because I often use patch cables which have narrow pins that don't seat firmly in the headers and other sockets on the fpga and my circuit boards. once that was fixed, the emitter is working extremely well. I have also determined the PFB debounce requirements, about 150 microseconds would work based on what I observed, so out of caution I will bump this up to half a millisecond. The photocell emitter does not suffer from bounce, so I put in only a 2 microsecond debounce time just to clean up any transients that might hit the line. When I went to zero debouncing, the results proved that it does bounce, just less than mechanical contacts.
I floated the fpga input for the emitter and put in a 1K pulldown resistor at the typewriter, which gives me a nice clean signal both by scope and received in the fpga. As with the ground connection, these are analog or classical electrical engineering issues and not digital logic problems. This is the phase where such problems will be encountered - initial full hardware test.
To my surprise, the emitter signal from the typewriter operates under a different protocol than the other two switches (printcycle feedback and upper case status), emitting 3.7V when the emitter is at logic 1 and 0 when it is off.
I began getting reasonable single character operation, but discovered that I misunderstood the polarity of the upper case status switch coming from the typehead. It caused my full logic to flip the typeball to print in the wrong case - a digit '1' became the character '!', the digit '3' became '#', etc. A quick fix got me back on track. I put in a crude carriage return capability during testing - one button that forces the typewriter to back up continuously while depressed.
Getting the emitter detection and shadow tracking of the position of the carriage was quite challenging. Once again, when I began driving circuits from the fpga, the fast rise times produced major transmission line issues with the sloppy wiring rig that served me well for the general logic debugging.
I decided to switch to a ribbon cable link, matching the fpga side impedance and killing reflections with a higher resistance termination where the cable connects to my driver board under the typewriter mechanism. Every other line in the ribbon cable is tied to ground, which establishes the cable at just a bit over 100 ohm impedance, matching the fpga outputs and the 75 ohm series resistance on the Digilent board. After the switchover, behavior was much more solid, but still not totally correct.
I ran my hand-coded 1130 program that will run through a buffer of characters using the 1130 console printer codes and drive the ET50 mechanism. I ran it in single instruction mode to separate issues of timing in my program from issues with the interface, adapter and physical typewriter mechanism.
I discovered that the IBM typewriter adapter logic is riddled with race hazards which depended upon the slow operating speed of the SLT logic gates and the signal paths among the modules/cards to achieve correct operation, but I hadn't modeled the single shot modules correctly enough.
IBM uses single shots (triggered pulses of some defined duration) and other pulses as timing control throughout their SLT machines, as logic is pretty much operating independently of an exact clock edge or of a common global clock. The IBM SLT instantiation of a single shot has the characteristic that after it has fired for its intended duration, it has a recovery time of at least that long afterwards when it won't fire again. This 'recharge' time allows for some spurious triggering signals that might be generated by a circuit due to timing differences between the end of the single shot pulse and the final state this will cause in other signals. During a short interval, the trigger may occur but it will have no effect.
In the typewriter adapter, a 25 millisecond timer (Single Shot 1) is fired, when it ends the adapter will trigger a second 25 ms timer (SS2). Logic considers the typewriter busy as long as either SS is active, but there is a short interval when SS1 drops to zero, the triggered output of SS2 has not yet arrived at some combinatorial logic but the newly zero value of SS1 has arrived. There is a blip where the logic thinks that both timers have ended. This can cause the SS1 to refire, if it has a zero recovery time like mine did. In SLT based machines, the SS module will not have recharged yet and ignores these false triggerings.
My solution was to update the behavior of my 'singleshot' component that is inserted whereever the ALD has an SLT SS gate. Where my gate had simply fired off a pulse until a counter of fpga clock cycles went down to zero, it now has to reload the counter and do a second pass to wait the same duration, before it will again be sensitive to triggering. This behavior is configurable via a generic when I instantiate the singleshot component, thus if I have logic that MUST trigger again almost immediately, I can support that as well as the IBM SLT conformant behavior.
I am seeing very good behavior from the typewriter, but still chasing down a few timing issues. In particular, it is still devilish to get the hidden shifts working well with the inherent timing logic built into the selectric adapter in the 1130 - it assumes every print operation will finish a print cycle within 25 and 50 ms after it begins, but with a hidden shift we need about 120 ms total for the twin operations of a shift followed by a print. I am going to study the output of the logic analyzer as I run many print tests, trying to find commonalities behind both success and failure.
DISPLAY PANEL ENCLOSURE
I designed, made and soldered on some brackets that will be used to connect the pedestals with the light panel enclosure. The attachment method I selected and the design of the box I used to make it are unsuitable. They can't be used if I want to end up with a pedestal box that looks the same as the 1130, but at least I can use it as a mockup while I build the final version.
With the box able to stand on its pedestals, I temporarily installed the LED lights into the box. I had cut the two side plates, one of which holds rotary switch to select the 'mode' of the 1130, the other will hold the sham emergency pull button that my friend, Lawrence, is having milled. I temporarily installed the rotary switch, wired it up, and installed it into the display panel enclosure.
The mocked up box is missing the plastic that has the printed mask which labels and outlines the various sections of the display and has clear outlines of the various numerals that are lit by the LED behind them. I will have to build a separator grid that surrounds the many LEDs such that light from one does not illuminate any adjacent positions. The 1130 itself has a plastic grid that accomplishes this, although IBM used incandescent lamps not LEDs.
I used a 3D printer to build the plastic grid that separates the LEDs, hoping to install that onto the front of the boards that hold the LEDs. I verified that this could fit into the panel enclosure box but my first try ran for the entire four hour timeslot I had and was only able to get to 38% depth- too thin to cover the LEDs from base to tip, which is the minimum to give good blocking of light from adjacent LEDs without some labor intensive individual cones or barriers inserted around the bulbs. I was shooting for 1/2" and only got to about 3/16" deep.
 |
| Mockup of console light pedestal stand |
 |
| Testing the arrangement and attachment options |
I believe I can make design changes to the grid, plus alter a few 3D printer settings now that I see how the first cut worked out, to turn out one of these within a four hour period. I uploaded the design file to several 3D printing services for quotes, with the lowest quote per unit at $131 and the highest almost at $350. Considering that the 1130 needs two of these, and we are talking about a simple 8" by 4.5" grid of plain plastic, those prices are unacceptable and I have to continue with self-manufacture.
My second try fared only a bit better - 3.5 hours to get to 45% completion. Looking at some alternative approaches otherwise will plow ahead fighting the 3D printer to get this done in the max time I am allowed on the machine. I do have other items to create that are quite a bit less massive and should be quick to knock out on the 3D printer.
The 1130 has handles on toggle switches that are 1" wide parallelograms, narrower front to back at the top than at the base, made of white plastic. I modeled the handle, got a much more reasonable quote from the 3D print services and have ordered the two I need. I have finished the design of the baseplates through which the switch shaft projects, with the handles described above attached to the ends of these shafts. Other plastic needs include special 'tab', 'space' and 'return' buttons for the faceplate of the console printer (typewriter), the side platen knobs and the top levers for pitch, etc.
I am working on a new design to build the final version of the box and pedestal, that will look correct from the outside and that I can manufacture with my skills with the available supplies and equipment. Once this is complete I will begin fabrication. Once built with all internal brackets soldered into place and all holes drilled or cut out, this will be powder coated with the grey textured powder I ordered.
I am beginning the creation of the artwork that will be silkscreened onto acrylic as the front face of the display pedestal that houses all the lights showing the contents of registers and various machine states. Once I have good artwork, I can work out how best to print the image on the inside surface of the acrylic that will cover the front of my display panel.
\
MUSEUM WORK
I have the full 1403 printer wiring diagrams and most of the other information needed to advise two museum projects on their interface of the printer to mainframes. I proposed an approach for the team working with the IBM 1440 system in Binghamton and listed the tasks, as well as noting the open questions that remain to be resolved. It is my expectation that I would advise and be available to whoever is doing the detailed design, fab and testing work, rather than my building anything directly. The 1403 printer that is going to NY has the cables and the appropriate connections to hook this to SMS (14xx generation logic), called 'paddle cards'.
 |
| 1403 printer cable with paddle cards to connect to 1440 era logic circuits |
The other project, tying the 1403 and a 2501 card reader to a 360/20 for a museum in Seattle, is less defined now, but I am continuing research in order to recommend ways to proceed. They have capable people at both of these museums, who will make decisions and implement what is needed for their projects; hopefully their task will be made easier by information and suggestions I can provide.
Since it is possible that I would need to design a general 360 multiplexor channel and interface it to the 360/20, which does not come with standard channels, I bought a bus and tag cable which has a modern connector on the other end, a high density 78 pin connection that it will be easier to accommodate if I move ahead to build the channel. With this, I may be able to 'breadboard' and test a channel to be sure I have it correct before passing it along to the museum.
I did some exploration of leveraging the MAX232 chips, which are designed to interface RS232 signal levels to TTL voltages, as I have an idea for how these can be used to interface to the CTDL levels of IBM SMS technology, e.g. for 1401 era machines. The CTDL logic is mostly based on +6/-6 and 12/0 levels, IBM terms these U and T, thus by appropriate offset of ground these chips can receive both voltage standards and I suspect I can generate acceptable signals for U and T as well. I will do some breadboard work when I get a chance.
No comments:
Post a Comment