Further digging into the cause of the spurious parity checks doesn't get me to an answer yet

METHODICALLY WORKING MY WAY FROM KEYBOARD TO PARITY GENERATION

I monitored the output of the keyboard so that I was certain it was setting the correct bits in the Storage Buffer Register during the XIO Read to pick up the character code for the key that had been pressed. A sampling pulse arrives to latch the SBR bit to the value coming from the I/O bus which is fed by the keyboard. 

The Storage Buffer Register output was steady from that sampling pulse throughout the time when the XIO Read was storing the values in memory, including when the parity checker falsely declares an error. The SBR output is fed through an inverter in B-B1 L6 although the output does not have a pullup to +3V thus it is difficult to monitor its output state. 

Nothing was obviously wrong with the output of the inverter, to the degree that I could see it, but when the signal arrived at B-B1 L7 where the parity is generated by a tree of XOR gates, the signal looked wonky. 

The yellow trace is the input on the IO bus from the keyboard. The purple trace is when the SBR is set based on that input. The blue trace is the detection of the parity error. What is anomalous is the green trace, which should follow the purple trace since it is just redriving the output of the SBR, but it does its yo-yo maneuver beginning earlier than when the SBR is set. Something else is injecting signals on this net and I have to find it. 

STRUGGLING TO FIND THE LINK SINCE THE KEYBOARD VALUE IS LOCKED IN

After a large number of experiments typing keys I see an inescapable correlation between the keys pressed and the failure. There are a few groups of keys that consistently cause the parity check when sequentially typing from one group and then the other. For example, F, W and O are in one group, while G, X and P are in another. Whether the F is pressed first successfully and then G triggers a parity check, or the G is successfully pressed first and then the F triggers the error, it always involves changing between groups.

Going between F and P or the reverse causes the same error, since they are in different groups. Another group involved the Z key and quite a few other keys, both alpha and numeric. I looked at the generated character codes for these and can see commonalities. The F/W/O group has the Hollerith row 6 active, while the group G/X/P has row 7 active. It appears that the switch between 6 and 7 introduces the error. 

The time between pressing the keys does not seem to matter. Pressing the keys after unrelated keys were used causes no issues. Pressing keys from the same group repeatedly causes no parity check. It only fails when a key from the 6 or 7 group is pressed when the immediately prior key pressed was from the opposite group. 

Since the program waits without an interrupt from the keyboard, we know that none of the contacts are electrically active in between the keypresses. It seems odd that the keyboard could have a memory for which group was pressed just before, based on the mechanism. 

I have to recognize the role that the alternating groups play in triggering the error, even if I don't see any physical means to hold state between the keypresses. That is puzzling fact number one. 

The second puzzling fact is that the signals from the keyboard controller logic are gated, thus they are not even routed to the Storage Buffer Register until an XIO Read instruction is executing. When they are routed to the SBR, a single pulse is sent to latch the input-output bus values into the SBR. This is a one time event; any changes on the signal lines from the keyboard do not pass through. All we have is a snapshot at a single clock cycle when the pulse latches the value into the SBR.

The third puzzling fact is that the output of the SBR appears to generate the odd waveform at least one cycle BEFORE it is latched to the input-output bus state. It wobbles up and down in the pattern we always see. 

Trying to fit these together yields a big headache. Signals should not care about the prior state of the keyboard from its prior keypress. These does not appear to be any mechanism to hold the state memory. The signals from the keyboard are not presented to the SBR until a specific pulse during the XIO Read instruction. The SBR will hold that value latched at a steady state for the remainder of the memory write cycle. Somehow the parity checking XOR tree is seeing a signal wobble, starting before the keyboard data is routed to the SBR, although the XOR is fed by an inverter from the SBR. The wobble only happens when keys were pressed in an order that switched between groups I experimentally found. 

TOOK APART KEYBOARD, ANNOYING ISSUES PUTTING IT BACK INTO SERVICE

I opened the console, unscrewed the keyboard and checked it over for possible errors. I readjusted the restore bail contacts which disconnect the signals while the keys are being unlatched. In any case, if they are changing after the read has finished and during a restore, the data is not being routed anywhere. If for some reason it triggered a new false keypress value, there would be an interrupt - but there is not. 

Many of the connections that feed the signal lines which vary between the groups are created by keystem latches. That is, a set of contacts at the bottom of the stem for the key F make a connection to route +12V out of the Hollerith row 6 wire, while contacts at the bottom of the key G make a connection out of the Hollerith row 7 wire. There is no method for both keys to be done simultaneously, even for a brief moment. Since the prior key was read, the key unlatched and the keyboard restored waiting for the next press, that connection state is long gone by the time another key is pressed. 

One problem that I had a couple of times was that the space bar ended up jammed down in the active position after I remounted the keyboard mechanism into the 1130. That put the machine into a tight loop displaying the Hollerith value for space - all zeroes. 

I removed it, tried to adjust the position as I reinstalled, with a few checks that the spacebar was latching and releasing, but when I closed up everything, the space bar jam was back. I ended the work session at that point, but once I get back I will get this installed successfully with a space bar that functions. I can then go on to track signals and test conditions, trying to sort out the mystery. 

Further testing of CPU instructions - 2

CONDITIONAL BRANCHING ADDITIONAL

I hadn't fully checked that the ACC negative worked, thus I tested this to wrap up the conditional BSC and BSI instructions

The MDX instruction conditional effect needed to be tested for both index register modification as well as the memory work modification variants. I set up values in the registers or memory location and then applied negative, positive and zero modifications to test the skip behavior. The skip should only occur when the modified register or memory location becomes zero or switches signs and that is how it behaved.

MISCELLANEOUS LOAD/STORE INSTRUCTIONS FINISHED

I finished checking with the Store Index (STX). The STX simply stores the value of IAR or the selected index register into the memory at the effective address - displacement from IAR+1 or the second word as an absolute address. .

ARITHMETIC CHECKING

We know that addition and subtraction are essentially working correctly because they are used to create the effective address by every instruction, but there are some aspects that are not part of instruction execution which we should check.

If two numbers are added or subtracted, depending on the result we might set the carry and/or the overflow flags. Numbers in an 1130 word are represented by 15 bits of value and a high order sign bit. Negative numbers are two's complement versions of the positive number. The two's complement of a number inverts every bit and adds 1. Thus the two's complement of 0001 is FFFE+0001 or FFFF. 

Whenever the sign bit changes, the Overflow flag is set. This indicates that the 15 bit remainder of the word was not big enough to hold the result. The largest positive number is 32,767 and if a 1 is added to it, the result is now -32768. The 15 bits before the addition were, in hex, 7FFF and after a 1 is added the result is 8000. The sign bit changed and 8000 is -32768. 

Whenever their is a carry out of the sign bit (for addition) or a borrow (for subtraction), the Carry flag is set. Shifting left sets the Carry flag to the value of the high bit what was shifted out. 

There is an exception for the Shift Left and Count (SLCA) instruction. This shifts the ACC left by a count set in the instruction. If a 1 bit is shifted out before the count gets to zero, Carry is set to 1. If the count dropped to zero, Carry is set to 0. 

I had to try various combinations of positive and negative values with addition, subtraction and divide to validate the flags. For shift, I had a smaller number of cases to test. I did try some mixed sign multiply and divide to determine whether the ACC and EXT signs were appropriately generated.

