Schedule January 2009

Wed January 07 - general

• Lots of folks: Ron Williams, Bob Erickson, Bill Flora, Frank King, Glenn Lea, Joe Preston, Ed Thelen, Robert Garner

Thursday January 08 - Tape Team

From Bob Feretich

TAU Debug Status - Thursday, 1/8/09 (Jeff S., Sam S., Allen P., Ron W., Grant S., & me) We moved the 729 Tape Drive Emulator to the DE system. It now sits at the end of the tape channel after the two real 729 drives. Note that it contains the terminator resistors for the Tape Channel, so it must be powered on if the real 729 drives are to be used. The power is connected so that it will automatically power up and down with the DE 1401. If you use the DE 1401 and ignore the Emulator, everything will work as before. If you turn off the power to the Emulator or change the power connections then expect the real tape drives to stop working.  (Basically, keep your fingers off the Emulator hardware and everything will be fine.) While working, we discovered that the Write Tape Mark logic in the TAU had failed. We replaced a card to fix the problem. We ran multiple programs to test the Emulator in conjunction with the real drives... Print from Virtual Tape: We opened drive 1 and drive 4 within the Emulator. We mounted the PcPrint object tape (produced by Rope) on virtual drive 1. This program reads records from drive 4 and prints them to the 1403. We mounted the Autocoder listing file (produced by Rope) of this program on virtual drive 4. We then pressed the "Tape Load" button on the 1401 console. The 1401 booted from virtual drive 1 and executed the program, which printed the listing file from the PC to the 1403 printer. Tape Copy: Starting with the above configuration, we unloaded the PcPrint tape from virtual drive 1 and replaced it with the PcTapeCopy object tape. This program reads records from drive 4 and writes them to drive 5. We also mounted a scratch tape on a real 729 drive and set it to be address 5. We then pressed the "Tape Load" button on the 1401 console. The 1401 booted from virtual drive 1 and executed the program, which copied the tape image the PC to the real 729 drive. Print from Tape: Starting with the above configuration, we unloaded the PcTapeCopy tape from virtual drive 1 and replaced it with the PcPrint object tape, the same program we ran in step 1. We also closed virtual drive 4 in the Emulator and set the address on the real 729 drive to 4. We then pressed the "Tape Load" button on the 1401 console. The 1401 booted from virtual drive 1 and executed the program, which printed the listing file from the the real 729 to the 1403 printer. We compared this listing to the one generated in step 1. They were identical. We tried some programs with the other real 729 drive. (the first one restored) Its operation was intermittent. Various errors and run aways occurred. At one point, we appeared to have successfully run a TapeCopy between the two real drives, but the intermittent failures on the original drive became worse and we could not verify the results of the copy. We also found a bug in the Autocoder assembler. I'll document this bug in a separate e-mail. The "enhancement" that I made to the Emulator's USB driver has a bug that causes Windows to BugCheck if during a session, all virtual drives are closed, then the user tries to reopen a drive. I'll work on a fix for the next session. Regards, Bob

from Grant Saviers

On Thursday, 1/8/2009, I compared the CT and DL SMS card schematic books and copied schematics that were missing one to the other. I also compared the merged books to the A size SMS schematics in the white binder on the document shelf and made enlarged or reduced copies as needed to make the contents the same for all three books. One exception is the DL books have several revision levels of schematics for many cards and the notebook and CT books only a single copy. Overall about 25 schematics were missing in one book or another. The CT books reproductions are significantly better than the DL versions, which I think were printed from fiche or microfilm. The CT schematics appear to be good xerox copies of originally distributed schematics, so refer to them if DL legibility is a problem. I think the books are fairly complete for the processor and memory as several schematics that were noted as missing are now available. I will check this further against the "used on list" that Ed produced some time ago. I'm still unclear about what we have/don't have for tape drive card schematics, so if anybody can shed some light on this topic, I would appreciate it. Grant

from Allen Palmer

Not sure what you mean relative to the ''tape drive'' card schematics. The schematics for these cards are in the 729 logic books. I can help you find them if that is what you are looking for. There is also a 'listing page' of 'where used'

from Bob Feretich

