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. 

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. 

Continued debugging of the 1053 Emulator - part 3

NEW MOSFET SWITCHING BOARD BUILT AND WIRED IN

I had verified using LTspice that the circuit behaves correctly and achieves everything I want. In this approach, the MOSFETs pass the voltage through to the 1130 circuit almost identically to how a mechanical switch would. 

It did add a transistor to each of the four switched signals, in order to switch the gate of the MOSFET to a voltage lower than the source. Resistor voltage divider on the gate circuit lets me dial in the voltage differential, to ensure that the MOSFET fully switches on the channel from source to drain. 

The new switches were built with P channel MOSFETS driven by an NPN transistor, plus a number of resistors. A quick check on the breadboard verified the behavior with the exact components, then I soldered this together on a perf board just like the previous one. After replacing the prior switch board inside the emulator, I was ready to test again.

Due to the high voltage on the switch for the -TWR CB RESPONSE signal, +48V, I had to use a high voltage NPN transistor, BD139, as the usual NPN transistors typically break down with more than 40V across emitter and collector. I had to wait for the part to arrive before I had the entire board completed and wired in place. I was mildly concerned that the transistors were from China, as there is the risk that this is a lower voltage cheaper transistor relabeled as a BD139. This is based on the high rate of chip fraud coming from Asia particularly through outlets like Amazon. 

HOPE TO CONVERT ONE OF THE CABLES TO A FEMALE SMS SOCKET

If the 3D printed part arrives in the next couple of days, I will convert one of the two signal cables from a male SMS paddle card to the socket I designed. This will match the polarity of the cables coming from the 1052 typewriter into the 1130. I won't need to wait to begin testing on the system, as I do have a gender changer/adapter temporarily installed. 

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. 

Developing SMS socket to connect to paddle cards

WHIPPING UP A FEMALE SMS SOCKET FOR THE BOX

I think I have a good plan for a female socket to plug into an SMS paddle card. I built some SMS signal paddle PCBs that I could adapt.

Using some 1/8" or 3/16" stock, I could cut some pieces and drill holes so they create a channel for the incoming SMS paddle card. Another larger plate sits on top of those side channels and creates the socket. Soldering some spring contacts on the pads of my PCB will allow good contact when the male paddle card is inserted. I could also add a block to stop the paddle card from inserting too deeply. 

I soldered some RF shield fingers as springy contacts - it wasn't a perfect job but they are all there with no shorts. Next I cut up some brass I had as the spacers and a plastic spreader as the top.

Very quick and dirty, but sufficient to test out the concepts and spacing. The brass spacers were .09" high and the tests I did shows that I need the space to be almost1/8" otherwise the contacts have to bend too much. However, by loosening the nuts slightly I could insert another SMS paddle card into this makeshift socket and verify connectivity for all thirteen pads. 

I have one additional spacing detail - I need grooves on the sides that are 2.2" apart. The SMS signal box in the 1130 into which the socket attaches has top and bottom rails separated by just over 2.2", thus the socket is held in place while in the system. 

Based on these tests, I will design a socket structure to connect with my SMS paddle card. It can be 3D printed fairly easily. 

I believe I can design a simple 3D printed part that can be attached with screws and nuts to form a socket, something cleaner than some scrap parts cobbled together. I will work on that but this temporary socket gives me an emulator box that can be long term loaned to the System Source Museum for use whenever the 1053 typewriter is out of service.