Discrepancy in logic diagrams and theory of operations documentation

FOCUSING ON TIMING OF SEEK CONTROL SIGNALS

The disk drive receives three signals from the 1130 disk controller logic:

• Access Drive (Access Go)
• Access 10-20 Mil Step
• Access Direction

The drive sends back a signal Access Ready that indicates when it can accept a seek request and shows the progress of the seek (crudely). Roughly, the Access Ready signal is true when the drive becomes ready and will switch to false about 5 ms after the seek begins, returning to true in a further 10 ms. 

The disk drive logic manuals describe Access Go as a brief pulse. Since it is inverted logic, -Access Go drops from high to low briefly to request a seek. The wiring diagram for the 1130 shows that -Access Go on the drive is directly connected to -Access Drive in the 1130 controller logic. 

The problem with the above is that the logic producing -Access Drive does not generate a pulse. It asserts the signal by making -Access Go low when the +Access Busy signal goes high at the same time that +Access Ready is high and -Full Word Count is high. 

The +Access Busy flipflop is switched on during an XIO Control (seek) instruction at time T6 as long as the count of cylinders to be traversed is not zero. The condition -Full Word Count is high when the cylinder count is non-zero, reaching zero when the final movement of the arm exhausts the requested number of cylinders to move. 

+Access Busy stays on for the entire length of a seek request, while +Access Ready turns on and off with each 1 or 2 cylinder step taken by the disk drive. That is because the drive only knows how to move 1 cylinder (10 mils) or 2 cylinders (20 mils), forward or in reverse. The +Access Go is sent to trigger each step, with the cylinder count decrementing until we complete the transfer such that -Full Word Count goes low. 

As long as +Access Busy is on (not done with the seek command) and -Full Word Count is high, we will repeatedly trigger the -Access Drive signal, each time it make the disk drive take another step. This happens because +Access Ready is high. When +Access Ready goes low in the midst of the step, it turns off the -Access Drive signal. 

The disk drive is causing the alternation of the -Access Drive signal is the feedback signal from the disk drive, +Access Ready. When +Access Ready is high, we retrigger the next step until the full word count (cylinder count) is reached. When +Access Ready is low, we reset the -Access Drive signal. 

The timing of +Access Ready from the disk drive has it go low about 5 milliseconds after the drive accepts a step request (i.e. -Access Go becomes low). It remains low for another 10 milliseconds then returns to high. The time to go low varies depending on whether this is a 10 mil (1 cylinder) or 20 mil (2 cylinder) step. 

If we issue an XIO Control (seek) for 7 cylinders total, the word count is set to 7 initially. The controller logic sees an odd count thus it initially requests a 10 mil step. The word count is reduced by 1 and the step size now reverts to 20 mil for all further steps. Thus the word count first drops to 6, then is decremented by 2 on each step until the count gets to zero where our -Access Go is no longer issued. An even cylinder count begins and continues with 20 mil step sizes. 

The timing chart for the disk drive has a brief pulse for -Access Go while we see from the controller logic side that instead it does low for about 5ms and then returns to high. 

The state of the +Access Direction and +Access 10/20 Mil Step signals is shown as changing simultaneously with the supposed -Access Go pulse. The notion of simultaneous is a bit slippery when dealing with signals in an 1130, where everything is a bit asynchronous and not based on clocked flipflops like modern designs. 

The +Access Direction signal is set or reset during the execution of an XIO Control based on bit 13 of word 2 of the Input Output Control Command (IOCC). That means at clock step T6 of the XIO step E1 the flipflop below is set and it is only changed at the next XIO Control, thus it remains constant through the course of an entire seek operation. 

The +Access 10-20 Mil Step signal is generated from the word count register - it is the same as the low bit (bit 15) of the register. During the XIO Control step E2, at clock time T4, the cylinder count is loaded into the word count register. 

The bits are inverted - thus a count of two (0000 0000 0000 0010) would load as (1111 1111 1111 1101). It looks at the B register (Storage Buffer Register) and when the bit is 0, the word count register bit is turned on. 

The very first time that -Access Go turns off during a seek, bit 15 is forced on. Thus, if the low order bit of the seek request - B bit 15 - was 1, for an odd count, the word count register starts off with its bit 15 set to 0 but after the first step it is forced to 1 and stays that way. Word count register bit 15 is interpreted as +Access 10-20 Mil Step, when it is 0, the step is 10 mil and after it is forced to 1 the step size is 20 mil. 

Thus, +Access 10-20 Mil Step will change when -Access Go is turned off, which is due to +Access Ready from the disk drive becoming false. It initially changes when the XIO Control command is being processed and then changes either once after the first step or stays constant for the duration of the seek command. 

HOW THIS MAY IMPACT MY FPGA LOGIC IN THE V2315CF

This compares poorly to the timing shown in the disk drive documentation, which implies that the direction and step size signals change simultaneously with pulses on -Access Go. My logic was based on the documentation for the disk, but I can see some weaknesses based on what I discovered and documented above. 

+Access Direction should be captured before the -Access Go signal goes low to start the timing of a step. I shouldn't see it change until the next XIO Control is issued. +Access 10-20 Mil Step will be set before the first -Access Go step and may change at the end of the first such step, before the next step is requested. I should capture the change while -Access Go is high and not change it until we finish a step of the arm. 

My earlier logic for the state machine looked for edges on the +Access Ready and -Access Go signals, but the logic of the controller moves grossly based on the ~5ms and ~15ms timing of +Access Ready. I don't know whether it is possible to get glitches on those signals, as their timing should move on a relatively glacial scale. I may slightly debounce them in addition to passing them through a metastability chain of flipflops. 

One final consequence of the way the logic functions is that when +Access Ready returns to high, the controller logic is going to be asserting -Access Go fairly quickly and I need to be ready to trigger off it. I am fairly certain that I already did this properly, but will double check. 

Running IBM disk diagnostic 309 against the Virtual 2315 Cartridge Facility - part 11

 MODIFYING DIAGNOSTIC 309

I first attempted to verify the values being loaded into core memory against the listing of the 2310B Function Test (diag 309), but found differences from the version I had documented. I then decided I had to put in a wait at an appropriate point in order to verify that the seek command is being properly set up. 

COLLECTING DATA ON FAILURES

Fired up the diagnostic program with it set to wait just before it attempts the seek to cylinder 199. This has been failing, stopping at cylinder 196 instead of 199. What I observed from the Input Output Control Command (IOCC), a doubleword pointed to by the XIO instruction, is that the count for the seek was set to 199 as it should have been. 

WHAT THIS RESULT SUGGESTS

