Experimenting with method to support overtyped APL characters using the 1053 Emulator

THE PROBLEM - APL CREATES CHARACTERS WITH TWO TYPEBALL GLYPHS

The earliest APL (A Programming Language) implementations by IBM were for the S/360 and 1130 systems. These used a terminal based on the Selectric typewriter for user interaction. The original Selectric has a type ball that has a maximum of 88 characters that it can produce, spread over two hemispheres, originally hosting upper and lower case letters for the office product typewriters. 

The APL language has more than 88 characters thus IBM chose to create some of the APL characters by combining more than one typeball character. It would type the first, backspace to the same spot on the paper and then type the second. For example, the character ⎕ is typed, the carrier is backed up to the same spot and the character ' is typed over it to produce the composite character ⍞. 

On any terminal emulator, all we would see is the character ' because the backspace would erase the first character before inserting the second one. We want one that combines the black pixels of both characters, as would happen if a type ball were printing on paper. 

IDEA FOR A TERMINAL EMULATOR RUNNING ON WINDOWS THAT SUPPORTS THIS

I envisioned a program that would produce results akin to what we see on paper with a Selectric typewriter. It would form lines of text graphically, updating positions if a second (or more) character were typed in the same column. When a line feed occurs, the next line is prepared in all white, waiting for characters to be typed. 

The Selectric typewriter mechanism for the 1053 console is 120 columns wide, which allows us just 16 pixels width per character in order to fit the entire line on a 1920x1080 monitor. This is sufficient for readability, although more would give a crisper image. Each character being typed is entered into a 16x16 image and then merged into the appropriate column of the 120 column wide line. 

EXPERIMENT WITH PYTHON PILLOW

I began to test ideas to make this happen, using the PILLOW library for Python. I was able to quickly achieve some combined characters by 'typing' the two typeball characters into their own 16x16 images, then merging them to produce the composite character. This combined a Quad symbol with a Divides symbol. 

I am thus comfortable that I can build the terminal emulator under Python, making use of the open source APL385 Unicode font to generate all the APL characters used on the 1130 system. Since this is Python based, the code may be portable enough to run on Mac, Unix and other systems as well, as long as they support the truetype font, PILLOW and Python3.

Building the new MOSFET switching board for the 1053 Emulator - almost done

MOSFET SWITCHING BOARD CONTROLS FOUR FEEDBACK SIGNALS TO THE 1130

The IO Selectric typewriter that is the basis of the 1053 console printer has microswitches that control four feedback signals - End of Line, End of Forms, CB Response and CR-LF-Tab Interlock. Three of these signals deliver +12V or are open circuits, while the CB Response signal delivers +48V or is open. 

My switching board design uses P channel MOSFETs to act as the microswitches, controlled by a 0 or 5V logic output from the Arduino inside my emulator. An NPN transistor controls the gate of each MOSFET, either leaving it at the supply voltage (12 or 48) or dropping it enough to switch on the MOSFET. 

For the three signals that are 12V level, I used an MPS2222A transistor but that won't work for the 48V signal. Every NPN transistor I had in my shop had a maximum voltage between emitter and collector of 40V or under. In operation, with the MOSFET turned off, the transistor will see the full 48 or 12V. 

I chose a BD139 transistor, which has an 80V maximum Vce rating, but had to order it. It will arrive tomorrow afternoon when I can add it to the board and wire this into the emulator.

Repaired Calcomp 565 power supply and pen up/down circuit

REPLACED DEFECTIVE PARTS AND RESTORED OPERATION

I wasn't ready to hook up the cabling that runs to the carriage and powers the pen solenoid, but I could insert a 10K resistor between the two terminal that feed the carriage cable ends. I first verified all the power supply voltages - +3, +1.5, -7.5, -9 and -24 - were correct. I then checked out the pen up/down circuit.

The circuit is a flipflop that can be triggered by commands from the IBM 1130 as well as from a switch on the front panel of the plotter. I verified that the switch is setting the flipflop to the condition being requested, and that the power flows through the 10K resistor when the flipflop is set to the on state. 

MECHANICAL ISSUES REMAIN TO BE SOLVED BEFORE THE PLOTTER IS RESTORED

