Schedule February 2008

return to main 1401 Restoration Page
go to Team Bios

Contents:

Wed Feb 06 - general, Thu Feb 07 - Tape Team,
Wed Feb 13 - general, Thurs Feb 14 - Tape Team,
Wed Feb 20 - general, Thu Feb 21 - Tape Team E-Mails, Sat Feb 23 - Drop-In,
Wed Feb 27 - general, Thu Feb 28 - Tape Team,


Wed Feb 06 - general,


Thu Feb 07 - Tape Team

From Bob Feretich
TAU Debug Status 2-7-08 (Allen P., Ron W., James D., & me)

Allen installed the capstan drive motors in the tape drive, so we started the day looking at the Write-Backspace-Read problem that occurs on the drive.
  • Probing found a card in the GO circuit that had a bad up level. It was switching between -2.5 and -6V instead of 0 and -6V. Changing the card had no effect on the failures.
  • More probing showed that after the Backspace operation was complete on the tape channel, but about 4 milliseconds before the 1401 retired the instruction, GO was reactivated. Debug indicated that the 729 drive was not reseting its "Write Latch" during the Backspace operation. (For this case, the 1st half of the Backspace operation occurs in Write mode, the 2nd half should switch to Read mode.) We were guessing that the Write status being reported by the drive was confusing the TAU and it was reentering the second half of the operation. Continued troubleshooting showed that, when viewed from the Channel Cable, the Write latch in the drive was randomly turning on and off. However probing of the Write latch in the drive was inconclusive.
We switched to testing with the Tape Emulator....
  • At this point the 1401 stopped running. It would not even read a card from the 1402.
  • We isolated a failed card in the TAU to CPU interface that drove an input for A-Reg bit 1. It was stuck "on".  Replacing this card allowed the 1401 to read cards. (I have previously observed intermittent parity errors occurring on Tape Reads that mysteriously went away. I wonder if that failure had returned as a solid fail.)
  • We ran Ron's Write-Backspace-Read program to the Emulator. It ran, but with inexplicable delays.
  • We then tried Ron's Write-Backspace-Read Card-to-Tape program. It ran with no error lights. The program reads each record written and prints the result below the data it wrote. The record read was always the first record written on the tape.?? It was as if two Backspaces rather than one were being executed. It also ran slowly with the same random delays.
  • We then ran Diagnostic 5000 Card-to-Tape. It ran with out errors and at full speed several times. The intermittent errors reported last week did not occur.
Conclusions:
  • The TAU is getting confused at the end of a Backspace operation. Perhaps the confusion is being caused by the 729 tape drive.
  • One of the cards we changed today may have fixed the intermittent error that we observed last week. Or, it could just be the alignment of the planets.
  • The Write Tape operation seems solid to the Emulator.
  • Either the Emulator has a new bug in handling the Backspace operation or the problem which was effecting the 729 drive is now also impacting the Emulator.
Regards,
Bob

from Allen J Palmer (Fri, Feb 8)

SMS cards ……….. conditions & replacements

The condition of the SMS cards is very poor. When tracking a ‘bug’ it is frustrating because of the intermittent failures & the lack of reliable replacement cards.

We have very few replacement cards for the TAU. I suggest we strip all the TAU cards from the Visible Storage 1401 and set up a test procedure to test them by type.

Ron Crane & I removed all the MDX cards from the 729 V & he tested them all & repaired those that failed.

To be honest, I would test all the cards in the TAU / 729 using that same process, test all by type.

The only replacement cards for the 729’s is to take one out of the other machines. We need to take cards from the drive in VS, test them & put into our replacement supply.

Defective cards … Defective cards are accumulating and with no one repairing them we are having problems locating problems using ‘card replacement’

If we built a ‘true’ SMS card tester where we could vary voltages & signal levels & shapes it would allow for more detail testing of cards. We had these type of testers when I worked at the Poughkeepsie plant.

It would take some time to build this & test the cards but I believe that in the long run it would save time & lower the frustration level

