Given some pricy advice to make progress debugging the 1130 MRAM memory infrequent bit failures

1130 MRAM BOARD HAS BITS DROP ONCE IN MANY THOUSAND READS

The failure is rare. When I loop through memory, there are almost 278,000 reads done every second. With just 8K of memory implemented, this means the system has looped through every location almost 34 times in a single second. 

The symptom is a drop of bit 14, when it should have been set, at varying addresses in memory. It only happens after thousands of successful reads of the same word. When I put my Rigol oscilloscope probe on the pin where the pulse arrives from my board into the 1130 memory register, the error goes away. Instead, bit 10 will now fail at a even less frequent rate. Putting a second channel's probe on that bit leads to almost flawless operation. 

THE QUANTUM MECHANICAL NATURE OF THIS FAILURE

Therefore, when I put on the scope probe or a logic analyzer probe, the failure does not happen. It only happens if I am not observing. That means I can't see how it is going wrong, because I can't get the failure to occur while I am measuring.

ATTEMPTED MANY TIMES TO CREATE AN EQUIVALENT LOAD TO THE PROBE

I can't run the machine with my Rigol scope permanently attached. Further, it may be that after 20 minutes or five hours, another bit will fail to be set. Since the presence of the probe seems to cure the situation that causes the failure, I hoped I could develop an equivalent set of components that I could attach to the backplane pin in lieu of my scope probe. 

However, this is a very messy and complicated situation. Many inductances, capacitances and resistances are involved in the scope probe through to the input amplifier. I looked up the probe and the Rigol scope schematics, but those only show the discrete components. They don't show the wire and connection capacitance, inductance and resistance, but those values are also involved if you want a correct model to analyze the resultant equivalent circuit. 

ADVICE ON HOW TO BYPASS THE QUANTUM MEASUREMENT EFFECT

My friend CuriousMarc suggested that if I used an active FET probe, which has much lower loading than the passive probes, I can probably observe the failure. If I can see what is going wrong, I have a better chance of fixing it. 

I immediately went online to look for active FET probes for my Rigol DS1054Z scope. What I saw set me aback. Rigol is a very cost efficient brand of scopes, but the active FET probe choices ran from about $1,500 to well over $4,000 depending on bandwidth. 

Since I don't regularly have a need for that kind of probe, I would be spending that money just to measure this situation - a one time process. I can't even be sure that what I observe would definitively lead me to a solution, thus it is a gamble on top of a serious investment. 

LOOKING INTO DO IT YOURSELF ACTIVE FET PROBES

At this point, I am willing to consider building my own active FET probe. I did find a few projects done by competent engineers. This gets into serious RF magic territory, well beyond my usual engineering experiences. I picked one and am seriously considering the effort.

To control the characteristics of the PCB for this probe, I would have to shift from ordinary PCB material (FR4) to Rogers material, which would push the price for the bare board up to around $150. The design I found is centered on a MOSFET amplifier used in UHF analog television circuits - the BF998 dual gate enhanced mode N channel FET. This has dual gates and characteristics like extraordinarily low gate capacitance.

Of course, with the advent of digital television, the market for those devices has dried up. The chip is obsolete and not stocked by any of the reputable distributors. Of course there are many offers for the device on Amazon and eBay, all from operators in China, but the risks that I would be sold a lesser quality FET that was relabeled are just too high. If the gate capacitance and other specs aren't what the design expects, it isn't going to work correctly. 

I did find one location that has stock of the FET, is not in China and seems to have a good reputation. Assuming they didn't just by the stock from the scammers, but instead had a legitimate supply that came from NXP through a distributor, then this solves the availability problem.

I found an Instructable from someone who built the probe successfully.  They characterized it as less than $20 but that assumes free PCB construction and a substantial electronics lab to measure and adjust the probe. The values they determined for filters to make this work linearly are only for the board they built. Because - RF magic. 

Minute variations in the PCB, the components and even in my soldering will mean that when I build it, I may need to do the measurement and tuning process myself. Even the presence of a bit of solder on the traces beyond what is strictly needed to mount a component adds capacitance and inductance. Also, too little solder turns the joint into an unwanted capacitor. 

It isn't the most practical Instructable. There are only simplified schematic fragments. The gerber files show many components, about half of whose values are NOT specified. Instead of showing a full schematic, the person uploaded an equivalent analytic model in NI AWR Microwave software format - thus having elements that stand in for straight and right angle traces, as well as actual components. 

As one caveat, they mention that "you may need a membership in a laboratory, or acquire some people's affection who do (i.e. via cold beverages). Also, the 20$ price tag suggests you only need to buy the special components, not the standard things which lie around in an RF-lab anyway." They also assume I will be milling my own PCB from 512µm Rogers RO4003 w. 17µm copper dual-sided board material. 