I ran across a few missing SMS schematics for TAU cards, but there was no pattern to what was missing. I seem to remember that a couple years ago when I debugged a 1406 memory unit problem, it seemed that many 1406 card schematics were missing.

Saturday January 10 - 2nd Saturday

From Stan Paddock

I thought I would pass this information on to you and you could do something with it. Ron Williams, Bob Erickson and Stan Paddock showed up today (Saturday) to work at the CHM. Bob and Ron continued their work from last Thursday on the CT 1401 system. They located a bad card connector pin in one of the 1401 CT gates. The pin was replaced today and the weird problem with the printer was fixed. After several hours of more work, they isolated and fixed the 1402 card reader problem. Ron loaded and ran his "power's of 2" program. The card reader, computer and printer worked as expected. (hurray) Just before we shut the CT machine down, we tried punching a blank card without Bill's help. The machine said "Where is bill?" and refused to do anything. Stan did a couple of dog and pony shows for tour groups that were brought in. One group was allowed to listen to the radio music from the DE 1401. They were impressed. Peter Christy came in with the remaining Fortran cards from his father. Bob Erickson helped using the IBM 413 to reproduce some cards that the HP card reader would not accept. After Stan started the first deck, Peter did all of the rest. Peter said the Microsoft Fortran compiler accepted most of the Fortran code as written years ago. Peter said he would write up some text describing what his father (age 92) is attempting to do with this data. Stan is continuing his course on the internals of a teletype ASR 33. Stan Paddock San Jose, CA

Wednesday January 14 - General

From Stan Paddock

On Wednesday, January 14, 2009, the following people came to the CHM to work on 1401 equipment and various other items: Ron Williams, Bob Erickson, Bill Flora, Joe Preston, Glenn Lea, Stan Paddock, Judith Haemmerle. Ron, Bob and Bill found the "last" problem with the 1402 card reader on the CT machine.!!!!! There was an interface connector block that was making intermittent connection. Bill replaced it and we are in business. Joe and Glenn brought the second 729 tape drive on the CT machine to life. There were a multitude of fans that complained about a lack of oil. The "organ donor" helped again. Stan has completer the conversion from our old 475MHZ IBM PC in the foyer to the new 3.5GHZ given to us by the CHM staff. Several weeks ago, an e-mail file was sent out with various ASCII art objects included. One of them required a program to print it with the ability to overprint. Currently, only the DE machine has this capability. Stan wrote the program, punched the program and the data and ran it on the DE machine. Everything worked as planned. Stan has been working with Karen Kroslowitz trying to get credit to Bob Erickson's neighbor for the donation of the Teletype ASR 33 we currently have in the restoration room. Karen has not said yes or no to the plan yet. Stan regrets that he will be in Boise, ID next week and will miss the fun and frivolity at the CHM. Stan

from Robert Garner

The bent SMS socket pin that Ron found (floating T level caused the 1403 to always want to print...)

CT1401 PowersOf2 Works

CT1403 PowersOf2 Works

Thursday January 15 - Tape Team

TAU Debug Status - Thurs. 1/15/09 (Jeff .S, Allen P., Grant S., Ron W., and me)
We continued our work on the DE 1401 System.

• I tested a new version of the Emulator Windows driver. We can now open, close, and reopen virtual drives at will. The repository has been updated.
  
• I increased the default tape buffer size in the driver from 2MB to 20MB, the estimated size of 2400 ft of tape recorded at 800 CPI.
• We attempted the Tape Copy of a very long file (16MB+) from a virtual drive on a wireless notebook PC to a real 729. We filled the tape. The 729 was set to 200 CPI, so it was able to hold 31,279 80-character records. The copy program would try to write a record three times before reporting an error. Three errors were reported, all within 11 records of each other about 20% of the way into the tape. There were many other retries writing the 729, but the Backspace/Skip/re-Write error recovery worked for them within the three tries. We didn't detect any retries occurring reading from the Emulator.
• We attempted to copy the newly written tape back to a virtual drive on the PC. This failed. Somehow the Emulator thought that it was being read from rather than written. We need to troubleshoot this next week. Therefore we were not able to verify that the data written to the tape is correct. All we know is that the TAU didn't detect any errors while writing it. (Except for the three records mentioned above.)
  