We have been working on this intermittent ‘backspace’ problem for over a year, many defective cards in the TAU. We have replaced one of the cards in the ‘GO’ latch circuit twice, while finding at least 6 – 8 other defective cards shooting this one problem.

I would like us to have a discussion on this.

Allen


Wed Feb 13 - general

Response from John Van Gardner about image of 513 punch and die
Seeing your picture of the 513 punch die reminded me of something I saw in 1955 at the Poughkeepsie plant. Before I went into the navy I worked in a machine shop making parts for sock knitting machines. Ever since then when I see a part from something I visualize how I would go about making one of those. After the navy when I went to work for IBM one of the first parts that caught my eye was the 80 column punch dies. When I went to 704 school in Poughkeepsie at the plant I used to wander around after school just looking at all the things they were making. At that time they had shipped the first SAGE system and had built a plant in Kingston to produce the rest of the SAGE systems. They had built a large wooden raised floor for the SAGE and had the first 6 production 704 systems on that floor. Next to that was an area all glassed in where they were making CRT tubes for the 706 electrostatic memory units for the 701 and 702 systems. Next there was a large area where a lot of women were stringing magnetic core donuts on wires and making core planes. Then there was an area where the 700 series pluggable units were being made. Lots of women soldering components into the units.

They were also building electric typewriters there with lots of small stamped out parts. On the back side of the plant there was an electroplating department and a paint shop. I was having a ball taking tours every day after school. One day I came across the area where they were making the punch dies for reproducers. It was a surprise because I thought they were an Endicott machine. Anyway I got to see how they did it.

They had a machine tool there that looked like a combination punch press and milling machine. It had a movable carriage that could move left and right. Attached to the carriage was a jig that held the blank piece of steel that would become the reproducer punch die. Above this carriage there was a table that did not move with the carriage. On this table there were two rectangular steel punches the size of the holes in IBM cards. These two punches were spaced exactly 40 card columns apart so that when the left punch was punching the hole for column 1 the right one was punching column 41. These punches were guided by replaceable hardened steel guide blocks through a hole in the table onto the target piece of steel.

After the first set of holes were punched, and the punches raised, the carriage was cranked the proper distance to space to the next set of holes numbers 2 and 42. When all the holes had been punched the new part was removed and heat treated to harden it. The holes had a slight chamfer where the punch had entered and a burr where it exited . A surface grinder was used to grind below these two defects and the die was left with perfect holes.

Van Gardner

  • We had quite a bunch of folks: Ron Williams, Bob Erickson, Frank King, Allen Palmer, Bill Flora, Dan McInnis, Joe Preston, Judith Haemmerle, Stan Paddock, Robert Garner and Ed Thelen. Jim Somers visited.

  • Bob Erickson and Judith Haemmerle exercised the 513 summary punch - verifying that it could reliable read and punch - seemingly endlessly. RArrRArrRArrRArrRArrRArrRArrRArr for an hour? two?

  • Bill Flora seemed to have a problem with the 1402 card punch - popular rumor suggested that an untrained person tried to replace the punch die?

  • Allen Palmer exercised the 729 tape unit seemingly endlessly. The machine gun like chatter of reading and writing short records at various speeds filled the air - worse than a war zone.

  • Frank King, Joe Preston and Stan Paddock worked on a key punch - silently :-))

  • Jim Somers visited us during lunch and gave the progress of planning for demos - also updates on museum happenings and the Babbage Machine.

  • We are looking for more Restoration storage - life in the 1401 restoration room is getting cramped, and the possible coming of the "Connecticut 1401" is causing concern for storage of parts and assemblies not currently used.

  • Ed Thelen finally found a suitable job :-)) Janitor - he swept and wet mopped the 1401 restoration area - probably not done for a year? and used "Simple Green" and a knife to remove many of the rubber marks from the floor. (Bob Erickson is sensitive to the more exotic solvents we were going to use.) This is Allen in "his corner" studying - note the clean, relatively mark free floor :-))
    Judith caught this picture of Ed mopping Judith says that she used her video camera to catch Ed on the floor scrubbing with Simple Green. Some character said that was a waste, a still camera would have caught all the action there was :-(( ;-))

  • And we just gotta have some fun :-)) Ron Williams attempts to capture an image of Bob Erickson onto the 1403 printer.

  • Dan McInnis punched the object deck of his adaptation of the BIG PRINT program adding some tape activity, via the PC to Keypunch.

  • Day's end. View of the Entry Way and 1401 room. Stan has connected the printer to the computer system. We are wondering if this work station could be somewhere else so that our little museum could be returned to this entry way.