The cables that pull the carriage, with the pen solenoid atop it, left and right are connected in the rear of the plotter by a spring that maintains the appropriate tension. I don't have the spring. Peers who have a working plotter measured the spring's size and force, which means that I can find a decent substitute. I have yet to do this.

The drum surface was dented and partially repaired, but it is still out of "round" and has a few high and low spots. I need to get this aluminum piece reshaped to an acceptable degree or I have to build or buy a substitute. It has pins on each side that provide tractor feed for the special paper rolls that are used with this unit. That is the hard part about finding a replacement.

I don't have the paper with pin holes that this uses. The roll is 12" wide, 120 feet long and has pin holes that are .375" center to center spaced down the sides of the paper, with holes that are .13" diameter. 

Finally, the Calcomp solenoid I have is for a cutter rather than a plotter. It used the same drum mechanism and carriage as the 565 but had a cutting tip that the solenoid would hold up or drop down onto the material being cut. Since the body of the solenoid and its electrical characteristics are identical between pen and plotter, I only have to design and machine a way to put a pen inside. Work still to be done on this aspect of the project.

When all of the above are resolved, I can wind the cables around the pulleys and attach the spring to allow the carriage to be moved left and right during operation. This sounds easy but the task of winding the pulley on the right side of the machine, as viewed from the front, is quite challenging. It is an operation that would require 4-5 hands working in close proximity to a pulley that is only about 2" diameter. 

Refining the 1053 Emulator code in the Arduino

ENHANCING SPEED OF THE CODE

I went through the code and looked for all the spots where I could reduce the time it took to perform a function or stop the processor from having to execute code unnecessarily. The aim is to ensure that we can keep up with the max rate of 15.5 characters or short movement commands per second that the typewriter can achieve. 

The code implements two state machines, one for the typing and short movement operations, the other for the three long/indefinite operations (carrier return, line feed and tab). The code interrogates the timer and compares it to the time when the state machine left the idle state. 

At specific durations, it switches the machine to the next state. However, it also outputs signals during some of the states, which can mean we are repeatedly outputting the same signal until the timer comparison moves the machine to the next state. A simple change fixed this - with the code that emits signals only taking place on the first cycle in a new state, saving the old state to detect the 'edge'. 

The character lookup was unnecessarily complex, looking through a table of all 44 possible tilt and rotate combinations for the typeball hemisphere to find a match, then using the index of where we matched to pick out a character from the hemisphere glyph table. I created a direct access table with all 64 possible combinations of tilt and rotate values, even though only 44 of them are valid, so that I could pick up the index using the tilt/rotate selection value as the displacement into the table. That avoided the loop reading through a table. 

I made many improvements long these lines to reduce the compute load and free up the Arduino for faster response. When I am back I can do some testing to verify whether it can keep up with the stream of characters and short movements, since that is still a design goal. 

ADDING IN APL TYPEBALL SUPPORT

One of the stretch goals when I began this project was to emulate both the normal console type element and the special Selectric ball used with APL (A Programming Language). I have a few type 988 balls which would allow the IBM 1130 system to run APL, when put on the 1053 console printer. I believed that adding this to the emulator would be useful. 

One of the challenges of the APL character set is that there are many more symbols than the 88 positions on a Selectric type element. Once you consider the 26 alphabetic and 10 numeric characters that must be included, only 52 spots are available for other glyphs. The solution IBM adopted was to overstrike, typing one character from the ball, backspacing, then typing another (or even a third), to combine together to form the intended glyph. 

This poses a small challenge to the emulator which sends data to a remote terminal program for display. It isn't using actual paper, thus when the backspace is sent after the first character is typed, the terminal will replace the first character with the second when it is sent rather than combining the two. 

This is a minor issue with normal console characters, since overprinting is not done that often with the 1130. Passwords might be obscured by backspacing and typing various characters over the entered password thus making it very hard for an observer to read the password from the paper. The 1053 diagnostic prints a line of O characters, each time backing up and typing a * character. This is used to verify how accurately the spacing and backspacing is operating. 

This becomes much more of an issue with APL where overprinting is very common. The meaning of a glyph is going to be impossible to discern if you only see the last character typed into a column and not the prior ones. For example, the character ⎕ is typed, then backspaced and the character ' is typed to overprint, yielding the combination character ⍞ which is not on the typeball. If you only saw ' on the screen you wouldn't realize the intended character was ⍞. 