Multiply takes the value in the ACC and multiplies it by the value fetched from the effective address memory location. The result is a doubleword, taking up both the ACC and EXT. This has no effect on the Carry and Overflow flags. The signs came out properly in all cases - e.g. -20 x -40 is the same as 20 x 40. 

Divide takes the doubleword value in the ACC + EXT and divides it by the one word value in the effective address location. The ACC stores the Quotient as a 16 bit signed value and the EXT stores the remainder as a 16 bit signed value. The EXT is always the same sign as the divisor (data in the effective address). The Overflow is set if the ACC has an overflow or if the divisor was zero. 

When I divided 40,000 which is larger than fits in a single word (but fits in the ACC + EXT as the dividend) by 1, the result was larger than can fit in the ACC thus the O flag was properly set. 

XIO INSTRUCTION TESTING

I couldn't more generally test the XIO instructions because many depend on peripheral device controllers. The XIO points at a doubleword effective address which is an Input Output Control Command (IOCC). The IOCC specifies an XIO type, an Area Code to select the particular device, an address and some modifier bits for certain devices. 

To determine which device controller(s) are requesting an interrupt, while in the interrupt handling routine, the Sense Interrupt type loads the ACC with the requesting status of all the controllers that can request this particular interrupt level. The bit positions were typically designed by IBM. For example, level 4 assigned bit positions:

• 0 for paper tape reader/punch
• 1 for the console keyboard and printer
• 2 for the 1442 reader/punch
• 3 for the 2501 card reader
• 4 for the 1403 line printer
• 5 for the 1231 optical mark reader

Each device controller typically has its own handler code, so that the interrupt handler, having seen a 1 bit for a particular device controller, then branches to that controller logic to deal with the device. Generally the initial interrupt handler scans the bits using the SLCA instruction, stopping on the first bit from the left that is on, then branches to that device's code. 

When the code is done, the interrupt handler exits back to the original code that was running when the interrupt was initiated. A version of the Sense Device instruction will reset the condition that caused the controller logic to request an interrupt.

If more than one controller on the interrupt level had requested an interrupt, the machine immediately goes back to the interrupt handler, which then uses the SLCA to find the next controller with a bit set, branching to its handler code. Only when all requesters have been serviced and their conditions reset will the machine stop entering the interrupt level and continue executing the originally executing program. 

The device controller can be interrogated with the Sense Device type of XIO. The controller loads the ACC with a word whose bit positions are defined by that device controller. For example, the console keyboard printer status word assigns bit positions:

• 0 - the typewriter completed a requested function
• 1 - the keyboard had a key pressed
• 2 - the Int Req key was pressed
• 3 -the switch on the console is set to Console (Entry Switches) if on, Keyboard if off
• 4 - the typewriter is busy processing a requested function
• 5 - the typewriter is not ready (either busy or out of paper)
• 6 - the keyboard is busy (KB Sel lamp on)

There are four kind of data transfer types. Read and Write will transfer one word from the address in the IOCC to the device for a write, or save one word from the device in the address for a read. Initiate Read and Initiate Write request the controller to start a transfer of multiple words asynchronously while the CPU moves on and executes instructions after the XIO. 

The Initiate types have an address in the IOCC whose first word is a count of words to transfer. The data is transferred to or from the words immediately following the count. For example, to read in a 321 word sector from the disk drive, the IOCC for an Initiate Read points at a 322 word long section of memory, the first word of which contains the value 321. 

Finally there is a type that does not transfer to or from memory, called Control. Its modifier and address portions of the IOCC are used by the device controller for its purposes. For example, it may specify a disk cylinder which the drive must reach by moving the disk arm. As another example, it might tell the card reader to steer a card to an alternate stacker pocket. 

I have tested the read type and the control type in my code working with the keyboard, using those to read the value of a keypress and to turn on the KB Select status for the keyboard. I have also used a Sense Device to check the state of the keyboard and printer. We know that it resets the keyboard controller request because we exit the interrupt level and resume the main program. 

I trie a Sense Interrupt type by triggering an interrupt on IL4 with the Int Req button, single stepping into the interrupt handler and then issuing the XIO to verify that bit 1 is set indicating that the console devices requested the interrupt. That did occur as it should. 

Until I have a peripheral device that uses the initiate type of data transfer working, I can't test those two types. A full test of XIO is really tightly tied to testing a particular device and its controller logic. I won't do any further testing at this time. 

Thoughts on leveraging George Wiley's RK-05 Emulator and Tester for the IBM 1130 disk emulation

PRODUCTIZED AND DEBUGGED MECHANISM FOR EMULATING DISKS SIMILAR TO 1130

The RK-05 Emulator and Tester works with the DEC RK-05, a drive derived from the original IBM 2310 (ramkit code name when installed in 1130). The 2310 is a single 14" platter in a slide in plastic cartridge, as is the RK-05, the Diablo 30 and many other's that licensed the patents and improved upon the 2310. 

They both have 203 arm positions radially from near the outside of the platter to near the hub, with the programmer requesting a seek to move the heads to one of those positions. They both have a head on each side of the platter, top and bottom, which is selectable by the programmer for each read or write. 

They both are self clocking on the disk, where each 'bit cell' consists of a clock pulse and either a pulse for a data value of 1 or no pulse for data value 0. There is always a clock pulse, which the drive synchronizes to so that it can separate out the clock pulses from the data pulses. 

The 2310 clock produces 720,000 bit cells per second, with the clock of 1.44MHz divided in two to produce the clock pulse at the start of a bit cell and an optional data pulse if the value is 1. Since the disk rotates at 25 rotations per second, the drive can fit 28,800 bit cells in one rotation. The density in bits per inch depends on the radial position of the arm, with the track closest to the hub having the highest density at 1100 bits per inch. 

The RK-05 has the same rotation rate, but its clock produces 1,440,000 bit cells per second, thus the bit density is twice as high at up to 2200 bits per inch. Similarly, the Diablo 30 (which also spins at 25 rps) has both standard and high density versions, at 1100 or 2200 BPI. Oddly the Diablo clock is a bit faster than either the 2310 or RK-05 delivering 781,000 or 1,562,000 bit cells per second although the rotation rate is the same. 

A very significant difference is in how the arm is moved. The 2310 has a physical ratchet mechanism with the CPU requesting moves of either 1 cylinder or two cylinders at a time, forward or backwards. The other drives have servomechanisms that seek directly to a target cylinder with one command from the CPU. All three drives use a spacing of 10 mil between cylinders thus the full radial motion is just over 2" of the 7" platter radius. 

The hub of the platter has notches cut in it, dividing a rotation up into sectors. Depending on the systems using the drive, the number of sectors in a rotation can vary. The IBM 1130 always has eight physical sectors although pairs are combined to form the four logical sectors that the programmer sees. DEC systems using the RK-05 commonly have either 8 or 12 sector packs, those chosen to be well suited to different word lengths. The physical disk cartridge must have the correct number of sector notches to be used with the intended system. 

All of these drives require that the circuitry on the drive be able to synchronize to know which pulse is a clock and which is a data bit. This requires a preamble, a sequence of zero bit cells long enough to have the circuit lock in on the only pulses which must be clock bits. The end of the preamble is a single bit cell with a 1 data value.  Thus they have in common the need to erase a short bit and write the preamble ending with the sync word (all 0 except for the last bit). 