• We want to create a tape of diagnostic tests. To do this we need to punch the diagnostics, including the "create diagnostic tape" utility, to cards, then run the utility that reformats the tests for booting from tape. Jeff wrote a program to punch a file from the PC. Jeff debugged his program and it was able to punch its own source file to the 1402.
• The first restored 729 Model V (let's call it serial number 1 (729V#1)) went into high speed rewind again when it was near the beginning of a tape, resulting in folding a wad of tape onto the reel.
  
• Later, the high speed rewind motor on 729V#1 also was making smoke, so Allen disconnected it.
• Even later today, Jeff noticed that the light beam that is used to detect the amount of tape on the take-up reel is focused too low and is only marginally illuminating the detection photocell. Allen, you may want to check this out next week.
• The other 729 (serial number 2 (729V#2))  will not rewind in high speed mode. Its high speed rewind lamp is off and may be burnt out. Ron and I speculate that the 729 detects the lack of current through the lamp and disables high speed rewind.
• 729V#2's take-up real is resists movement. Either the manual release button is not completely releasing the clutches or the bearings are having trouble.

Regards,
Bob

Wednesday January 21 - General

Frank King, Glenn Lea, Ron Williams worked on the 1403 printer print hammer time-of-flight adjustments. These are screw type adjustments accessable from the back of the print hammers at the back of the printer. The picture to the right is (hopefully) a before picture. ;-))

Ron Williams helped find a bad socket pin connection in the CT 1401 that was open, which caused a signal to float, causing an braintwisting intermittent problem.

Ron made this bullet appearing thin to help remove Push?Pull? the pin from the socket to enable pin replacement.

Bill Flora and company have had night mares trying to get the CT 1402 card reader to read cards. A few weeks ago he found a bad connection inside a read brush connection block. That helped a lot - the reader went from not working at all to only really flaky.

This is the site of the recent battle ground, the lower right front of the 1402		A typical relay in the battle ground area
A broken contact that is supposed to contact a relay plug-in		from here
Just for fun, gotta show some indicator fuses, when they pop, the bottom part hits the bar at the bottom, causing warning lights		And an informal field modification?

Thursday January 22 - Tape Team

TAU Debug Status - Thurs., 1/20/09 (Jeff S., Sam S., Grant S., Ron W., & me) We started the day noticing the DE 729 #2 was resisting the movement of reels when the brakes should have been disengaged. The take-up reel was making scraping noises when moved. The supply reel didn't make scraping noises, but the tape loop in its vacuum column would move very high often resulting in pulling the tape out of the column. So instead it would make vacuum column noise. Grant located a mechanical interference on the supply side and made an adjustment. See the 1401 log for specifics. My main goal was to troubleshoot the real tape to virtual tape copy problem. Before we started trying to recreate the error scenario, we tried to perform some basic write and read operations to the real tape drives using the TAU Control Panel. The TAU was reporting frequent intermittent errors on both drives #1 & #2. We noticed the starting from the load point, writing to the tape on drive #2 would result in the following error sequence... False compare error (lights showed the A-Reg=B-Reg) False compare error (lights showed the A-Reg=B-Reg) Valid compare error & A-Reg VRC error (lights showed the A-Reg bit B was dropped) Valid compare error & A-Reg VRC error (lights showed the A-Reg bit B was dropped) Valid compare error & A-Reg VRC error (lights showed the A-Reg bit B was dropped) Able to write to a long stretch of tape without errors The compare error should occur if incoming data in the A-Reg is not equal to the data latched in the B-Reg. The B-reg is more sensitive to weak input signals. We found that the false errors were initially being reported as a bit 1 miscompare. We were writing bit 1 as a 1. When the data was read back, ... B-Reg bit 1 = 1; A-Reg bit 1 = 0; thus the compare error was triggered and the state of the TAU was frozen; however, even with the clocks stopped, 650 uSecs later the A-Reg bit flipped to 1. We don't know if the flip was being caused by noise or if the latch had become meta-stable due to a poor input level. Replacing the SMS card for A-Reg bit 1 eliminated the false error. After replacement, the reproducible sequence was ... Valid compare error & A-Reg VRC error (lights showed the A-Reg bit 1 was dropped) Valid compare error & A-Reg VRC error (lights showed the A-Reg bit 1 was dropped) Valid compare error & A-Reg VRC error (lights showed the A-Reg bit B was dropped) Valid compare error & A-Reg VRC error (lights showed the A-Reg bit B was dropped) Valid compare error & A-Reg VRC error (lights showed the A-Reg bit B was dropped) Able to write to a long stretch of tape without errors Because of the reproducibility and the lack of errors beyond this point, we believe that this was a result of a bad region of tape at the beginning of the reel, so we started troubleshooting the "tape copy" bug. Ron ran a program the wrote to both tapes #1 and #2. At the end of the program, we observed... The sequence Write Tape #1, Write Tape #2, Backspace Tape #1, Backspace Tape #2, Read Tape #1, Read Tape #2 was performed many times, and appeared to work. Tape #1 rewind was executed. Tape #2 rewind was executed Program Halt However, tape drive #2 would start running away in the forward direction. The TAU CE Panel showed that the "Go" signal was stuck on. The symptom that we observed last week was that after reading from a real drive, the 1401 would try to write to a virtual drive, but the Emulator would be in the middle of responding to a Read operation that it erroneously thought was directed to it. This symptom would have resulted if the TAU had not dropped "Go" after the read from the real drive. So our theory was that the TAU's GO latch was not being reset at the end of read instructions. Unfortunately, it is difficult to trigger a scope on the absence of this reset. It is supposed to occur several milliseconds (>11 mSec) into the operation; and the reset pulse is only 1 uSec long. We needed to bring out Robert's HP logic analyzer and probe the 10 signals that were to produce the reset pulse. After a three hours of relearning how to use the logic analyzer, we were able to trigger the two analog oscilloscope channels from the trigger formed by monitoring 10 state channels. Now, because we could locate the instant in time where the 1 uSec pulse was to occur, we were able to locate the pulse and trace the pulse from its source into a gate that was too slow to respond to it. We replaced that card and the runaway problem was eliminated. Again, before we started trying to recreate the Tape Copy error scenario, we tried to perform some basic write operations to the real tape drives using the TAU Control Panel. The TAU was reporting frequent intermittent errors on both drives. There was no obvious pattern to the errors, except that bits were being dropped in the A-Reg, which is a symptom of weak signals on the Read Bus. We tried writing and reading records to/from Emulated drives. We did see one or two skew errors in several minutes of operation, but the error rate was much much lower than that which we were seeing on the real drives. It was too late in the day to start into a problem of this type, so we ended our session. Regards, Bob

The Tape Team developed a pseudo Mag Tape box which emulates (as seen by the 1401) up to 6 mag tapes drives.

Here is an interface unit, the square chip on the right has more memory and compute power than the 1401

With its debug hardware

The Tape Team present Jan 22, note the logic analyzer and scope

Logic analyzer probes in DE 1401

Tape Adaptor Unit (TAU) clock trains

Sam Sjogren sent some pictures

Bob Feretich pondering

Jeff Stutzman ;-))