Since the IOCC was correct but the drive didn't move all the way to the correct location, this hints at some interaction with the running code or the interrupt handler of the diagnostic, considering that a hand coded XIO seek to 199 performs correctly when executed in single instruction mode. 

DID MORE MANUALLY CODED SEEKS AND SEEING SOME ANOMALOUS BEHAVIOR

I did seeks to intermediate cylinder locations - 160, 180, 190, 200, and 197. In each case, I first did the seek forward from the home location (cylinder 0) and then did a reverse of the same distance. Mostly these worked properly, but I then hit some odd cases.

In one case, although I had set up a reverse seek to head all the way back to the home cylinder, the arm instead moved forward and then pushed on the stop at cylinder 202. In another case, when I moved all the way forward to be at the final cylinder the system no longer responded to seek commands in spite of the Seek lamp on the Virtual 2315 Cartridge Facility (V2315CF) box. 

WILL RE-EXAMINE AND RECODE THE SEEK LOGIC IN V2315CF

I now suspect malfunctions in the state machine in the seek to cylinder module of the FPGA logic. The non-responsive condition must be a stall in the state machine. Also, if it stalls in an intermediate state it might leave the direction signal in a previous state, causing the anomaly where the arm moved forward instead of in reverse. 

I will also think more deeply about the corner cases - making sure my logic will track properly. 

• when an XIO Seek is issued to back up but the arm is already at the home cylinder

• when moving forward from a high location more than the remaining cylinders

• when trying to move forward from cylinder 202

In real mode (the drive actually moves the arm as well as the virtual arm inside the V2315CF), the seek to cylinder logic is needed to shadow the position of the real drive arm, allowing us to know the current cylinder. This is necessary to feed or update the proper data from the virtual cartridge image, that intended for the cylinder.  

The real drive is the one responding with signals such as access ready to the signals such as access go from the 1130 disk controller logic. We sit in the middle and count the movements to maintain a cylinder number that should be synchronized with the real drive arm. 

Replaced circuit breaker on IBM 1130 +6V power regulator

WEAKENED CB TRIPPING INCORRECTLY

As I had determined, with the machine drawing less than 9A from the +6V power regulator, the CB will trip off when power is turned on if it was warm. I power up the 1130, run for a while, then when I want to turn off power for a short time before turning it back on, the breaker will trip off. 

+6V power regulator

FIRST TRY AT ORDERING REPLACEMENT CB FOILED BY VENDOR ERROR

I bought a 25A CB that is close enough to the one included in the regulator. When the shipment from Amazon arrived, I discovered a problem. The plastic package listed the product as a 25A breaker, but then breaker inside was a 10A unit. I returned it to Amazon and waited again for the correct breaker to arrive.

Replacement breaker

MECHANICAL FIT IN THE REGULATOR

The failing circuit breaker provides three additional terminals which are used to indicate whether the breaker is turned on or off. The IBM 1130 does not make use of these, thus the replacement breaker didn't need that. I removed the wires for the indicator from the breaker and the regulator terminal block at the other end. 

The replacement breaker is nearly the same size, but differs in its width, thus the two mounting holes are too close together to have both attached with screws. 

Test fit

I was able to mount the new breaker  in the same location, using one screw. It seems well enough anchored. I wired it up and replaced the regulator in the 1130 system. 

Ready to re-install

Failing breaker

TESTING ABILITY TO CYCLE 1130 POWER WHEN IT HAS RUN FOR A WHILE

I brought up the system and did some work on it, letting the regulator warm up. I then flipped off machine power, waited 60 seconds, and turned the system back on. The power cycle worked exactly as it should. Annoyance resolved. It was occurring often enough that it would have been intolerable at its home when attempting to show off the working 1130 system. 

Running IBM disk diagnostic 309 against the Virtual 2315 Cartridge Facility - part 9

ANNOYANCE - THE +6V REGULATOR TRIPS ITS CIRCUIT BREAKER WHEN WARM

There have been lingering problems where the circuit breaker on the voltage regulator module for the +6V supply will trip off as if it had overcurrent. This often happens when the machine has been running for a while, is shut off and then turned back on within a couple of minutes. 

I hooked wires to the load resistor inside the regulator which senses the full current flowing out of the regulator. It is nominally 0.072 ohms and the voltage drop across it should tell me the current being drawn out of the regulator. If it is 1.728V or less when the 1130 system is not drawing more than the 24A capacity of the regulator - that would indicate that the circuit breaker itself is weakened and needs replacement. If the sensed voltage is higher then I have to find the components drawing excess power and repair them. 

My voltmeter showed a consistent .607V drop across the resistor. I had verified that the resistor was just over 0.07 ohms using a sensitive ohmmeter, thus Ohms Law indicates the current being consumed by the 1130 system was fairly steady at just under 8.5 amperes. 

This tells me that the circuit breaker is very likely to be faulty. The regulator would need to be consuming more than 200W for the CB to be near its limit yet the system draw of 8.5A regulated to 6V is only a quarter of that. The regulator can't be that inefficient. The unregulated input power is a bit over 8V thus it should be in the 70% or higher efficiency range. 

I ordered a replacement - not an exact copy but should be able to fit it into the regulator in place of the original breaker. 

HALTED DIAGNOSTIC ON FIRST ERROR - DRIVE IS INDEED SEEKING TO 196

The diagnostic program begins by seeking backwards to the home cylinder, which is indicated by a microswitch on the drive that signals when the arm is at cylinder 0. It then issues a seek of xC7 - 199 cylinders forward. The seek ends with the arm stopped at cylinder 196 which is consistent with the data my V2315CF returns when a sector is read after the seek. This means we either have a controller unit logic defect in the 1130 or a diagnostic program error. 

DID A SINGLE XIO SEEK FROM HOME FOR 199 CYLINDERS

I then hand coded an XIO to seek 199 cylinders from the starting (home) position. In this case, the arm correctly stopped at 199, not 196. I have to validate that the diagnostic program is issuing the correct XIO seek command. I will load the program into core and then stick in a wait instruction right after it has prepared the IOCC for the seek and before the actual XIO is issued. 

I can examine what was generated and then let the program continue to issue the seek and evaluate the outcome. This should permit me to point the finger of blame at diagnostic or controller logic. 

Running IBM disk diagnostic 309 against the Virtual 2315 Cartridge Facility - part 8

TESTING IN REAL MODE

With the V2315CF set to real mode, the 13SD disk drive inside the IBM 1130 runs and participates in the disk activity along with the V2315CF. With a virtual cartridge loaded into the V2315CF and any old physical 2315 cartridge loaded into the 13SD, flip the motor power switch on to spin up the drive. 