I was able to take their gerber files and get them into KiCad so that I could produce an acceptable set of gerbers and drill files to send to a professional PCB fab house. I am working hard to identify the components they installed at all the open gaps on the PCB, so that I can purchase them. If I am successful in developing a complete bill of materials and can find the parts, I will then order the PCB and commit to the project. 

The component values which are totally custom are the ones needed to form a filter to compensate for a resonance around 800 MHz. He started with components such as 1.8 pf capacitors and 22 nH inductors, but suggests that I have a well stocked supply of different values to try. This might involve some iteration ordering parts from a supplier and stretch out the completion. 

The current snag in finding parts is the SMA connector he uses - it is a straight SMA female with a solder-on pin, but has a mounting flange with two holes. The flange is at right angles to the connector, but the inner conductor comes out straight. All I have found so far that have the flange at a right angle bring the inner conductor out at the right angle, which isn't going to work. If anyone recognizes this and knows where I can find it or at least how to describe it when searching, let me know. 

This probe produces a 50 ohm output impedance. My Rigol DS1054Z oscilloscope has a 1M input impedance. The solution is to add a 50 ohm terminator in a Tee connector at the input of the scope. I will have an SMA to BNC cable hooked to the tee where it is terminated, the other side of the tee connected to the scope input. 

Invested time simulating and correcting code to archive IBM 2315 cartridges on a Diablo model 31 disk drive

ARCHIVAL NEED

I own several dozen 2315 cartridges that contain software for IBM 1130 systems. Rather than risk them directly on the internal disk drive of the IBM 1130 (and rather than risking damage to the very rare disk heads inside the drive), I want to extract the contents and put them on virtual cartridges for use with my Virtual 2315 Cartridge Facility (V2315CF) for the 1130. 

The V2315CF holds the contents of a cartridge on an SD card inside a holder designed to look like a miniature cartridge. When inserted into the V2315CF, the contents are made available for the IBM 1130 to read and update while it believes it is accessing the physical internal disk drive of the 1130. 

A dummy 2315 cartridge spins in the physical disk drive, providing the timing information and offering the user the sounds and vibrations of a running disk and its seek movements. The data flow to the heads is instead fed from the V2315CF, giving the 1130 the stream of pulses that would have come from the heads. Any sector that is written to will have the pulses from the 1130 captured and update the contents of the virtual cartridge. 

The archived contents of the physical 2315 cartridges can also be used with the IBM 1130 simulators running on personal computers, expanding the pool of software available for hobbyists and researchers of the 1130 system.

IBM developed the 13SD drive and used it with the IBM 1130 and 1800 computing systems. It took the 14" disk platters and head technology from the larger 2311 and 2314 disk drives, creating a single platter version that was housed in a cartridge (a 2315 cartridge). 

The 13SD drive was installed in IBM 1130 computer systems, inside the main 1131 processor cabinet. Drives were also put into the separate IBM 2310 cabinet, hosting one or two drives in each cabinet to give expansion capacity for 1800 and 1130 systems. The cartridge was pushed into a front loading slot of the 13SD drive and spun up to use it with the drive, then removed when a different cartridge's contents were desired. 

DIABLO MODEL 31 STANDARD DENSITY DRIVE

Diablo licensed the technology from IBM to design their Model 31 standard density disk drives. These used the same 2315 cartridges and were compatible, able to share data between the model 31 and an IBM 13SD drive. A 2315 cartridge in standard density read and wrote bits at 720Kbps with the cartridge platter spinning at 1500 rpm. 

The data is recorded in a self clocking using a 'double frequency' method where each bit is recorded in a cell with space to record two magnetic flux reversals. The first reversal was always recorded - that was the clock bit. The second time interval would either have a flux reversal, to indicate that the data bit value was 1, or skipped a reversal to indicate that the data bit was a 0. 

The platter was organized into 203 concentric rings of information as the disk head moved radially inward and outward towards the center. 2315 cartridges from IBM had the circumference of the platter divided into eight equal pie slices, with a notch in the hub ring generating a Sector Marker as the drive reached each of the slices. A special double notch at one point generated the Index Marker to define which was the first sector of the eight. 

IBM chose to combine pairs of slices to form the four logic sectors that were used in the IBM 1130 and 1800 systems. Diablo offered cartridges with 8, 12, 16, 20 and 24 physical sectors per rotation. 