And Sam Sjogren

Saturday January 24 - 4th Saturday

Wednesday January 28 - General

• Present were - Ron Williams, Bob Erickson, Frank King, Allen Palmer, Bill Flora, Joe Preston, Stan Paddock, Robert Garner, Ed Thelen

• Frank King and Bill Flora trying to figure why a CT 1402 card punch warning causes the card reader side to hang up

  Bob Erickson on the floor also.

  Bob showing that there are three versions of the same wiring page for the CT 1402 card reader - unfortunately, the wiring in the machine does not match any of the three :-((

• Joe Preston worked on the CT tapes (mod 2), Allen Palmer worked on the DE tapes.

• Ed and Stan tried to find why the "new" PC in the 1401 room is so slow - I has only 1/4 gig of DDR memory working :-| Ed thinks he has 1 gig of DDR memory at his house, will bring it next Wednesday.

• Robert Garner went off to a conference with Karen Kroslowitz CHM Registrar

• Frank King wrestled with a replacement status lamp for the DE 1403 printer. The seeming spare barely glowed. Ron Williams remembered that Ron Crane had soldered wire leads on to some correct lamps for status display. We called Ron Crane who pointed out that the correct envelope was infact correctly tagged - all we had to do was read :-(( We did open our eyes, and the story ends happily ;-))

Thursday January 29 - Tape Team

TAU Debug Status - 1/29/09  (Jeff S., Allen P., Sam S., Grant S., and me)
As the subject stated, we copied a file from 729 #1 to the PC today. The key was fixing the TAU Reset GO problem, which we fixed last week, and a bug in the Emulator. But let's not get ahead of ourselves...

The day started with the TAU unable to access any drives, real or virtual. Write operations were hanging with GO=off, Write=on, FirstChar=on, ReadCond=on, and WC=7. Before we made any progress on shooting the bug, it went away. (About 15 minutes after power on.)

We then encountered many A-Reg VRC and Compare errors (A-Reg!=B-Reg) on both 729 #1 & #2. These problems did not occur on virtual drives. In addition 729 #1 high speed rewind was shredding tape and making the rewind motor smoke. While 729 #2 was pulling he tape out of the supply side vacuum column and halting. (I credit Allen for not giving up and heading for the nearest bar at his point.)

We observed the HS Rewind motor on 729 #1 becoming very hot while not moving, even though it was mechanically isolated. Since it is a 3-phase motor, our guess is that only one phase was being powered. (Allen, check out Relay 5 closed while Relay 1 is open. Just a hunch.) To proceed, we disconnected the rewind motor on 729 #1. Note that both 729s on the DE system now have high speed rewind disabled.

Since we were seeing Read Bus errors (A-Reg VRC), we checked the NRZI waveforms the drive was transmitting. From either drive, on every bit, we were receiving a less than 8Vpp signal with the positive hump clipped at ground. Further troubleshooting indicated the Emulator was responsible for clipping the signals. We found that a ground connection was missing on the Emulator's Analog Board. We applied a temp fix to jumper the connection to ground and the clipping problem was solved. The ground connection was needed to force the Emulator off the Read Bus when it was not selected. Without the connection it would only be "mostly off the Read Bus".

We then checked out the Read bus signals from each bit on 729 #1. All bits were very good except the B-bit which was very noisy. We traced the noise to the B-bit's delay card  (BJ@02K06). We were driving the passive delay card at pin A and tapping he result at pin A, so the delay was zero, but the card was still generating a lot of noise. We had seen a similar problem over a year ago. We replaced the card with one from the 729 Mod II donor machine and the waveform was clean.

We then performed some operations from the TAU console. We saw some skew errors, but many records were processed correctly between these errors.

We tried to copy a files from the Emulator to 729 #1. Several attempts failed, with continuous write errors being reported  on the 729.  We were about to quit for the day when Jeff insisted that we give it another go.  We did. The Tape Copy from PC to 729 #1 was successful. We then ran a program to print  the contents  of the tape on 729 #1. The 1403 listing was correct. Next we ran Tape Copy to copy from 729 #1 to the PC (Emulator virtual tape drive). The newly created PC file contained the same data as the one we started with. No errors were reported during this sequence of programs.

Just to close things off, Jeff downloaded his new rev of the Emulator firmware which implements the Rewind&Unload operation. We were able to repeat the above test without errors, so the new rev didn't break anything. We then executed a Rewind&Unload from the TAU console. The 1401 was happy and the GUI notified the user that "The 1401 has detached the tape drive and the user needed to press the UNLOAD button" to download the results. This means that his new firmware worked. However, when we pressed UNLOAD, the server rebooted. That means that we have a kernel driver issue in the follow-up of the Rewind&Unload operation. Don't try to execute Rewind & Unload until we fix it. (Rewind is fully operational.)

We have a solid bug in the driver Rewind & Unload code which should be easy to fix. But, we are facing some difficult intermittent TAU problems in accessing tape drives. I suspect that (for now) there are two or three intermittent problems that are combining to make our sessions interesting. Hopefully they will become consistent enough for us to shoot them soon.

Regards,
Bob Feretich

---

From Sam Sjogren-

And after smelling smoke three times in the machine room (a new one-day record, I think), I got home to a similar smell! One of my UPSes had died horribly. What a day...