Once the disk drive finished its 90 second purge of dust from within the spinning drive, the File Ready lamp on the 1130 main console lit up as well as the RDY light on the V2315CF box. The 13SD drive believes it has lowered the heads onto the surface of the spinning platter, but they remain safely above. This made the disk ready to be accessed by the diagnostic or any other program on the 1130.

INITIAL FAILURE TO RUN TRACKED DOWN TO A BROKEN WIRE

When I began to test, the 1130 never indicated that the drive became ready. The FILE READY lamp should have illuminated, as well as the RDY light on the V2315CF box. I did hear the solenoid on the disk drive click on to load the heads down, which should have sent a signal -File Ready from the drive to the V2315CF and onward from there to the 1130. 

A quick check with a continuity tester identified the wire which carries that signal was broken in the cable. After a bit of work, the connection was restored and the drive ready state would recognized by the 1130. 

TESTING RESTARTED

The diagnostic moves the disk arm around first to verify the behavior of the Home (cylinder 0) detection and correct arm movement. Once it backed up to the home cylinder, it executed a seek to cylinder 199 but based on the data read back from the V2315CF, we believed we were at 196. A second attempt to move to 100, by seeking 3 cylinders forward, retrieved data from cylinder 197, but after that the system did sync up at 199. 

Test routine 2 began, which would perform patterns of seeks such as two cylinders forward, one cylinder back, each time reading a sector to verify the proper location was achieved. At some point during this test, the diagnostic issued a diagnostic complaining that after it issued an XIO instruction, the disk drive device status did not indicate a busy condition, just a not ready status. 

Shortly thereafter the diagnostic reported that a completion interrupt never arrived. This caused the diagnostic to terminate. My analysis of this is that the controller logic set the drive to not ready status, as if it had been switched off manually. The next XIO attempt would produce exactly the symptoms detected by the diagnostic. 

I don't know why the disk went off line like it did, but I will work out a test plan to track down the cause. Further, I have an easy way to point the blame for the initial seek failures, by setting the diagnostic to halt on the first error. Thus when it attempts to seek to cylinder 199 and receives data from cylinder 196, I can compare the disk arm in the physical 13SD drive to both of the reported locations. 

If the disk is at 199, then the failure is in my V2315CF. If the drive is at 196, then the failure is in the IBM 1130 disk controller logic or in the drive itself. 

Very sporadic parity errors - need to capture evidence to find and fix

TYPEWRITER DIAGNOSTIC RANDOM PARITY ERROR WITH BIT 10 FALSELY DETECTED

I snapped a picture of a parity error stop that popped up randomly while the typewriter diagnostic was running. The 1130 was fetching the next instruction to execute from location x0258, which you can see from the Storage Address Register (SAR) in row 2. The process of fetching the instruction causes the Instruction Address Register (IAR) in row 1 to be bumped up by 1, which is why it shows x0259. 

The data read from memory is in the third row, the Storage Buffer Register (SBR), with xC220 showing. Looking at the listing for the diagnostic monitor running the typewriter diagnostic, at location x0258 is a LD 2,0 instruction - load from the address in index register 2 plus a displacement of 0. This would be xC200 but we have bit 10 turned on incorrectly. 

Each half of the memory word has its own parity bit which is set so that the total number of 1 bits in the half of a word plus that parity bit must be an odd number (odd parity). The left half has bits 0, 1 and 6 turned on, an odd number, so parity bit P1 is off (middle section of the display panel). The right side shows bit 10 on (the error) which would be an odd number of 1 bits put the parity bit P2 is set - triggering the parity stop. 

When the data in that location was originally being written as xC200 the right halfword had no bits set thus it needed parity bit P2 set to achieve an odd total. Somehow the data read back had bit 10 also set to 1. This could happen in the write or during the read. Alternatively, something else can inject a 1 bit at the time that the read is occurring in spite of the data from memory bit 10 coming back as 0.  

When originally written, the parity bit P2 is set but some error in the core memory might stick in a 1 in bit 10, because bit 10 is not inhibited to store a 0 value.  Core memory cycles always have a read phase followed by a write phase. Any bit that has a 1 value will cause a sense pulse during the read.

DETAILS OF THE MEMORY AND SBR CIRCUITRY

During read, all cores in the word are flipped to zero and any that had previously been set to 1 cause a pulse to come out of the sense amplifiers and into the SBR register. During write, any bit that should remain a 0 has a current passed through the inhibit wire, otherwise it will be flipped to 1 during the write phase. 

Failures in the inhibit or sensing function of core memory might cause the random false 1 bit to appear. 

Parity checking and setting are done with the SBR register. The SBR is the source of data for the inhibit wires during a write phase. It is the destination for sense pulses during a read phase. 

In addition, the structure of the SBR register circuitry has a number of pulses that could set bit 10 to a 1 value. These include transfers from the IAR register, from input output devices during XIO instructions, from the Accumulator (ACC) register during address computations, and the sense pulses coming for a read phase in core memory. A possible failure would be no sense pulse but one of the other pulses incorrectly arriving to set the SBR bit 10 to 1. 

SETTING UP A LOGIC ANALYZER TO CAPTURE AND FREEZE AT A PARITY STOP

I chose to use my DS Logic USB based logic analyzer to try to capture the cause of bit 10 being incorrectly set to 1. I only have 16 channels on the device so I can't record all relevant information - contents of the full 16 bit SBR, the 13 bits of the SAR that address the 8K of memory, as well as the pulses going into the SBR to set any of the 16 bits. 

I therefore will hope that these sporadic errors are always a falsely hot bit 10 and set up the signals to determine when/how that is occurring. I will monitor the parity stop flipflop and trigger the analyzer to stop when it is set. The trigger will be placed at the end of the buffer so that I can watch the signals that led up to the error. 

The IBM 1130 uses many asynchronous pulses, not aligned with the clock edges, which includes the sense pulses and the various pulses that set the SBR. I thus can't use a traditional logic analyzer mode that records the state only at a common clock edge. Fortunately the DS Logic analyzer can record such unclocked signals. It can also deal with the 0 and +3V signal levels of an 1130 system. 

IBM 1130 typewriter (console printer) repair and adjustment - part 12 - completed!

FREEING UP THE CYLINDERS ON THE SCREW LINKS

I pulled out my Nye clock oil and applied it to the screw link and hollow metal cylinder around it that was binding on certain tab and carrier return solenoid activations. After moving the cylinder and link by hand many times, I ensured that everything was moving freely as it should.