Diablo then enhanced the drive, doubling its capacity, as the high density version. Many other minicomputer manufacturers licensed the IBM disk technology and made use of the high density approach. Over time, these vendors also narrowed the size of a ring on the platter to implement 406 cylinders rather than 203. None of these were interchangeable with the IBM 1130. 

The disk controller for the 13SD drive handled disk arm movement differently from Diablo. IBM used a toothed comb with pins that held the arm in the 203 positions. An arm movement involved a command to the disk drive to move 1 or 2 positions in either the forward or reverse direction. The drive made a grunting sound as the pins detented into and out of the comb during seeks. 

A microswitch in the drive indicated that the arm was at the home (cylinder 0) position. Modeling the seek meant tracking the arm position based on the 1 or 2 track movements received as well as the home cylinder indication. A feedback signal turned off when a seek began and switched back on when the arm was settled in position on the new track. The command signals to move, the step size and direction were all defined length pulses. 

Diablo dropped the use of the comb and pins, instead implementing a servo that precisely positioned the arm at the 203 possible cylinder; it was much quieter as a result. The drive accepted different commands. It was given a cylinder number to attain and simply asked to seek. The request was maintained until feedback indicated it was accepted. 

The drive would first acknowledge acceptance of the target cylinder number with one feedback signal, requiring the controller logic to drop the movement request once the feedback arrive. Another feedback signal would turn off when the seek began and turn back on once the arm was correctly in position. The drive did not indicate when it was at cylinder zero.

The drive would emit the Sector Marker and Index Marker pulses, just as did the 13SD, but in addition would output a binary coded decimal Sector Number directly. The controller logic no longer had to interpolate the sector by counting SM and IM pulses. 

Other differences included a Restore command that would move the arm to cylinder 0. Error signals were generated if the requested new cylinder number was out of range or if the seek mechanism somehow failed to work properly. 

FPGA LOGIC WRITTEN A WHILE BACK BUT HAD KEY DESIGN FLAW

My version of the archiving logic used the 13SD seek commands and feedback signals. The Diablo model 31 did not conform to that, thus it required redesign to use the Diablo interface signals. 

ADAPTING TO THE DIABLO INTERFACE

Fortunately, I am quite familiar with the Diablo drives and how to drive them with an FPGA, as I did this to archive all the cartridges from the Xerox PARC library a few years back. Those contained code used on the Xerox Alto computers, the pioneering systems that developed the graphical user interface, ethernet, WYSIWYG and other concepts that made their way into the Apple Lisa, Macintosh and Windows. 

SIMULATING TO VERIFY THE UPDATED DESIGN

I changed the logic and then had to carefully simulate the behavior to be certain that my updated design conformed to the Diablo specifications and would work correctly. This was a long slow process as each rotation of the platter took 40 milliseconds to complete, with more than one turn required to be able to sync up with the SM and IM pulses to correctly mirror the sector number under the heads. This took a long time in simulation before I could observe the movement behavior. 

To fully simulate the archiving of an entire cartridge would require 120 ms per cylinder plus 15 ms for the one track seek. This would approach 30 seconds of simulated time, many, many hours of simulation time on the laptop. 

Using new hysteresis technique to protect against noisy signals in some of my FPGA designs

EXTERNAL SIGNALS MAY NOT BE CLEAN ENOUGH FOR CERTAIN LOGIC

Every external signal coming into the FPGA has to be passed through a series of flipflops to reduce the risk of metastable states - the risk that if the pulse arrives at just the wrong time compared to the clock edge in the FPGA, it may assume an incorrect state or even hang up. The conventional solution is to pass through three clocked flipflops to clean up the signal for use inside the FPGA. 

The risk of a signal sitting in a metastable state goes down dramatically by the third flipflop. It does introduce a delay of three clock cycles before you are seeing what has occurred externally, but with a 100MHz FPGA clock and the relatively slow equipment to which I am connecting, this is not an issue.

These signals may have a bit of bounce in them, similar to how contacts behave when a switch is flipped. That is, even though digital logic is driving the signal rather than electrical contacts, I might see a sequence of bits coming out of the three flipflops that don't definitively transition between 1 and 0 states at only one cycle. The output might have a stream of 0 0 0 1 0 1 1 1 for example, where a long sequence of 0 change to a long sequence of 1 but there is a sort of stutter for a cycle or two. 

Often we want to react when a signal changes state, but we take an action only once. In essence we only care about the signal edge, the rising transition. If there is a stutter, than we might detect more than one rising edge when the external situation only changed once. If we are counting based on the edges, we might incorrect count higher than we should. 

In many cases, the external signal is used to advance a state machine, so that it doesn't matter that there is a pair of edges close together, but I have to think carefully about whether the state machine could malfunction with stutters. For example, the state machine may use the falling edge to move onward, which the stutter will appear to deliver. 