The systems using the drives diverge significantly from this point. IBM writes up to 321 words in a logical sector. Each word has error checking built in, with no sector wide error checking. The DEC, Xerox and most other systems, on the other hand, tend to write just the data words with error checking performed at the end of all the data with a checksum word. IBM has a single field, up to 321 words, written in a sector. Xerox Alto has three fields written in each sector, called header, label and data. Each has its own preamble with a sync word. 

Even decisions such as whether the most or least significant bit is recorded first vary by the system using the drive. This is why it was common to pair up a controller card with a drive, both being designed with the same choices. 

George Wiley's device will control RK-05 drives for various DEC systems, thus it is able to handle 8 or 12 sector systems and other variations. It inherently operates that the 2200 bit per inch rate of the high density version. It handles the preambles, sync words, bit ordering with a word and checksum algorithms that are used with the DEC controller cards. 

CHANGES NEEDED TO USE WITH MY 2310 DRIVES

The code must be changed to operate at the 720KHz data rate of the standard density. The preamble and sync word are the same although the duration of erasures and preambles may vary. The data words on disk are 20 bits long, 16 data bits plus four error checking bits. 

The ECC algorithm is very simple, the number of one bits written on the four error checking positions will break the total of one bits in the word up to 0 modulo 4. Thus if the word already has 0, 4, 8, 12 or 16 bits that are 1, the four error bits are 0000. If the data word has 5 bits that are 1, then the error bits are 1110. A word with a count of ten 1 bits ends with the pattern 1100. 

I will need to change the code of this emulator to generate the four ECC bits on every 16 bit output word and to check for proper parity (0 mod 4) on input. There is no checksum so the code can skip calculating that and skip checking the nonexistent checksum word. 

The code expects to receive a target cylinder number from the CPU and to interlock with signals until it reaches that point. The 1130 system will instead send relative motion requests, 1 or 2 cylinders at a time. The code of this emulator will have to handle the 1130 method of stepping, changing the stored cylinder number in increments. 

SLT VOLTAGE/CIRCUIT ACCOMMODATION

The IBM 1130 uses SLT, which is a Diode Transistor Logic circuitry with nominal signaling levels of 0V for logic low and 3V for logic high. However, the gates are only sensitive to having current drawn out of the input to a lower voltage, typically near ground through a transistor. If current is not flowing, it is at logic high even if the voltage is zero. 

Secondarily, these are fairly voltage insensitive and tolerant. It is not unusual to see 9V or high on the input of a gate, which is ignored. Those same inputs might be presented with a path to -3V rather than 0 for a logic low, which still causes a current to flow out of the gate input and is considered valid. Others may more rarely be presented with +48V when not conducting to ground to register as logic low. 

GENERAL STRUCTURE OF THE EMULATOR

The emulator consists of an FPGA which does the signal manipulation and state management. It also accesses a DRAM with enough room to store an entire RK-05 cartridge. Rather than the 2MB capacity of an RK-05 pack, the 1130 cartridge will hold only 1M bytes (512K 16 bit words). There is an SPI link between the FPGA and a Raspberry Pi Pico, which interfaces with the user and accesses an SD Card which contains the cartridge image. 

The product has voltage translators (between 5V for the RK05 and 3.3V for the FPGA/Pi) and proper termination for the DEC controller cards. 

More thoughts on the cause of the parity checks on certain keystrokes

TRIGGERING THE IL4 INTERRUPT WHEN A KEY IS PRESSED

Once an XIO Control instruction has been issued to select the keyboard, restoring any previously pressed keys, the twelve bits generated by the keyboard (forming the Hollerith code for the key) are funneled to the Keyboard Response flipflop which will be set if any one or more of those bits turn on. 

The Keyboard Response requests an interrupt on level 4, which diverts code execution to the interrupt handler software. Once the source is identified as the console, the software checks the specific cause via an XIO Sense Device and sees the bit set for KB response. It then issues an XIO Read to grab the value from the key that was pressed and stores that into the memory location pointed to in the XIO. 

I have slimmed down the ALD page to remove unneeded detail. The path marked in red shows the flow of a positive signal from the keyboard (KB Bit 7 - for punched card row 7) that will eventually be stored in memory as bit 9 during the XIO Read. However, the red path shoes all the bits are combined in an OR gate and flow to the controller logic to trigger the Keyboard Response FF and interrupt request. 

The path in green is only enabled once the XIO Read command is issued. Before that read is issued, there is no path from the various keyboard outputs to the Storage Buffer Register where it will be written to memory. In the scope results shown in the last post on this error you could see that the bits for the intended character did sharply turn on right when the XIO Read was issued. 

However, we could see random noise on the SBR bit 9 signal line which began exactly as the Keyboard Response FF turned on. This was what triggered the interrupt initially and the signal on that bit 9 continues to wobble up and down rather than being latched into place in the card implementing SBR Bit 9. 

When the keyboard is restored (all keys up) and selected (KB Sel lamp is on), the +12V is isolated from the circuitry by a microswitch. Once a key is pressed down to latch some contacts forming the Hollerith key code, the 12V is connected to present those bit values to the controller logic. The KB Response flipflop can't be set until the voltage is present on those lines.

This is a simplified version of the keyboard wiring showing the routing of the +12V from the KB Restore Bail Contact switch at the upper left, through the All and either the Numeric or the Alpha buses, through some bail and latch contacts. Latches are under a keystem, while bails are triggered by any of a number of keys. 

We know that the paths from the two diagrams above are involved because no request for IL4 occurs until I press down on a key. The random looking signal on bit 9 is not coming through the 4615 card (assuming it is working correctly) because that would only be present once the XIO Read is issued. Thus we have one mystery - what is causing the random signal on bit 9. 

That may also be the bit that first triggers the KB Response interrupt but we don't know for sure. We see it visible only when the KB response goes active, which is suggestive, but not definitive. The trigger could actually be one of the bits actually part of the Hollerith code for the key, but someone the bit 9 noise is there. 

There is no path from the keyboard to the SBR bit 9 until the XIO Read is issued, thus we may have an entirely different source that is not connected at all to the keyboard. We may only be sensitive to that noise once the controller logic is watching the SBR. Further, the SBR should be latching the value of the keyboard bits only at one clock cycle and holding them steady afterwards, so that the noise, varying with time, should not be from the keyboard.

What is strange is that the parity check issues only seem to crop up when we alternate between keys that have keyboard bits 6 and 7 active. Such pairs include F/G, W/U, and O/P. Typing keys that don't involve those bits get no false parity checks. Typing either of the characters initially has no error, it comes up when I move from one of the pair to the other in either direction. This is misleadingly pointing at the keyboard as the source of the issue, although the lack of an XIO Read and the wavering nature both are inconsistent with a keyboard origin. 

This one is going to take more scope captures and experimentation to further narrow down the possibilities and eventually find the one culprit. 

Further testing of CPU instructions 1

CONDITIONAL BRANCHING

There are two kinds of conditional branching, both of which will either execute the next sequential instruction or take an alternate path. In most cases, the alternate path is to skip over one word. The first kind checks against certain conditions that can be tested by the instruction. The second kind skips an instruction when a value becomes zero or changes sign. 