RERUNNING DIAGNOSTIC AND SEEING PROPER BEHAVIOR ON THE TESTS

I ran the diagnostics to get a complete clean run as a proof that the console printer (typewriter) is working properly.

I was happy with the results and could consider the typewriter to be back to operating condition. 

REINSTALL IN THE MACHINE

I had to remove the front panel of the typewriter to reattach the CES (console entry switches) subassembly. The front panel was then placed back on the typewriter and all the covers put back in place. This involves detaching and reattaching the tab set/clear pushrod. 

The signal and power lines run through one heavy cable that I had to route down through the machine as I sat the typewriter on its stand atop the 1130. The cables were re-plugged into the SMS signal and power connector blocks.

You can see the heavy grey cable wrapped around the usage meter block and then routed downward towards the SMS connectors. I then put the bottom cover on the typewriter in preparation for its placement back on the 1130 system. 

Ready to reinstall

The typewriter was nestled back in its normal position, below the console light display pedestal and behind the keyboard. A quick check showed that the typewriter was working. 

I can now get back to my Virtual 2315 Cartridge Facility checkout, because I can see the output of the diagnostic programs on the console printer. 

IBM 1130 typewriter (console printer) repair and adjustment - part 11

TEST AGAIN WITH DIAGNOSTIC

I loaded the console printer/keyboard diagnostic into core memory and began its execution. This runs through several routines to test the printer as long as the Console/Keyboard switch on the 1130 console is set to Console. It prints each in black first, then in red:

• Carrier Return typed at left and Tabulate typed at a selected tab stop
• shifted to lower case and typed all 44 characters
• shifted to upper case and typed all 44 characters
• printed one row first typing +, then backspacing and printing a 0
• tabbed to the stop, backspaceed, then printed BACK SPACE
• printed INDEX by tabbing and typing one character per line for form vertical word
• returned, typed CARRIER RETURN, then spaced to activate the automatic return at end of line
• for each rotary position (column of the typeball), printed the row in sequence from tilt 0 to tilt 3
• for each row of the ball, printed all 11 characters in sequence from -5 to +5
• printed characters selected to have maximum change in tilt and rotate between each letter

The goal is to have the output appear as below (other than seeing black and red color):

OBSERVATIONS OF THE DIAGNOSTIC OUTPUT

The diagnostic expects a single tab to be set at column 40 to achieve the output shown above. The instructions from my copy of the diagnostics manuals asserts column 20 instead. 

The output of most of the tests was perfect, but I did see a couple of cases where movement functions didn't trigger properly. 

In the test segments above, the lower case side of the typeball missed a carrier return before it printed the row in red ink. It then successfully did the following test,  typing 0 and asterisks in a pattern involving spacing and backspacing, which stresses the alignment of the carrier rack and precision of the space and backspace movements. However, the next test, which should have proved out line feed and backspacing, failed. 

The failure was the lack of the initial tab movement, after which it should have backspaced, typed E, backspaced twice, typed C, backspaced another two times and typed A, and so forth, to spell out BACKSPACE in reverse from the column where the tab stopped. Similarly, it should have tabbed and did a line feed before typing each letter in INDEX. 

I reran the test but tried to hit the TAB button on the front of the typewriter to force it to take place. I didn't get it perfectly but you can see that I got part of BACK SPACE to print showing how it should look if tab had occurred. 

The remaining tests all worked properly - proving out the automatic carrier return/line feed when the carrier passes the end of line setting, then printing characters in three stressful patterns termed rock, roll and twist. It provides that character selection when typing is working right even in the most difficult circumstances. 

SUSPECTING STALE LUBRICATION IS CAUSING THE SPORADIC TAB AND CR FAILURES

When I first freed up the tab function, I had to manually rotate the hollow metal cylinder that should move freely on the screw link between the armature and the tightening nut. It worked properly for a while and then failed again during the backspace/index test. 

I had flushed out the old lubricants during the entire restoration to get the typewriter working properly. The oil turned to gum plus it absorbed dust to further solidify. I had to use extremely thin clock oil to seep under the solidified stale lubricant then move each part to get it freely moving. 

I suspect that stale lubricant in the hollow shaft of the metal cylinders is causing sporadic binding. I will have to carefully flush these out to make them slide up and down without resistance. 

Scope on typewriter feedback signals to verify timings and adjustments of the typewriter

BACK AFTER EXTENDED ROAD TRIP

I have been away from the shop for two weeks while my wife and I visited relatives and friends in Myrtle Beach South Carolina and Wilmington North Carolina. Along the way we spent a few days visiting Savannah Georgia for sightseeing. A quick jaunt to Raleigh North Carolina to visit a bar famous for elaborate Bloody Mary drinks rounded out the journey. 

UNUSUAL DIAGNOSTIC CODE RAISED QUESTION ON TIMING

The new version of the typewriter diagnostic combines more than one movement command for the typewriter into a single output instruction (XIO Write), something that isn't discussed in any of the 1130 system manuals or that I have found in any other programs. This combined movement might result in a momentary rising edge on the -Twr CB Response signal before it drops again until all movements were complete. It might cause a falling edge on the +Twr CrLfT Interlock signal in the midst of an operation. If either happens, the edge would trigger a premature completion of the operation, allowing a new XIO Write to be issued while the mechanisms in the typewriter are still in motion.  

FEEDBACK SIGNALS ON THE TYPEWRITER

The two feedback signals are implemented with strings of microswitches. Some movements, such as spacing or backspacing, activate a single switch. Carrier return and tab movements are not only long operations, but vary in duration based on how many columns are traversed. Therefore, each of those two types have a pair of microswitches that overlap to cover the entire duration of the movement. If the pair of microswitches are not properly adjusted, they might open a brief interval where movement appears to have completed, leading to issues when a program issues a new XIO Write prematurely. 

The -Twr CB Response signal is formed with three microswitches in series. One covers the Space/Backspace/Tab operational clutch, the other two cover typing one character and shifting between upper and lower case hemispheres of the typeball. When any activates, the signal drops to 0 and then rises back to +48V when the switch closes. 

The +Twr CrLfT Interlock signal is formed by four microswitches in parallel. It rises to +12V when any switch is activated and drops back to 0 when none of them is turned on. One switch covers the 360 degree rotation of the CR/Index operational clutch, during the time that this either latches up a carrier return or moves the platen in a line feed. Another switch covers the latching of the tab movement during the 180 degree rotation of the Space/Backspace/Tab operational clutch. A third switch is on the latched carrier return mechanism, so that from the time it begins moving leftward until the latch is released by striking the left margin, the switch is active. Finally, a switch covers the movement part of a tab. Tab movement continues for a variable number of columns, between the start point and the next set tab stop, so it has a microswitch that turns on as the carrier begins to slide rightward and turns off when it comes to a stop.

