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.