The conditions that can be tested are:

• Accumulator is zero
• Accumulator is negative
• Accumulator is greater than zero
• Accumulator is an even number
• The Carry flag was set
• The Overflow flag was set

The instructions change how they conditionally behave (and whether they do) depending on whether they are short or long format instructions. 

The Branch and Save IAR (BSI) instruction is only conditional when the long format is used; for short format, it will always branch to the effective address + 1 after storing the current IAR in the effective address. 

The Branch or Skip on Condition (BSC) instruction is always conditional, but the use of the condition bits is somewhat different between short and long format. For short format BSC, if any of the selected conditions are true, it skips over the next instruction otherwise it falls through to the next sequential instruction. For long format BSC, if any of the selected conditions are true, the branch is NOT taken and it instead falls through to the next sequential instruction. 

Thus, matching one of the selected conditions will either skip (short) or fall through (long). Inversely, if none of the selected conditions are matched, the short format falls through while the long format takes a branch to the effective address. 

The Modify Index (MDX) instruction acts on the IAR, index registers or a memory location, depending on the format and selection of an index register. 

I tested almost every condition and all the conditional BSI and BSC variants, which all performed correctly. 

A short MDX with no index register will modify the IAR, in other words it is an unconditional branch. It does not skip even if the IAR becomes zero or changes signs, unlike all the other variants of the MDX. Short format uses the last eight bits of the instruction as a displacement, a signed number that is -128 to +127. It is added to the IAR+1 when the MDX is executing, to form the effective address of the branch.

A short MDX with an index register specified will add the displacement to the contents of the index register, putting the updated value back in the register. Thus, you can bump a register up or down by the signed displacement. If the updated value of the register becomes zero or changes sign, then the MDX will skip the next word, otherwise it executes the next instruction. 

A long format MDX with an index register will add the value of the second word to the index register specified. You can bump the register by any value from -32768 to +32767, which is what can be held in the 16 bit word of an 1130. If the updated value of the register becomes zero or changes sign, the MDX will skip the next word otherwise it executes the next sequential address. 

A long format MDX without any index register specified is also called a Modify Memory (MDM). It will add the displacement (-128 to +127) to the contents of the effective address location, storing the new value in that memory location. If the value in the memory location becomes zero or changes sign, the MDX will skip the next word, executing at IAR+2, otherwise it falls through to the next sequential instruction (IAR+1). 

I didn't get to testing the MDX instructions during this session.

MISCELLANEOUS LOAD/STORE INSTRUCTIONS

Load Index (LDX) and Store Index (STX) will act on index registers or the IAR. Unlike an MDX, which takes the current value of the IAR or index register before adding the displacement or second word, the LDX just loads the displacement or second word into the IAR or register, replacing whatever was there. 

If an index register is specified, the displacement or second word (for long format) is put into the index register wiping out its previous contents. 

Updating the IAR is effectively an unconditional branch - either to an address between -128 and +127 if short format is used, or to any address for long format. The STX simply stores the value of IAR or the selected index register into the memory at the effective address - displacement from IAR+1 or the second word as an absolute address. 

Load Status (LDS) and Store Status (STS) transfer the Carry and Overflow tags between the CPU and the memory at the effective address. Bit 14 is Carry, bit 15 is Overflow. When storing status, bits 8 to 13 are set to zero before the Carry and Overflow are used as bits 14 and 15. When loading status, only the bottom two bits are used to set the CPU condition. It is a good practice to put an LDS in the location where the STS will store the status, because then that word can be executed to load the saved status back into the CPU. 

I was able to load the status with LDS and store it with STS. I tested all of the LDX instruction types and they all passed. I did not get to the STX instructions today. 

Narrowing in on keyboard issue causing false parity checks

MECHANISM FROM KEYPRESS TO READING THE KEY CHARACTER CODE

It is important to understand what occurs from when the user pushes down on a key until the interrupt handler executes the XIO Read instruction to store the code in a memory location. This allows the reader to understand why the faulty signal is producing the wavering signal that leads to the parity check failing. 

When the key is mechanically pushed down, bails are twisted by tabs on the rear of the keystem and simultaneously contacts are pushed together at the bottom of the keystem. The bails activate contacts that can be triggered by every key which has a tab on its stem at the height of the particular bail. The contacts at the bottom of the keystem are unique to that key, while bail contacts are activated by a number of keys. 

Any key pressed down closes a common switch to feed +12V to the wiring of the permutation unit, where the combination of bail contacts activated and the keystem specific contact route the voltage to signals for bits 0 to 15 which encode that key character. 

The contacts are connected to the output bits using debouncer circuits, allowing them to stabilize before an XIO Read is executed to write the bit values into memory. However, the way that the programmer knows that a key was pressed involves triggering an interrupt on level 4.

All the sixteen bit lines from the debouncers are connected through an OR function. Actually half the bits are handled by each of two 4615 SLT cards, so there is an OR for each card. Those two signals are then connected by another OR gate to form the trigger for requesting a keyboard interrupt.

As long as the keyboard was selected (via an XIO Control instruction) the KB Sel lamp is lit and the trigger is connected to set a flipflop. The first of the sixteen bits of the encoded key character that turns on will set the flipflop and request an IL4 interrupt.

The keyboard remains mechanically latched with the key down, the contacts set, and no other key able to be depressed until an XIO Read is issued. The read will cause the character value bits to be placed in memory at the location specified in the XIO Read instruction. It then restores the keyboard, disconnecting the various contacts and shutting off the +12V to the permutation unit. It will remain idle until again selected by an XIO Control. 

The program code for the interrupt handler for IL4 determines that the interrupt comes from the keyboard, after which it issues the XIO Read and then resets the flipflop via a modifier bit on the XIO Sense Device instruction. 

EVIDENCE THAT A SIGNAL IS ARRIVING BEFORE THE KEY LATCHES THE CONTACTS

The yellow and green traces are the two contacts which encode the key I pressed, The turn on crisply near the right of the screen and hold steady due to the debouncers. The blue trace is the -parity check signal, which goes low to signal the parity error occurred. The purple trace is the interrupt request flipflop for the keyboard. 

What we see is that the interrupt is requested prematurely, before the keyboard has latched down and is driving stable signals for the character code. Ignoring the noise spikes caused by poor ground connection to the scope, we realize that some signal that is NOT our actual character bits must have switched on and activated the flipflop earlier. 

BIT 9 LINE IS PRODUCING THE PREMATURE TRIGGERING

Here we connected to the bit 9 signal in the green trace. We can see that it starts wobbling around and has fed through the OR gates to activate the interrupt request flipflop. Its continual wobbling eventually is confusing the parity check circuitry and triggering our parity check. 

During my next visit I will zoom in on that signal generation to figure out why the random flipping is taking place. This may be a broken wire, it may be a bail or keystem contact that is out of position and almost connected except for the vibration of pushing on a key, or it may be that the +12V is connected prematurely to the permutation unit before all contacts have settled down. Finally, it could be a wiring break from the permutation unit to the controller logic. 

Traced back to problem in the keyboard! Meanwhile CPU seems flawless

SIGNAL ANOMALY SPOTTED