Thu Feb 14 - Tape Team


Wed Feb 20 - general

  • Present were: Ron Williams, Bob Erickson, Frank King, Bill Flora, Glenn Lea, Joe Preston, Judith Haemmerle, Stan Paddock, Robert Garner and Ed Thelen.

  • Allen Palmer called in telling of his trouble yesterday (Tuesday) including inability to access the Internet. It turns out that the ?modem? in our 1401 room was hung, and needed RESETing by powering it off (pulling the power plug) for a minute, then plugging it back in again. - Hmmm - just like a computer :-((

  • Bill Flora explained that the troubles with the 1402 punch seemed to be the punch drivers. The trouble either moves or temporarily quits when moving the driver cards. (See Saturday Feb 23)

  • Joe Preston is still working on 026 key punch #3. Stan Paddock found a loose/shorted connection in the read station of 026 key punch #4 which caused punches of a numeric 2 to actually punch a hole as numeric 3 :-( Fixed.

  • Bob Erickson and various folks are building shields for the now working IBM 513 :-))
    Something about "Nicht fur fingerpoken".

  • "We" are having an interesting time with trying to make the tapes do a proper backspace. Some one found a splice in the middle of some reel, and while this is tacky, it is not causing our problem. Here Glenn is unwinding into the trash can.

  • We may have had another case of improper loading of cards into the punch side of the 1402 - (They should be reversed from the read side so that they can merge into the center pocket correctly.) None of the existing 1402s in the museum have labels remaining - they take a beating in service. So we are considering what kind of label to make. Here is a label on the input hopper of our 083 sorter.


Thu Feb 21 - Tape Team

