Schedule April 2009

return to main 1401 Restoration Page
go to Team Bios

Contents:
Wed Apr 1 - General, Thurs Apr 2 - Tape Team
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


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 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.
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.

A more serious attempt at recovering the data would entail:
  • 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.
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.

Regards,
Bob Feretich


Saturday April 25 - 4th Saturday


Wednesday April 29 - General


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



Go to
May 2009
go to Team Bios