Testing the card involved setting up quite a few signals into the card in order to check each bit output. The area got very crowded with cables, many forcing signals to ground so that the circuits would work right. In no case could I see the debouncers causing the odd pattern that was characteristic of the error. 

After checking the cards on the testbench with no issues found, I began scoping various signals related to the bits causing the parity check. When I watched both bit 8 and bit 9 at the same time, I spotted the cause of the changing parity. 

Green trace is bit 8, purple trace is bit 9

When bit 9 is a logic high, the scope showed bit 8 blipping on for a short period then off, while bit 9 turned on right after 8 went low. This makes no sense in the context of reading the keyboard. 

TRIED ALL OTHER KEYS - CONSISTENT ISSUES WITH BIT 8 - BIT 9 TRANSITIONS

I began systematically hitting keys, noting when I saw a Parity Check falsely detected. When I typed a G after an F, I get the error (and the same going in the reverse direction). When I type a P after an O, or a W after a V, the error occurs. Several special characters such as * and % also triggered errors. 

If I type some other character and then a P, it works fine, but if I typed a character with bit 8 first and then type P, the Parity Check is thrown. This has to originate from the keyboard mechanism itself, which encodes characters using a complex circuit combining bails (contacts operated by certain keystems) with latch microswitches under specific keystems, along with the Numeric key. 

I took a quick look at the diagram before I pull the keyboard out of the machine for an in depth investigation. I noticed that bit 8 is unique in that it is fed through a pair of back to back diodes. If a diode isn't (e.g. a short) we might be charging up one of the debouncers one way and then draining it off as bit 9 turns on. 

Other possibilities include sludgy stale lubricant on one of the bails, which causes it to stick in one orientation for one of the paired keypresses and then flip to the other. What is confusing here is that the mechanical motion should be complete before the CPU takes the interrupt and issues the read to pick up the key code. Perhaps the tight loop I am using for this test is a worst case minimal delay before reading, which combines with a poor response of the moving parts due to sticky lubricants. 

EXERCISED CPU BY HAND FOR AN HOUR, TRYING MANY INSTRUCTION VARIANTS

I walked the CPU through instructions, including variations, with every single one performing properly. The 1130 has several addressing modes. An instruction can be short (one word) where the effective address is relative to its current location, or long (two words) with a full address in the second word. It can apply the contents of one of the three index registers to the effective address. Finally, it can treat the address as indirect, reading from that address to get a different address to finally use with the instruction.

For example, if an instruction is at address 0200 and is short format with the remaining bits (displacement) set to xx0F, then the effective address takes the Instruction Address Register (IAR) while the instruction is executing (0201) and adds the displacement to form the address 0210. 

If in addition, the instruction uses index register 2, then the contents of that are added to the effective address 0210 we just calculated. If IX2 has 0040 in it, then the effective address becomes 0250. 

Finally, if indirect addressing is specified for the instruction, then we pick up the contents of location 0250 - lets say it has 006A stored in it - so that the final effective address is 006A. For long format instructions, we skip adding a displacement to the IAR, instead just taking the second word as the effective address before we add index registers or apply indirect addressing.

All these variations worked perfectly. I tried the Load Doubleword instruction which fetches a pair of words from the effective address (and address+1), putting the contents in the ACC and EXT registers. If the effective address of a doubleword instruction is pointing to an odd address, then the CPU will instead just fetch the word at the effective address twice, putting the same value in both ACC and EXT. This worked correctly.

I tried all the AND, OR and EOR (exclusive OR) functions, which worked great. The effective address computation use the add/subtract circuits, so we know they are working properly as well.

Finally, I tried a simple Modify Index and Skip (MDX) to branch to the effective address, as well as a Branch and Store IAR (BSI) to store the address after the BSI in the effective address location and set the IAR to effective address + 1, beginning execution at that point. This worked properly short, long and indirect. 

The next time I work on the machine I will focus on all the conditions that are used for the conditional branching instructions, things like ACC is zero, ACC is negative, or Carry occurred). These are used with the Branch or Skip on Condition (BSC) instructions. 

The MDX instruction adjusts index registers or memory locations, either executing the next instruction or skipping over one instruction word - I need to test all the variations to be sure it works well. 

I have used the input output instruction XIO successfully for the keyboard testing, so it is working well, thus I will be left with some minor instructions to round out the test. 

Not the XOR card, moving on to investigate setting of parity bit 2

RETRACING SIGNALS AND ABSOLVING THE XOR CARDS

The issue is that bit 8 and 9 are turning on - correctly - from the keypress of an F or G character, but then they oscillate which defeats the parity setting circuit. It looks like a switch bounce, although it is one machine cycle long and completely repeatable. The bit comes on for a cycle, goes off for a bit less than a cycle, then comes back on steadily.

Green traces shows the 'bounce' shape

The keyboard is mechanical, but the key latches down and doesn't move until the character code is ready by an XIO instruction. Therefore no contact is moving to cause a bounce. Further, bounces would not be so deterministic. 

CHALLENGES DEBUGGING

I had so spend the majority of the day trying to identify the root cause because a number of characteristics of IBM SLT based computers introduce problems that produce confusing or ambiguous results on measuring instruments.

The nature of SLT gates, which are Diode Transistor Logic (DTL), means that for the most part, the only significant action on an input is to draw current towards ground (or sometimes a negative voltage). The absence of a current is a logic high, regardless of the voltage present. 

Some gates will have a pullup resistor so that when the final transistor is not conducting, the output rises to the +3V nominal high level. Others, however, do not and they can appear to be at ground when they are at logic high, since the transistor is not conducting and they are not pulling current through it. 

Thus, signals on an oscilloscope which is primarily a voltage measuring device will appear to be at or near ground. They can have glitches and induced signals in them. However if they are not conducting to pull current from gate they are feeding, then they are at logic high. You just can't tell very well using a scope. 

While the stated voltage levels for SLT are 0V for logic low and +3V for logic high, some circuits in the 1130 can have logic high at 9 to 12V and others can have logic low at -3V. You can't tell from the ALD logic diagrams as all gates appear to be standard SLT. 

To save on components, IBM makes extensive use of wired-OR, just tying the outputs of multiple gates together. The signal would be an inverted one, where a logic low means the condition is true. Thus, wiring together many gates creates a shared bus, where any one or more gates can pull the signal low to assert it. 

This matters because the source of an anomalous signal is hard to find when they are wired together into these shared bus 'wired-OR' nets. The output goes down and it could be any of the connected gates that is doing this. If the gate is defective, then looking at the inputs to each gate won't help, because the assertion of the signal is an error. 

The bus can be multiple bit also - the Storage Buffer Register constitutes sixteen bits, each of them a shared bus for that particular bit. In this case, I was debugging a problem where bit 8, fed from multiple sources, was activated with that funny bounce. 

Finally, life is complicated because SLT cards often have multiple circuits on them, which can be assigned to a number of different parts of the machine. Otherwise, the straightforward way to find which gate is pulling down a wired-OR is to yank out the cards implementing the gates one by one. However, when a card is performing other functions at the same time, those can be essential. If the card is pulled, the machine won't work enough to create the situation you are trying to debug. 