Various Tape Oriented E-Mails

  • from Allen Palmer - 2/22/2008 6:51 PM

    Van,

    What can you remember about the 'backspace' logic. When we issue a simple backspace command the drive backspaces then drops the'' backspace logic level'' but ''go'' remains up resulting in the tape now moving forward in a run-away mode. We have been through the TAU logic and it looks as though the write logic level is active (not sure - because latches are 'on' - 'reset off' & then coming up again. I have rebuilt the prolays, swapped in a different set, and adjusted the gaps both statically & dynamically. Still getting the old fashion 'bouncy' start envelope. Swapped the plastic rollers - not change. I took a number of pictures last Tuesday before and after different adjustments. I will get them into an email or you to look at. The program we are running is a write, backspace, read. We can i/e through up to the backspace & the single cycle through and it fails like clock work.
    Think about it.

    Allen j Palmer

  • from John Van Gardner - 2/23/2008 9:06 AM

    Allen,

    I have been thinking about your problem and it doesn't sound like a drive problem but more like a problem in the TAU backspace logic. If you can write a bunch of records on tape and rewind it, then read the records with no problem this would point to the TAU. You could even single cycle the read commands to exercise the prolays more.

    I am attaching a sequence chart that will help explain backspace. One thing to keep in mind is that any backward command (Backspace, Backspace file or Rewind) after a write command caused a write forward to finish the record gap after the last record written. If you were writing over old data and did not do this you would end up with a 3/8" gap after the last record.

    The Backspace command turns on the Backspace latch in the TAU and this starts the delay counter running in millisecond mode. Assuming the tape to be in write status the "Select and write" response from the drive set "Go". A write forward before backspace is now executed. D50 from the delay counter resets "Go" and D96 turns on the "backward latch. This sets backward status and read status in the tape unit. When the delay counter runs to D160, it turns on "Go". The time between D96 and D160 allows the prolays to change to backward status. When the delay counter runs to 180 read condition is turned on to gate the final amplifiers and reset the delay counter. Tape will be moving backward and searching for the check character of the record.

    When the check character is read into skew reg. A, the first bit starts the read clock. RC 7 will turn on the RDD latch and start the delay counter. Since this is backspace the RDD will be in milliseconds mode. The delay counter will keep running as the tape moves from the check character to the last character of the record. Since the RDD is in millisecond mode and the conditioning circuits are searching for an RDD 16, there will not be sufficient time to reach it between the check character and the last character of the record. On a 729 II in low density the check character is written 250 us after the last character. RDD 16 represents 600 us or 0.6 ms. When the last character of the record is read into skew reg. A, the first bit starts the RC again. RC 4 resets RDD and RC 7 starts it again. This continues until the first character of the record is read. The RC 7 of the first character starts RDD. Since there are no more characters to be read, the counter runs to RDD 16 which resets read condition and prevents any further information being set into skew registers. At RDD 22 for 729 IV, or RDD 38 for 729 II, the Go latch is reset. By RDD 64 tape has come to a stop and the 64 pulse is used to reset backward. The counter keeps running until RDD 152 when the tape control circuits are reset.

    There is a sequence chart of the Backspace 729 operation in the ILD (Intermediate Level Diagrams) Fig. 197. The best thing about this page is it gives you the ALD page of the actual logic cards where you can find pins to connect your scope. With all those fancy scopes out there you shoule be able to capture a good picture of what is actually going on especially since it fails every time on single cycle.

    I hope this helps. It may be more than you ever wanted to know. My wife says when someone ask me the time I tell them how to build a clock.
    Van Gardner

  • From Bob Feretich - 2/23/2008 2:31 PM

    In the previous debug session, we traced the problem to GO being reactivated at the very end of the Backspace operation.

    According to the TAU handbook:

    • At RDD-38 (about 5.7 msec after the tape has backed up over the record), The GO latch is reset.
    • At RDD-64 (about 9.6 msec after the tape has backed up over the record), The Backward latch is reset.
    • At RDD-152 (about 22.5 msec after the tape has backed up over the record), The Backspace latch is reset. (this is the final action of the Backspace instruction).
    All the above things happen on schedule, however at about 20 msec after the tape has backed up over the record, Go is turned back on. This is not supposed to happen.

    Our debug from last time involved the Tape Drive being stuck in Write mode. When a Backspace instruction is executed after a Tape Write instruction, the Backspace operation has two phases. In the first phase the tape moves forward erasing the tape to leave a good inter-record gap (IRG) after the the written record. In the second phase, the drive is placed in read mode, Backwards is asserted, and the tape is backed-up to the previous IRG.

    Our interface probing showed that the Write latch in the tape drive was not being reset. Set_Read_Mode was being asserted, and while it was asserted, Select_Ready_&_Read was active, but Select_Ready_&_Write stayed active the whole time. (Note that Set_Read_Mode was not active.) When Set_Read_Mode was released,  Select_Ready_&_Read dropped and Select_Ready_&_Write remained active.

    Probing inside the drive initially confirmed this, but later the symptoms disappeared. Shortly afterward, the 1401 failed completely, and we got distracted into fixing that bug.

    I believe that Select_Ready_&_Write being active is fooling the TAU into thinking that it was in the first phase of the Backspace instruction and that some logic executed the phase 1 to phase 2 transition, when it was supposed to be ending the instruction. Every odd Delay Counter decode from DC-129 to DC-151 will cause block B9.60.11.1-3A to set the GO latch.

    Trouble shooting should be focused on determining why the drive is getting stuck in Write Mode. Somewhere in the 729, between the input relays and the Write Latch, the Set_Write_Mode signal is getting stuck on.

    Regards,
    Bob Feretich

    One more thing, card DGY @ 02B2AD15 should be replaced. It's P output low level is weak. We replaced the card during the last work session, but the tape movements became more violent (prolays popping every couple milliseconds) and it didn't fix the problem, so I put the original card back in. Once the stuck Write problem is fixed, the new card should not cause the violent behavior.


Wed Feb 23 - Saturday Drop-in

  • Present were: Ron Williams, Tim Coslet, and Stan Paddock. Ed Thelen visited.

  • Tim Coslet tested the "intermittent" punch driver cards found during card swapping on Wednesdays. Unfortunately, as far as he could tell, they were just fine. He did not connect up an output load into +45 volts. He was having an interesting enough time trying to get the edge triggering of the set side of the flip-flop working correctly with the level triggering of the RESET side of the flip-flop. Maybe out test jig could stand some more enhancement - but intermittents are always a bear to chase in any case. Voltage margins? vibrations? temperature?

  • Sometimes it seems good not to ask too many questions - Something about Stan and the 1401 power-up sequencing relays - Ron Williams left Stan with that challenge - and instructions to get the fault fixed before Wednesday. The current symptom is that "A" and "B" register lights don't work, and memory does not work :-((


Wed Feb 27 - general

  • Present were Ron Williams, Frank King, Allen Palmer, Glenn Lea, Bob Feretich, Joe Preston, Judith Haemmerle, Stan Paddock, Robert Garner, Grant Saviers, and Ed Thelen.

  • Power up sequencing is getting "interesting". As reported last Saturday, the 1401 box would not power up all the way. This morning (Wednesday) it would power up just fine - but then power itself down again a few seconds later - and this was not tripping a power supply that required resetting.

    PowerUp Sequence Overview

    PowerUp Sequence Relay Group

    Is that a strange "6" or malformed "8"

    Well, there are 4 terminal strips here

    135 K byte drawing
    OK - lets unplug the 1403 and the 729 tape drive and see what happens
    Hmmmm, power stays up - lets plug 'em back in one at a time -
    Hey - power now stays up, no problem
    - well at least not until some future VIP demo :-|
    (Murphy's 2nd? Law)
    Lets go to lunch -

  • Lets work on the tape back space problem.
    The following is from Bob Feretich
    
    The first part of today's session was lost to a 1401 power problem. The 
    system kept shutting itself off. The 1403 and 729 were disconnected, and 
    the problem went away. It did not reoccur when the 1403 and 729 were 
    reconnected.
    
    The TAU was rewinding tape (slow speed) during the Backspace operation. 
    We found a problem in the Read_Cond circuit of the TAU. During 
    Backspace, a 1 usec pulse was arriving to turn on the Read_Cond latch. 
    Over the last two weeks the latch had grown too slow to be set by the 
    the pulse. (The circuit was working before.) Since the latch was not 
    being set, the Read Amplifiers were not being turned on, therefore the 
    tape would rewind completely while looking for a record. We replaced the 
    "set" part of this latch and this problem was fixed.
    
    However, we still did not return to the previous problem symptoms. Now 
    it appears that errors are occurring during Write operations and GO is 
    not being reset when it should in the second stage of the Backspace 
    operation.
    
    After we quit for the day, we started to suspect that one of the other 
    circuits on the quad 2-inp NOR that we replaced may have been bad.
    
    Regards,
    Bob Feretich
    

  • Today's keypunch gang

  • Frank King and Glenn Lea worked on improving/aligning the cover latches on the 1402

  • Ron Williams hopes that the schematics (ALDs) for the possible "new" 1401 match better than with our current equipment. The 1401 ALDs do not match the interface logic to the 1406 added memory - which makes fixing the "Scan Print" software debug feature very difficult. Ron says it is almost like the 1406 came from another machine and was just plugged into this machine.


Thu Feb 28 - Tape Team



Go to
March 2008
go to Team Bios