Created an SMS signal socket to connect to a paddle card for the 1052 Emulator

SMS SIGNAL CONNECTIONS USING PADDLE CARDS

IBM had developed standards they used to build computers in the 1950s and early 1960s, starting with the IBM 7030 - Stretch - computer and including all of their transistorized 70xx and 14xx systems and spinoffs. The cards that implemented the logic had discrete components such as transistors mounted on printed circuit boards with thirteen contact pads on the edge that fit into sockets on the backplane of the computer. 

The contacts are labeled with letters from A to R. IBM skipped letters I and O as these were easy to confuse with the digits 1 and 0 particularly with the low resolution printers of the era, thus A B C D E F G H J K L M N P Q R are the contact names. The contacts are all on one side of the PCB. 

A mainframe of the era involved multiple backplanes (gates) which had to be interconnected by cables. A backplane from the 1401 holds six rows by 26 columns of sockets, thus can fit up to 156 cards. The backplane used wirewrap on the back to connect the pins of the 156 sockets together. Some of the card slots are used to connect cables which route signals between backplanes.

A version of an SMS card that has the thirteen contacts but is used to connect wires from a cable instead of components is called a paddle card. These are inserted into a socket to hook the cable to the backplane. A cable therefore typically had paddle cards on each end, plugging into different gates. 

When IBM moved to the next generations of computers, such as the Solid Logic Technology (SLT) used with S/360 and 1130 systems beginning in 1964-1965, the leveraged some peripherals and components from the earlier SMS generation. Thus, inside an 1130 system, there are spots where SMS cards, sockets and paddle cards can be found. These include both power supply technologies and older peripherals attaching to the new SLT systems. 

For example, the console printer (1052) of the 1130 and 360 systems attaches via SMS paddle cards into a block of SMS sockets inside the new system, as does the 1627 plotter, and the 1055 paper tape punch. In S/360, devices like the 1403 printer leveraged many SMS cards to control the printer thus SMS gates and sockets were folded into some frames. 

GENDER - SOCKETS VS PADDLE CARDS

There were situations in the SMS era where two cables had to be plugged together, for example when two independent frames holding gates were put together during installation in a customer location. A dual sided socket was created that was not mounted in a gate(backplane) but mounted near the interface between the two frames. A paddle card is plugged into each side, one cable from each frame, to join the two together. 

In essence, a paddle card plugged into one of these adapters creates the equivalent of a socket. Inside the 1130, a row of these adapters are used to accept the SMS paddle cards from the older peripherals, leveraging hybrid cables inside the 1130 having an SLT connector on one side and an SMS paddle card on the other. 

The supply of these adapters, as well as of SMS sockets as used on a backplane, is extraordinarily limited. I own two sockets and can borrow an adapter from my own 1130 by disabling the console printer temporarily. 

The reason that this matters is that when IBM built the 1052 console printer, they have two signal cables, but only one has an SMS paddle card on the end. The other signal cable has a special SMS socket, much rarer than adapters or sockets. When I built my 1052 Emulator box, I used SMS paddle cards for both signal cables because that was all I had available. 

This means that I need to use a borrowed adapter to convert one of them into a socket to connect to my 1130. The 1130 only has one gender changer/adapter for the 1052, the other space requires the cable socket from the 1052 be used. Hooking up my emulator ties up the borrowed adapter, which is not a workable situation for when I want to loan the 1052 Emulator to others. I therefore need to modify one of my signal cables to have an SMS socket on the end. 

CREATING MY SOCKET TO BUILD A CABLE

I had previously designed and built a few PCBs that create an SMS paddle card to which I can connect wiring. Recently I developed a housing that could convert one of those (male) paddle cards into a (female) socket. The first sample of the housing arrived yesterday and I assembled it with one of my paddle cards to test out the mating effectiveness.

This card implements the 13 contacts, with holes to solder wiring from a cable. It was created with four holes where bolts and nuts can be used to attach it to something. 