This can be solved by developing a custom terminal program to display the output of the emulator. It would retain the characters in the current line, thus when backspacing it would merge the prior column contents with the newly typed character. The program will be displaying the columns as bitmaps avoiding the need to find a unicode glyph for the combinations. 

Meanwhile, I had to create the alternative set of glyphs for the 88 positions of the APL typeball. The emulator has a command that can be issued over the serial link that switches between normal and APL elements. I just had to find all the glyphs such as ⊥ and ⌊ to put them into the table. As long as unicode had the character, I could transmit it over the serial link. I found a freeware font, APL385 Unicode, that includes everything I needed. 

To make life more interesting, since I was visiting relatives in Myrtle Beach, South Carolina over the past few days, I had to recreate the APL typeball without having it in my hand for direct inspection. I had to look over various online documents and use a 3D viewer to examine a replacement typeball designed by another hobbyist.  

Power supply failure and debugging on the Calcomp 565 plotter

RESTORING LAST BIT OF CIRCUITRY WHEN AN ANOMALY OCCURED

Having previously restored the carriage left/right servo to full operation with the replacement power transistor installed, I turned my attention to the pen up/pen down circuit. This operates a solenoid in the pen that either holds the pen up in the air off the paper or allows a spring to push the pen down for drawing. 

I had discovered a failed power transistor in the circuit and when the spare part arrived, I installed it. As I was probing around investigating the operation of the circuit, I installed a similar solenoid onto the carriage and hooked it up. Apparently Calcomp also made a cutter solenoid that would work on the same plotter mechanism, but place a knife on the paper/plastic/fabric so that patterns could be cut with .01" precision. 

It is almost identical to the pen solenoid, which is why I scooped it up on eBay, planning to convert it into the pen. It has the same inductance and method of attachment to the carriage. It was in place and I began checking voltages, when I saw that the -24V level shot down to -41V. It may have been something I did duriing the probing or it may have been a coincidental failure. 

I turned it off, then when I powered up later the voltages were now all near or at zero. The fuses were good, so it appears that something failed in the power supply. 

FIRST FAILED PART DISCOVERED - A WIRE

I verified that the AC output was coming from the transformer, but there was essentially zero coming out of the bridge rectifier. Checking all the diodes did not find any that were shorted, open or otherwise malfunction. Just zero volts coming out and I had confirmed it was NOT due to a short that the rectifier was feeding. 

After some continuity and other testing, I discovered a defect in the wire which connects one of the transformer secondaries to two diodes in the bridge. The wire was not a wire. It is one of a bundle of wires that are laced together and routed through the power supply, with no obvious sign of damage or overheating. It was just an open circuit. 

ADDED A NEW WIRE BUT THE VOLTAGES WERE NOT GOOD

I soldered in a new section of stranded wire between the terminal board where the transformer secondaries attach and the junction of the two diodes. With continuity, I powered up and began to check the voltages being produced by the supply. The line that should be -24V (or a bit more negative since it was unloaded) was at -41V, the same as what I observed just before the wire committed suicide. 

I checked a couple of the other power rails and they were all off significantly. Something else failed in the supply besides the wire. I ran out of time to find the issue when I had to leave the workshop.

OVERVIEW OF THE POWER SUPPLY

The power supply of the Calcomp plotter is interesting, using just one s et of transformer secondaries and no regulators yet producing -24, -9, -7.5, +1.5 and +3V rails. It depends upon a chain of diodes to generate the proper voltages, a voltage divider taking the approximately 27V produced by the rectifier bridge under load and turning it into the rails above.

There is a small additional part of the circuitry that is connected to the bridge rectifier before the filter in order to have pulsing DC, used for the fast stepper modes that drive the servos at 120 steps per second. It is not salient to the issue we are debugging so I didn't include it in the pseudo-schematic above. 

For me to see 41V instead of the 34V I previously observed, the most likely failure is that the Zener diode has shorted. I tested all the other diodes with a VOM in diode mode and found them all to have a good diode voltage and not pass any current in the reverse direction. However, I couldn't check a Zener with that method.

The acid test for a Zener is a transistor curve tracer, where carefully limited current and controlled voltages can be introduced and the results observed on an oscilloscope. The diode should be high resistance at voltages up to 7.5 then exhibit a nearly vertical slope to the current flow allowed by the tracer setting. 