INVOLVEMENT OF SWITCHES IN MOVEMENTS

With the paired commands, there can have more than two switches involved. For example, if a backspace is combined with a carrier return, three switches participate and both signals send status. With a simple operation like typing a character, only the -Twr CB Response will be involved.  

Since Carrier Return (CR) movement continues depending on how many columns it has to pass while moving, two microswitches control the +Twr CrLfT Interlock signal.  The reason that a CR has a pair of microswitches is that we have one mechanism that is busy during the 360 degree rotation of the CR/Index operational clutch, which is the time needed to latch up the CR mechanism and then the second switch is active until the latch is released. 

 The reason that Tab has a pair of microswitches is that we have one mechanism that is busy during the 180 degree rotation of the Space/Backspace/Tab operational clutch. That covers the time needed to latch the pawls out of the way so the carrier can slide rightward. The latch of the pawls sets the second microswitch, so that it is only when the latch is released by banging into the set tab stop that we turn off that switch. 

There is a switch on the Space/Backspace/Tab operational clutch, which participates in the -Twr CB Response signal, but another microswitch on the linkage that sets the tab latch. The second switch participates in the +Twr CrLfT Interlock signal. Thus during a Tab, both signals are active but start and stop at different times with some overlap. No other operation on the typewriter affects both signals - they activate one or the other depending on the operation type. 

SCOPE OBSERVATIONS

I set up a manual XIO Write instruction to trigger the different movement commands, both individually and in the combinations seen in the diagnostic code. For each I observed the feedback signals on the oscilloscope. I compared those to the expected signal shape for each operation to identify where there are any switches that are maladjusted. 

I found that the individual write commands were working as expected for most movement types, but that the tab and space movements were not activating on the typewriter. The feedback signals were correct for all the working movement types. I didn't initially try the combined movements from the diagnostic as I wanted to get the individual types all working correctly before doing any combinations. 

The yellow trace is the XIO Write to the typewriter of a carrier return movement, the blue trace is the busy condition signal and the purple trace is the +Twr CrLfT Interlock signal showing that the return movement is underway. By comparison, an XIO Write for a tab or space showed busy but neither the purple +Twr CrLfT Interlock nor the green -Twr CB Response signals move at all since no motion took place. 

INVESTIGATING FAILURE OF TAB AND SPACE COMMANDS

The circuits from the 1130 controller logic to the typewriter solenoids were observed. Each will be at +48V until the relevant XIO Write value pulls a solenoid line to ground. This should cause it to pull down on a trigger and activate the typewriter movement function. 

I saw the lines pulled to ground for both of the solenoids, yet the movement didn't trigger. One other thing I noticed was the duration of the grounded line to the solenoid was longer than the working solenoids such as carrier return. Of course, the feedback signals didn't change since the typewriter mechanism was not triggered to perform the tab or space. The difference in duration may be caused by the feedback signal arrival which might terminate the solenoid action; no feedback thus no termination. 

CHECKING OUT SOLENOID ACTION FOR SPACE AND TAB

I set up to watch the solenoids when I attempted to write a command to tab or space. I want to find the cause of the failure to trigger the movements. There are several possible causes, with the resolution depending on exactly why the motion is not triggered.

The movement starts with a trigger that releases the left operational clutch which rotates 180 degrees before latching back to a stop. The left clutch powers the space, tab and backspace movement functions. A right 360 degree clutch powers carrier return and line feed movements. 

The release of the clutch to allow it to turn is due to a trigger lever. 

The left operational clutch has three trigger levers, one each for tab, space and backspace. These trigger levers can be moved by two different types of mechanisms - pushbuttons and solenoids. On an ordinary Selectric typewriter, a third mechanism based on keylevers is used instead. The pushbutton on the front of the console printer is connected via a cable to trip the trigger.

The trigger is also pulled down to activate the clutch by the operation of a solenoid. When it is energized, the armature pulls down on a screw link that moves the trigger. 

Thus, the failure of the tab and the space triggers to activate the left operational clutch could be caused by several causes. The solenoid might be mechanically jammed and thus not move its armature down. The screw link might not move the trigger down far enough to cause the operational clutch to release. The cable from the pushbutton might be holding the trigger up so that the solenoids pull doesn't result in enough trigger movement to trip the clutch. 

We know that the pushbuttons are triggering the tab and the space functions. We know that the backspace command from an XIO Write will trip the clutch and cause a backspace. What is failing is XIO write to request tab or space. I therefore watched to see what the solenoid activation did on this machine. Did the armature move? Did the screw link pull the trigger down? Is the cable from the pushbuttons stopping the trigger from moving down to trip the clutch?

ADJUSTMENTS MADE TO CORRECT THE ANOMALIES

Having found the root cause, I worked on a fix. It was important that both pushbuttons and solenoids worked for the two movements in question - tab and space - so I had some checking to do after each change. 

The magnet unit above supports tab, backspace and line feed at the top row, space and carrier return at the bottom row. The armatures are arranged to form a line across the middle, with screw links up to the triggers for the tab, space, backspace, carrier return and line feed in that order left to right.

The screw links were adjusted to allow the armature to start moving before it pulled on the trigger yet move far enough to ensure it did trigger. That worked for the space function but I still had issues with the tab. 

The screw link passes through a hole in the armature, then there is a metal cylinder under the armature and surrounding the screw link. Finally a nut at the bottom adjusts the length of the screw link. The metal cylinder has a gap on each side - armature and nut - which allows the armature to get up to speed before it starts pulling down on the screw link .

I adjusted the screw links for the two solenoids that were malfunctioning until they seemed to be reliably triggering. I did find interactions with the pushbuttons, so that I had to reset those adjustments with the front panel in place on the typewriter. 

Finished checking and fixing up the diagnostic load file

FOUND ALL THE DIFFERENCES TO THE LISTING

I ended up with quite a few words that didn't match, although most of them are consistently different because of some corrupted test sequences towards the end of the code. Since the test sequences were a bit longer the address of data at the end of the program shifted, thus any instructions that referenced these locations did not agree with the listing. 

In addition to all the differences based on the shifted locations near the end, there was a single word that was incorrect - the value that caused our spurious error message. However, it was not just a matter of shifted locations for everything else. Some of the test sequences to be typed were alternatives to the code I discovered but seemed like it would accomplish the same purpose.

ALTERNATIVE TYPING SEQUENCES