This holder can attach the SMS paddle card PCB using bolts and nuts. If I solder a spring contact, an RF shield finger, onto each of the pads, it creates a means for another SMS paddle card to be inserted and make good contact with the newly created socket. I added notches on the sides to mount this in the slots in the 1130 where the gender adapters or cable sockets are held. 

It turns out my design for the holder is not perfect. I had to do some improvising with a Dremel tool and drill some new holes, as well as cut notches in the SMS paddle card PCB with the shields on it, but I was able to assemble a working socket. 

SMS SIGNAL SOCKET MADE FOR PF2 CABLE

The second signal cable from the 1052 typewriter (console printer) has a female SMS connector on it, rather than a paddle card. I built an equivalent socket and wired it up. A quick final check on the 1130 verified that the cables work properly

PACKING THE EMULATOR UP TO LEND TO SYSTEM SOURCE MUSEUM

I completed an installation and operations manual as part of the github repository for the project and provided the document along with the necessary files (APL 385 Unicode font) to help them get this operational as quickly as possible. 

The 1053 Emulator will be on long term loan to the Systems Source Museum since they frequently demonstrate the 1130 system and the 1053 console printer is the most fragile part of the system. This gives them an alternate way to allow visitors to interact with the IBM 1130 without chewing through boxes of special paper. 

Implementing and testing the overtyping behavior in the 1052 Emulator - part 2

TEST WITH MODIFIED FONT AND STARTUP STRING

I reloaded the font with the Putty configuration to be certain it is using the modified version I created with FontForge. The 1053 Emulator started up and wrote out a sequence of a quad, a Zero Width Joiner (ZWJ) and a quote character. This should cause Putty to render this as a composite quad-quote character instead. 

It did not. Frankly I am losing faith in the ability of Putty to create composite characters with the APL font. Many online searches claim that it works fine, allowing you to combine emojis and do other composite work, but the actual Putty document is silent on the issue. I suspect that the quality of online searches is the problem here.

ALTERNATIVE TO SUPPORT APL AFTER FAILURE TO SHOW COMPOSITES

The strategy now is to change the selection code to a special one that displays the actual composite character which exists as a single character in the APL385 font. When we are adding a selection code to a column where there was a previous entry, we look for the special cases that exist with APL for the 1130. We insert the special select code in the line buffer and remove the two separate characters that requested it. 

The routine to convert a selection code to a character from our typeball Unicode strings will have to recognize the special code and insert the proper glyph for printing. A means of doing this has to be devised. We also need to efficiently do the check for dual characters and replacement operation from the paragraph above. 

I have the source code of APL for the 1130 which allows me to grab all the possible overtyped characters it produces. Once I correlate these to the printed composite that would appear on the 1053, I can look up the glyph in the APL385 font and record that Unicode value. I found eighteen such combinations.

For example, the exclamation glyph (!) does not exist on the APL type element, so it is formed by a quote, backspace and period. The character for logarithm is formed with a circle, backspace and star. 

I experimented and was able to find the correct glyph to display for all 18 of the combinations issued by 1130 APL. I tried these characters on the 1053 Emulator and they displayed perfectly. 

DEBUGGING THE MODIFIED CODE

I have been debugging the code on Wokwi.com and it is working fairly well. I still need to test some edge cases to be certain it works okay, but it has been displaying the composite character when I type one part, backspace, and then type the other character from the APL typeball. 

Implementing and testing the overtyping behavior in the 1052 Emulator - part 1

OVERTYPING IS A FEATURE OF THE 1052 THAT I WANTED TO EMULATE

The 1052 Console Printer is based on the IBM Selectric typewriter and uses interchangeable type elements to print on paper that is tractor fed using pinholes on the sides. The 1052 types across 120 columns, although the user can set the left and right margins to constrain the starting and ending column used. It types through a bicolor ribbon, allowing the program to select between red and black printing.

Because this typewriter puts ink on paper, it is possible to backspace and type a different character in the same column. This may be used to obscure text, such as a password that somebody typed into a program, or to form composite characters by combining more than one character from the typeball. 