Bit 8 is fed by the controller logic for the keyboard, console entry switches, 1132 printer, 1442 card reader/punch, paper tape punch, 2501 card reader, and the internal disk drive. Another source for bit 8 is the logic to process an interrupt; bits are injected onto the SBR to appear to be a BSI Indirect instruction, causing the next instruction to be executed from the location pointed to by the interrupt vector for that interrupt level. 

SLOWLY, PAINFULLY FOLLOWED THE FAILURE UNTIL I FOUND A SUSPECT CARD

The signal is generated in the keyboard controller logic, putting the value on the shared bus when the computer is executing an XIO read instruction for the area code of the console/keyboard. Further, it is during an execution memory cycle of the instruction execution where the value of the keypress is latched into the Storage Buffer Register for writing to the memory location specified in the XIO instruction.

A double size SLT card, number 4615, implements a lot of functions for feeding data from the keyboard and the console entry switches. One of the functions is debouncing of the signals from the keyboard. This is implemented by an RC network plus a diode. I began to suspect that the network was oscillating when the signal switched on. 

Two of these cards are in the machine, at slots A-C1 B2 and A-C1 C2. I swapped them since the one at B2 or C2 seemed to be causing my problems. The problem changed, so that I could type the F and G keys with no falsely detected parity errors. However, other keys would fail, since the problem was just kicked over to the other signal lines from the keyboard. 

WILL BE DEBUGGING THE CARD IN THE COMING DAYS

I do not have the schematics for the 4615 card. It always seems to be failures in card types whose schematics are unavailable! I will put the card sections through its paces on the workbench to try to spot the problem, but undoubtedly I will need to reverse engineer at least some of the circuitry in order to fix it. 

The circuits the two cards implement are listed above, but the names such as C1 refer to sections of the SLT card schematic, which I don't have. We can look all the functions that are on card C2:

One of the debouncer circuits was used for the typewriter End of Forms contact. Another used for the Keyboard Restore button on the keyboard. A third used for the Prog Load button on the console. The rest of the debouncers are for the console entry switches and contacts in the keyboard. 

The rest is mainly for gating signals, implementing compound gates with multiple AND gates feeding a NOR, so that a particular SBR bit is fed from the console entry switch if doing a read of Area 7, otherwise it is fed from the keyboard contact if doing a read of Area 1. There is one large OR circuit so that if any of the keyboard contacts are active, the output is logic high which is what triggers the interrupt request after pushing a key. 

My issue was with bit 8, most likely the debouncer (what IBM calls an integrator) or the gate it feeds. Because the symptoms changed when the cards were swapped, it appears to be card specific and thus a defect. 

There is another possibility, however. If the gating signal that routes the keyboard contacts onto the SBR bus has the bounce shape, it would produce the same effect. The card receives three signals, +XIO Read, +Area 7 and +Area 1 which when combined to gate either the console entry switches or the keyboard contacts to the SBR when performing a read. If these are not correct it might cause that bounce-like signal. 

A maze of signals exist for gating the bus onto the SBR as well as signaling that we have a read of the keyboard. I expect to spend some hours checking all of these until I find and track down the source of the bounce. 

Testbench ready

FOUND SUSPICIOUS WIRE FRAGMENT ON B-B1 BACKPLANE

I did find a bit of wire sticking out from a pin which might have been a wire that should have continued to another location. At some future point I might be chasing a problem and the solution ends up as a wire wrap from this point, something that may have been done by past repairers. 

Bit of wire sticking diagonally left and downward from a pin

Debugging failure during Branch and Store IAR instruction execution

THE OP CODE, FORMAT AND INDEX REGISTER LAMPS WEREN'T REGISTERING

I had to debug this first, because if the machine wasn't latching in the instruction type properly it didn't make sense to look deeply at any instruction malfunctions. After some tracing of signals, it was clear that the issue was only the failure of the signals to get up to the display light panel.

All the signals were on connector A2 of a particular compartment. I pulled the connector out and reseated it, with a satisfying click, and the lights now work properly.

IN THE PAST I SAW FAILURES WITH THE BSI INSTRUCTION, THIS WAS NEXT TO DEBUG

The instruction should store the current IAR in the target location, then set the IAR to the target word + 1 to begin executing the next instructions. This is used to call subroutines. When done in the subroutine, the address in the first word is set as the next instruction to be executed, thereby returning to the caller.

While any instruction is executing, the IAR has been bumped up to point to the next word after the instruction. Thus when the BSI stores the IAR, it is pointing to the instruction immediately after the BSI. Coming back from the subroutine will resume executing at that next instruction. 

The error was a parity check in the midst of the BSI instruction, as it has stored the return address in the word at the target location but before execution starts at the following word (target+1). Fortunately, this was NOT a problem in the memory unlike the real parity problems I had been dealing with.

The return address that was stored had the correct parity when read from memory. The parity check stop was a false error, caused by defects in the CPU circuitry rather than the memory. I began capturing signals with the oscilloscope to determine the failing component.

The parity scheme in the IBM 1130 is to have odd parity for each halfword. That means that for either bits 0 to 7, one of the halfwords, or bits 8 to 15, the other halfword, the count of 1 bits must be an odd number. The parity bits are used to ensure that condition is satisfied. Thus, if the number of 1 bits in a halfword is even, the parity bit for that halfword is turned on so that the halfword plus its parity bit had an odd count. 

The particular value I was troubleshooting was an IAR value of 1001 that would be stored at the target address. Since each halfword has only one bit turned on, they are already at odd parity and no parity bits would be turned on. After the false parity check, indeed the value in memory at the target address was 1001 with both parity bits off. 

I had the scope checking the signals that produce the parity check at clock step T6. I saw that the signals for the two halfwords were initially good - indicating that parity was odd - but then switched to believing the parity was even. The clock step T4 is when the parity bits would have been set but they were both odd then. At clock step T5 the parity of the second halfword changed to appear to be even, but it was past the point where the parity bits are changed. With the state remaining even, at T6 the parity check latch is set and the machine stops.

The green trace has -even flipping between T4 and T5

I then put the scope on the sources that generate the green signal (-even 2). That is a tree of Exclusive OR (XOR) gates connected to the eight bits b8 to b15 as well as parity bit 2. I traced down the tree watching the parity state flip between odd and even, until I found the XOR where the inputs didn't justify the output.

Bits 14 and 15 feed into the XOR gate and the output has the error shape that matches the -even 2 signal. You can see from the scope output below that neither bit 14 nor bit 15 change between T4 and T5 but the output of the XOR flips.

The dark blue trace is the -parity check signal, which turns on (goes to 0) at T6. Yellow is the output of the XOR gate, while green and purple below don't change. Further, they do reflect that the low halfword is 01, with only bit 15 at a 1. The slight glitches are a result of imperfect ground connections for the scope probes. 

TWO IDENTICAL CARDS USED, ONE PER HALFWORD

The 9 signal XOR gate tree that calculates the parity is implemented on a 3022 SLT card. Slot L7 has the card for the low halfword, while K7 has the same card type, used to check the high halfword. I swapped the two cards to verify that I likely have a defect in the 3022 card. 

The failure of the BSI instruction went away with the swapped cards. However, when I began to run the code segment to check the keyboard entries, I experienced parity faults in a different spot. I interpret this to mean that the fault moved to the high halfword and signal -even 1 because it is the card itself that is defective. 

