Schedule April 2009
return to main 1401 Restoration Page
go to Team Bios
Contents:
Wed Apr 1 - General
Wed Apr 8 - General, Thurs Apr 0 - Tape Team, Sat Apr 11 - 2nd Sat
Wed Apr 15 - General, Thurs Apr 16 - Tape Team,
Wed Apr 22 - General, Thurs Apr 23 - Tape Team, Sat Apr 24 - 4th Sat
Wed Apr 29 - General, Thurs Apr 30 - Tape Team,
Wed April 01 - general
Thursday April 02 - Tape Team
from
Wednesday April 08 - General
- Present were Ron Williams, Bill Flora, Frank King, Allen Palmer, Glenn Lea, Don Luke, George Ahearn, Judith Haemmerle, Joe Preston, Stan Paddock, Ed Thelen, Robert Garner.
- Don Luke is back from the trials and tribulations of hip replacement. Apparently hip replacement is an imperperfect art. Something about initial replacement, two tries to stabalize things getting lose - Then trying a new larger replacement hip. This one seems stable. I think Don mentioned something about months being zonked on pain pills :-(( watching day-time television :-((
He was gone a year, but he now seems bouncy (with crutches) and lively :-))- Frank King and company worked on the CT 1403 printer, largely adjusting print hammer timeing - to make beautiful print :-))
- Ron Williams and Bill Flora found that there is another read check problem in the CT 1402 - and occasionally the op code but not the word mark disappears from a program in memory :-(( The parity seems correct -
- Allen Palmer and Stan Paddock tried to reverse engineer and find a replacement for 729 tape unit tape level light - used to help sense when to stop the high speed rewind phase.
- Joe Preston worked on a high speed rewind problem on a CT 729 Mod 2 - A new lamp, "borrowed" from another 729 helped - the old had burned out. The circuit sensing the current through the lamp prevented the unit from going into high speed rewind. With current now detected, the high speed rewind does not stop until the tape whips off the take-up reel :-(( Not desirable - The photo sensor circuit seemed open, but the photo sensor works fine - a broken wire somewhere?
- Some one brought in a big box of SMS cards with a note from the IBM 1620 folks that these cards are not used in the 1620. The current list of cards used in the 1401 and 1406 did not include cards used in the 729 tape drives. Ed Thelen got a list of 729 cards and compared the lists with the contents of the 1620 box. We use about half of them - unfortunately, non of the cards are for the 729s - for which we have no spares.
The list of SMS cards used in the 1401 area is now complete except for the cards used in the varous power supplies. We need to incorporate these new cards into our system of spares.
Bags of cards from the 1620 group that are used in the 1401. 
Thursday April 09 - Tape Team
from
Saturday April 11 - 2nd Saturday
Wednesday April 15 - General
- Present were Ron Williams, Bob Erickson, Bill Flora, Frank King, Glenn Lea, Don Luke, Joe Preston, Sam Sjogren, Ed Thelen, Robert Garner.
- Joe Preston says that the CT 729 Mod 2 tape drive he has been working on is working on is "working pretty good". The final problem seemed to be a broken jumper in the rewind photo-cell assembly. - Maybe damaged during the trouble shooting of the rewind problems? There are a few errors printed as a result of tape diagnostics, but that could also be tape with bad spots. I don't know if there is a tape test designed to test tape quality - like look for bad spots.
- Bill Flora, Bob Erickson, and company continued wrestling with CT card read problems - The fiber of one of the rollers is maybe twice as lumpy (flattened zones) as the same roller in the DE machine. This might not be the problem - but what is?
- Frank King, Glen Lea, etc. ordered some (5 gal.) hydraulic oil for the CT printer paper advance mechanism. That seems to be the minimum amount you can get at "retail" :-|
Frank wrote later -
I have ordered a 5 gallon pail of hydraulic oil from the Chevron distributor. ISO VG 15; Chevron Rando HDZ Premium Oil. This appears to be an exact replacement for IBM # 3. The smallest I was able to obtain was 5 gallons. I will pick it up when they call. Should be <10 days. - Sam Sjogren was very busy - calling Bob Feretich and Van Snyder, practicing front panel operations with the 1401, ... in preparation to reading some externally written 7 track magnetic tapes. He wrote after hours
In short, I managed to get everything working. I've written to and read from a physical tape in odd parity (binary mode) as well as even parity (normal mode). Seems that the left-hand tape drive isn't working, but the right-hand one is mostly OK. See you guys tomorrow.
I should clarify one thing. Even though I was able to create an odd parity tape and read the data back, as far as I know the emulator system is still doing BCD-ASCII conversion on it. I'll look at the code to see if there's a switch to turn this off or if it will require some coding to add a way to bypass it. I doubt that I'll be able to get this done in time for Thursday afternoon, but at least we should be able to determine whether we can read Chris's tapes without error even if this week we can't give him PC files with the binary data as contained on the tapes.
Thursday April 16 - Tape Team
BobFeretich 729Emulator | 
BobFeretich DangerousVoltages | 
ChrisHolloway | 
SamSjogren |
SamSjogren-02 | 
SamSjogren ChrisHolloway | 
SamSjogren ChrisHolloway |
Wednesday April 22 - General
Thursday April 23 - Tape Team
from Bob Feretich
1401 TAU Bring-up status - Thursday, 4/23/09 (Sam S. & me)
We reviewed the symptoms that Sam reported last week, arrived at some conclusions, and fixed a couple bugs. The Webserver logs provided some useful information.
Sam is going to patch the TapeCopy Autocoder program to truncate records at 3000 characters. This is an easy fix that he can have ready for next week. The "right way" to change the program is more time consuming and it doesn't seem to be justified by our role in this effort. My understanding is that a different solution is being pursued to recover the tape data. I'm not sure what is expected of us, but my assumption is that we are trying to use technology that we developed for the Computer History Museum (CHM) to gleam more about the readability and contents of the tapes. Sam's quick fix should allow us to dump a good chunk of the tape contents to a PC file.
- Sam commented that the sample tape started using even parity and then switched to odd parity. I suspected that this was due to the existence of a tape label record on the tape. We found a description of the IOCS tape label format and Sam was able to identify it (starting with the characters "1HDR") as the record he saw printed last week. To process this tape, the label records need to be read in even parity, even if the data records are written in odd parity.
- Server logs show that the TapeCopy Autocoder program repeatedly tried to write records that were longer than 3000 characters to the Emulator. The Emulator can not handle records longer than 3K characters. This action probably resulted in many aborted runs last week. The Emulator ignores the data beyond the 3K limit. Since it doesn't echo the data on the Read Bus, the TAU raises error flags. The TapeCopy Autocoder program can be modified to eliminate this problem. I'll discuss this and other suggested changes, in detail, at the end of this report.
- Sam reported that 729#1 would not load tape properly. I noticed that the mercury switch on the take-up shaft had worked its way loose again. (It broke free from the glue!) We also noticed that the fuse indicator on this drive is on, but none of the CBs are tripped. It also always has its Selected indicator on. It could have been jumping on the I/O bus and interfering during operations to the other drive and the Emulator.
- We also found three Webserver crash dumps from Thursday that showed memory access violations by the Emulator's User Mode Driver. We determined that this was due to a race condition that occurred between console button actions and the timer status update. Sam's rhythm pressing buttons apparently generated the critical timing that caused race condition to fail. I restructured and synchronized the code in this area. Sam spent a few minutes testing the fix. So far, the fix seems to have eliminated the race.
- At 800 CPI, we noticed the TAU dropping some bits. Cleaning the drive head reduced the error rate substantially, but some still occurred. Read data was being latched by both the A & B registers, but bits were dropped when it arrived at the R/W register. This indicates a weak control signal in the TAU. We were shooting another bug when this symptom started occurring, so we didn't pursue it. Later, the problem stopped occurring.
A more serious attempt at recovering the data would entail:
The effort in achieving the above solution would be a distraction to our work to stabilize the 1401 System and its preparation for use in CHM classes. However, the project is feasible and should be considered, if the right partnership were formed with the CHM and the restoration team.
- Modifying the TapeCopy Autocoder program to process tape labels, read the long records into memory, and then cut the records into smaller records before writing it to the Emulator. Error recovery Backspace/Re-Read code should also be eliminated from the program. We think that Backspacing the tape could stress it. Instead, the TapeCopy program should move smoothly from one end of the tape to the other while tagging each record with a physical record number, record segment number (to reassemble long records), and error information.
- Instead of being converted to ASCII text files, the Emulator should create SIMH binary files. These files would retain the original binary encoding and permit easy subsequent forward/backward data analysis.
- Each tape would be read several times. Using the record number and tag information described above, an analysis program similar to a multi-way "diff" program would be able to read the multiple PC file images of the tape and produce a merged and corrected image. Each record in this image could be tagged with a "validity confidence factor" that is computed from the error data tags within each input image.
Regards,
Bob Feretich
Saturday April 25 - 4th Saturday
Wednesday April 29 - General
- Present were Ron Williams, Bob Erickson, Bill Flora, Glenn Lea, Don Luke, George Ahearn, Joe Preston, Ed Thelen, Robert Garner.
- Docent Bill Worthington arranged for some of the CHM staff, Kirsten Tashev, Dag Spicer, and ?Lauren Silver? to see the 1401s and us at work :-))
Bob Erickson found that slightly warped IBM card jammed in the 077 Collator and set out to find the problem. It seems that cards could hit bottom pocket selector head on. Unfortunately, visual access to this area is virtually impossible :-(( From the top it is concealed by the top read station and top pocket selectors and from the bottom (everything else) After much head tilting, squinting, pondering, manual cycling, ... , the problem remains unresolved. 
- Ed Thelen is trying to contact Tim Coslet who made the in-circuit tester shown at Weird Parts to find the values of the two unidentified resistors. We need some kind of aid in fixing SMS cards, and are having trouble getting started on a more elaborate tester.
- Ron Williams and others are farther along in making the CT 1402 card reader work as designed. There is supposed to be an about 3 second delay on starting to read to allow the cards from the top long chute to get into the read hopper that normally holds about 150 cards. This delay has not worked properly since we got the machine - almost every component in the Resistor Capacitor based three second delay circuit has had problems - including an open diode (broken lead). Now they are looking for an adjustable 1000 ohm 2 watt resistor.
- Joe was doing something on the tapes - he just does stuff - not much noise ;-))
- Robert Garner made an e-bay raid/buy again, amongst other loot are 15 scope probes. :-))
Thursday April 30 - Tape Team
from Bob Feretich
1401 TAU Debug Status 4-30-09 (Sam S., Grant S., & me)
Last week we stated that the Emulator driver detected records being written to it that were longer than 3000 characters. Since last week, we discovered that our "tape copy" Autocoder program was written so that it could not write records that were that long. So we explored why we were detecting large records.
We found a cosmetic limit check problem problem in the Emulator User Mode driver and fixed it. It was not the reason long records were being detected.
Further exploration showed that the Write Pulse signal from the TAU would double its frequency about 1500 characters into a record. (Write Pulse strobes the data from the TAU into the tape drive.) The expected pulses were delivered on time, but another pulse would grow between each pair of legitimate Write Pulses. As these extra pulses grew, characters in the data record would be repeated. First the some characters in the record would be duplicated, then triplicated, and so on until the same character would be strobed into the drive continuously.
The root cause of this problem was determined to be the 8-bit of the Write Clock counter. At about 1500 characters int a record, the 8-bit would start setting prematurely. So, the count instead of ended up counting
8-9-10-11-12-13-14-15-8-9-...
Skipping the 0-7 states prevented the TAU from incrementing to the next character. We replaced the 8-bit flip-flop and the problem was eliminated.
While debugging the above problem, we noticed that the Emulator was stuck at the low density data rate for tape reads. We will put this on the list for the next session.
We also noticed the TAU's "No Echo" indicator turning on a couple times. Not a solid enough failure to get priority during this session.
While executing Pass 2 of the Autocoder program, a Read followed by a Backspace was consistently hanging the Emulator. Unfortunately, the Autocoder Source Listing that we have does not match the object code for this section of the program. It will be difficult shooting this bug without source.
Regards,
Bob Feretich