Some programs in the IBM 1130 make use of this. For example, the APL/1130 system creates additional printed characters beyond the 88 available on the typeball by using overtyping, combining the quad (⎕) and quote (') characters to form the quote-quad () character. The 1052 diagnostic program prints, as I remember, a row of zero characters in one color then backspaces and prints a row of asterisk characters in the other color; this visually demonstrates the accuracy of spacing and backspacing as the asterisk should be inside the zero in all cases. 

SUPPORT IN PUTTY DEPENDS ON A SPECIAL CHARACTER

It appears that Putty, the terminal emulator I recommend for use with this emulator, can combine the foreground pixels of multiple characters but only if a special character is issued between the two. This is a unicode character called Zero Width Join (ZWJ). It is \u200D entered as a character in C. 

STRATEGY OF THE EMULATOR CODE TO IMPLEMENT THIS

The emulator will maintain a line buffer holding the selection codes for up to five characters overtyped in each of 120 columns. This is zeroed out whenever we move to a new line. As a request comes into the emulator to print a character, we add it to the line buffer in the current column position and then type everything at that column.

That is, we type the first character and then for each subsequent selection code that might be in that column of the buffer, we emit a ZWJ character followed by the next character. Thus we could combine up to five characters in any column.

When we backspace, we just move the cursor back but do not change what is displayed by the terminal program yet. If we are printing a character and we already had something in the column, because we have backspaced, then we add that to the buffer and print the new combination there. 

Spacing forward, as well as tabbing forward, will send a blank to the terminal program if the buffer does not contain a selection code for that column. Spacing forward over characters that were already typed should not emit a blank, it should redisplay the contents of the buffer for that column. 

TESTING ON WOKWI.COM TO VERIFY BEHAVIOR

I put the code on the Arduino Mega 2560 simulator at Wokwi.com and set up buttons to type characters, backspace and space so that I could test the logic. The simulated serial monitor at Wokwi.com does NOT support the ZWJ or combined graphics, but it does support Unicode characters. Thus I can't really be sure how this works until I run it on a real Arduino feeding the Putty terminal program. 

My initial method just saved the selection code but I soon discovered the flaw in that approach. The same selection code is used for both hemispheres of a typeball. We might have printed from the lower case hemisphere, then backed up and typed from the upper case side. The buffer must remember the hemisphere as well as the selection code in order to properly print the sequence whenever needed. I just added 100 to the selection code when we are using the upper case hemisphere, then separated the values when typing. 

Finally, it all appeared to be working properly. What I saw with Wokwi.com is the sequence of characters printed rather than overtyping, with no complaint about the ZWJ character in between them. If Putty does work like it is said to and will work with the APL 385 font, this should add my one missing capability to the emulator. I don't see why it won't work if it does blend emojis as well as handling languages like Arabic with composite characters, but we shall have to verify with testing. 

TESTING ON 1130 WITH PUTTY

I updated the emulator box with the new Arduino code and fired up the IBM 1130 system. I set up a sequence of print characters that include the quad-quote composite character and gave it a try. 

It printed the two characters in sequence, it did not combine them.  I then attempted some other combinations but had the same result. 

Finally, I tested the ability to back up quite a bit, overprint a character and then space forward without obscuring the previously entered text. That works correctly. 

I was understandably disappointed that the ZWJ didn't seem to work even though many references insist this works in Putty. I did some digging and discovered that the font you use with the ZWJ has to have that character slot defined as a zero width, in order to trigger the combining behavior of the two characters. 

I then grabbed FontForge and opened the APL385 Unicode font file. I found the slot for the ZWJ and saw that its width was indeed set to 600, not zero. I edited the width and saved the font. After replacing it on my windows system, I did some tests to see if this enables the composite character support I need. 

First, I added the ZWJ between two APL characters in a text processing program using the APL385 font. I seemed to have the zero width character sitting there in the string, but the program itself does not have the functionality to combine them. I then wrote the string out in the startup of my emulator program, so that I can verify immediately under Putty if the composite character will be produced. That is probably the only software I have that will render it properly. 

I am heading back to the workshop to test this out. If I can't turn on the behavior I want from Putty, I will disable the attempts in my emulator and just replace whatever was in a column previously with the newly typed character. That way I can get the emulator into productive use at the System Source Museum while I continue to look into the stretch goal of modeling overtyping. 

Finished debugging the 1053 Emulator - part 6

CORRECTED THE CURSOR POSITIONING CODE

The positioning of the cursor is now correct for all tab movement situations. I also tested the cursor positioning supporting a left margin set to a column past 1. Simulation on Wokwi.com demonstrated that the right margin and left margin support are working properly. 

RETESTING ON THE 1130 IS A SUCCESS

In addition to testing the cursor positioning from tab movements, I also verified the behavior when the left and right margins are set bigger than 1 and less than 120. I was pretty happy with the results of the testing. The emulator has passed all my tests and works as intended. 

The only 1052 functionality that is not working in this version is support for overtyping to form composite characters as that depends on a capability in the terminal emulator that will be connected over the USB cable to my emulator. That wasn't an original design goal. 

ADDING ENHANCEMENT TO COMBINE 'INK' WHEN CHARACTERS ARE OVERTYPED

Currently, the 88 APL typeball characters all print correctly but when the APL/1130 system outputs a compound character, the last typeball character is all that shows on the screen, the previous character that was printed and then backspaced over is no longer visible. 

I wrote a simple program to send one of these sequences - a quad character, a backspace, and then a quote character. Some information on the internet suggests that Putty, the terminal emulator I am using, does properly deal with graphemes combining characters in this way. I tested it. 

It did not work. Further investigation revealed that I had to emit a special Unicode character called the zero width joiner (ZWJ) to make Putty overlay the two characters. This is instead of the backspace character I would have issued. My emulator program won't know in advance when it gets a character such as quad whether it will subsequently receive a backspace and then another character that combines to form a grapheme. 

I could just send the ZWJ instead of a backspace, which will give the correct behavior to paper typing as long as the next character sent is not another movement command. For example, three backspaces in a row should overtype on the character a few back in the stream, not on the immediate prior printed character. In fact, Putty will swallow the next character if it sees ZWJ which does cause problems if a grapheme is not the intended result. 

All of this will require some additional logic in my emulator to work this out. I could buffer the characters that are sent on a line, then use it to update a position when backspacing. I first let the bs move back to a given column, setting a special mode. I update the column and move the cursor based on the movements within that saved line buffer. 

When a printable character arrives during the special mode, retype the original that was in the given column, followed by ZWJ and then the new character. Any movement that leaves the line will turn off the special mode. Also, if the original character in a column that we backspaced to was a space, we just reissue the space. 

The advantage of the code above is that the user does see the effect of the backspace movements immediately, then sees the output as it would have existed on paper if typing with the real 1052 console printer. This works properly for all 1130 operations that try to overstrike a column with multiple characters, such as obscuring an entered password field or placing asterisk over O characters as part of the 1052 diagnostic to check how well the typewriter registers at each column. 

Suitable spring found for the Calcomp 565 (IBM 1627 equivalent) plotter restoration

FINDING A SPRING THAT MATCHES BEHAVIOR OF ONE MEASURED FROM ANOTHER 565

The spring was missing from the plotter that I am restoring, but friends in a museum have one and were kind enough to measure it for me. Armed with the rest length (39mm), the length as it sits in the Calcomp 565 plotter (61 mm) and the force it takes to elongate the spring to that measured length (about 1.5 Kg), I located a spring that delivers that behavior, roughly 1.5 Kg of force when extended to about 60 mm in length. I will install the cables that move the pen carriage and attach them to the spring. 

Continued debugging of the 1053 Emulator - part 5

END OF LINE SIGNAL ISSUE RESOLVED

I did do some tweaking of the code so the first thing I did was to retest by setting a tab stop at column 119 then typing a couple of characters. That should trigger the EOL signal and trigger an automatic carrier return and line feed to reset the column to 1. 

This worked perfectly now.

RIBBON COLOR ISSUE RESOLVED

I went back to the settings for Putty, where I refined the ANSI sequences I was sending and tested under the Wokwi.com simulator. I then fired up the emulator and did some testing to see if the typed characters would come out correctly in black and red. 

I did achieve what I wanted. Each character is typed in either black or red, depending on how the ribbon color is set. The background opens as all white, just like blank paper. 

SPEEDING UP THE TAB OPERATION

I searched with a fast pointer based routine that compared doublewords to zero, advancing through the byte array in steps of eight, then identifying the location that has the non-zero byte. Since I start from the current column number it searches only the amount it needs to. 

I was also calculating the duration of the tab movement on each pass through the main loop until the time had expired; that was quickly moved to a one time calculation when we start the movement. 

The timing and operation of the tab is now perfect, except for one small issue. The cursor on the terminal screen is not advanced to the correct column position to match where the carrier is current positioned. I will fix this before the next testing session. 

SPEEDING UP A CARRIER RETURN

Just as with the tab movements, I was recalculating the time to return to the left margin on every pass through the main loop. This too is now done just once as we begin the return operation. Similarly, the line feed duration was converted to a single calculation.  

REPEATING THE TESTING ON THE 1130

I verified that every character is correctly printed. I then switched to the APL typeball and verified every one of those characters. Carrier return, line feed, tab, space and backspace all work correctly. The ribbon color shifts and the typeball virtually spins to the correct hemisphere for all characters. 

Attempting to pass the right margin will trigger an automatic carrier return and line feed, after having backed up and blanked out the last character we tried to type. I also send the bell signal but there is no sound presently produced by the Putty terminal emulator when it receives that code. I will look into whether that can be changed. 

Since I have one outstanding defect - improper positioning of the cursor on the terminal screen after a tab movement - I will retest quickly when the defect is corrected. I also need to replace an SMS paddle card with an SMS signal socket on the PF2 cable from the emulator. I am waiting on a 3D manufactured part to complete that work. 

INSTALLING MY SMS POWER PADDLE CARD FOR THE EMULATOR

I removed the hacked up SMS card I had been using to grab power for the emulator and installed a proper SMS Power Paddle card. I couldn't find my conformal coating spray so I have to wait for a can to arrive tomorrow before I can seal the card. 

Continued debugging of the 1053 Emulator - part 4

EMULATOR PLUGGED INTO THE 1130 AND TESTING RESUMES

I put the emulator through its paces, printing every character on the typeball and issuing every movement command - space, backspace, tab, line feed, and carrier return/line feed. I checked that the column displayed on the box matched where the typewriter would be. 

I wanted to verify that the box turned on the +TWR END OF LINE signal when it reached the right margin. This included changing the right margin and verifying that the behavior changed. The typewriter should issue bell characters each time it prints past the right margin. Further, when that signal is asserted, the typewriter should stay busy and automatically perform a carrier return and line feed.

The end of line signal did not work properly. I need to debug this further on the next session. As far as printing speed goes, the emulator did perform at about 16 characters per second if they are all on the same hemisphere. Where I ran into speed problems was in the performance of a carrier return and again with a tab. These took way too long to calculate the new column or complete the return operation. I need to work on the code in the Arduino to fix these speed issues. 

I used the space button to reach certain columns where I used the Tab Set and Tab Clear buttons then verified via the TABS = command typed over the serial link that the proper tabs were there. I used the tab command and the tab button to verify that the emulator reached those points, both in the column number and in the position on the screen of the remote terminal.

I issued Shift to Red and Shift to Black commands, to check that the characters 'printed' on the terminal were in the appropriate color. The ANSI Colors commands are being issued by the box and the terminal program running remotely should be honoring those as it displays the output that would have appeared on the paper if the 1053 were being used instead of the emulator. 

The colors did NOT change. I suspect this is an issue with the configuration of the Putty terminal program rather than a defect in the emulator. I will debug this further on the next session. 

Otherwise the emulator seemed to be performing properly. Once I address the issues I discovered with colors, the end of line signal and the performance doing tab or return, I will repeat the testing to finish this box off.