When I get back to the shop, I will remove the Zener diode and test it on my transistor curve tracer. If I need a replacement I must be sure to get one with a high enough power dissipation capacity. The schematic lists it is a 1N3016A diode so that would be the perfect replacement, or a substitute with the same or higher specification of 1W capacity. Interestingly, the spec sheet does not show the voltage threshold as 7.5V, instead listing it at 6.8V. 

Designed SMS socket and having it manufactured

THE NEED FOR AN SMS SOCKET

The Standard Modular System was the construction methodology used for IBM computers in the generation from the Stretch computer until it was replaced in 1964 by Solid Logic Technology of the System 360 and 1130 systems. The 1401 and the 7094 are two well known systems based on SMS. 

IBM did use SMS components during the later generations such as S/360, both for components such as power supplies and for attaching older peripherals originally designed to connect to SMS machines. In the IBM 1130, many peripherals are attached using SMS paddle cards and SMS power cards. 

The paddle card looks like the end of an SMS logic card, but is attached to cables. SMS cards have 13 pads, labeled A through R (as they skip the letters I and O due to their resemblance to the digits 0 and 1). The power card is similar but has some pads combined into fatter pads to handle more current, e.g. M and N become a double width pad, and it has a notch in the middle. The connector block into which power cards are plugged has a steel bar to block ordinary SMS paddle cards but allow the notch of the power card to slide around it. 

I do not have any reasonable source for SMS paddle cards, SMS sockets, nor the gender changer/adapters that allow two paddle cards to be connected. I had to build my own small PCBs to work as SMS paddle cards and SMS power cards. 

The challenge I face is that there is another option connected to a cable, a socket into which a paddle card will plug. One of the cables coming from the 1053 Console Printer, a selectric typewriter used as the console of the IBM 1130, has a socket on it rather than a paddle card. My 1053 Emulator project was originally built with SMS paddle cards, but one of the cables either needs a gender changer/adapter or a socket.

CONCEPT FOR SMS SOCKET

I realized that I could solder some RF shield fingers onto the pads of one of my SMS paddle PCBs. These are springy gold plated contacts that stand 2.5 mm above the PCB but can compress down to 1.5 mm or less, ensuring a good contact across all thirteen pads of whatever we mate to. I needed a body that would hold the paddle card PCB with its fingers and hold an inserted SMS paddle card against the contacts. 

At first I was working on a design that would put my paddle card PCB inside and have a slot for the insertion of an SMS paddle card. However, I realized that the paddle card PCB itself acts as one side of the socket, thus it does not need to be enclosed. 

I designed a part that will be installed over the top of my paddle card PCB, bolted in place through the four holes I put into that PCB. The opening of that part is 3.8mm high, thus an SMS paddle card at 1.54mm will slide in and compress the fingers on my PCB down to 2.26mm height, giving a good solid contact. The part has a wall to stop the SMS paddle card from sliding in too far. 

It has two additional features, notches for mounting and an opening for the cable wiring to exit the socket. The opening is not particularly important, but the notches are key to use in the 1130.

The IBM 1130 has a U shaped bit of metal, the height of the U much larger than the width of the opening. The opening itself is just over 56 mm. The U shaped bit is rotated 90 degrees and mounted in the 1130. 

The IBM gender changer/adapter parts have notches built in so that they can be slid into the U and thus anchored, with SMS paddle cards plugging into the front and back of the adapter. SMS sockets such as the one attached to the 1053 also have the notches and are slid into the U the same way. 

DESIGNED IN FREECAD AND SENT OUT TO MANUFACTURE IN NYLON

I whipped up a design for the body that converts my SMS paddle card PCB into a socket.

I transmitted the design through Cloudcraft and should have three of them by the end of next week.  

Continued debugging of the 1053 Emulator - part 2

TESTING AFTER THOSE CORRECTIONS

I plugged the emulator into the VCF 1130 system and ran my hand entered code to fire off characters and commands to the emulator. I needed to see it successfully handle a print, triggering the interrupt level so that I knew it had the correct feedback signals from my box. Without the feedback working, I can't do a shift nor test out the characters on the other hemisphere of the type ball. 