My plan for tomorrow is to put the 3022 card on the SLT testbench and test its operation. If I can find and reproduce the fault on the bench, then I can find a way to replace the XOR gate SLT module. This card has eight of the 361477 SLT modules that are XORs plus one 361451 SLT module which is a standard And-Or-Invert gate, acting as an NOT gate in this case. 

The XOR module has the following circuit:

Pads 1 and 6 are connected together on the card, with the two inputs to the XOR connected to pads 3 and 6. If pad 3 is high, its transistor T1 conducts. If pad 6 is low at the same time, then the transistor T1 is conducting to pull the circuit connected to pad 11 to ground. With pad 11 at ground, transistor T3 will not conduct so the output at 9 is pulled up to +3 because pads 8 and 9 are tied together.

If both inputs are low, neither T1 nor T2 can conduct so the base of T3 is pulled high, causing it to conduct and pulling output pad 9 to ground. If both inputs are high, both transistors T1 and T2 won't turn on because their emitter is as high as the base. Again, T3 activates and pulls pad 9 to ground. 

Thus, the only way to get a logic high output (+3) is when one input is +3 and the other is 0V. The circuit is symmetric so we don't care which one is high as long as they differ. 

I do have the card schematics and know which XOR module is bad, assuming I reproduce the failure on the testbench. Then it is just a matter of finding a spare XOR module to replace the faulty one. 

Actual 3022 card schematic

Making the repair on the core stack - part 5

FINISHED ROUTING WIRE TO E2 SOCKET GROUND PIN FOR BIT 7 REPAIR

I insulated my splice to the new section of wire and positioned it for its passage between the cards at E3 and F3. I then soldered it to the D08 pin on E2 and verified by ohmmeter that everything was working electrically. 

Grey wire barely visible running to open slot E2

REPLACED SLT CARDS, POWERED UP AND RAN MEMORY TESTS AGAIN

I put the SLT cards back in place once I was done. The machine was ready for some testing, using the Storage Load and the Storage Display functions to loop through memory. This worked great with all zeroes and with all ones. 

STORED SOME 1 AND 0 VALUES FOR BIT 7 IN EACH 2K OF MEMORY 

This gave me evidence that the sense/inhibit wires were good as the machine could inhibit writing a 1 and also could detect a 1 when reading a word. 

TOGGLED IN PROGRAM TO TEST THE KEYBOARD AS A VERIFICATION

This time I was able to toggle in the program and run it successfully. Hopefully this would wrap up the memory issues and let me move on to the rest of the restoration. At this point I consider the memory healed and ready for normal use. 

New mainspring for typewriter, more adjustments and lubrication, motor power testing

NEW MAINSPRING ARRIVED AND WAS INSTALLED

The process of installation requires preloading the spring with about five turns while the carrier is at its rightmost position, then additional tension is added by the motor as it moves the carrier to the left in a carrier return operation. 

FREED UP LEVER SO THE CARRIER CAN SPACE

The mechanism to move the carrier one space to the right is activated in two ways - by a cam at the end of any print cycle and by triggering the operational clutch for a space. The operational clutch itself is triggered two ways - by a solenoid activated by the computer or by a pushbutton on the front of the printer faceplate which trips the trigger. 

All of these merge to a claw which pulls down on a pivot to turn the space torque bar, with the claw moving backwards and snapping off the pivot so that the torque bar is only twisted for a brief moment. This is long enough for a tooth to be pulled out of the escapement rack and the mainspring to start the carrier sliding to the right. The tooth pops back into the very next slot in the escapement rack due to the short duration of the torque bar operation, resulting in a move of just one column.

The claw was frozen in place so that it wouldn't snap off the torque bar pivot and then snap back for the next space operation. I lubricated and worked it free until it reliably spaced. 

WIRED UP MOTOR AND TESTED CARRIER MOVEMENT OPERATIONS UNDER POWER

The machine performed carrier returns and tab movements very well when commanded by the front pushbuttons. The space button triggered the movements but sometimes stuck blocking it from triggering again. I will work on that. I did a few print cycles and felt satisfied with that at a gross level. I will fine tune the selection to be sure it prints the right character during a later phase of the restoration. 

I tested the operational triggers for line feed (which worked great) and backspace, which did not work. I will have to find the gummed up parts for the backspace and ensure they more correctly. The operational clutch was turning but that wasn't translated into movement of the backspace rack. 

The shift between upper case and lower case sides of the typeball worked decently, but it needs adjustments to trip to restore to lower case. The solenoid moves a lever but the shift clutch doesn't detect that and spin. 

The typewriter is coming along very nicely and should be fully restored with just a few more hours of work. 

Making the repair on the core stack - part 4

METHOD CHOSEN TO RESTORE THE COMMON CONNECTION FOR BIT 7 LOW SENSE

I judged the risk of taking apart the backplane and core stack too high, as it could cause another wire to come off or worse, trigger yet another continuity break on the bottom board of the core stack. Therefore I looked for the best means of repairing this with the stack still mounted on the backplane and in the frame.

My first approach was to solder a wire from the common pins on the bit plane, bridging the low and high core planes of bit 7. This was good because the two common wires, although separately routed to the jumper blocks, ended up tied together at pin D06 of the same sense/inhibit card in slot B3. Therefore I just changed the point where they were tied together to the far end, on the core stack. 

The ground wire that was twisted around the other two wires for bit 7 low 4K would therefore be connected through this jumper and provide the same shielding to the twisted wires up to the point of the jumper block pins. This seemed to preserve the impedance and noise suppression almost as well as the original connections. 

IMPLEMENTING THE FIX WITH THE JUMPER - FAILED

I pulled out many SLT cards in rows 2 and 3 to give me clean access to the top of the core stack where I was going to make the hack. All I had to do was tack a short wire from the common pin on the right side of the core plane to the common pin in the middle of the plane - adding to the wires already connected to those pins. 

However, this time I was utterly unable to get the wire to solder to the pin, in spite of all the flux and technique I could apply. It just would not stick at all; I believe that the odd metal, probably minimally magnetic, used for the connection points required spot welding at the IBM factory. 

SECOND METHOD DEVELOPED

If I couldn't solder to the pins on the bit 7 plane, I still had the black wire (ground) which was not connected at the jumper pin any more. Since it was loose, I hoped I could gently coax it back, sliding out between the blue and white wires it was braided with. If I got an end out of the backplane where I could solder to it, I would still have it wound around part of the distance of the wiring from bit plane to jumper block. 

I didn't have the ability to solder to the bit plane pins, but I did have access to the pins of the backplane in rows 1, 2 and 3 above the core stack. Most would be blocked by SLT cards and connectors but there were two slots unpopulated on the 1130 core memory compartment one of them at E2 not that far from where the wiring originally was routed to F4. 

I would connect the wire directly to the D08 pin in the empty card slot - which is ground - since the common ends route to their SLT cards (e.g. B3) which internally connects the common to D08 of the card. This loses some of the shielding from induced noise, but hopefully the sense circuitry can still reliably detect one bits during reads. 

During all this hacking, I used my ohmmeter to connect to the two bit 7 low 4K sense connections on the B3 card. As long as they continued to have continuity and low resistance, nothing I did damaged the connections any further. This was my patient monitoring equipment during my open heart surgery on the core stack. 