HYSTERESIS - SCHMITT TRIGGERING

Schmitt triggers are gates that switch at different thresholds in one direction than the other, designed to eliminate the risk of small variations inadvertently switching the output state. Usually this is an analog approach - perhaps the rising edge must get to 75% of the full on voltage before the gate registers it as a 1, but it won't switch back to 0 unless the falling edge drops below 25%. The signal can bounce or oscillate around the 50% level quite a bit and still not be reflected in the output. 

This is hysteresis - where the change in state depends on the history of the signal not just the immediate value. It adds a delay before the change in the signal is recognized and acted upon, but it can eliminate bouncing or stuttering signals. It involves different thresholds for when it turns to 1 and when it turns to 0. 

MY THRESHOLD FILTERS

I created a module that adds this hysteresis for critical external signals. It first address metastability with the usual series of three flipflops. It then adds or subtracts to a counter based on the instantaneous signal state. The thresholds for when the output changes are specific high and low counts. We might require five successive 1 values before the output is switched to one, when the counter reaches a count of 5. Future 0 values decrease the counter from its maximum, but we don't change the output state until we get to a count of 2. That spread between the rising and falling thresholds is the protection against bounce or stutter. 

The time delay can be an issue - in the example above a signal that rises to 1 won't be recognized for a minimum of 8 FPGA cycles, more if there were stutters. At 100MHz clock frequency, that is 80 nanoseconds or more delay. The case for most of my projects is that the signals are much, much slower than that. Even the stream of clock and data bits from the disk drive are changing more like 1400 nanoseconds, more than 17.5x slower. More importantly, all the signals are arriving wih a similar delay. 

It will add delay for when my output signals to an external device don't react for 80 nanoseconds, but that isn't significant. A sector on the disk takes 10 milliseconds to rotate past the head, thus the signal delay is only 0.0008% of the sector duration. 

I am first applying my threshold filters to the tool I built to use a Diablo disk drive to read and archive all my 1130 disk cartridges. The protocol for the disk is to record magnetic flux reversals in 'bit cells' of two bit times. A reversal always occurs first, which is the clock, then the second bit time skips the reversal if the bit value is 0 otherwise a reversal signals a 1 bit. 

The disk drive itself tries to separate the flux reversals and route them out separate clock and data signal lines, but I have to see the clock pulses to know which bit of a word that a data pulse belongs to. Thus, the edges of clock and data really matter in this process. I expect my filter to help me determine when to watch for data pulses and when to shift the prior result into a word. 

My state machine is driven by the clock pulse edges - the falling edge sensitizes me to watch for any 1 bit coming on the data line. The falling edge of the clock resets the detector, then any data pulse turns it on. The rising edge of the clock is when I check the detector to see if a data pulse had arrived any time during the roughly 1.4 microseconds between those edges. 

Another application where the threshold filter might be very helpful is in the Virtual 2315 Cartridge Facility, where I have had some discrepancies between the seek distances requested by the disk diagnostic program and the attained cylinder position. Since the commands from the 1130 to the disk pass through the V2315CF, if a stutter caused a failure in my FPGA logic I could have dropped a movement or added one as I drove the disk drive from my code. 

Found substitute spring for the Calcomp 565 plotter and verified it works properly

RESTORING CALCOMP 565 PLOTTER

I was given a Calcomp 565 Plotter, one of the first drum plotters, which is the same mechanism as IBM resold under the model number 1627 for use on their 1620 and 1130 computer systems in the early 1960s. Since I own an IBM 1130 I was given this machine as an eventual restoration project.

The machine had suffered a serious blow on the drum, denting it significantly. It had been disassembled and was in a bin when I received it. In addition to the drum damage, it was missing the pen assembly, a solenoid that pulled a pen up away from the paper or dropped it down to draw on paper fed around the drum. 

Recently I found a Calcomp cutter which was the same solenoid and a slightly different top. used to cut films on the same plotter instead of drawing. I bought it and plan to modify it to accept a pen so that this plotter could once again draw graphs under computer control. All that assuming I could repair or find a substitute for the drum. 

I recently repaired the circuitry, which had a few bad semiconductors, then began to reassemble it temporarily, with the bad drum, to confirm whether it could be restored once I solved the drum and pen issues. I discovered it was missing a spring as well as some nuts and bolts. The fasteners are no issue at all, but I needed to replace the spring.

CABLING TO MOVE PEN CARRIER LEFT AND RIGHT