The first deviations in test sequences began in the middle of the Backspace and Index test. This test begins by issuing a tab, then types backspace in reverse backing up from the tab column, then does a tab and types index with a line feed and backspace between each character so that it appears vertically on the page. 

The code I have in the file issues a character code that combines more than one control function in the same character, which isn't defined as valid in the programming documentation. Every control function has the low order bit set to 1. The other bits define which control function:

• 81 - carriage return
• 41 - tab
• 21 - space
• 11 - backspace
• 09 - shift to black
• 05 - shift to red
• 03 - line feed

Note that the functions above are a single bit set plus the low order one. My listing for the diagnostic accomplishes the index part of the Backspace and Index test by issuing an 11 then an 03, to backspace then linefeed. The load file has a single control character 13, which seems to combine the backspace and the line feed into a single command. 

Because the load file combines these commands, it is shorter by three words. That displaces all the sequences that follow (Auto Carrier Return, Rock, Roll and Twist) plus all the data and code that follows the sequences. One word was added to a data table, which consumes one of the three words that was gained by compressing pairs of movement commands into a single hybrid command such as line feed plus backspace. 

CORRECTED LOAD FILE FOR SINGLE CORRUPTED WORD

Since the typing sequences and related address shifting appear to be an intentional update made by IBM in order to fit a change in the same diagnostic test footprint, the only difference that seemed to matter was the constant for the desired Device Status Word (DSW). After the typewriter is commanded to type a character with an XIO Write instruction, while the mechanical operation is underway but before it completes. an XIO Sense Device should return a DSW that has both the busy and not ready bits set. The constant should have had both bits turned on, but it instead only had a bit for busy status. 

NEXT STEPS

With the file corrected, when I next arrive at the workshop I should be able to run the diagnostic without receiving the false error messages that were caused by the corrupted constant. I have some things to do that will delay my next visit to the shop, but once I am able to return I will load the fixed file and try out the typewriter.

I do have questions about the unorthodox combination commands that mix more than one movement command in the same XIO Write instruction. The reason I want to look closer is because the controller logic is sensitive to two feedback signals coming from the typewriter, which are -Twr CB Response and +Twr CrLfT Interlock, both of which are produced by multiple microswitches. 

Two of the typewriter movements, tab and carrier return, are variable duration events which depend upon pairs of microswitches to properly cover the entire duration. If the adjustments aren't correct, we could see a spurious edge on the signal that convinces the controller logic that the movement is complete even though the signal goes back to busy for additional time. 

I will put the oscilloscope on the two feedback signals and watch what occurs with the combination movement commands, hand coding an XIO Write to trigger the movement. If anything looks wonky, I will know the microswitch(es) to check and readjust. 

More on the errors with the console printer (typewriter) diagnostic

USED SCOPE TO VERIFY THAT NOT READY AND BUSY ARE PRESENT

I could clearly see that when an XIO Write was issued to the typewriter, both Busy and Not Ready activated at the same time and for the appropriate duration. I traced the Not Ready signal to every location in the machine just to satisfy myself there was no issue with the DSW. 

RAN DIAGNOSTIC AGAIN, THE SAVED DSW WAS CORRECT BUT ERROR PRINTED

Indeed, after an XIO Sense Device the Accumulator (ACC) had bits 3, 4 and 5 set, which stand for Console/KB switch set to Console, typewriter busy, and typewriter not ready, respectively. This is correct. 

The diagnostic printed error E0402 which indicated that our status was not correct. The text in the documentation suggests that the busy status was wrong, but it was just poorly worded. Nor was the Not Ready status wrong - as we just verified. The error message should not have been printed. 

STEPPING THROUGH TESTING CODE, I FOUND A CONSTANT WAS INCORRECT

The code involved in this producing this error message had immediately issued an XIO Sense Device after it did an XIO Write to type a character. I saw it apply some bit manipulation then check to see that the saved DSW matched the archetype for a correct status. However, the word with the archetype status, which should have held x0C00, was instead 0x0800. This was triggering the spurious error message. 

I did a quick update of that word to the proper value, reran the diagnostic and, miracle of miracles, the error message was no longer emitted. However, if there was one corrupted value, there may be more. 

COMPARING DIAGNOSTIC ASSEMBLY LISTING AGAINST CORE FILE

I began to check the value of each word in the file I load into core to run the diagnostic, comparing it to the printed listing of the diagnostic program. This is time consuming. So far, I have found the one error word that caused the erroneous error message, but also see that the address of one routine near the end of the listing is off by two words. However, every other word so far has matched perfectly. 

As I finish the cross check, I can clean up my diagnostic program file so that it will be loaded exactly as intended by the authors at IBM and therefore should run flawlessly. 

Substitute relay arrived for 2501 card reader, tested and installed

RELAY R3 HAD AN OPEN COIL THUS REPLACEMENT NEEDED

The power supply box includes a function to keep the main motor of the card reader running for 15 seconds after the 2501 receives its last read or feed request via an -execute command signal. Relay R3 latches every time -execute command arrives but the voltage across the coil declines based on an RC circuit until about 15 seconds have elapsed, when the relay coil is no longer able to hold the connection. 

The contacts of relay R3 send a signal -motor hold sw back to the 1130 system's controller logic, which uses it to maintain or drop the -motor relay command back to the reader. If this isn't working, the motor will shut off instantly after every card is read, which is hard on the motor and disruptive to the process of reading. 

EXACT PART NOT AVAILABLE BUT LOCATED A RELAY THAT SHOULD WORK PROPERLY

The Sigma part number did not come up in any online search, but there were many similar relays from Sigma that I could choose from. I looked for the critical specifications to get as close to the original relay as possible. This included the voltage and current rating of the contacts, the voltage for the coil, the DC resistance of the coil and factors like the drop out voltage. 

The original relay had contacts rated for 2A of current, but that is extremely far above the actual signal currents used in the 2501 and 1130 system. Thus, a 1A part was very suitable. The voltages for the contact, coil, and coil drop out were identical. The resistance of the original relay was 10K but the part I found was 9K. 

The final difference was the mounting method - the hole locations and shape of the mounting foot. I will have to adjust for the difference to install this new relay into the power supply box. 

CONNECTED AND TESTED ON THE WORKBENCH

I connected the power supply box to my 220V step up transformer and used some resistors and jumpers to simulate the control signal -execute command to trigger R3. My VOM was hooked across the contacts of the new relay to let me hear the duration of the relay actuation. The circuitry around the relay includes a potentiometer where I can fine tune the time duration, which should help me compensate for any differences due to the substitute relay.