I gripped the blue and white wires while applying pressure on the black, but it was not moving. I suspect it was pinched between the backplane walls and the plastic block on the core stack, something that yanked it off the pin but wouldn't let it move. I had to shift gears a bit, so I just snipped off the black wire as close to its entry to the backplane as I could.

I did a test connection of the black wire to a D08 ground pin on the backplane and then tested the three connections for the bit 7 low on card B3 - these were pins D02, B02 and D06 for the two sense lines and the common connection respectively. The readings were perfect. The only open question is noise pickup during memory operation. 

Tomorrow I will finalize the connection to E2 D08 for the common/ground line of bit 7 low 4K sense/inhibit lines. This is mainly a mechanical process, ensuring the wire will route between the cards in slots E3 and F3 as it goes up to the open slot at E2, plus insulating the splice I had to make from the snipped short original black wire. 

Making the repair on the core stack - part 3

REINSTALLING BACKPLANE + STACK INTO THE IBM 1130 FRAME

Once the core stack was screwed onto the backplane, the hard part was over. The backplane enters the frame from the back with the core stack side moving through the opening. The stiffener around the backplane sits against the frame. The various plastic holders and their hex style screws get attached to lock the backplane into its place on the machine. I put the two bottom holders partially on the frame, so that the backplane could rest of them while I attached top and side holders to refine the positioning. 

Two of the plastic holds cracked in my hand - a common issue with the loss of plasticizer in the plastic parts that were used in these machines. 

POWER CONNECTORS GO BACK ON THE BACKPLANE

The power rails reach the backplanes through push-on connectors whose wires run vertically along the sides of the frame. These provide the standard +6, +3, -3 and ground power connections. The memory circuitry also uses the +12V supply, which is connected to a single pin on a card slot for the voltage regulator card using a smaller push-on connector. 

TOP CABLES RECONNECTED

Three connectors plug into the T1, T3 and T4 slots near the top of the backplane, carrying the data, address and control signals between the CPU logic in other compartments and this memory compartment. I pushed them into place. 

SLT CARDS REINSERTED

The circuitry for the memory is implemented on SLT cards that fit in card slots on the backplane surrounding the area where the core stack is mounted. Rows 2 and 3 have room all the way across for cards. It is not fully populated because the core memory design for the 1130 is also used for the IBM 1800 system, which has additional locations outside the 8K which are addressed by an AUX bit. The 1130 does not use AUX memory locations and can dispense with the cards that support that function.

Rows 4, 5, 6 and 7 have the core memory stack in the middle, but columns A, B, M and N are available. Mostly these slots are used for the cards that support the sense/inhibit functions, each card handling two bits for a 4K portion of the 8K memory. The memory has 18 bits (a word in the 1130 is 16 bits, plus a parity bit each for bits 0-7 and 8-15) so we have eighteen cards for this function, sixteen of them in rows 4-7. 

POWER UP AND TEST OF MEMORY

I used the Storage Load and Storage Display functions from the CE switches to test the memory. A pattern is set in the Console Entry Switches on the front of the typewriter, then Storage Load will cycle through memory writing that pattern. Storage Display will cycle through memory reading every word. By varying the patterns I can be sure that the memory is being written and read correctly, without any parity errors. 

Alas, bit 7 in the lower 4K is still not correct. I popped the SLT cards for all the connections on the troublesome jumper blocks F4 and H4. All were good except for bit 7 low. The original fault was a break in continuity of one of the wires for a 2K loop on the core plane, while the other loop wire and the common connection to both was fine. Now, the common connection, which is tied to ground on the SLT card, is not connected.

LOOKING AT OPTIONS

The obvious but labor intensive approach is to remove all the jumper blocks, cards, power connections, take out the backplane and deinstall the core stack from it again. I could then repair the wire which evidently has pulled off of pin B13 of F4. This does come with the risk that other wires might be pulled when I put everything back together again.

I am considering ways to provide the common point connection without separating the core stack from the backplane. I am looking for ways to make this happen while preserving the noise prevention effect that the twisted triplet of wires provided for the bit 7 sense/inhibit signals. 

Making the repair on the core stack - part 2

BIT 7 WIRES SOLDERED ON THE JUMPER BLOCK PINS - EVENTUALLY

Just as I had done yesterday with the wires for bit 9 sense/inhibit windings, I soldered the wires to the appropriate pins (B12, B13 and D13) of the F4 jumper block structure. As I was working on the wires, the two sense lines broke off the core plane. This was a setback.

The metal that the wires attach to on the edge of the core plane is some kind of soft tin like material. This is probably the right material to bond the fine wires that suspend the cores inside the plane, but it is not designed for soldering. I think that IBM spot welded the wires to the metal during construction of the core stack. 

It was quite challenging to my soldering technique, but I did manage to get the metal to accept some solder in the end. The points where the wires were attached are right along the edge of the core plane and surrounded by many other small points. Very little separate, plus the triple wire cables run around that area. I had to use the stereo microscope and have a very stead hand to be able to heat the pin and wire without hitting the other points and wires that are less than a millimeter away.

I used the ohmmeter to verify the connectivity and low resistance matched the working sense lines, as well as checking that I didn't affect the nearby sets of wires where I had cut wires from the S-clip connectors. 

ANOTHER BAD CONNECTION FOUND

During that testing on the F4 and H4 blocks where I made my attachments, I found another signal that was bad. This one was for bit 11 in the upper 4K of memory. I was certain I had tested this and it worked properly a couple of days ago. Perhaps the work done near the S-clips and around F4 and H4 pushed another trace over the edge. So far, all the connection faults are on these two jumper blocks, which are the top two of the eighteen for the memory. 

I removed the wires from the S-clip area, routed them up to their pins on H4, dug out a relief channel in the plastic block, and then soldered them on. Another round of testing, this time covering every sense/inhibit wire in the machine, showed that no other connections are bad. 

INSTALLING CORE STACK BACK ON BACKPLANE

It was tricky to get the core stack remated with the backplane, because there were 10 pins sticking up from each of eighteen jumper block pads and all 180 had to fit through the tiny holes in the backplane. The slightest misalignment of a pin would cause it to jam against the backplane unless some wiggling got it to enter the hole. Cumulative misalignment in differing directions would render the wiggling ineffective.

This was quite a challenge as I tried to reinstall the stack. The IBM maintenance documentation for core memory replacement simply details the steps to remove it, ignoring any advice on how to get it to fit through the holes for installation. 

It took about a hour of very patient work before I finally (!) got the pins to all fit through the holes and could screw down the core stack. 

Core stack behind this with the pins sticking out of holes

The stack is held to the back of the backplane with four screws, which I installed. 

Attachment screw

VERIFIED ALL SENSE/INHIBIT CIRCUITS AGAIN BEFORE PROCEEDING

After the stack was securely mounted on the backplane, I once again checked the continuity and appropriate low resistance of all the sense/inhibit wires for the machine. Ten wires per bit, 18 bits in the machine, but all 180 connections are now working well. 

INSTALLED THE EIGHTEEN JUMPER BLOCKS ONTO THE BACKPLANE

This bonded the signals of the backplane circuitry and the core stack. It is now electrically joined and ready for the SLT cards and reinstallation into the IBM 1130 frame. 

+The frame where it will be installed