The oscilloscope was set up to watch the feedback signals as further confirmation that they are reliably delivered into the 1130 system. I did not see enough swing in the signals to cause the 1130 controller logic to operate as intended. I have to throw in the towel and give up on using the N-channel enhancement MOSFETs - the only type I had in the shop. 

THE PROBLEM WITH N CHANNEL MOSFET SWITCHING

The N MOSFET needs a positive voltage on its gate relative to the source, of a high enough differential to switch on the channel and pass current from the drain through the source (actually electrons flow from the source to the drain, but the conventional notation used in circuits has the current flowing from + to - terminals. That is why an N channel MOSFET has a positive voltage on the drain relative to the source.

The classic circuit for these is to have the source hooked to ground, the drain hooked to the + rail through a current limiting resistor, and the load being switched is hooked between the drain and the limiting resistor. An Arduino delivering 0V to the gate will keep it off since the gate is NOT more positive than the source. The high (+5V) output of the Arduino is positive enough for some N channel MOSFETS, although some require a higher differential, thus it can turn on the flow through the MOSFET and pull the load down to ground. 

The situation with the 1130 and the 1053 is not the classic situation. The load line is pulling current from the + rail down to -3V inside the debouncer in the 1130. When the MOSFET is switched on, the load line jumps to nearly the + rail, when the MOSFET is off the load line is seen to be at -3V. 

The drain of the N MOSFET is thus nearly at the + rail  when the switch is off, but drops down to -3V when it is turned on. The gate is more positive than the source when the MOSFET is turned on, but we have to limit current through the resistor which drops the voltage sent to the debouncer circuit. When the switch is on, the current is flowing through the MOSFET in addition to going into the debouncer. 

This gets more severe with one of the signals, which has a +48V rail, as the current limiting resistor is set for 2.5W of consumption yet that lowers the voltage to the debouncer too much to work reliably. In reality, the classic circuit does not work well for me.

The ideal use of the MOSFET switch is indeed as a switch, with the + rail on the drain and the debouncer circuit on the source with no current limiting resistor at all. That way it works purely as a switch, the perfect analog for the mechanical switches in the 1053 typewriter we are emulating. The challenge comes from trying to control it with the gate.

The source voltage is going to vary now, from -3V when the switch is intended to be open up to the + rail when the switch is closed. The gate has to be more positive that the source to turn it on, but that means it has to be more positive that the + rail. Unless I want to add additional power supplies above the 12 and 48 V rails of the 1130, this is not possible to do. I certainly can't do it with an Arduino's 5V logic high. 

There is even the risk that some current will flow even when the Arduino puts out 0V, logic low, as that is 3V more positive than the source initially. The MOSFET is likely to turn on just enough to raise the source to a point where the gate-source differential is lower than its threshold.

P CHANNEL MOSFET IS THE SOLUTION

If I switch to a P Channel MOSFET and hook it up as a switch, the situation gets better. The rail connects to the source terminal, the drain is connected to the debouncer. The gate has to be more negative than the source terminal, but fortunately in this case the source is steady at the + rail, not varying as in the N channel case. We just need a way to get the gate to sit either at the + rail or about 8-10V below the rail, to have the switch off and on respectively.

That is provided by a simple NPN transistor and a voltage divider between the + rail and the collector. The emitter is hooked to ground and the Arduino will turn this on or off as it drives the base with logic high and logic low respectively. The transistor, when off, allows the MOSFET gate to see the full + rail voltage. When the transistor conducts, the pair of resistors in a voltage divider are sinking current to ground through the emitter. 

Choosing the values of the two resistors lets me set the gate voltage I want the MOSFET to see when we want to turn it on. The MOSFET doesn't need any appreciable current to the gate, thus the resistors can have high values. If the upper resistor is 30K and the lower resistor is 10K, with a +12V rail, the junction of the resistors will drop to 3V when the transistor conducts. putting the gate about 9V more negative than the source. 

Now this is simplified due to things like the diode voltage drop of the transistor and non-zero emitter-collector on resistance, but you get the idea. For the +48V rail, we can choose an upper at 18K and a lower at 47K to produce just under 35V at the junction and thus the gate will be 13V more negative than the source. 

I will order some P channel enhancement, MOSFETs with suitable voltages and thresholds. I have plenty of switching NPN transistors on hand and enough resistors to create the voltage dividers I need.