The relay activated cleanly when the control signal was given. The relay opened up after 5.5 seconds. Based on that, I began adjusting the potentiometer but the max delay I could achieve was around 7 seconds. 

I experimented changing the resistance of the time adjustment leg - the potentiometer plus a 10K resistor - to see if I could lengthen the hold. Even with an infinite resistance, the relay held for 13 to 16 seconds, varying a bit, which I deemed close enough to proceed. The specification for motor hold time is 15 seconds +/- 3, therefore we are within the proper range. 

The potentiometer and related resistor are out of the circuit. The relay coil appears to be draining power faster than the original did, or it has a higher drop out voltage, or both. An alternative solution would be a larger capacitor in the timing circuit, which would accommodate the higher current flow and lower its voltage at a slower rate. However, since the unit performs adequately now, I won't pursue this alternative.

MODIFIED MOUNTING METHOD TO INSTALL INTO POWER SUPPLY BOX

The original relay had a rectangular plate on the back with holes near the top and bottom. The new relay has a different shape and hole pattern, thus I had to take off the plate from the old relay, drill out a hole and use a screw to attach the new relay to the plate. 

READY TO PUT POWER SUPPLY BOX BACK INTO 2501 CARD READER

The lower compartment of the 2501 card reader holds the power supply box, a card cage for the SLT circuits and the connectors used to connect cables to the 1130 system. The power supply box fits in the compartment using slots in the box that match mounting hardware in the 2501.

A flat rail runs across the top of the compartment, from front to back. Slots in the top of the power supply box allow it to fit over the rail, with enough room in the slot to move further upward than its final mounting position. 

That permits the bottom of the power supply box to be swung over the top of a rectangular rail that sits across the bottom of the compartment, running from front to back. Square cutouts on the bottom of the power supply box allow the box to settle down onto the rail. This suspends the box from moving side to side in the 2501. A bolt goes through the bottom of the power supply box to lock it down in position on the bottom of the 2501 compartment. 

Once I do this I will be reconnecting all the cables and wires I had to disconnect in order to move the power supply box to the bench for testing and repair. 

Oops - error in test code thus troubleshooting the wrong problem

MY HAND CODE TO TEST THE DSW AND SAVE IT WAS DEFECTIVE

The error messages from the diagnostic were described as indicating the failure of the typewriter to appear busy during an output operation. The hand code was intended to save the Device Status Word (DSW) immediately after a character was output, with the result saved matching the character code of the letter I typed rather than a valid status.

Based on that I was down a rabbit hole trying to imagine a failure scenario that would place the character code in the accumulator register (ACC) after a sense DSW. It was quite unlikely which meant that I didn't have a good starting point to test signals to eventually locate a fault. 

Imagine my embarrassment when I began to execute the code in single cycle mode to see exactly how the XIO Sense Device was working. I noticed that I was saving the ACC at the wrong time, just after I typed the letter with XIO Write, not after the XIO Sense Device. Thus the value I saved was in fact reasonable and consistent. Unfortunately, it was not an indication of what might be wrong in the diagnostic!

ACTUAL ERROR DISCOVERED BY LOOKING AT DIAGNOSTIC MEMORY LOCATIONS

I pulled out the listing of the diagnostic program and found the point where it was writing the error message. The code showed me a location where the DSW had been saved before it was checked doing an exclusive OR with the value x0C00 and requiring the result to be all zeroes. Those two bits in the DSW are busy and not ready, respectively. 

The busy bit was on, as it should. The not ready bit was not set. My DSW was x0800 but had to match x0C00 for the test to pass.

NOT READY SHOULD GO ON AT THE SAME TIME AS BUSY

The architecture of the IBM 1130 specifies that the not ready bit is turned on by multiple things, one of which is a busy condition. It is also set when the typewriter is out of paper (Forms Check lamp is lit on the 1130 console). In the past this had worked properly, so the diagnostic error was new, popping up sometime while I was doing the last round of typewriter adjustments. 

Since it had occurred immediately after I changed things on the typewriter device, the likely cause was something wrong in the typewriter itself. Once I watched the typewriter perform properly I turned my attention to the typewriter controller logic inside the IBM 1130. Sadly I read the error as indicating that the busy bit was not turning on. This bit turns off once the operation is complete and the controller logic requests an interrupt from the processor. 

I then set up a defective program to look at the DSW to check for busy right after the XIO Write but before the interrupt was requested. Based on a flawed test, I was chasing a false error scenario in the controller logic. Armed with the actual situation that triggers the error message in the diagnostic, I can start testing the portion of the 1130 that is involved. 

NOT READY STATUS LOGIC

There is a small amount of logic and connections involved in turning on not ready while the typewriter is busy. This all begins when the typewriter turns on its busy flipflop, during the XIO Write instruction, step E1, at clock time T6. That signal stays on until the rising edge of the -Twr CB Response signal from the typewriter. 

At this time, the busy flipflop is turned off and the operation complete flipflop is turned on. The request for an interrupt on level 4 is raised whenever operation complete is set. A subsequent XIO Sense Device with bit 15 set will clear the operation complete flipflop, stopping the request for an interrupt. This normally is issued within the interrupt request handler code so that when the interrupt handler exits, we don't immediately jump back in due to the active request. 

-Twr CB Response is created by a chain of microswitches in the typewriter, all of which are normally closed. When one or more of them opens, indicating that a mechanical operation is in a sensitive portion of its cycle, the signal drops to logic 0. Once that protected portion of a cycle is finished the switch closes again, creating the rising edge back to logic 1 state. 

Since we are receiving the interrupt request we know that the rising edge is detected. We know from looking at the DSW after the interrupt that the busy bit is not on. I know from the stored DSW in the diagnostic that the busy bit was set while the typewriter was outputting the chosen character. 

The signal -Twr Not Ready is generated by the logic below:

As you can see, it is very simple. On the left, the End of Forms microswitch is debounced and is an inverted logic signal -Twr End of Forms. The -Twr Busy signal is also inverted. 

If both of them are logic high, thus we are not busy and we don't have an end of forms, then the signal +Twr Not Ready is generated as logic low due to the rules of a NAND gate. If either condition is true (logic low) then we raise the +Twr Not Ready signal that goes over to produce the DSW bit 4. 

Also, if we have a logic high on this generated +Twr Not Ready signal and at the same time we are not busy (logic high on -Twr Busy) then we drive the -Twr Forms Check Lamp line low to light the bulb. This means that the lamp doesn't actually go on while we are performing a typewriter mechanical operation, waiting until the completion. 