A pair of metal rods across the front of the plotter support a moving fixture into which the pen solenoid is mounted. Cables stretch from both sides of the fixture, around pulleys inside the plotter, connect to a stepping motor, and then are joined by the missing spring at the back. 

These cables are insulated with a plastic sleeve at the front, since they also carry the current to activate the solenoid when the pen is to be held up off the paper. The rear portions of the cable are not insulated and ride over metal pulleys that are isolated from the machine chassis. These two pulleys make the connection of the 24V solenoid power to the cables. 

The routing and winding of the cables around one pulley and around the stepper motor is a bit complex, but the result is that when the stepper moves, the fixture slides left or right. The spring at the back maintains the proper tension on the cables. The two cables have nylon eyelets so that the spring does not make electrical contact, merely providing tension. 

What I didn't have was any idea of how long the spring is and how resistant it is to extension. Too, I didn't know the target tension it should be applying to the cabling. 

KIND ASSISTANCE FROM COMPUTER MUSEUM OF BASEL

I have had help over the years from the Computer Museum of Basel, in Switzerland, as they have a restored IBM 1130 system. We often cooperate on 1130 issues. Alex and Christoph agreed to measure the spring in their Calcomp 565 plotter so that I could then look for a suitable replacement. 

They provide very precise measurements of the rest and extended length of the spring as well as the tension it provided to the cables. That was just what I needed. 

FOUND SUITABLE SPRING AND INSTALLED IT ON CABLING

I did locate a spring that had the correct rest and extended length, as well as the force it should exert when stretched to the target length. I wound the cable through the machine and inserted the spring in the rear to hold the cable ends together. It wasn't a final assembly but was sufficient to verify that this will allow the plotter to work properly once I have the pen and drum issues solved. 

Rough fit test of spring

Whipped up a 1053 Emulator log file display and print program

1053 EMULATOR OUTPUT ON PUTTY SCREEN VERSUS PUTTY LOG FILE

The Putty terminal program screen shows the text being output by the 1130 in black or red text, exactly as it would be seen on paper if an actual 1053 were used instead of the emulator. It also saves a log file but that does not support color, thus the ANSI color sequences are visible, disturbing the look of the output.

PROGRAM TO REPLAY THE LOG AND TO PRINT IT

I wrote a Python program to open the file (using a standard file dialog box starting at the Desktop). It then asks if the user wants to skip the green text. The startup of the emulator prints its menu in green. Too, the responses to any command typed on Putty to the emulator are displayed in green. Choosing Yes to this dialog box means all that is removed. This leaves only what the user would have seen on paper on the 1053. 

The program displays the log file in logical pages of 120 columns by 35 lines. Buttons are provided to move to the next page or to the previous page, as well as to print the current page or to quit. The program uses the Windows default printer, in landscape mode, to print in color. Thus any color capable printer will give a page by page copy of the session that is recorded in the Putty log.

File open dialog starting Desktop

Option to omit non-1130 output

Main window

When the Print Window button is pressed, it blinks red and green until the print has completed. The Quit button immediately ends the program. The other two buttons allow the user to move down page by page in the captured virtual paper form that was printed by the 1053. Each page is 35 lines deep by 120 columns across. The output is printed in color and in landscape mode, filling the printer page. 

I included this in the github project as well as it will be useful to anyone who builds and uses the emulator. 

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

METHODOLOGY FOR OVERTYPING

Since the Putty terminal program does not combine the characters into a single composite, the original design was abandoned. The older design kept up to five characters buffered for each column, issuing the Zero Width Joiner character between them in a futile request to have the terminal program overlay the pixels into a single displayed character. 

The line buffer now saves only one character for a column or is zero if that column has not yet been type onto. Each time we perform at carrier return or line feed, the buffer is zeroed out again. When the 1053 backspaces, we move back to the prior column. The terminal program goes back and erases the column, so we retype what was saved in the line buffer.

When a character is typed at a column, the code looks to see if there was a previous character that had been typed there. If so, and only if the APL (988) typeball is being used, we will look for the eighteen cases where APL on the 1130 overtypes pairs of characters to form a composite. When we find a pair, in either order of typing, we replace it with the Unicode character that is the composite glyph. 

One pair in the table is for the ∇ (del) and ∣ (stile) characters, which combine to form the composite ⍒. Another example is the ∩ (cup) and ∘ (degree) which when overtyped form the composite ⍝ .

FINAL TESTING OF THE 1053 EMULATOR SHOWS IT IS READY FOR PRIME TIME

I put the emulator through its paces, testing as much as I could including many edge cases. As far as I can determine, this is working exactly as intended and ready to be used for any purpose as a substitute for the 1053 Console Printer. 

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.