Schedule March 2009
return to main 1401 Restoration Page
go to Team BiosContents:
Wed Mar 4 - General, Thurs Mar 5 - Tape Team ,Wed Mar 11 - General, Thurs Mar 12 - Tape Team, Sat Mar 14 - 2nd Sat (free food ;-)) Wed Mar 18 - General, Thurs Mar 19 - Tape Team Wed Mar 25 - General, Thurs Mar 26 - Tape Team, Sat Mar 28 - 4th Sat
Wed March 04 - general
- Present were: Ron Williams, Bob Erickson, Bill Flora, Frank King, Glenn Lea, Joe Preston, Stan Paddock, Ed Thelen, Robert Garner.
Smile now - you know we got another tough day at the CT 1402 Yeh - no smile now
Thursday March 05 - Tape Team
from Bob Feretich
1401 Autocoder Bring-up Status - 3-5-09 (Jeff S., Sam S., Ron W. , and me)
I created a readable tape image from the Autocoder_H.bcd file on Paul Pierce's website. We mounted the tape image on the 729 Emulator as virtual drive #1 and booted from the tape....
Positives:
- The 1401 read some of the virtual tape and halted at the prescribed address. From there we had two options. One, press "Start" and the program would print a listing of the program (estimated 350 pages). Two, press "Start Reset" then "Start" to skip printing the listing.
- We pressed "Start" and printed several pages of the listing. We then stopped the 1401, reset it, and rebooted the tape.
- The second time through we skipped printing the listing and the 1401 advanced to the next prescribed halt address.
- We followed the instructions in the manual and readied the 1402 Card Punch. And, after clearing a torn card fragment that was stuck in the punch, we pressed "Start" and the program started punching a 1300+ card "system deck".
- Punch errors were detected by the program about every 10 cards. Good cards were selected to stacker 4. Bad cards were selected to the normal stacker . Typically, an error resulted in both the bad card and the one after it being sent to the normal stacker . The program would automatically re-punch both of these cards. After every 10 punch errors the program would halt. Pressing "Start" would reset the error counter and the program would proceed for another 10 errors.
- After punching card 1359 the 1401 turned on a check light showing a non decimal address in the SAR and both I-cycle and A-cycle indicators on.
- We examined the converted tape image and determined (wrongly) that this was the last card that needed to be punched.
- We then replaced the Autocoder program with a scratch tape on virtual drive #1 and loaded the newly punched system deck.
- The 1402 Card Reader raised read check about every 100 cards. The processing the 1401 was performing prevented the reader from operating at full speed and the "almost full speed" operation was difficult for the card reader.
- We figured out the secret for continuing after a read check was to restart the read starting at the last card that was placed in the output stacker. That meant that this card and the two cards in the reader track needed to be moved back to the input hopper.
- The program also detected three gaps in the sequence number order. These cards had been accidentally selected into the normal punch output stacker . Unlike error selections, these cards were individually selected rather than in pairs. We never determined how to restart after a sequence number error. Each one forced us to load the deck from the beginning.
- We finally got the 1402 to read the entire deck. But, rather than print the expected message on the 1403, the program issued another Read Card instruction. Obviously, the program recognize our last card as the last card.
- Close examination of Paul's BCD image revealed that my conversion program failed to output the last buffer of converted cards (about two dozen). I fixed the conversion bug and regenerated the readable tape image.
- Rather than re-punch the entire 1300+ card deck, we were able to extract required two dozen card images to a file.
- Jeff had written a Tape-to-Punch utility program, so we booted that program to punch the remaining cards.
- However, the 1402 Punch was dead. It would not move its picker knives. (The output joggers would run.) We spent some time trying to troubleshoot the bug but we were not successful. We did find that one of two small springs near the card input slot was disconnected at one end. We reattached that end of the spring, but it didn't make a difference.
Not so positives:
- We made some progress bringing up Autocoder
- The 1401/729 Emulator combination worked well. No errors were observed.
Regards,
- The 1402 Punch is dead
- The 1402 Reader issues frequent read checks
- The 3rd keypunch from the door does not duplicate cards properly.
- The fan in gate 1A5 is installed backwards
- The stock market is down again today
Bob
From Van Snyder, Mar 6
The process of punching the deck on the Autocoder distribution tape, and then converting the deck to an operational tape, could be done in SimH.
Wednesday March 11 - General
- Present were: Ron Williams, Bob Erickson, Bill Flora, Frank King, Glenn Lea, Joe Preston, George Ahearn, Judith Haemmerle, Stan Paddock, Ed Thelen, Robert Garner
We have a "new recruit" - George R. Ahearn. Well, OK - George helped design the 1401s - so that makes him a "founder". He is on the left talking with Bill Flora, who turns out to be a neighbor - have known eachother for years, but Bill didn't know of George's early involvement with the 1401 :-| - From Stan Paddock -
Last Wednesday I worked on all four keypunches.- The amazing thing is that they all still work!
It was reported that number 3 keypunch failed at duplication. Number 4 keypunch was known to jam while punching cards from the IBM PC.Research on number 4 showed that the two primary rubber feed rollers had a coefficient of friction of .0023. With the application of a sheet of glazing material, I was able to elevate the coefficient of friction to .4382. Subsequence testing revealed that this problem was the cause to both reported problems. All four keypunches were tested for duplication errors and none were found. All four keypunches were "modified" to keep chad in the ballot box and not on the table top.
Known DE IBM 1401 machine status- 1. Intermittent false card read errors. (More inter than mitient)
- 2. Card punch total failure.
- 3. Multi-color rotating fan fully operational!
Thursday March 12 - Tape Team
from Bob Feretich Autocoder Bring-up Status - Thursday, March 12, 2009 - (Jeff S, Sam S., and me)
Despite our best efforts,we all ended up coming in today for a work session.
Van had generated an operations tape from our Autocoder "system deck", so we tried to boot it on the DE 1401.
Also, it looks like our stock market fix is taking hold. So far we have three days of run time without red arrows appearing. The credit belongs to Jeff. He sold his leveraged "ultra-long financials" ETF three days ago. Now if we can get him to go ultra-short with his entire portfolio, the S&P would go back to 1600.
- Initially, we had a problem with the ASCII encoding. That was easily fixed.
- We then noticed that booting the tape caused the whole tape to be read and the 1401 to loop reading off the end of the tape. We had also defined virtual tapes on drives 3 (scratch), 4 (input deck), 5 (scratch), & 6 (listing). None of these other tapes were accessed.
- We Placed an address stop in the read loop (the assembly listing covers this code) and stepped the program through one read at a time. It would read a record look for the string
"999999 HEADR". If it found it, it would check the next record to see if it is an EOF (a BCD Tape Mark). If both checks were satisfied it would exit the loop and start reading records from tape drive 4.- Consistently, running at full speed would never exit the loop. Address stopping in the loop caused a normal exit. We don't know which part of the check was failing.
- By examining this loop, we saw how 1401 subroutine linkage was done. However, to call subroutines, the Index Register Feature must be installed. Does the CT machine have this feature? If it doesn't, it will never run the Autocoder assembler.
- After address stopping through the loop, we pressed put the 1401 in Run mode and pressed START. The Emulation server instantly "Blue Screened".
- We then rebooted, address stopped through the first loop, and address stopped through a second loop that read source data records. Before the 1401 exited the second loop, we had read about 8 source records, written 5 listing records, and wrote 3 records to drive 5. When it exited the loop, lots of lights flashed, and the server "Blue Screened" again.
- I brought Windows kernel MiniDumps home for analysis. The Emulator driver is accessing invalid memory addresses. We noticed that just before the crash, the 1401 rewound tape 5 and may have tried to read it.
- We also noticed intermittent "Echo Errors" being raised by the TAU. We don't know if the TAU or Emulator is at fault here. We haven't seen these errors since we implemented the echo in Emulator hardware.
Regards,
Bob
Saturday March 14 - 2nd Saturday
From Stan Paddock - not usually known as a shrinking violet ;-))
Ed, No need to post but Ron, Bob and I worked on Saturday.
(Free lunch)
I am proud to boast I fixed the punch on the DE machine.
Well I fixed it with a bunch of technical help from Ron and Bob.
The reader still has two problems left to address.
Stan
Wednesday March 18 - General
- Present were: Ron Williams, Bob Erickson, Bill Flora, Frank King, Glenn Lea, Joe Preston, George Ahearn, Judith Haemmerle, Stan Paddock, Ed Thelen, Robert Garner
- Ron will bring in a hair drier, with extra defuser to assure more even heat all through the air stream, and test the unit for heat sensitivity - maybe the room was considerably warmer when Ron Williams had the trouble.
- Ron Crane and I left about 6:30 -
Thursday March 19 - Tape Team
Saturday March 21 - 3rd Saturday
Wednesday March 25 - General
- Present were: Ron Williams, Bob Erickson, Bill Flora, Allen Palmer, Bob Feretich, Glenn Lea, Joe Preston, George Ahearn, Judith Haemmerle, Stan Paddock, Ed Thelen, Robert Garner
Allen Palmer is back from a European adventure, something about Italy and France :-)) Here he is with his head light -
- Should I say "AAHHH"?
- or confess to crimes I never imagined?
- Bob Feretich is trying to get ready to read 800 bpi (bits per inch) tapes for someone next week. There were many errors - Allen Palmer got out his IBM official 800 bit/inch reference tape to assure that the individual track read and write head delays were properly set. (We are very fortunate to have such a tape :-))
- Judith Haemmerle and Bob Erickson have just about completed an IBM 513 disassembly manual, with lots of pictures.
Bob Feretich had me do an Alpha Test on his instructions for using the Tape Simulator. Also involved is a PC with APACHE server software. - Joe Preston and Glen Lea fixed up two more CT 729 circuit breakers - as mentioned previously, the signaling contacts are badly corroded, and the unit thinks that power is not all the way up.
Thursday March 26 - Tape Team
from Bob Feretich
Late Wednesday, we were able to get the DE 729#1 to read and write tapes at 800 CPI. We don't know the root cause of the earlier problems. The error symptom kept changing.
Things we did:
The bottom line is that operation at 800 CPI is temperamental. It may take some fuss'in with the system to get it to read the sample tapes.
- I cleaned the drive tape path with tape drive cleaning solution. (That is supposed to be done at the beginning of every shift that makes heavy use of tapes. I had not used the drive nor cleaned it for several weeks.)
- We removed the old scratch tape and mounted a Master Skew Tape. The Read Bus signals looked very good when reading this tape.
- We remounted the old scratch tape. Very few errors were detected writing/reading from the tape.
- The drive had been powered on now for a couple hours. So it was now warmed up.
- We ran 800 CPI tape copies in both directions between the Emulator and the drive. No errors.
- We ran the entire set of tape system diagnostic decks against the drive at 800 CPI with no errors.
- Oh-yes, Allen invoked favors from the Tape Drive gods. I'm not sure what he sacrificed, but I sure that he/she/it won't be missed (too much).
No progress was made on the Autocoder bring-up. It seems that the End-of-Reel/End-of-File signal is slow. If there is a NOP between the Read Tape and BEF (branch on EOF) instructions, it seems to work. When there is no NOP, we don't branch, but still clear the EOF condition.
I plan to visit the CHM about 11:30 to 3:00 next Wednesday, between a dental appointment and a ESC seminar. Next Thursday, I have a full day of seminars.
Regards,
Bob
Saturday March 28 - 4th Saturday
Go to April 2009
go to Team Bios