For example, if the carrier is near the right margin and a carrier return is requested, when the platen rolls up one line, we might have the paper end leave the End of Forms microswitch. The lamp doesn't turn on until the carrier has finished its move to the left margin. Presumably an eagle eye could spot that sequence of operations, but it seems to be a unnecessarily sophisticated implementation of a warning lamp. 

Finally the signal -Twr Busy that we are combining to produce the -Twr Not Ready condition comes from this logic:

The Twr Cycle flipflop is turned on by the combination of XIO Write, Area 1 (typewriter address) and time T6, as long as the typewriter is not busy. The busy signal arms the edge detector which fires off a set pulse when we exit T6 in an XIO Write to the typewriter. The flipflop is turned off when the signal +Twr Interlock Latch drops as long as we are not in a shift cycle, since shift cycle conditions the edge trigger. 

When the typewriter needs to shift between the upper case and lower case hemispheres of the typeball, it converts the request into a sequence of two typewriter actions. First, a shift is fired off. When that is complete, we then fire off the character type command. 

The interlock latch is on while mechanical action is underway and will turn off after the shift and again after the typing of a character. We don't want to turn off the print cycle after the shift, only when the actual typing is done. 

Our busy condition is formed with a NAND gate, turning on if any of three signals are true:

• Twr cycle flipflop is set
• We detected the end of line microswitch on the typewriter
• The interlock latch is on due to mechanical motion

Since this output is an inverted logic signal, -Twr Busy, it is logic low when on. That feeds directly to the logic producing the +Twr Not Ready signal (see diagram). 

Now that we see how the two signals, -Twr Busy and +Twr Not Ready, are produced, we look at the logic which presents +Twr Not Ready as bit 5 of the DSW.

When we have an XIO Sense Device for Area 1 and the +Twr Not Ready signal all at logic high, we set DSW bit 5 low (which produces a 1 in the DSW). 

All of the logic involved is on gate A, compartment C1 of the 1130, which eliminates any compartment to compartment cables from suspicion. We have just a few gates that might be malfunctioning. The only other possibility is a broken trace on the backplane of compartment C1, which is very unlikely. 

Potential bad gates include:

• A C1 C2 D07 output producing the -DSW Bit 5
• A C1 E5 D04 producing +Twr Not Ready

The correct operation of the logic producing the interrupt request and good status for busy eliminates any other gates in the machine from consideration. 

OSCILLOSCOPE PROBE OF HAND CODE TO WATCH NOT READY SIGNAL

This is a very simple test - trigger the scope when the busy condition is produced at A C1 D4 D04, on the falling edge. Watch the two signals above to see if they are generated appropriately. Based on that, test the gate in question, find the bad component and then fix it. 

Debugging issue with XIO Sense DSW - part 2

GATING ONE REGISTER TO ANOTHER IS A BIT COMPLICATED

The terminology suggests that you will get an exact copy of the source register in the destination register, but the reality of the circuitry is important to understand. Gating into a register involves IBM's edge sensitive gates, which produce a pulse to set a flipflop for the bit. This pulse sets the flipflop. It does not reset it. The contents of the source will not be turning off the flipflop of the destination. 

Further, the control signal that arms the edge sensitive gate is the bit value of the source. If the source holds a 0 value, then the edge sensitive gate is NOT armed and cannot set the flipflip. It is when the source holds a 1 value that the gate is armed and turns on the flipflop at the appropriate time. We transfer 1 values but not 0 values. 

This may sound like a quibble, but it means the entirely different circuits are involved in resetting the bits of the destination. This would be a register clear signal that turns all the flipflops to 0. Now imagine that the register previously held a value of x3C00 and it was not cleared. If the source holds 0x0800 when the gating occurs, the destination register remains at x3C00. If the source holds x00F0 then the destination register would become x3CF0. We are doing an OR into the destination, so that we absolutely must have it cleared to x0000 before we do the gating. 

ONE POTENTIAL FAILURE MECHANISM

If we first posit that a register has the typed character code at the end of the XIO Write instruction, and that nothing in the execution of the I1 and E1 steps of the XIO Sense DSW make use of that hypothetical register, then if the register clearing pulse does not get to the register, we might get the symptoms I observe where any bits from the typed character code remain on in the destination register. 

REVIEWING PATH OF DSW DATA FROM CONTROLLER TO ACCUMULATOR REGISTER

During execution of an XIO Sense DSW, at the start of the E2 step of execution, the typewriter controller logic turns on bits that should be a 1 in the DSW. It does not turn off any bits - again, the circuits in the 1130 generally are asymmetrical and flip bits on with edge sensitive gates. While the controller holds the desired bits at 1, pulling them to logic low since the IO Bus is inverted, an early step of E2 for the instruction gates the IO Bus to the B Bus. Assuming the B bus was cleared previously then it has 1 bits only in the positions that were set in the IO Bus.

A bit later in the E2 step of the instruction, it gates data from the B register to the D register. If the D register was previously cleared then it will match the B register value. A touch after the transfer, control lines are set to the arithmetic logical unit to cause the value in the D register to be transferred into the A (Accumulator) register. 

TRYING TO FIND A FAILURE MECHANISM THAT INVOLVES THE D REGISTER

We know that the B register updated after every memory access, so that the original typed character code from the XIO Write instruction is replaced, first by the XIO Sense DSW instruction itself, then by word 2 of the IOCC in step E1, and finally from gating of the IO Bus in step E2. 

However, fetching instructions and reading the IOCC does not involve the D and A registers, only the B register. Thus there is the potential that something has gone wrong with clearing one or both of them, so that when the IO Bus is gated into D we are just doing an OR of the IO bus with the prior contents of D. 

For this to happen, we must have the character code of the XIO Write instruction somehow get transferred to the D register. There is no need for this to happen as the XIO Write should simply have the data in the B register so the typewriter controller can work with. I must find evidence that a transfer takes place to D otherwise this explanation of the defect can't be correct. 

Looking at the logic of the machine, the data should stop at the B register because the CCC counter is decremented to 0 at the start of step E3 of the XIO Write instruction. The last thing in the D and A registers will be the first word of the IOCC as it was read in step E2. For this speculation to cause the symptoms we see, the transfer into D must happen in E3 of the XIO Write, through some kind of defect. Then, a second defect must suppress the clearing of register D so that when the XIO Sense DSW step E2 gates in the IO Bus, we get an OR with the prior contents of D.

I am skeptical that I would have two scattered defects that combine in this way but otherwise code seems to run fine on the 1130 system. I need a starting hypothesis to debug the machine, otherwise I might need to monitor hundreds of signals blindly to try to spot a problem. More thought is required.