Return to Continuing Maintenance

"Status of the 1401 Demo Lab - Activity Reports"

2023, 2022,
2018 through 2021 Maintenance Reports
2018 -2019 Demo Reports
2013, 2012, 2011, 2010, 2010-2004


2023 Maintenance 2023 Demonstrations
Jan - 4, 11, 18, 25, Jan - 7, 11, 21,
Feb - 1, 8, 15, 22, Feb - 1, 4, 15, 18, 22+24, 25,
Mar - 1, +, 8, 15, 22, 29, 29+, Mar - 1, 4, 8, 11, 13, 18, 22, 25,
April - 5, 12, 19, 26, 28, April - 1, 4, 8, 15, 19, 22, 26, 29,
May - 3+, 10, 17, 24+26, 31, May - 3, 6, 10, 13, 17, 20, 27, 31,
June - 2, 7, 9, 10, 14, 21, 28, June - 3, 10, 14, 16, 17, 21, 24, 28,
July - 5, 12, 14, 19, 26, July - 1, 5, 8, 12, 15, 19, 22, 29,
August - 2, 4, 5, 9, 10, 16, 23, 30, August - 4, 5, 9, 12, 19, 20, 23, 26, 30,
September - 6, 13, 20, 27, September - 2, 4, 6, 7, 9, 13, 16, 20, 27, 30,
October - 4, 11, 14, 18, 21, 25, October - 4, 7, 10, 11, 14, 18, 21, 25, 28,
November - 1++, 6, 8, 15, 17, 18, 22, 29, November - 1, 4, 8, 11, 15, 17, 18, 22, 25, 29,
December - 6, December - 2, 6, 8, 9,

IBM 1401 Demonstration - Saturday 12/9/23
from Stephen Madsen - 11:00 am Demo
Peter Chang and I demonstrated the 1401 to 45 visitors. Michelle Yu was backup operator. Foreign visitors were from Canada and China. The keypunches, sorter and microphones worked fine. We started using CT, which tested OK during setup. When we tried to process the volunteers punched card, the 1402 jammed. Peter punched another card, but it also jammed. Then we transferred to DE. When trying to load BigPrint, we had reader/punch checks. We restarted DE, and then we were able to load BigPrint and read name cards. In summary we were able to demonstrate BigPrint and process name cards after the demonstration without too much delay. The visitors were patient.

Stephen H. Madsen

- from Larry Hara - 1:00 PM
I had the privilege of showcasing the 1401 today December 9, 2023 at 1PM with the distinguished Paul Laughton as the operator.

We had 35 visitors including one very enthusiastic visitor from Poland who was happy to see the real machines instead of on a YouTube video. The audio worked perfectly!

Unit record machines - we used keypunch #1 for the demo with no issues. The 083 worked well.

Prior to our demo, Steve and Peter reported that CT1401 had reader stop and jamming issues with the first card, so Paul and I tried a few things to get it working but to no avail. The first card jammed immediately at the front and on a second attempt, the card landed in the far left bin, crunched and with roller skid marks as shown here:

We remade fresh and clean first cards but this did not help. No surprise, we didn't use CT.

Since BigPrint was already loaded from the 11AM demo, we ran BigPrint from DE 1401 memory and did not attempt to reload the program. It ran well for the demo, although about 30 minutes after the demo, we encountered reader stop issues on DE1402. Powering down and restarting allowed us to continue post-demo runs.

DE1403 ran beautifully!

For the tape demo, we ran DE727#2 and #3; #1 was out of service. We also ran all 4 CT729s for better visibility to the visitors and it worked well.

1401 Friday Special Demo for Homeschoolers on December 8, 2023
- from Karen Sun
Jim Maurer, Paul Laughton and I signed up for today's special demo for the homeschoolers. It has been the 2nd time recently that three of us worked together to pull a live demo for a bunch of kids and their parents. We were happy that we gained more experience in serving the parent-kid group and we even found ourselves enjoying talking with those curious young children, most of them under 10.

Jim and Paul arrived early before 9:30am to test both of the 1402s. Jim successfully ran CT 1402 and we finally demonstrated Big Print for the kids using CT 1401. Paul successfully ran through the DE 1401 Big Print after rebooting the DE with quite a few reader stops and reader checks and duplicating the frailed first page of one deck. Hence we were pretty confident to have two 1402s ready before the demo. We didn't know when the group would arrive and Jim walked around to find the group in a software exhibit and brought them to the lab room.

Under Jim and Paul's support, I flipped the classroom in a new format, with those young children and their mothers being divided into two groups. I guided each of the team by lining in front of the two keypunches so that Jim and Paul could show six of them one by one to punch a name card. During these casual punch moments, the parents were also engaged to ask relevant questions about the keypunches by surrounding Paul and Jim. I designed a question related to the punch card
and guided the parents and children with some basic computer knowledge, simple addition and subtraction and I was surprised they were able to come up with the right answers with hints.

Afterwards we demonstrated the sorter, printer, CPU components and tape drive with all of their attention and their great questions and feedback shared. I was amazed how well those young children could understand those ancient computers by:

  • pretending three of us are great magicians that what we helped them punch earlier would show up somewhere in big letters (once we moved them from the card reader to printer, they couldn't help but whoa and take out the phone to record the printing)
  • asking them to observe how a Big Print looks like and what they noticed (Big letters purposefully turned into a bit smaller to fit the whole page, there is a date on the printout, the CPU lights were flashing busily while printing, the printer hammers are striking on the page, etc.)
The CT tape #3 has some tape thread issues and due to the time constraint we flipped it into inoperable before the demo. The rest worked fine. After the demo, the small group stayed for more questions. A couple of more Tencent(the Chinese instant message giant tech company)employees (who were having their holiday party on the 2nd floor) were roaming in and asked about 1401.

- from Jim Mauer
The tape was already threaded. I manually wound it past the marker and hit load. The tape then came off the take up reel and into the vacuum column. I stopped it and rethreaded it on to the take up reel, manually advanced past the marker and hit load. The same thing happened again. I went through it one more time with the same thing happening and took the drive off line. The other drives worked fine.

- from Jack Ghiselli
This sounds like the tape reel's leader is too short (maybe somebody cut some off?). Or possibly the start-of-reel reflective spot is incorrectly mounted. In either case, the fix would be to cut off the existing leader, attach a new reflective spot, and then try re-mounting the tape. The IBM spec is that there should be at least 10 feet of leader tape before the reflective spot. I suppose the 729 Tape Drive sensor for the reflective spot could be bad, but that's unlikely.

Jack Ghiselli mobile 1-408-839-1051

1401 Restoration Report - Wednesday, Dec 6, 2023 - updated through Friday morning
Re: SMS data logger proposal, December 6 - from Ken Shirriff
Here's my updated SMS data logger card design. I've added a socket so it can function as an extender. This lets you put it in-line with a card and log the signals. I also extended it to 12 signals so you can log all the signals on most SMS cards.

With the socket, the board is the same length as an SMS card (so the PCB is shorter than a normal SMS card). One disadvantage is that in the new design, you need to unplug the SMS card to connect a USB cable to the Teensy. Otherwise the socket will obstruct the USB port.

I'm not sure what is the best way to fasten the socket to the board. In the mockup, it's held on by soldering the pins to the board, but some additional mechanical support would probably be good.



Comment from Curious Marc

t’s getting even nicer! I was just thinking you should add a CRT to your instrument so we can see the results directly, I’m sure it will fit…

- from Ken Shirriff
Not much to report. All the tape drives work from the TAU now, and I fixed the tape that was threaded on the wrong side. (It was twisted about 200 feet in, so I cut off the bad part.)

After the various reader brush measurements, I figured I should get to the bottom of what the 1402's "half write" variant is, but I'm still confused. Does anyone understand what it is?

The basic idea is that each brush goes from the card reader to the 1401, where it goes through a resistor on a paddle (behind the front panel) and then directly to a row bit core, as shown below. The "regular" circuit uses 180 ohm resistors, while the half-write circuit uses 330 ohm resistors.

I took some photos of the paddles and it turns out that the DE machine has 180-ohm resistors, while the CT machine has the 330-ohm half-write resistors. So the CT's current through the cores will be approximately half of DE's.

In the 1402, the circuit difference between half write and not half write models is very small. Transistor T2 pulls the brush common up to ground under control of the solar cell. It also sends this signal to the 1401 so the 1401 knows the solar cell status: RC 187 SC-CB2. In the non-half-write model, R11 is connected to -20V, so the brush line is at -20V when not used, same as the other side of the core, so no current flows. But in the half-write model (below), R11 is tied to RC190, which provides the 1/2 write bias from the 1401. What does this current accomplish?

ALD explains that RC 190 goes to storage array A from 10 pin 27. So it goes to some pin on the core memory module. But I can't find any more information on what this pin is. It's a bit strange for this to go to the core memory module rather than to a voltage or resistor.

So can anyone explain what is going on with the half-write? Is there a second wire through these cores providing the other half of the current?

- from Arda Ugur
Report - in .pdf format

- from Robert Garner

Thanks for your great report on the relay contact cleansing. They clean up well! :)

I realized that I do not have any photos of you cleaning the relay contact pins using the burnishing tool.

- from Carl Claunch
Hi Ken et al

My speculation is that this is a modification to increase the speed of the core switching, perhaps related to a model or feature that offers higher speed reading rates.

Here is my redrawn schematic to discuss this. The brush closes to common when it reaches the beginning of a hole, but the solar cell blocks "sampling" until later when it fires T2. Thus, half current is fed to the core over the entire duration of the hole passing the brush but the transistor increases the current to full when it fires in the sampling window. The core inductance delay is lessened because the current swing is reduced. Ignore the transistor number, the core inductance value and the current shown for the current source. I don't know the exact current to be injected but this would be adjustable, no doubt.


- from Ken Shirriff

Thanks, Carl, for looking into this. The part that I don't understand is that R2 is 330 ohms vs 180 ohms, so the most current you're going to get is half vs the simple circuit. In other words, when the transistor fires, the current won't go from half to full, it will go from I2 to half. So unless there is another winding through the core, I don't see how you get enough current to flip.


- further dialog, from Carl Claunch, received Friday, December 8

Hi Ken

I agree with your point that in my diagram the increased resistor would decrease the current to the coil even with T2 conducting compared to the original 'full current' case. That is assuming that the far end of the coil is still hooked to -20V in the 'half current' case, but neither of us knows what the rest of the circuitry including the core stack wiring looks like.

As an example of a change that could enable this, imagine that the far end of the cores for the row bits is hooked to -36V instead of -20V as in the canonical case. If we wave away a lot of complexity and accuracy, ignoring any diodes or other factors, the core in the original design sees a current of a bit over 110ma from a 20V source.

The core would need around 55ma of current to be at 'half current' when the brush sees a hole but T2 is not triggered. The resistor on the current source leg drops about 6V and the 330 ohm resistor drops a bit over 18V thus the core doesn't see a higher effective voltage than it did with the original 20V supply. The current source is set to deliver 55ma to keep the core at some level below where it will flip. When T2 energizes the full 36V across the 330 ohm resistor achieves a current of about 110 ma, what we assumed for the original case.

Pure speculation I admit, but the key to understanding what really exists will be to look at the current driver and the wiring of the core stack used with the half current version. Also ignoring junction voltage drops and other details for the sake of a simpler explanation.


- from David Clementson
We started the day looking into PM relays with the goal of developing an inventory of known-good units to be used to resolve CT1402's chronic Reader Stop errors. The details of the relay refurbs can be found in Arda's excellent writeup.

I had brought in a 4-wire ohmmeter to do a "QA" check on each relay. I found that a freshly cleaned relay contact exhibits a resistance of anywhere between 0.06 and 0.15 ohms. Any contacts with higher resistance were rejected and sent back for rework. Marc noted that this kind of QA testing would be ideal for automation, preferably using as much vintage HP equipment as possible. While admittedly overkill for the need at hand, building and programming such a test rig would be immensely entertaining and I would love to see us go for it. Let me know how I can help.

Once a few good relays were produced, we turned our attention back to the CT1402. Frank and Sam had been working on fixing its Dynamic Timer which had failed recently. They were able to extract the two vacuum tubes that it uses, and were able to confirm that the 6AL5 dual diode had an open filament. They were able to find a replacement in our tube stash, and the Timer now works. Nice job! BTW, I think that was our last 6AL5, so we could probably use another if anybody has one to donate.

We then started to look at the Reader Stop errors only to discover that they were no longer occurring. Decks ran fine except for the usual Reader Check errors. So we focused on the Read brushes. We agreed that the "print all fives" deck (a program and data deck that prints the number"5" on every column) should be our "gold standard" performance check. When we ran it, three brushes exhibited problems, most notably brush #3 which had been giving similar errors before. We replaced these brushes and managed to fix two of them including #3. So we have one remaining flaky brush. The replacement brushes that we used showed signs of rust and corrosion on the wire tips - a consequence of their age, no doubt. So it is very possible that continued use will polish off the rust and the brush performance will improve. If not, we may need to provide a little abrasive help to speed its break-in.

The next step will be to continue with the Check brushes.

So CT1402 is getting better, and I encourage the docents to try to use it when they can so we can collect more information about it (mis)behavior.

That's it for this week


- from Samuel Plainfield
Looks like these 6AL5 tubes are readily available online and after a review of the 1401-info site, it doesn't look like that tube was ever replaced before ~ that is quite a run!

Here's the faulty tube, I have added it to the demo cart.

Robert also found another "bottle of bits" that I also added to the demo cart.

Worth noting: we sanded down the contact roller with 400 grit sandpaper just a bit and that did make a visible improvement in the all 5's printout. We want to be careful with sanding/cleaning/messing with the contact roller because it is not an easily replaceable unit.

At the end of our (David, Frank and I) overtime shift ( Robert promised us an X-mas bonus, right Robert? ;) ), only brush 37 was exhibiting some intermittent read brush issues. So, there's some significant improvement and it is important to note how sensitive everything is and bear in mind when performing future maintenance on the brushes / diagnosing read check issues.

~Samuel Plainfield

1401 Demo on December 6, - updated through Friday afternoon
- from Scott Stauter
Today Jim Maurer and I gave the 1401 demo to 34 visitors, with 2 more visitors before and 1 visitor afterward. The audio equipment, all three keypunches, and the sorter worked well. We gave the demo using DE 1401. The 1403 and the three tape drives worked perfectly. The 1402 gave us a Reader Check which was easily fixed, but the 1401 stopped once with an OVERLAP error. We reset the 1401, reloaded the program, and it worked fine.

We had foreign visitors from Argentina, Canada, India, Japan, Sweden, and Turkmenistan.

Scott Stauter

- from Larry Hara - received Friday afternoon
Hi All,

I did a few things the week before Thanksgiving to straighten out our program cards. Here's what I did so far:

  • Duplicated and verified the decks of VOBJ 2.1
  • Restored the BigPrint deck # 4 that had missing and out-of-sequence cards. Verified with VOBJ.
  • Labeled the actions I took - see photo below:
I plan to go through the other demo programs (e.g. BigPrint, Powers of 2, and any others if needed) to ensure they're all in operational order, label similar to the above, and create a log of what I do.

Other ideas: Some of these may already be redundant to what is in practice already and I don't know about it yet, so if it is, please let me know.

  • Take an inventory of what programs we have in the trays on the demo cart, unless one exists already.
  • Organize the card trays by keeping the demo programs together and label them "For Demos"
  • Document a Preventive Maintenance Standard Operating Procedure
  • Create a log for monthly PM
On a separate but related topic:

Samuel Plainfield and I were discussing how we could prevent cards from being mixed up or damaged in the first place. From a continuous improvement and broader perspective, we think it would be beneficial for us recently qualified operators and leads to spend some time together as a refresher. The "Program Execution Error Recovery Table" from the 1401 Machine Operator Manual, Developed in 2022 by CHM Volunteers Paul, Pat, and Jack, and distributed during our initial training last year is an excellent resource. If the veteran Leads (you know who you are ) are willing to, we'd love to learn from your experiences and document best-known methods (BKMs) for:

  • handling the cards
  • how to detect if cards are out of sequence during a demo
  • troubleshooting and quick thinking during a demo for problems with the:
    • card reader, include the method to restart loading a deck if there is a reader check (or other) error
    • tape drive
    • printer
Our idea is to step through the demo process and find areas where we could benefit from learning more about the machines. Also, there are so many accomplishments and repairs that the Restoration Team continues to do and those feats would make great stories for our visitors before or after the demo.

We don’t think we need or want to make this a big project or take up much more of everyone’s time. So what if we just set a date to meet in the 1401 demo lab? We could discuss the above, take good notes or videos, document as needed, and provide mini / ad hoc demos to any walk-ins since we're there.

What do you think? Worthwhile? Please let us know your thoughts.

Larry and Samuel

P.S. Late yesterday afternoon, I took a peek in the 1401 Demo Lab and saw a deck of Big Print on CT. I wasn't sure if anyone was using it or not so I left it there. But I'm concerned that cards can get damaged or out of sequence if left out in the open.

IBM 1401 Demonstration Saturday 12/02/23
from Jack Ghiselli - 11:00 AM
Peter Chang and I gave the 1401 Demo to a small group of 21 visitors. There were international visitors from Korea, Paraguay, and Russia.

We ran on DE, which ran very well, including all three 729 Tape Drives (thank you, Restoration Team). During our demo we loaded and ran both BigPrint and Powers-of-Two. The 026 Keypunches and 083 Sorter also ran fine. The CT1403 ran out of paper, so Peter loaded a new box from the back room. We might be getting low on paper again, although both 1403s now have full boxes.

Just in case, we powered up CT, but it was not very useful. Every time we tried to load a card deck on the CT1402 we got Read Check on the first card. We tried operating the 729 Tapes via the TAU, but only Tape Drive #2 (second from left) would move.

Exciting news: Peter Chang has been working on his hand-coded one-card "Hello World" program. Today, he ran it successfully! Yay Peter!

Jack Ghiselli mobile 1-408-839-1051

- from Stephen Madsen - 1:00 PM
Duane Sand and I demonstrated to 52 visitors. Foreign visitors were from Brazil, Ethiopia, Germany, Poland, and Russia.
We used the keypunch farthest from the closet, and it worked OK. The sorter and microphones worked OK. We used DE. The printer and all three tape drives worked OK. We had some reader checks, but were able to try again, and it worked OK. The CPU stopped with power off. We restarted the CPU, and then it worked OK.

Stephen H. Madsen

Wednesday 11/29 1401 demo
- from Scott Stauter
Tim Robinson and I gave the demo today.
The museum was fairly empty and we only had 12 visitors for the 3 pm demo. We had one person before the demo and two after. The foreign visitors were from Brazil, France, Germany, New Zealand, Portugal, and Singapore.
The keypunches and the sorter all worked well. The CT 1402 was giving punch stops, so we elected to give the demo using the DE 1401. The reader and printer worked flawlessly. We used DE tapes 1 and 2. The audio system worked satisfactorily.
Scott Stauter

- from Tim Robinson
Right before the demo our dedicated restoration team release DE tape drive #3 as fully working again (at least from the TAU). We did not have time to set it up before starting the demo and so didn't use it, but I ran it after the demo and it worked fine, so all three drives are good again on DE.

Tim Robinson

1401 Restoration Reports - Wednesday, November 29nd, 2023
- from Ken Shirriff
Not a lot to report:
DE 729 #1: It wouldn't load. Relay #111 was the problem. I put contact cleaner on it and it worked okay in the relay tester. The tape drive loads now, but I'm still a bit suspicious of the relay.
DE console: One of the lightbulbs was burnt out (B reg A) so I replaced it.
Punch check: No signs of it.
John's hanging branch on tape error problem. I tried reproducing it but it didn't happen for me.
SMS-based data logger: I did some more measurements to make sure the card will fit.


- from David Clementson
CT 1402 Card Crunching:

Some progress today! We started the day by confirming that the DE machine does not mangle a card when an NPRO is run after the card has been manually preloaded into the throat. We were further able to confirm that this is due to the fact that the machine executes multiple clutch cycles when this test is run. This is the clutch solenoid signal for that test:

You can see that the first two waveform cycles are different because of the interaction with the Card Lever signals as the card passes. Contrast that with the prior observation that the CT machine executes one and only one cycle under these same test conditions.

We then demonstrated that during NPRO, the DE machine will transition from a continuously-clutched condition to interrupted-but-repetitive clutch cycles as soon as Card Lever 1 is activated. When we tried this same test on CT, we found that it changes from a continuously-clutched condition to a single clutch cycle after Card Lever 1 is pressed. Once that cycle is done, no further cycles occur. This behavior is similar to what happens when the test card is preloaded into the throat. So the Finger of Blame is starting to point to a logic fault as opposed to a roller fault.

Next, we looked at the relays and cams involved with generating the -T NON PROC FEED signal which is required to start a clutch cycle. For starters, we swapped relays #1 (Hopper) and #2 (Card Lever 1) between the CT and DE machines. The behavior of both machines remained unchanged, indicating that both relays are probably okay.

I theorized that CT's single cycle "one shot" behavior may be due to a relay that was picking but not holding. Since the problem involved Card Lever 1, we looked more closely at the hold coil drive on the Card Lever 1 relay (relay #2.)

I used a dual opto isolator to view #2 pick and hold coils, and found that pick signals were the same but the hold signals were different between the CT and DE machines. Relay #2 hold coil is fed through one of its own contacts (which we saw above are known good) and cam RC8. We cleaned CR8 with no effect.

Next, we went to look at some other signals in this area. Relay #12 (Feed Control) is involved with the Card Lever 2 relay and the generation of -T RD COMP GATE back to the 1401. We swapped relay #12 with a random spare from the workshop and voilà, the machine behavior changed to agree with the DE machine! We tried to force an NPRO card crunch, but could not; the preloaded card ran out correctly to the pocket. So it looks like we have at least gotten to the bottom of the card crunching issue. It also exonerates the rollers from any involvement with the card crunching bug.

HOWEVER, after trying to load a program card, the machine immediately gave a Reader Stop error. Bummer! We spent the remaining part of the day fussing around swapping relays, but the Reader Stop errors persisted. We even restored the relays to the original configuration from the start of the day, and the Reader Stop errors still occurred. So it seems we have introduced a new problem somehow.

I discovered that we are very low on our spares inventory of 20 volt relays. So the next step will be to refine the relay tester to include both pick and hold functionality, and then to use it to rehabilitate our flaky relays. I took the faulty relay #12 home for a deep dive into its contact's behavior. I want to try using a THD+N analyzer to look at the "fidelity" of the contacts when they are used in an audio attenuator circuit. In my prior life, I found this technique to be very effective for analysing relay and switch contacts.

Here is some further relay info thanks to Ken.

These are 1402's PM relays for the reader unit. Not sure what the "Type" column indicates, I will attempt to find their PN's:

Relay specs: (note that the 1402 generally uses the 20 volt pick models in sizes 4 and 6)

That's it for this week.


- Update - received Dec 4, 2023

I had a closer look at the bad #12 Feed Control relay which we extracted from the CT 1402. I was easily able to detect a bad contact (#6, N.O.).

However, according to the base diagram and the relay table in the schematics, this bad contact set #6 is not used.

I checked the other contacts with both a THD+N analyzer and a 4-wire ohmmeter and they all checked okay. So it is not clear why swapping this relay changes the behavior of the 1402. It will be interesting to check this relay on John's tester.

BTW, the THD+N analyzer test puts the relay contact in the series arm of a -3 dB resistive attenuator, then measures the THD+N of the attenuated signal:

Plotting the THD over time allows the detection of any time-varying resistance, like from a flaky contact or even a bad connecting wire. Here is a plot of the bad contact (~-73 dB) compared to a good one (~-109 dB.)

The 4-wire ohmmeter is also very good at analyzing low resistances. The good contacts measured around 0.56 ohms, whereas the bad one settled at about 10.5 ohms. Note the reading differences between the Fluke DMM and HP DMM. The residual resistance of the 4-wire technique (measured with the test leads shorted) was about 0.05 ohms, which dropped to 0.03 ohms after the application of a little Deoxit to the tips of the test leads.


- from Marc Verdiell -

Late report, we finished to reconnect the DE tape drive #3 with John and Arda. The newly installed tape load motor works, but on occasion it seemed that the vacuum contacts were a bit lazy.
We put a new CMOS battery in the tape emulator computer, which made it noticeably happier. We moved it in place to try on DE next week.

SMS data logger proposal
- from Ken Shirriff
Here's a proposed schematic of my SMS data logger. The idea is that it plugs into an unused SMS slot and can log 8 signals.

A Teensy 4.1 is used as the microcontroller. It is very fast, has lots of memory, supports a micro-SD card, and USB.
Plugs into an unused SMS slot. Pins A-H are inputs and can be jumpered to the desired signals.
Each input can be -20V to +6V and is scaled by a resistor network to 0V to 3.3V.
Each input goes into a comparator to threshold it into a digital signal. 8 jumpers allow selection of a T or U signal as input.
Each input also goes to an analog input on the Teensy in case we want to log analog voltages.
A battery backup supports the real-time clock on the Teensy.
An I2C temperature chip lets us log the temperature.
An RGB LED provides status.
A low-dropout regulator produces +5V from the 1401's +6V. The Teensy produces +3.3V from that.


Comment on Ken's SMS data logger (above)
- from David Clementson
Hi Ken: Nice work! I can only think of two suggestions:
  1. add 0.1uF bypass caps to the two comparator reference voltages "ref_t" and "ref_u" just in case
  2. maybe add a manual push button input so you can add an external event to the log file. A couple of pads or a 2-pin connector in parallel with the switch would allow you to remote the button outside the 1401 frame.

Ken's coment on David's comment (above) ;--))
Good ideas! I've added the capacitors and a pushbutton.


- from Bill Newmaan

Wow! I love it! You've probably already discussed what follows...

My only suggestion would be to put an sms socket at the end of it so we can use it as a card extender, for any slot in the 1401. Not only could we debug easily with it, (using the data logger), we could also build a database of what the signals are when the 1401 is working properly.

Will it capture waveforms? Or do we specify hard thresholds for the inputs? In any case, what sample rates for how many signals?

The socket is a major change, I know, maybe we save it for the 2.0 version that emulates sms-cards and does automatic diagnosis (!!)

Bill Newman

Nov. 25 1401 Demo Reports
- from Jack Ghiselli - Sherlock Holmes and the Case of the Reversed Tape Reel - 11:000 Demo
I was Operator for the CHM 1401 demo on Saturday, 11/25/2023 11:00. Pat Buder was Lead and he will be posting the report.

However, in answer to your question, Saturday morning we found a strange condition on CT 729 mag tape drive #3 (counting from the left). The tape on the feed reel was wound backwards. In the diagram below, a correctly would feed reel looks as shown on the left. That is, the tape comes out as shown, and then is fed into the drive rollers. The bad reel instead looked like the diagram on the right. When moving a tape forward, the feed reel rotates clockwise, feeding out tape. You can see that if the bad tape rotates clockwise, it actually PULLS IN tape.

I removed the bad reel and placed it on top of the CT1406 with an error tag. If this reel cannot be fixed, it should be replaced with a new tape reel. I didn't have time on Saturday, since the 1:00 PM demo was about to start.

I have no idea how this problem was created. Perhaps the tape is kinked and folded farther in? Perhaps a well-meaning operator incorrectly threaded the tape? The winding almost looks like a TAKEUP reel rather than a FEED reel. But the existing gummed labels suggest this originally was a feed reel. Duane, you mentioned the other day that you'd found a tape reel with the tape twisted so that the wrong (non-oxide) surface was up. Could this be that reel?

Since recent demos have all used DE, this problem on one CT tape does not cause problems with demos.

Jack Ghiselli mobile 1-408-839-1051

- from Pat Buder
On Saturday, 11/25/2023, Jack Ghiselli and I gave the demo to 38 guests from Japan, Canada, and U.S. states. We also had 6 drop in before the demo. One family was from Princeton, NJ. I reminisced with them about my five years living in New Jersey long ago.

We ran on DE due to ongoing CT 1402 issues. We tested several programs before the demo, and all ran fine. My Beautiful Assistant, Jack, asked if we should demo program loading or just leave BigPrint loaded. I said that we should go for it. Fortunately the DE 1402 was feeling fine and loaded both BigPrint and Powers of 2 without incident. Tape #2 and the 1403 worked perfectly.

The 083 sorter and keypunches #1 and #3 worked fine. The printing on 026 #2 was too light to be usable. Reversing the ribbon didn't help. The A/V system worked well.

Before the demo we tried to prepare the tape drives on CT in case of failure of all DE tapes. However, we discovered that the CT tapes would not run from the TAU. We were attempting to run drives #1, #2, and #4 because #3 was marked inoperative (see Jack's email regarding a tape wound the incorrect way on that drive.). After the demo we spent some time looking at the TAU operation issue. During one attempt, I was standing by drive #2, and I heard a faint click when the TAU start switch was pressed. We then decided to test the drives individually. #1 and #4 didn't work, but #2 did. Food for thought for our fabulous restoration team.


- from Jim Maurer, - 1 PM 1401 Demo Report
For the 1 PM demo on Nov. 25 I was the lead and Duane Sand was the operator.

There were 44 visitors that attended and 8 came after. There were visitors from Japan, Mexico, and Ukraine.

We used DE since it was used in the earlier demo. The only problem came near the end of processing visitor’s name cards when the 1402 acted up. We got two read checks that were easily cleared by doing a non-process run out and a check reset followed by it working for a while. But then got it again and after clearing the read check it immediately happened again. After trying a couple of times to reset it I power cycled the system and reloaded Big Print. It then worked for the rest of the cards. Tape drives 1 & 2 were used and had no problems. The 1403 also had no problems. All 3 keypunches; were used and had no problems. And the sorter also had no problems.

There were no problems with the microphones.

Jim Maurer

1401 Restoration Reports - Wednesday, November 22nd, 2023
- from Arda Ugur
IBM 1402 Card Read-Punch machine (CT) relays tested using John’s custom build relay tester.

Arda Ugur, Sam Wainwright, Marc Verdiell, John Howard.

Using John’s Arduino-based custom relay tester (shown below), Arda and Sam tested a total of 31 relays on 1402 Card Read-Punch machine of the CT unit.
  1. A series of installed relays were identified as shown below. Top row being “Row 1” and bottom row being “Row 2”, relays were numbered from left to right.

  2. Each relay carefully removed from the machine in the order shown above, using the appropriate tool from IBM 1401 maintenance tool case.

  3. Each relay tested as follows:
    1. Set the relay in appropriate socket and press the “Select” button to ensure the correct test configuration.
    2. Press the “Test” button observe the relay pin resistance values for R_NC and R_NO positions.
    3. Press the “Rattle” button to mechanically trigger the relays.
    4. Repeat steps (a) through (c) three (3) times if the observed pin resistance values for every pin is below 2.0 ohms. Such relays are deemed to be OK.
    5. Repeat steps (a) through (c) ten (10) times if the observed pin resistance values for at least one at any time is above 2.0 ohms. Record each reading for pins. Such relays are deemed to be further investigated, replaced, or cleaned.
  4. Visually inspect each relay for broken relay tabs, and record the ones found to be broken.

Test results and findings were discussed, and two potential solutions were considered to address the relays deemed problematic. First, physically remove and clean relay contact wires, as illustrated in IBM Customer Engineering Instruction-Reference for 1402 Card Read-Punch document (shown below). Second option is to try ultrasonic cleaner – which Marc is to see into (Row 2, Relay #12 is given to Mark for trying this option).

Retrieved from: Wayback Machine (

Samuel took some additional photos of the efforts.

For more detailed information on this work (measurements and detailed photos), please refer to the attached file.

Additionally, Marc and Arda worked on the IBM 513 Summary (and Reproducing) Punch unit for minor mechanical details such as mounting from view panels back in the unit and trying to fix the turn knob of the left front panel, using epoxy.

Please let me know if I missed anything.

Last but not least, Happy Thanksgiving everyone.

Kind regards,


- from Ken Shirriff
Punch Check: I've been trying to track down this problem but it didn't happen, so I didn't make any progress.

Boot cards: I disassembled the boot card sequence with Samuel so he could modify them to not clear high memory.

SMS logger: Someone suggested using a data logger to catch the Punch Check circumstances and other issues. I've come up with a design for an SMS-based data logger.

The idea is that this card would plug into an unused SMS slot. You attach wires to eight pins of interest and then the microcontroller (Teensy) logs what happens. You can then examine the data later.
To deal with the inconvenient 1401 voltage signals, I use 8 jumpers to select T or U voltage levels. 8 comparators (along with resistors) turn the input signals into 3.3V digital signals that can be handled by the Teensy.
The board is powered from the SMS card's +6 V, with a voltage regulator to drop it to +5 V. A coin cell provides battery backup for a real-time clock so the board can log what time things happen.
The microcontroller has a micro-SD slot so data can be logged to the SD card. A USB cable can also be plugged into the microcontroller to extract

What do you think? Would this be useful? Any potential issues?


- from Samuel Plainfield
Arda and Samuel W. did an incredibly thorough job with the relay testing. Much needed, and I am sure Frank is proud.

With Ken's help, stepping through the bootstrapper code slowly to ensure that modifying the small loop from I9I (15,999) to 599 won't affect anything else in the code. Massively helpful, and the testing was mostly successful, albeit with some odd artifacts that need some troubleshooting on my part. I'll explain next week after more testing...
As such, I am not yet replacing the bootstrappers.

~Samuel Plainfield

Wednesday 11/22/2023 demo report
- from Jim Maurer
Today I was the lead for the 3 pm Wednesday demo. Larry Hara was the operator. And all in all, it went very well today.

There were 73 visitors and 16 visitors before and after. Foreign visitors were from Australia and Russia. There were also visitors from Washington and Maryland.

All the keypunches were used. Number 2 sometimes would not feed, but it mostly worked. The printing on #2 was also light.

There were no problems with the 083 sorter.

We used DE today. Big print was loaded beforehand. There were two read checks on the 1402. They happened when we were running name cards. A check reset and a non-process runout took care of it. Tape drives 1 and 2 were used and there were no problems. And as usual the 1403 was perfect.

The wireless mics worked fine, though at the end I could not turn off mic 1 with the button and had to pull the battery.

So, a good time was had by all!

Jim Maurer

CHM: Progress on Tape Demo, November 18,2023
- from Jack Ghiselli
Hi John,
I'm still working on the TDEMO software we talked about to run 1401 demo programs from magnetic tape. I made some progress on ROPE this week, and was able to simulate creating a multi-demo-program tape, and selecting and loading a demo from the tape.

Next is to try it on the actual 1401. We'll need to wait until Dave Clementson gets the CT1402 running. We'll need a working CT1402 Reader and Punch, a working CT 729 tape drive, and the CT PCWRITE/SERVER interface. I suspect we won't have all that this Wednesday, but I can show you what I've got, and CT should be working in the near future.

The idea of the system is that we select some good (existing) demo programs, be sure we have them ROPE-assembled with Tape Object (.tobj) files, and then spend some time with PCWRITE/SERVER to create a multi-demo tape. Once the tape is created, we would press TAPE LOAD on the 1401 console to bring in the TDEMO supervisor, then use Sense Switches to select the desired demo and finally press START to move the tape to the selected demo, load it, and execute it. Since we'll use the ROPE-provided tape self-load, there won't be many restrictions on existing demo programs regarding resources, so they won't require changes.

The software I've got needs some enhancements to recover from tape read errors, but we can test it without that.


Jack Ghiselli mobile 1-408-839-1051

IBM 1401 Demonstration Sat. 11/18/23 11:00 am
11:00 am - from Stephen H. Madsen
Peter Chang and I demonstrated to 36 visitors. Preparation ran late, so we did not have much time to visit with the visitors.

The microphones worked OK.
We used the keypunch farthest from the closet, and it worked OK.
The sorter worked OK.
We used DE.
We fixed tape drive #2 by rethreading the take-up spool and adding a magnetic reflector to the tape. The printer was printing faintly, so I manually turned it to get darker printing. There were some card reader errors, but we managed to make it work. We preloaded BigPrint before the demo rather than load it during the demo.

Stephen H. Madsen

1:00 PM - from Larry Hara
Duane Sand and I showcased the IBM 1401 during the 1:00 PM demonstration today, November 18, 2023. While the crowd was sparse at first, it grew quickly and eventually to a total of 75 visitors before, during and after the demo. We had the continents of North America (US), Europe (Italy), Europe/Asia (Russia), Australia, and Africa (Egypt) represented.

A/V - works very well!

Unit Record Machines

  • We used keypunch #026-1 for the demo. #026-2 wasn't feeding for a while but the machine decided it wanted to work again and did so. #026-3 (closest to the A/V closet) worked well too.
  • Sorter 083 worked beautifully.
CT 1401 - not operational. Nothing happened when trying to load a program. No reader check. No error codes. Nothing. Is this a switch/interlock/power issue?

DE 1401, 1402, 1403, 729

  • We used DE 1401 but xsince the 1402 had intermittent issues earlier during the day, we loaded BigPrint prior to the demo and did not attempt to re-load it again. Duane explained what he would have done and then just ran the program using the visitor's name card.
  • The 1403 printer worked well and printed nicely. We ran out of paper after the demo so Duane installed a new box.
  • The 729-1 and 729-2 worked wonderfully. 729-3 was not in service.
Post demo extra-curricular activities
  • I duplicated a set of VOBJ using the 026. I still need to verify the duplicate cards prior to putting it into service so I am holding on to it for now. The original VOBJ and instructions are in the metal trays as usual.
  • I started doing QC on the programs and found that BigPrint Deck #4 did not have a F/C. In fact, the first ~8 cards were missing or out of order. After Jack's efforts to straighten out the BigPrint decks, I don't understand how this can happen so quickly. I forgot to label this with a sign "do not use" but will do so on Wednesday, or better yet, if I have time, I'll restore the deck.


NPRO crunching update - received Friday November 17, 2023
- from David Clementson
Per a comment Marc made in a recent email, I have begun to question the validity of my assumption that our test case should proceed without crumpling a card. Our test case consists of pre-loading a card into the throat of the machine, then pressing and holding the NPRO switch. It is possible that this procedure reliably crunching a card may just be normal behavior. However, since this procedure does not crunch cards on the DE machine, I am now considering the possibility of faulty logic (card levers, relays, etc.) explaining the behavior difference. Others have pointed this out already, and you may be right.

Here are some observations:

  1. The roller-to-roller spacing must be smaller than the 3.25" width of a card so that a roller-to-roller handoff is possible. If the spacing were larger, cards would get stuck between rollers. I measured the machine today and found the roller spacing is approximately 3" for all four rollers, which makes sense.
  2. One 360 degree clutch cycle advances the cards by 5.00" based on the calculation that the 0.250" row spacing matches the 18 degree (= 1/20 of a revolution) solar cell pulse spacing. A full revolution then equates to 20 * 0.25" = 5.00" of card motion. Once the clutch trips, the cards advance by 5" and cannot be stopped.
  3. Our rotary encoder experiment showed that when we ran the "preloaded card" test case that crunched the card, the clutch executed one and only one cycle.
  4. Per Items 2 and 3 above, the crunch test grabs the card immediately and moves it 5.00" from its initial position at which point the clutch releases and the clutched rollers stop. Per Item 1, this is about 2" into the second roller. But the second roller is unclutched, so the card will continue until it crashes into the stopped 3rd roller.
  5. According to the timing diagram (see below), during a normal pick the knives load a new card so that Card Lever #1 makes (and the first roller grips) at 227 degrees. Since the clutch releases at 315 degrees, the card moves only 88 degrees (= 1.22") on this cycle. Compare this to the 5" of card movement for our test case. It is no wonder the card crunches.
  6. Comparing this behavior to the DE machine would be useful. I will bet that if we put the rotary encoder (or a scope) on it and execute the same test case, we will see that Item 3 does not hold, and DE executes more than one clutch cycle. That is just about the only way for the test case card to not get crunched. If this is the case, it will point the finger at the -T NON PROC FEED qualification logic being somehow different between CT and DE, which may be the true root cause of the card crunches.

So we may wish to do this test on the DE machine before we make the decision to install the new rollers into the CT machine. The test is quick and non-invasive, and it could point us in a new direction about the true cause of the CT machine's behavior. And Shmuel, it doesn't violate any debugging rules!


1401 demo for Pacific Collegiate students - November 17, 2023
- from Jim Maurer
Today we gave demos to 100 students and some teachers and parents from the Pacific Collegiate school in Santa Cruz. They were divided up to two groups of 50 each. I was the lead, Karen Sun was the operator, and Paul Laughton and Duane Sand were the backup operators.

When setting up the equipment before hand I tried loading Big Print on both machines. The CT 1402 did stop with the first card stopped halfway into the reader. There were no checks. I did a non-process runout and tried again, and it loaded the program fine. When I tried DE, it also stopped with the first card half into the reader. I tried a few times, and it would not load, so it was decided to use CT. Then the students arrived. I like it when we load the program as part of the demo, so I did that. I will not be doing that again; I learned my lesson. The 1402 would load about half of the deck and then stop, with no checks. Pressing start it would then load a few cards and stop. So, Paul went to work on DE while we went ahead to show the tape drives and the cables. Paul did get DE to load the program by powering the whole system off and on again twice. The students were then punching their name cards and we started running them through DE. However, the ribbon stopped advancing so the print got very faint. Paul went to work on the printer and was able to get the ribbon to advance. The second group then arrived, and we started the presentation for them. However, we had to stop because the group leaders found out that there was an accident on highway 17 and it was going to take them a long time to get back to Santa Cruz. We were able to run some of the name cards while they were getting on the bus and Duane took them out to the bus before it left.

So, we had issues with both 1402 readers. We had an issue with the DE 1403 not advancing the ribbon. All the tape drives worked fine. All the keypunches worked fine. The sorter also worked.

Paul, Karen and Duane, please chime in if I’ve left out anything that happened.

Jim Maurer

Demo Restoration Report, Wed 11/15/1023
from Jack Ghiselli
The main restoration effort on DE was Ken Shirriff continuing to investigate the problem with DE1402 Punch Checks preventing card loading.

I noticed that our demo BigPrint decks were not doing well. Some were marked "Doesn't Run" or similar. So, during the periods when Ken wasn't using DE, we fooled around and were sometimes able to get the Punch Check to disappear for a while. I took that time to use DE to run VOBJ to investigate the BigPrint deck problems. We currently have five (5) copies of BigPrint, identified as #1 through #4 and a fifth one marked "Frank King". I found at least a trivial problem with every one of these decks.

  • BigPrint #1: First Card was missing the program ID in columns 76-80. Probably happened when a Good Samaritan duped a worn first card and got tired of holding down the DUP key about column 77. Trivial error, which did not prevent this deck from loading and executing OK.

  • BigPrint #2: The deck was missing Cards #2 and 3. Probably, this happened when somebody loaded the deck, got a Read Check on the first card, and forgot to do Non Process Runout when re-building the deck. As it was, this deck would not load.

  • BigPrint #3: Cards #53 and #54 were swapped. Despite this minor error, this deck would still load and execute OK. No idea how this happened.

  • BigPrint #4: First Card was missing the Program ID in columns 76-80. Card #9 was incorrectly moved after Card #11. Despite this minor error, this deck would still load and execute OK. No idea how this happened.

  • BigPrint "Frank King": Card #1 was missing the Program ID in columns 76-80. There were three (3) copies of Card #98. A few years ago, BigPrint Card #98 was patched to correct a printing error for the big letter "D". Two of the Card #98s were the unpatched version, and the third was patched. Probably the "Frank King" deck was copied from an old copy of BigPrint which hadn't yet finalized the patch. The minor errors did not prevent this deck from loading and executing OK.

I corrected all the problems noted above. As of 11/15/2023 2:00 PM, we have in the demo trays five (5) BigPrint decks which all are identical, and all load and run. The DE1402 Reader infrequently gives Reader Check errors, but they don't seem to be related to any specific BigPrint deck. I didn't have time to investigate any other demo programs (Powers-of-Two, Lincoln, etc.).

Jack Ghiselli mobile 1-408-839-1051

- from Jim Maurer
Today, 11/15/2023, Scott Stauter and I gave the 3 PM demo. We used DE today. We had no hardware issues with the system. Tape drives 1 and 2 were used. All the keypunches operated normally. The sorter worked with no issues. The 1402 worked with no checks occurring.

There were 24 visitors who attended the demo. Plus, there was 1 person before and 2 afterwards that we talked to. Foreign visitors were from Hong Kong, Sweden, Romania, Ukraine, and Canada.

There were problems again with the channel 2 wireless microphone. Sometimes when you attempt to put it on standby or power it off it will not respond to the button. You must remove and reinstall the batteries and hope it doesn't happen again.

Jim Maurer

Restoration Report for Nov. 15, 2023
Restoration Report for Nov. 15, 2023 - update
- from David Clementson - arrived Thursday evening
A couple of updates:
  1. The new rubber rollers have arrived and they look great. The rubber is quite hard, which is good, and the OD is a tiny bit oversize (1.22" vs 1.21" theoretical), which is also good. See the photo below.
  2. It occurred to me that by using two rotary encoders, one on the #1 drive roller and the other on its pinch roller, we can compare them for evidence of card slippage. If there is no slippage, the drive and pinch rollers will have a ratiomatic angular relationship determined by their differing diameters. If the software is written to compensate for that diameter ratio, the two angular position plots should be congruent. If they are not congruent, something must be slipping.


- from Ken Shirriff
I attempted to debug the Punch Check on DE, but the error didn't show up, so I didn't get very far. I studied the punch documentation some more and found that there are two ways to get a punch check: first, if the hole count doesn't match (which I knew about), but also if there is a parity error on the B register during a punch (which I didn't know about; this signal is confusingly called ALLOW B REG CHECK).

Either way, there shouldn't be a punch check unless a punch scan is happening, so I still think the underlying problem is in the punch scan circuit. But it's hard to track down because it is intermittent.


- from David Clementson

Card Crunch movie

CT 1402 Reader card crunching:

I wanted to try to cut the motion analysis problem in half to see if either the machine is somehow misbehaving (bad clutch, etc.), or if the cards are just not moving as the machine needs them to move. So I attached a high-speed, high-resolution rotary quadrature encoder to the #2 clutched roller shaft to see if I could find any evidence of mechanism misbehavior. The setup has a brass hub to couple the encoder shaft to the roller pulley. The curved metal strap is screwed to the encoder body to keep it from spinning:

The encoder signal was sent to an ESP32-based quadrature capture board and from there plotted using the Arduino Print Monitor function. This is what a single clutch cycle looks like after being triggered by about 10 degrees of initial motion:

The vertical scale is degrees of machine cycle, and the horizontal scale is (approximately) milliseconds. You can see from the linear trajectory that the roller comes up to speed almost immediately and spins at constant speed until the clutch releases, at which point it stops dead. The small ringing at the stopping point is likely due to elasticity in the belt and vibration of the thin sheet metal arm that keeps the encoder from spinning. This 'signature' waveform happened when a single card was processed correctly. An identical waveform was produced when the card got crunched. There was no observable difference between the card crunch waveform and a normal single-card read waveform. This agrees with what we have seen all along when observing the solar cell waveform. I think it is safe to conclude that the mechanics and relay logic are not misbehaving when the card gets crunched.

We then took a high(ish) speed iPhone video of the card crash (attached). Viewing the movie frame-by-frame clearly shows the card jamming into the stopped clutched roller #2, but card slippage at the first clutched roller is not readily apparent. Maybe better video analysis (or a proper high-speed camera) will reveal that, though.

We had a mid-morning coffee+brainstorming session to review the results. One theory that emerged is that as a result of the roller swap John and I performed last summer, the "new" rollers we installed may be slightly smaller in diameter than they should be. This would result in the card not moving as far as it should do when its drive roller turns its prescribed number of degrees, making the card "late." So we set out to measure the "new" roller diameter.

Since it is not possible to fit calipers inside the machine, we measured the card travel per clutch cycle instead. We manually rolled a long strip of printer paper under the first roller until the clutch unlatched, marked the throat plate position on the paper, manually cranked a single machine cycle, and marked the paper again. The theoretical card travel for a 360 degree machine cycle is 5.00", calculated from the ISO 0.250" row spacing and the 18 degree per row solar cell spacing. The measured travel was 4.9", only 2% below the theoretical value. While we don't think this 2% completely explains the crunching problem, it may be adding to it by eroding whatever margin the mechanism has for allowable slippage.

One next step for analysis would be to somehow track the actual card position with similar speed and resolution as the rotary encoder does for the roller angle. Gluing a "tail" to the card that has some kind of linear scale (optical or magnetic or ?) and passing that through a reader would allow us to track the actual card position. Comparing that to the roller angle would allow us to characterize the card/roller interaction.

Another next step is for me to ping the vendor about the delivery date for the new rubber rollers.

That's it for this week.


CHM 1401 Demo Saturday 11/11/2023, 11:00 AM & 1:00 PM
- from Jack Ghiselli
On Saturday, 11/11/2023, I came in early to assist as 2nd Operator for the 11:00 AM demo, which was given by Karen Sun and Peter Chang. The hardware was not cooperating. Karen and Peter had tried the CT1402 Reader, but found it was crunching cards (Dave Clemenson and Sam Plainfield are working on fixing this), so Karen & Peter were working hard to repair the first few cards of damaged BigPrint decks. The DE1402 Reader was also INOP, due to a pesky Punch Check which refused to clear (Ken Shirriff is hot on the trail of fixing this), so Karen and Peter were disappointedly preparing to do a demo with no card loading or printing. However, at the last minute we tried powering off DE, waiting a bit, and powering it back on. Somehow, this cleared the DE1402 Punch Check, and the DE Reader would now load cards normally. Karen and Peter proceeded to give their usual excellent 11:00 demo using DE and running BigPrint.

Between the demos, Peter again tested his one-card "Hello World" program. It didn't finish correctly today, but Peter is getting better and better at programming.

Duane Sand and I gave the 1:00 PM demo to 40 visitors, plus mini-demos to 30 additional people who wandered in after the main demo. We had international visitors from Brazil, China, Finland, France, Japan, and Turkey. We had one special distinguished visitor, Mr. Jackson McGregor, from Homer Alaska. He came with his mother, Kate. Also attending was Emily Beeston, the new CHM Staff member who'll be working with us volunteers, so we got to meet her. Late in the day, the DE1402 started to get Reader Checks. Another DE Power off/on cycle seemed to correct that.

All three 026 Keypunches and the 083 Card Sorter worked fine. We used the TAUs on both CT and DE to demonstrate tapes (2 drives on DE, 3 on CT) so all the visitors could see. I had some problems getting the microphone wire on my Audio Headset to stay positioned. Duane fixed it for me, so Duane is definitely the go-to guy to help with headsets.

Unless more hardware gets fixed on Wednesday, I guess our recommendation would be to demo on DE, and try powering the system off and on if you get a non-clearable Punch Check.

Jack Ghiselli mobile 1-408-839-1051

IBM 1401 Demo: November 8, 2023 3:00 PM
- from Larry Hara
Samuel Plainfield and I presented the IBM 1401 demo today, November 8, 2023 at 3:00 PM. We had 52 visitors before, during, and after the demo. Our out of town guests were from locations such as Pittsburgh, Spain, and Ukraine.

All the keypunch machines worked and we used #1 for the demo.

Sorter 083 worked just fine.

The Restoration Team worked hard on CT1402 during the day. [Thank you] But at 2:40PM, things didn't look promising so we made plans to use DE, which was working well earlier. Then, 15 minutes prior to the demo, DE had card reader problems. We resided to use our backup plan of just talking through the demo with props and printouts from previous runs. Luckily, Sam's persistence and our collective positive thoughts and energies came through and BOTH DE and CT started working again immediately before the demo.


Samuel was able to run BigPrint on CT.

The first 2 drives of DE729 were successfully used for the demo.


IBM 1401 Maintenance - Wednesday, November 8, 2023
- a long list of e-mails starting Wednesday at 8:27 AM
- from Bhushan Mohan - 8:27 AM
During NPRO the clutch is always energised and the card does not stop anywhere.
For looking into card jams of these types, it's good to diagnose on NPRO by deactivating the hopper card lever.
Hopper card lever checks for cards in the hopper and under normal operation cards are to be removed from hopper for NPRO. But if Hopper Cardlever is deactivated (i.e. its open then NPRO shall feed the cards continuously.
No harm in trying this out to diagnose the problem

Bhushan Mohan

- from David Clementson - 9:09 AM
Hi Bhushan:

The clutch solenoid cannot be continuously energized because of of its series capacitor; it has to be pulsed. And we see this on the oscilloscope when we observe the solenoid drive voltage. But the solenoid can be retriggered just before the dog is about to reset, resulting in a pulsed solenoid drive, yet a continuous rotation of the clutch output pulley.

I deliberately described that the cards stop in front of each brush station to underscore the step-by-step nature of the card processing. But if the solenoid is pulsed just before the clutch is about to unlatch, the clutch continues to spin and the cards don’t actually stop. Yes, my original description was purposely a bit deceitful, but I didn’t want readers to think that the solenoid just turns on and the cards flow forever without further logic intervention until the solenoid is turned off. All of the card lever and cam switch qualification logic still happens for each clutch (half) revolution, even if the clutch is still turning when a new cycle begins. This is important because our card crunches may be due to some failure or instability in this qualifying logic.

Or else the rollers are slipping. ;--))


- from Bhushan Mohan - 9:09 AM

The above picture is of the feed rolls.
From what I understood from Samuel mail was that 2 Clutched feed roll stopped on NPRO resulting in card jam.
I have marked the clutch, Clutch belt, clutched feed rolls and the continuously running rolls in the above pic.
Hope my understanding of Samuel's observation is correct.
Card levers 1 and 2 could timings could give indication on the card movement.

Bhushan Mohan

- from Bhushan Mohan - 9:32 AM
My comments are as below
Bhushan Mohan

On Wed. Nov 8, 2023 at 9:09 AM David Clementson wrote:
> Hi Bhushan:
> The clutch solenoid cannot be continuously energized because of of its series capacitor; it has to be pulsed. And we see this on the oscilloscope when we observe the solenoid drive voltage. But the solenoid can be retriggered just before the dog is about to reset, resulting in a pulsed solenoid drive, yet a continuous rotation of the clutch output pulley.

Agree. The clutch shall get energised by the pulse. However it shall not latch up and cards move continuously.

I deliberately described that the cards stop in front of each brush station to underscore the step-by-step nature of the card processing. But if the solenoid is pulsed just before the clutch is about to unlatch, the clutch continues to spin and the cards don’t actually stop. Yes, my original description was purposely a bit deceitful, but I didn’t want readers to think that the solenoid just turns on and the cards flow forever without further logic intervention until the solenoid is turned off. All of the card lever and cam switch qualification logic still happens for each clutch (half) revolution, even if the clutch is still turning when a new cycle begins. This is important because our card crunches may be due to some failure or instability in this qualifying logic.

Any failure would reflect on both the 1st and 2nd clutched rolls. To me it looks to be a mechanical issue-could even be improper clutch operation. That's the reason I enquired about the two clutch springs-for this you will have to remove the eliminate any problem from there.

Or else the rollers are slipping

Eliminate the pulleys and the drive in case only the 2nd Clutch roll is giving problems. Do check the timings both at card levers and the brushes.


- from David Clementson - 8:44 AM
Shmuel and I used the scope to measure the elapsed time from the clutch solenoid energization to the Card Lever #2 switch closure. All cards always arrive a little late according to the timing diagram in the schematics, but cards that get crunched arrive much later still. I have interpreted this as hard evidence of roller slippage. But of course I could be wrong, so I took the deep dive into the NPRO process and the switch and cam qualification logic that controls it. I found lots of ways to suppress further clutch cycles once NPRO has begun, but none to terminate an in-process clutch cycle. I also didn't find any way for a card to get delayed. And by looking at the uninterrupted solar cell pulses, we can see that the clutch is not coming unlatched, and the roller belt is not stopping mid-cycle. And we verified that the roller pulleys are all keyed and the keys are intact, making the pulleys incapable of slipping on their shafts.

It comes back to roller slippage as still being the prime suspect. Replacement rollers are being fabricated and should arrive in a week or two.


- from Bhushan Mohan - 4:53 PM
I agree that misfeeding the card under the rollers would most likely be the reason for the card jams.
While you are waiting for the new rollers I suggest we check the following:
  1. Drag under each roller.
    Manually feed one card and check the drag on both sides (rear and front) on the card. Should be checked for the complete circumference of the rollers.
    Better still cut the card longitudinally and pass iech strip under the front and rear of EACH of the rollers to check the drag. For the clutched rollers please engage the clutch. Drags could give indication which of the rollers might be slipping.

  2. Bearings for bind and play. Gears of continuously running rollers
    Each pair of the 4 card feed rollers have one fixed and the other spring loaded roller. Would be good to check for all the 8 spring pressures and also all the 16 bearings for bind and play.
    Also please check the continuously running front cogged belt driving the 2 contact rolls and also the gears driving the 1st and the last continuously running feed rolls. Problems in any of these areas would result in card jams.

Please also update any further developments that took place today. By now you would be packing up for the day.

Bhushan Mohan

- from David Clementson - 6:13 PM
Hi Bhushan: All of the checks you mentioned have been done already repeatedly weeks ago. And and we repeated some of them again today. Since the jam happens before the card gets to the (already stopped) 2nd clutched roller, I think we can safely say that the problem is upstream of that roller. We have been all over clutched roller #1 already, and today we looked closely at unclutched roller #1. Its grip tested fine statically and its pinch roller bearings, pivot, and springs also inspected okay. So we are just about out of things to check.

BTW the jamming is much less frequent than you might think it is. Maybe once in a few hundred cards? So we are encouraging the operators to use the machine for demos with the understanding that they may encounter the occasional jam.

But manually loading a single card always jams on CT and never jams DE. When manually loaded, the card is in a position that is similar to an mis-picked card, which can happen during a demo. A subsequent jam wrecks the demo, so we seem to agree that the problem is real and needs fixing.

Besides installing the new rollers when they arrive, next steps for me include studying the potential of making a “high visibility” card path that would allow a high speed camera to capture the fault as it occurs. We have spare brush assemblies that can be stripped of everything except the card guide. Then I will try to make a clear acrylic version of the card lever 2 plate. That plus adding location markers on the cards and rollers should enable us to make a realtime recording of the jam.


- from Bhushan Mohan - 9:20 PM
Only one card feed gives problems but a program of 100 cards may feed ok. Continuous Read problem is less. Intermittent Read m/c gives card jams(?). It appears the problem comes whenever the Clutch gets latched at the end of Read cycle. If the above is correct then the problem is likely to be in the reader clutch operations..most likely not latching, keeping or detenting properly. Latch keeper could be a likely problem giving a backward motion to the card. This problem would NOT appear on scoping under continuous read. Need to be checked under intermittent feed.

If only one card does not feed ok, please check the clutch status. First check the Latch Keeper. The Latch Keeper could be checked without opening the clutch.

Else it would be worth opening the clutch for cleaning and checking the Latch, Latch Keeper and also the Dog and Detent on the clutch.

Worth a try to check these out

Bhushan Mohan

- from Robert Garner - 10:35 PM

> Latch keeper could be a likely problem giving a backward motion to the card.

Interesting idea. Can you possibly explain further how this might/could happen? Did you ever encounter this in the field?

Thanks again for participating in our 1402 bug shooting expedition.

— Robert

p.s. I wildly pontificated last week that something (who knows what) might/could cause a slight/momentary backward roller motion. :)

- from David Clementson - Thursday 11:55 AM
I don’t understand how the solar cell‘s signature waveform would not show some kind of perturbation if the clutch is having trouble latching, or is not rotating smoothly. There is an 1:1 relationship between the solar cell and the clutch output gear thanks to the cog belt. And since we trigger the scope on the clutch solenoid signal, any clutch latch failure will appear as out-of-time late solar pulses. We have never seen that, even when the card gets crunched.

But monitoring the clutch output angle more closely may yield more clues. I’m thinking about adding a second rotary encoder to the clutch output somehow that gives both better angular resolution and covers the entire 360 degrees of rotation. Although a high speed camera looking at the clutch output pulley would also work well.

I like the idea of breaking the problem in half to see if the trouble is “before” or “after” the clutch in terms of mechanical energy transfer. Slipping rollers are “after” the clutch pulley, whereas a malfunctioning latch, keeper, or dog are “before” it.


- from Samuel Plainfield - Thursday 11:57 AM

On the CT1402, it looks like the second (read) set of brushes are currently working very well. A print of all-four's deck results in a perfect print-out.

However, we are still getting reader checks. So, Frank and I methodically checked via storage scan and saw that the first set of brushes (check) 3, 30, 50, and 51 were repeatedly showing up.

(Note brush #30 on the console appearing)

With Arda's mathematical help, we located the suspect brushes; I replaced three of the brushes. Brush #3 was not replaced, because it was not showing up as often as 30, 50 and 51. Running the tests again, it didn't seem to make much difference... the brush errors came back with similar results...somewhat.

(Brush #50 being removed)

During the demo, I was able to run the full deck of software and myriad name cards with no jams and with I/O check on. At one point, I got a reader check; due to my confidence that the second set of brushes are not the culprit, I just switched off I/O check and continued printing the name cards which sure enough printed correctly. Due to the intermittent nature of the device, this may work today and utterly fail by Saturday. I left I/O check off -- so, if you forget to turn it back on, and get a strange error on the console, that means something went awry on the second set of brushes.

There's a box o' brushes that were donated from a former IBM CE. Frank told me that he gave it all to the museum some years ago and Frank opened the box to discover all those "juicy" parts. Those "new" brushes are indeed fresh and juicy. I suspect there's plenty of micro-rust on the "old" brushes that would benefit from being put in some kind of safe solution to dissolve it away -- does anyone know of such a substance that might fit the bill?

("New" 2-group brushes!)

David observed that brush #3 is used in connection with the dynamic analyzer which was left on by accident; so, that may play a role in some of the behavior we're seeing.

David and I were experiencing some potential operator error in getting the dynamic analyzer to work. We configured the settings on the 1402 CE panel to what we recall/thought should display the neon lights to show cam timing, but were unable to do so on either machine ... so, we'll need Frank to remind us and I'll memorialize those settings. We were also unable to get the reader clutch switch (to advance a card without 1401 input) to work -- which we've never seen work before. David noted afterwards that perhaps the motor needs to be running prior via Start in order for that switch to work since the switch by itself has no mechanism by which to activate the motor.

David and I also checked the firmness of the pinch roller for the continuous unclutched rollers. They're extremely tight, no way that a card can slip when captured.

I rck'n that's all for now,

~Samuel Plainfield

- from Frank King - Thursday 2:22 PM
One of the things we must consider is that punching all, 80 holes in the card is a worst case for the brushes as it would be rare for the reader to read that many holes at one time. We are not saying it shouldn’t, but the test is not realistic. So, I say let’s be sure to test in a more realistic manner for a 70 year old. The fact we can load a program should be enough to give it back to the docents.

Frank King

- from Ken Shirriff - Thursday 3:36 PM
Summary: got closer to finding the DE punch check problem, but last week's hypothesis didn't work. My current suspect is board 01B4 B26.

The problem is intermittent, which makes it harder to track down. DE was working in the morning but failed after lunch. I turned off the air conditioner which (maybe coincidentally) got it working again in time for the demo. It is hard to get all the measurements I want because the problem is intermittent. Moreover, the triggers (flip-flops) are very sensitive and sometimes putting the oscilloscope probe on a pin toggles it.

Working backward from the punch check light:

I am pretty sure that the difference between working and non-working is the PUNCH SCAN GATE is -10 in the good case and -5 in the bad case. I pulled D19, which caused the light to go out, but the system still failed to read cards, so the problem is before D19.

Last week, I suspected the PUNCH SCAN trigger A22 was misbehaving. Marc and I tested it extensively and it appears to work properly. We also swapped the card and that had no effect. (One random thing: If we toggled it high, the console went wild as the CPU tried to perform a punch scan.) So I think the problem is between the trigger and the PUNCH SCAN GATE signal, that triangle northeast of A22.

The triangle (AND gate) consists of 3 boards (!) Here is the relevant part of the ALD:

Based on my measurements, both signals into the NAND gate are low, but the final GATED PUNCH SCAN (yellow) is high in the bad case. So maybe the NAND gate B26 is bad? Since the other cards only have one input, I don't see how they could give the wrong answer sometimes. So my plan is to examine B26's inputs and outputs the next time the punch check happens, to see if it is the culprit.


- from Bhushan Mohan - Thursday 7:47 PM
Reader problems ( Reader Check, Reader Stop, Card Jams) are divided in 2 categories.
1. Problems in Continuous Read operations
2. Problems in Intermittent Read operations
The first one is simpler and can be addressed very logically
The second one points out problems mostly in the Read clutch drive area. More difficult to scope logically.
Many of our large customers used to read almost 100,000 cards per day. And most of them used to be in intermittent Read. (Only program decks used to be in continuous read).
As a practice we had modified our PM program for these critical customers and scheduled Reader Clutch PM including checking of all belts and pulleys once a month. In India the dust levels are very high and the card quality was not that good. Lots of fluff from the cards. Also to save time any unexplained intermittent Read problem required the attending CE to check the Read Clutch area. This was one of the best practices we adopted. Our target for System availability was 98%.
Although most of the problems in intermittent Read were Reader Checks and Reader Stops, the card jams were more rare. I do remember at least one such incident which was circulated in our CE bulletin.

@ David,
You are very right in observing perfect solar cell signals. As I had mentioned in my earlier mail this observation is taken in continuous read operation. The problem as I suspect is coming at the end of the read cycle when the clutch is getting latched. That situation has not been scoped. Moreover I rely on solar cell pulse along with the brush reading pulse from the card and that too when cards are fed with intermittent Read.

I would like to add the best tools that we had for diagnosis was the Tek 465 oscilloscope.
I would strongly suggest looking into the clutch status after feeding one card which is not in the proper position.
Problems with the keeper or the clutch arm although are rare but many a times during our PM time we had found it to be worn out needing replacements.

IBM also circulated lots of CEMs during that time. If CEMs on 1402 or even on 2540 ( later but faster model) are available it would be a good idea to go thru them.

Bhushan Mohan

The 1402 NPRO Cycle
- from David Clementson - Monday, November 6, 2023
- and a comment from Bhushan Mohan
Since the CT 1402 card reader and its errors are still a subject of concern for the Museum, and for the benefit of our latest volunteers, I thought I'd dive into how the card reads are accomplished. In particular, I'll focus on what I've found about the Non-Process Runout (NPRO) cycle.

Ken wrote a great overview of the basic card read process here. He did another excellent writeup of how the clutch cycle works mechanically here. Studying those two blogs will help you follow along with the rest of this writeup.

The card read process centers around the clutch cycle, which is the mechanism by which the 1402 moves cards step-by-step along the reader card path. On their journey from the Hopper (input card stack) to the Stacker (output card stack), the cards can stop at two intermediate locations, one just in front of each of the two sets of read brushes. So a full card read takes three clutch cycles: Hopper-to-Brush #1, Brush #1-to-Brush #2, and Brush #2-to-Stacker. After getting "picked" from the bottom of the Hopper stack, the card is fed into the first clutched roller which grabs it and then stops, holding the card in preparation for the next cycle. During the next cycle, the first clutched roller turns and forces the card under the first set of brushes. On exiting the first brushes, the card is grabbed by a continuous running roller which feeds it into a second clutched roller. This roller grabs the card then stops, again holding the card in preparation for the next cycle. On the third and final cycle, the second clutched roller turns and forces the card under the second set of brushes. After exiting the second set of brushes, the card is grabbed by a second continuously running roller, which sends it to one of the Stacker output bins without further delay.

The problem the CT machine is currently experiencing seems to happen during the handoff from the first continuously running roller to the second clutched roller. In order to have a smooth transition from one roller to the next, both rollers must be turning during the critical handoff interval when the card is simultaneously gripped by both rollers. What we are seeing on CT is that for some reason, the second clutched roller is not turning during this handoff interval. This results in the first continuous roller jamming the card into a stationary second clutched roller, which crumples the card.

This card destruction happens reliably during a non-process runout (NPRO) when a single card is manually loaded into the first clutched roller as if it had been freshly picked. So we have been using that scenario as debugging the test case. This is why I chose to take a closer at the NPRO process.

First, it is important to understand that the clutch cycle is electrically triggered, but once triggered, there is no way to stop it short of a mechanical failure of the clutch. There is circuitry to monitor the success of the clutch failures, and we have never seen evidence of such a failure, even after a great deal of study and analysis using a variety of techniques.

Triggering a clutch cycle requires the cooperation of the 1401, since the actual clutch driver amplifier resides inside the 1401. The 1402's clutch solenoid circuit is shown below:

The solenoid coil itself is labeled READ CL MAGNET and is located at the top center of the diagram. Notice that it is in series with an RC network comprised of R15 and C4. The purpose of the network is to limit the power dissipation in the solenoid. The component listing shows the solenoid's DC resistance as 3.3 ohms. Since the solenoid is driven from -20V, if left on continuously it would draw about 120 watts, certainly enough to burn itself up. So the RC network essentially AC-couples the solenoid. Here is a SPICE model of the circuit and its response (note that the 10mH solenoid inductance value is just my guess, but it seems reasonable):

The green trace shows the solenoid current pulses, while the red trace (cathode of D1) agrees with the signal that we have been using to trigger the oscilloscope for debugging. The ground connection at the anode of D1 sumulates an always-on condition of the 1401 driver signal.

Looking back at the 1402 schematic, you can see that the left side of the solenoid is connected to switch CT-A, and RC5. CT-A is involved with the Dynamic Analyzer's manual card feed function, and is not enabled in our test case. RC5 (continuous running cam #5) is driven by RC6 ((continuous running cam #6) whose timings can be seen below. They provide a once-per-cycle or a three-times-per-cycle (depending on the state of the SYNC switch that shorts RC5) pulses that actually pulses the solenoid. These cams are represented by V1's .PULSE statement in the simulation.

Again looking at the 1402 schematic, the right side of the solenoid drive circuit is connected via switch CT-B to RC 170 (-T READ CLUTCH). CT-B is again associated with the Dynamic Timer manual card feed feature and can be ignored. RC170 is the pin number of the cable going to the 1401. -T READ CLUTCH is a signal generated in the 1401 on ALD as seen near the bottom right corner here:

The driver of this signal is SMS card type "MD," which is a PNP open collector current sink driver as shown here:

Looking at the ALD again, the input of this MD driver is the wire-or connection of two signals: one is a logically qualified version of -T PROC FEED (shown to the far left of the driver), and the other is a filtered and level shifted version of -T NON PROC FEED. These signals come from the 1402 via wires RC 171 and RC 172 respectively, and can be seen at the middle right side of the 1402 schematic above. -T PROC FEED is used during a standard card read, with the additional qualification on the ALD having to do with 1401's general readiness to receive card reader data. -T NON PROC FEED is used during an NPRO, and has no further qualification logic in the 1401. -T NON PROC FEED is actually a fairly complicated signal that determines the clutch action during a NPRO.

The NPRO process is described in the manual thusly:

As mentioned above, the NPRO key has two functions: one to control the main motor (and hence the timing cams), and the other is to generate -T NON PROC FEED.

NPRO process Steps 1 and 2 show that Main Motor control happens via relay R9 MOTOR CTRL, and is conditioned only by relay R1-1N which is picked directly by the Hopper card lever. This is why the Hopper must be empty to start a NPRO.

Steps 5 and 6 indicate that there are two conditions that can generate -T NON PROC FEED, each with separate qualification logic. To understand them, we need the relay name decoder ring from the schematic.

Relay 13 is unnamed in this table, but on the schematic (see below) its pick coil is labeled STOP CONTROL.

For Step 5 we have these conditioning qualifications:

  1. R4-2T (READ STOP relay, contact set #2, T indicates the contact is closed when the relay is energized, aka 'picked')
  2. R6-3N (READ FEED relay, contact set #3, N indicates the contact is closed when the relay is dropped)
  3. R7-2T (RUN-READER relay, contact set #2, T indicates the contact is closed when the relay is picked)
  4. RC5 (continuous cam #5, CLUTCH SYNC)

And for Step 6, these qualifications:

  1. R6-3T (READ FEED relay, contact set #3, T indicates the contact is closed when the relay is picked)
  2. R13-2N (STOP CONTROL relay, contact set #2, N indicates the contact is closed when the relay is dropped)
  3. R2-3N* (#1 card lever relay, contact set #3, N indicates the contact is closed when the relay is dropped) N* = determined from schematic symbol
  4. R1-6N (Read Hopper card lever relay, contact set #6, N indicates the contact is closed when the relay is dropped)
  5. R3-4N (#2 card lever relay relay, contact set #4, N indicates the contact is closed when the relay is dropped)
  6. R11-3N (#1 CLUTCH DELAY relay, contact set #3, N indicates the contact is closed when the relay is dropped)
  7. R4-2T (READ STOP relay, contact set #2, T indicates the contact is closed when the relay is picked)

To further understand these qualifications, we need to know which relays are picked under which circumstances. This is an extremely complex matrix of conditions, but here are some observations:

  • Common between Step 5 and Step 6 is the 2T contact of relay R4 READ STOP. This indicates that -T NON PROC FEED can only happen when the READ STOP relay is active. But in Step 3, the NPRO always picks R4 READ STOP, so this condition will always be true during an NPRO. The READER STOP light shows this condition.
  • Also common between Step 5 and Step 6 is relay R6 READ FEED. However Step 5 uses the 3N contact, with the "N" meaning this relay must be deenergized (aka 'dropped') in order to enable -T NON PROC FEED. In contrast, Step 6 uses contacts 3T, with the "T" indicating that the relay must be picked to allow -T NON PROC FEED. So these opposing conditions may indicate the rationale for having two sets of conditions for allowing an NPRO. Keep reading.
  • The circuitry for the R6 READ FEED relay is shown below.
  • Notice that R6 READ FEED relay is picked by clutched cam RL3 (READ FEED PICK) whose timing is shown here:
  • The fact that R6 only picks via a clutched cam, meaning the clutch must already be engaged to pick R6. This might reveal the reason for the two ways to generate -T NON PROC FEED: one to start a clutch cycle when the machine is dormant, and the other to continue cycling if a cycle is already in progress and the clutched cams are operating.
  • Step 6 further shows that CARD LEVER relays #1 and #2 the READ HOPPER relay need to be dropped in order to generate a -T NON PROC FEED. These relays have cam-driven pick and hold coils, so they will pick and drop depending on the state of the card levers and the angle of the machine. Another complex matrix of conditions.
  • Finally, the CLUTCH DELAY relay must be dropped to generate a -T NON PROC FEED. I suspect this is meant to de-assert -T NON PROC FEED signal after a clutch cycle has successfully been initiated.
So this is the NPRO process in some detail, but doesn't answer all of the questions, particularly about the role of the card levers at different times in the machine cycle. Even though it doesn't explain our current card crumpling problem, I hope this info is at least somewhat useful to future debuggers!


from Bhushan Mohan

Excellent write-up on the Reader card feed mechanism. Would be very useful for any person debugging in this area. To further debug the card jam on NPRO, you could block the card lever in the hopper ( by removing one of the wires from the card lever contacts), put cards in the hopper and do NPRO. This would give continuous clutch cycles and enable to feed cards without any read instruction from the CPU. Could be very useful to diagnose the Card Jam bug in an offline mode.

Bhushan Mohan

IBM 1401 live demos Sat Nov. 4
IBM 1401 live demo Sat Nov.4 @11am
- from Karen Sun
Paul Laughton and I gave the Saturday morning demo to 50 visitors. Michelle is our backup operator and she was very helpful throughout the whole session, especially managing the big crowd to punch their name card after the demo. We had international visitors from Germany, Nepal, China and a group of Pittsburgh Penguins Hockey fans (who were gonna cheer for the Pens vs. Shark game at the SAP stadium tonight). Hence we helped them punch out something like "Tonight lets go for Pens" on their Big Print. Yay~

We used the keypunches farthest from the closest. After the demo, we got a chance to take a look at the other two keypunches. Paul had a sharp eye to flip one of the keys from off to on so the 2nd keypunches could serve the guests. I found a card jammed in the one nearest the closet and Michelle found a tweezer to take it out. So all three keypunches worked fine with the middle one having light ink for the afternoon session. The sorter worked perfectly and Paul kept getting rounds of applause after each operator's demo. Woo-hoo~

Before the demo, while I started to test the simple program Powers of Two (As from the Wednesday Tim's email it seems neither of the card readers worked) on DE, none of the decks worked until Paul flipped the Punch button off on DE the card reader. The DE card reader worked perfectly during the demo and it kept working for our visitors who wanna punch a card after the demo. As a 3rd DE tape drive was inoperable, we used the first two tape drives on DE and they worked fine.

As an endnote, in the morning Paul and I marked two Powers of Two decks missing the last card, yet by playing around in the demo lab all day from the morning session till the afternoon session, I had a guess that it wasn't the fault of Powers of Two decks didn't have a last card as Big Print does, it was just because the Punch button was flipped on. I wish I didn't shut down the lab room so quickly so that I could test it out myself:-)

IBM 1401 Demonstration Saturday 11/4/23
- from Stephen Madsen
Michelle Yu, Karen Sun, and I gave a demonstration to 35 visitors. International visitors were from New Zealand, Germany, England, Canada, India, and China.

The keypunches and sorter worked OK.
The microphones worked OK.
CT was not usable, so we used DE.
The morning team used DE and left BigPrint running, so we left it that way. DE worked OK for us.

Stephen H. Madsen

IBM 1401 demonstration Wed Nov 1. 3pm
- from Tim Robinson
Samuel Plainfield and I gave the Wednesday demo to 24 visitors. We had international visitors from Nepal, Australia, Italy, Taiwan and Minnesota :-)

All three keypunches worked fine as did the 083 sorter. However neither 1401 was operational. The reader is still down on CT and when we powered up DE there was a Punch Check which we were unable to clear. Even with the punch turned off the reader still refuses to read anything because of this so we could not load the demo programs. The restoration team worked on the problem right up to the demo start time, replacing one blown fuse but were unable to clear the problem. So we had to be content with showing the visitors the outputs (bigprint, powers of two) we would have obtained had the system been working, and getting them all to punch souvenir cards. We used the tape drives on CT. All four started out working, but part way through the demo #3 just stopped, no longer responding to commands from the TAU and refusing to rewind/unload. The other three worked fine.

Despite the problems the visitors seemed to go away quite happy.


Restoration Reports for 11/1/2023 ++
- the ++ is due to the many reports and comments
Restoration Report 11-1-2023.docx
- from John Howard
Converted from .docx to .pdf (4 megabytes)

Previously David recovered a good motor from Yosemite for replacement in DE drive 3

Frank John and Arda installed the motor and accessories

Received later in response to a question

Thanks for the question, I should have included that also previously Ken diagnosed the drive failing to a short in the motor.

Restoration Report for 11/1/2023
- from David Clementson

CT 1402 Card Reader mangling: I was able to use the two-resistor method to scope the Card Lever 2 switch closure time relative to the clutch solenoid firing event. I was able to prove that when a card gets mangled, it is indeed late, typically by about 20 ms which corresponds to about 7 rows or 1.75". The photo below shows a non-crunch card read. The Card Lever 2 closure event can be seen at the right hand cursor, when the two terminals of the switch (cyan and magenta traces) become congruent. The Clutch signal is in blue at the bottom of the screen and the solar cell pulses at the top of the screen. The elapsed time for this card transit is the distance between the cursors, or about 51 ms.

It is worthwhile to note that according to the documentation, the theoretical time for this switch make event is more like 43 ms (208 machine degrees); the switch should close just before the start of the last solar cell pulse (see the bottom trace of the timing diagram below.) So the card is late, even on a "good" read.

When the card gets mangled, the picture is quite different. This photo shows the switch closure at about 75 ms:

Here, the cyan and magenta traces are different up until the switch closes at about 83 ms. This card was very late and got very mangled.

The method Sam developed to crash a card is to insert it manually under the throat plate and just into the #1 Clutched Roller, then start a Non-Process Runout (NPR.) Now this is a bit of an unfair test, however it is not unreasonable that a card might end up at this location, and one would think that an NPR should never crumple a card under any circumstances. If no card is present, the NPR just keeps the clutch triggered and all of the machine's rollers spin as long as the NPR switch is held. We proved that by holding down the NPR switch to continuously run the rollers for cleaning. So the question I have is why does the clutch un-trip and stop the 2nd Clutch roller when the card is present? I don't know enough about the NPR process to answer that question, but it makes me suspicious that there may be something else going on to explain the card mangling. It might have something to do with the jam error sensing, or the clutch check timeout, or the Proc Feed circuitry. Anyone?

On another front, after making a puller to remove a spare roller from its shaft for measurement, I machined four aluminum hubs and sent them to Terry's Rubber Rollers to get them coated. We should have them back in a couple of weeks. There is no guarantee that these rollers will work, but at $210 for four rollers, it seemed worth a try.

Sam and I also looked at the pinch rollers a bit more closely. All of them show wear and flat spots, and the #1 Clutch pinch roller bearing holder pivot showed a bit more movement than the other when the machine was running. Is it possible that the #1 Clutched Pinch Roller isn't doing its job? So it may be worthwhile to true up the pinch rollers when we replace the drive rollers. It is not clear that there is enough material on the existing rollers to allow that, so we may need to replace them with new ones made from some appropriate material. Maybe an acetal plastic like Delrin or Turcite? And I will need to make another puller for that.

That's it for this week.

Re: Restoration Report for 11/1/2023
- from Samuel Plainfield

Indeed, it is rather common that a card can end up in such a position during normal operation.

Also, I forgot to mention: one morning when I was demonstrating the repeatable crashing to Frank, when the non-process button was first pressed, the second clutched roller would perform one quick cycle and then stop immediately and not continue to roll (even with the npro button continuously held down). This odd behavior would obviously cause a crash -- and indeed did -- but once we were able to summon everyone else over to take a look, it somehow fixed itself.

The fact that it happened, though, indicates that there is some electrical component that can enable the clutched rollers to stop when they otherwise shouldn't. It would be grand if we could figure out the exact series of signals that take place when the npro button is pressed. Frank suspected that the relay that is responsible for engaging the clutch magnet was malfunctioning.

Towards the end of the day, I reset the DE1402 and the punch check went away immediately... so, DE may be available for demos this Saturday. For most of the day, the punch check went away. It remains a mystery what exactly is causing that to sporadically appear and disappear.

~Samuel Plainfield

Re: Restoration Report for 11/1/2023
- from Bhushan Mohan
Hi Samuel,
Your observation of the 2nd Clutch feed roll is excellent. See my comments below.

Bhushan Mohan
Bhushan's comments are in blue

On Thu. Nov 2, 2023 at 4:40PM Samuel wrote:
Indeed, it is rather common that a card can end up in such a position during normal operation.

Also, I forgot to mention: one morning when I was demonstrating the repeatable crashing to Frank, when the non-process button was first pressed, the second clutched roller would perform one quick cycle and then stop immediately and not continue to roll (even with the npro button continuously held down). This odd behavior would obviously cause a crash -- and indeed did -- but once we were able to summon everyone else over to take a look, it somehow fixed itself.

With NPRO the clutch is permanently engaged and BOTH clutched feed rollers are positively rotated thru the Clutch timing Belt. Both 1st and 2nd have toothed pulleys on the rear end which are driven by this Belt. Is the pulley slipping?? Suggest removing the clutch belt and check for both the rollers and Pulleys. Also check for any binds as suggested to David earlier today. Is The clutch disengaging itself by any chance? Hopefully both the springs are there on the clutch- earlier once David opened the Clutch he observed one of the springs had fallen off! Could be easily checked.

The fact that it happened, though, indicates that there is some electrical component that can enable the clutched rollers to stop when they otherwise shouldn't.

Clutched rollers are positively driven by the clutch belt

It would be grand if we could figure out the exact series of signals that take place when the npro button is pressed. Frank suspected that the relay that is responsible for engaging the clutch magnet was malfunctioning. ( If clutch magnet does not operate both the rollers shall not move. To me it appears to be a mechanical problem. The noise of the machine would immediately indicate that clutch has not been energised)

Towards the end of the day, I reset the DE1402 and the punch check went away immediately... so, DE may be available for demos this Saturday. For most of the day, the punch check went away. It remains a mystery what exactly is causing that to sporadically appear and disappear.
(This intermittent bug seems to be coming and disappearing)

~Samuel Plainfield

Answering a few questions: Asked by Bhushan Mohan
- from David Clementson

  • Are the pulleys on the clutched rollers slipping? I had the same thought and when I went to check, I was reminded that the pulleys are keyed. And yes, I checked that the keys are still in place. And the belt was replaced with new-old-stock. And the pulleys all checked out okay when we had them out when the rollers were swapped. And the ball bearings for both the #1 driven and pinch rollers are brand new. And I checked the card path for impediments or reaction points and I found none.

  • Is the clutch disengaging itself? Possible, but there is Clutch Check relay logic to check for that which, I believe (and assuming the circuit is not faulty,) would generate a Reader Stop error. Do we see a Reader Stop when the card gets crunched?

  • Is the relay responsible for driving the clutch magnet faulty? There is no such relay. The clutch magnet is driven (through an RC network, actually) directly by the wire "-T READ CLUTCH" from the 1401. In the 1401, there is an SMS card that implements a common-emitter driver amplifier that provides the necessary clutch coil current. We have observed the waveform and it appears okay. I have also measured the capacitor for both capacitance and ESR and it checks okay.

  • Is there electrical circuitry that can stop the clutched rollers when they shouldn't? It doesn't quite work that way. Only a clutch cycle completion or a clutch mechanical malfunction can stop the rollers once the clutch solenoid is tripped. However there is circuitry that can prevent subsequent clutch solenoid firings once the first clutch cycle happens, which is similar to the rollers stopping when they shouldn't. It's not that the roller is stopping, it's just not continuing.

  • How does Non-Process Runout (NPRO) differ from a normal read cycle? In normal operation, there is a flow control technique that prevents the card reader from overflowing the 1401 with data. As I understand it, when the 1401 is ready to accept a new card read, and when the 1402's -T PROC READ signal gets asserted via cam switch action, the 1401 asserts the -T READ CLUTCH signal. Electrically, -T READ CLUTCH is the collector of a PNP transistor with a grounded emitter, and it provides a ground return for the clutch solenoid. At the appropriate point in the machine cycle, a cam switch applies -20 volts to the clutch coil allowing current to flow via the transistor. In a NPRO cycle, the -T READ CLUTCH signal is once again issued by the 1401, but this time the logic that generates it is actually generated by the 1402. The 1402 sends the signal -T NON PROC FEED signal to the 1401 where it is OR'ed with the logic that generates the -T READ CLUTCH signal. So it would be instructive to observe the -T NON PROC FEED signal to see if it is responsible for the premature termination of the NPRO process.

Restoration Report for 11/1/2023
- from Ken Shirriff
Summary: looked at John's problem with the Branch on Error instruction on CT. Looked at the punch check on DE. Didn't solve anything.

Branch instruction details:
The branch on tape error instruction hangs. There are two CPU locks for tape operations. Processing is stopped entirely during a tape operation. At the end of the operation, processing continues, except the branch on tape instruction is locked for an additional 2.8 ms until the read check completes. So something is going wrong with the second step. I'm digging through the ALDs to try to figure out the signals get from the TAU to the instruction interlock, but haven't figured it out yet. I ended up in the RAMAC ALDs at one point before realizing I was on the wrong path.

Punch check details:
Shortly before the demo, the DE punch started giving punch check errors, which stopped the reader from working as well. This has happened intermittently in the past, but has gone away after pushing a reset button in the punch or reseating the punch unit. But this time it didn't go away. I did some investigation, comparing signals in the DE and CT machines. After the demo, the problem randomly went away.

This problem is strange. A punch check error indicates that the 1401 compared the card read-back to the punched value and found an error. (Note that a punch stop error is completely different, indicating a mechanical problem in the punch.) A punch check should only happen after a punch instruction. It is generated by data, not mechanical issues. We're seeing it with the punch turned off. It doesn't make sense to get a punch check when you're not executing a punch instruction.

From the signals that I traced, my hypothesis is that something is going wrong with the Punch Scan trigger in the 1401 (, ILD 62). This should get reset by the Start Reset button, but it appears to get stuck (maybe) in the 1401. This trigger seems very sensitive; putting oscilloscope probes on it can cause errors to light up on the 1401 console. After probing it a couple of times, the problem resolved itself. (The trigger got reset?) So I will look at this circuit more next time.

The circuit below is where I started looking, The Punch Check trigger drives the punch check light, the punch light on the 1401, and goes to other parts of the 1401. This trigger is getting activated incorrectly. Note that it is cleared by the punch check reset button, which matches what we saw, the punch check light goes out while the check reset button is pressed. The input to this trigger comes from a bunch of signals and they all seem to be different between the DE and CT machines, making it harder to figure out what is going wrong.

My hypothesis is the Punch Scan CB trigger is the problem, not getting reset by Start Reset and causing problems downstream. From the oscilloscope, it looks like this trigger is stuck on, but I don't have a smoking gun yet. If we need to get DE working for a demo, replacing this card (01B4 A22) would be worth trying.


Re: Restoration Report for 11/1/2023
- from Bhushhan Mohan
My take on the CT TAU problem on Branch on Tape error

  1. The "additional 2.8 ms until the read check" is dependent on the Type and Model of the Tape Unit. It's higher for 7330 and lesser for 729 higher models. Have to check the logic which gives this delay in TAU.

  2. Since the logic of checking Tape transmission error is same for both Read and Write operations, it would be useful to check for this bug on a Tape Read instruction followed by a Branch on Tape Error.

DE 1402 Punch Check.
I fully agree with your analysis and would be useful to try replacing the 01B2A242 SMS Card. Since the problem is erratic we could quickly Check the J (Ground) pin on the back panel. Also check the Voltage bus pins (Ithink its L,M,N,P) for any loose back panel bus. To eliminate, we could also deactivate the Punch Check Latch till the Punch Unit is rectified for the DE system. Use of cello-tape to float input or output is a normal method used.

Bhushan Mohan

- from Ken Shirriff
Sorry Ed, but one more message :-)

I've traced out the logic that delays the branch:
B9.30.56.1: the TAU generates FWD STOP DLY after a write. FWD STOP DLY or BUSY generates BRANCH INTLK A branch with "L" (I.e. the branch on error) and BRANCH INTLK turns off DELTA PROC. I think this is what stops the CPU.

The implementation of the branch itself: ERROR TEST and BRANCH INTLK generates TAPE PROGRAM SKIP TAPE PROGRAM SKIP generates PROGRAM SKIP

Checking the circuitry on should reveal where the branch is getting hung up.


- from Bhushan Mohan

Hi Ken, Tried going thru but in absence of relevant ILD could not make out much. Also found there is an EC installed as per screenshot attached.
Trying to Download the ILD portion also to look into the detailed logic. However I would again repeat to test the system on Tape Read instruction followed by Branch on Tape Error. Do share your observations.

Bhushan Mohan

Please look into TAU ILD pages 186 (ALD B9.20.10.1) It gives logic for the delay counter with selection of Type and Model of the Tape Drive.
Delay Counter on ILD 187, Forward Stop Delay on ILD188 and finally GO controls on ILD 189.
Since the tape stops after Write command means GO command is dropped (ILD 189).
Need to correlate the logic as given in the Instruction/reference manual.
You may find these useful for diagnosing the bug.
Bhushan Mohan

from Jack Ghiselli
Hi Ken,
I will extend the little Tape Hang test program to add tape Read in addition to Write, as Bhushan suggested. I'll try to punch an object deck but if we can't get the 1402 Reader and Punch working, we'll just key it in from the 1401 front panel.

Jack Ghiselli - mobile 1-408-839-1051

CHM 1401 Demos Sat 10/28/2023 11:00 AM and 1:00 PM
- from Jack Ghiselli
On Saturday 10/28/2023, Peter Chang and I gave the 1401 demo at 11:00 AM to 28 people. At 1:00 PM, Karen Sun and I gave the demo to 50 people. Mariane Kim assisted as 2nd Operator for both demos and was a big help. We also gave mini-demos to 10 people who wandered in before or after the main demos. We had international visitors from Austria, China, Czech Republic, Greece, India, Italy, Japan, Nepal, and Taiwan. We had a couple of visitors from China whose English was not too good, so Mariane gave them some explanations in Mandarin.

Since the CT1402 is still INOP, we gave the demo on DE, which ran very well. DE729 Tape #3 is still INOP, and none of the DE Tape Drives run under software control, but they work OK with the TAU, so no problems for the demo. DE1402 Punch is still INOP, but also no problem for the demo. The 083 Sorter and all three 026 Keypunches worked OK, although KP #2 still has light printing.

Before 11:00 we successfully tested BigPrint and Powers-of-Two. But, during the 11:00 demo, we couldn't get any program decks to load their first card. Sharp eyed Peter Chang noticed that somebody (probably me) had inadvertently set the DE1401 front panel Run Mode to STORAGE PRINTOUT instead of RUN, and after we fixed that everything worked fine. It's a good reminder that card load failures can be operator failures, not always hardware problems. Prospective new demo volunteer Mitch Butler attended the 11:00 demo, and we talked to him -- he's been working with Kate.

Peter Chang is writing his first 1401 program, a one-card "Hello World", punching the program directly from a keypunch, and doing pretty good. Before the demos we worked on that. We loaded his program and noted from the DE1401 front panel how it ALMOST worked. Peter knows what's wrong, and I expect he'll get it to work soon. Peter has also been trying to run ROPE at home on his Macintosh and getting error messages "Wrong CPU". Is anyone else successfully running ROPE on a Mac? I use a PC.

Jack Ghiselli - mobile 1-408-839-1051

diagnostic testing restoration report 10-25-2023
and CT 1402 card reader mangling:
diagnostic testing restoration report 10-25-2023
- from John Howard
We have been searching for information on the IBM developed 1401 diagnostic function tests. We located a scanned copy of “IBM DIAGNOSTIC FUNCTION TEST DESCRIPTIONS and hard copy pages in the file cabinet. There are 77 very well documented tests contained in this 3” binder.

A book with a ring binder Description automatically generated

In addition to the test documentation there are instructions for running the tests from tape, and we have located 3 reels of diagnostic tapes.

A close-up of a few tape rolls Description automatically generated

The tape drives on CT are down and we got a Check light when trying tape 1 on DE. Locating these tests and discovering the very extensive documentation for each test provides a strong base for the goals of this project.

CT 1402 card reader mangling:
- from David Clementson

CT 1402 card reader mangling:

The current theory about the CT reader's card mangling problem is that the 1st clutched rollers are old and slipping, causing the card's late arrival at the 2nd clutched roller. In normal operation, the 2nd clutched roller grabs the card from the prior unclutched roller, and carries it to a spot just ahead of the 2nd read brushes where it stops and waits for the next cycle. With a late arrival, the 2nd clutched roller has already stopped by the time the non-clutched roller delivers the card. The result is that the non-clutch roller drives the card into the stopped roller and crumples the card.

Since this is only a theory, I felt that we needed definitive proof that this either is, or is not actually what is happening. It would be pointless to pursue a slipping roller remedy if the rollers aren't actually slipping.

So new volunteer Shmuel and I worked on a means by which we could measure the elapsed time from when the clutch activates to when the card arrives at the 2nd card lever switch. If the rollers slip, this elapsed time should be greater than when the rollers do not slip. Unfortunately, the switch by itself does not give a valid electrical signal from which its closure event can be determined. The switch is energized by cam signals that are high-impedance through the critical arrival window, leaving no electrical drive to enable the switch closure to be observed. I tried using a pull-down resistor to generate a valid signal, but I was not thinking clearly enough at the time to realize that it would take TWO pull-down resistors, one one each side of the switch, to generate a usable signal. So by the end of the session, we were not yet able to make the measurement I wanted.

After the session (and before the dual resistor epiphany), I thought about how we might be able to put an independent card position sensor at that location. I came up with a scheme that uses the 2nd card lever mechanism to wave a flag through an optical interrupter. It is a bit of a hack, but it does work. I went in late Friday and installed it into the machine. The photos below show the photo interrupter plus the thin aluminum flag. The interruptor PCB is double-stick taped to the frame, and the flag is taped to the card lever switch leaf. The photos show the machine with a card manually cranked to just before the card reaches the switch and to just after. The red LED can be seen glowing in the card-absent state.



PDF of Drive Roller - note the three different views available

I left the setup in the machine and will give it a try with the machine running at speed next Wednesday. I will also try the double pull-down resistor method which, in hindsight, will probably give a better measurement since it's more immune to vibration.

Also this week I created a mechanical drawing of the roller (attached) and sent it to a vendor for quotation. I got an immediate reply and worked out some details. I will need to machine some bare hubs then send them to the vendor for rubber coating. The vendor quoted $50 per roller plus $10 for shipping. I asked the vendor to quote for sixteen rollers (eight for our two machines plus a spare for each) but I think I will start with an order of four rollers for us to test. I am a bit skeptical that the critical outside diameter will be maintained, but we shall see.

Also up for next week, I want to check the torque of the clamping collar screws on the #1 drive roller pulley. A slipping pulley would have the same effect as a slipping roller, so it is worth a check.

That's it for this week.


1401 demo on October 25
- from Scott Stauter
also visit from Bob Haas of the vintage TEK museum
1401 demo on October 25
- from Scott Stauter
Jim Maurer and I gave the 1401 demo today to 34 visitors and then had another 8 guests afterward. The out-of-country visitors were from Singapore, South Korea, Northern Ireland, the United Kingdom, Canada, Belgium, and Italy. The keypunches and the sorter worked. We used the DE 1401 system and had one reader check, but the 1403 worked perfectly. Tapes 1 and 2 worked ok. The audio system worked well, but microphone #2 would not turn off with the switch, so we removed the batteries.
Scott Stauter

Visit from Bob Haas, board chairman of the vintage TEK museum in Beaverton ( ),

Bob Haas, board chairman of the vintageTEK museum in Beaverton (, paid us a delightful visit last Wednesday, Oct 25th. He shared his interesting vintage IBM 305 RAMAC and 1401 programming stories...

On their web site, vintageTek has illustrated “at least 12 Tektronix" scopes in the iconic Endicott 1401 manufacturing line photo: <

Here a photo of the 305 console that he programmed "that IBM kept in their basement in Omaha for the convenience of SAC, which they needed it for (obviously non-secure) application.”

Unbeknownst/undocumented until now, IBM had apparently augmented the 305’s (bare-bones) instruction set with a branch instruction, per this hand written note. (Originally, control was transferred to the 305’s plugboard where conditional tests were wired up, with plug wires returning control to the next instruction on the drum. This one foot in the plugboard past doomed successors to the 305, which the 1400s superseded, according to Bo Evans directive to reduce the number of different computer architectures in IBM.)


— Robert

p.s. Bob picked up my two Tektronix 575 transistor curve tracer scopes for vintageTek’s collection.

Saturday October 21 11:am 1401 Live Demo
11:am - from Karen Sun
Michelle Yu and I gave the live demo to 31 visitors with international ones from Korea, Germany, India, China, Japan and other parts of the US. One of the visitors from Germany had offered both of us a small pinnable microphone as her hearing aid so our presentation was converted into text on her small screen simultaneously. So happy to be more inclusive to our visitors.

As Sam told me he would take a check on CT 1402, we used the DE 1402 for testing for the Big Print Program and it worked fine. Unfortunately during the demo it didn't load any of the cards. We gave it another try and this time it started to load the first card and stopped. The backup deck was given a third try yet the first few cards jammed in the machine this time. We skipped printing out the Big Print and continued the demo. Before the demo, we turned on the 3 keypunches for testing and all worked well. DE 729 tapes 1 and 2 worked well while #3 has its in-op sign flipped on, we didn't use it. The DE 1403 worked beautifully later when Sam helped us flushed out the jammed card and the deck started to load properly. A big shout-out to Samuel as our safety net and I would definitely need to learn it from you.

After the demo, Michelle and I were able to print out several Big Prints for the 11am visitors before 11:45am's private demo with Ronald Mak's SJSU students got started on time.

Michelle and I stayed till the end of 11:45am's demo to see if we could be Samuel Plainflied and Ronald Mak's assistants. It turned out they rocked the private demo. The successful private demo enabled Michelle and I to have a close look at the side glass of DE 1401 Main Processing Unit for its stacked SMS cards and other mind-blowing elements. Michelle Yu and I gave the live demo to 31 visitors with international ones from Korea, Germany, India, China, Japan and other parts of the US. One of the visitors from Germany had offered both of us a small pinnable microphone as her hearing aid so our presentation was converted into text on her small screen simultaneously. So happy to be more inclusive to our visitors.

As Sam told me he would take a check on CT 1402, we used the DE 1402 for testing for the Big Print Program and it worked fine. Unfortunately during the demo it didn't load any of the cards. We gave it another try and this time it started to load the first card and stopped. The backup deck was given a third try yet the first few cards jammed in the machine this time. We skipped printing out the Big Print and continued the demo. Before the demo, we turned on the 3 keypunches for testing and all worked well. DE 729 tapes 1 and 2 worked well while #3 has its in-op sign flipped on, we didn't use it. The DE 1403 worked beautifully later when Sam helped us flushed out the jammed card and the deck started to load properly. A big shout-out to Samuel as our safety net and I would definitely need to learn it from you.

After the demo, Michelle and I were able to print out several Big Prints for the 11am visitors before 11:45am's private demo with Ronald Mak's SJSU students got started on time.

Michelle and I stayed till the end of 11:45am's demo to see if we could be Samuel Plainflied and Ronald Mak's assistants. It turned out they rocked the private demo. The successful private demo enabled Michelle and I to have a close look at the side glass of DE 1401 Main Processing Unit for its stacked SMS cards and other mind-blowing elements.

My SJSU students' visit - from Ronald Mak/SJSU

Sam and I were a great tag team in the 1401 demo lab! My San Jose State University students were all very impressed by what they experienced. Ten students came. Another computer science professor tagged along. It was his first visit to the museum, and now he wants to bring his students, too.

Thanks, Sam! And Karen and Michelle, too.

— Ron

P.S. For historical interest, I show my students a tape sort, an old data processing problem. You have a mag tape containing unsorted records. You want to create a new tape of sorted records. Your computer’s memory can hold only a small number of records for internal sorting and merging. You have four tape drives, the unsorted tape, and three blank tapes. The tape drives can only read and write in the forward direction, but you can rewind the tapes. (The following assumes the computer memory can hold only 3 records, and it overwrites the unsorted tape.)

There are algorithms for when you have fewer tape drives. (The CHM’s 1401 systems each has only 3 drives.)

From Ed Thelen - "only 3 drives", not a big deal. Assure that there is no write enable ring in the unsorted source tape. When the unsorted source tape rewinds, stop the computer, replace the unsorted source tape with the merge tape (with write ring) and proceed. Been There, Done That :--))

IBM 1401 Demonstration Saturday 1:00 pm
from Stephen Madsen

Michelle Yu and I demonstrated the 1401 to 40 people. The previous demonstration to Ron Mak's SJSU classes ran close to our starting time, so we did not have time to talk to the visitors and find out where they were from.

Keypunches: We only used the one farthest from the closet, and it worked fine.
83 Sorter: Worked fine.
Microphones: Worked fine.
CT was not used.
DE was used for the previous two demonstrations, so we used it too.
We had some reader checks but were able to work our way around the problem.
The other equipment worked fine.
When putting things away, we were not able to find the cover for the box in the shopping cart.

Stephen H. Madsen

Re: CT 1402 card jamming (was Re: Restoration Report for 10/18/2023;
from Robert Garner - 10/18/2023. 4:20 PM
David, Ken,

> [David] The current theory is that the #1 clutched drive roller is slipping and causing the cards to arrive too late to be grabbed by the #2 clutched roller. Instead, the unclutched roller is jamming them into the #2 roller after is has stopped, causing general mayhem. The roller probably needs tpo be replaced.

Sounds sensible, but I’m perplexed about why this problem so suddenly befell the CT 1402? It had been working reasonably well since August 12th (i.e., for eight weeks), and then suddenly the first clutched roller is massively slipping? That seems odd. (Although oddness is not something we’re unfamiliar with. :)

> [Ken] My conclusion is that the first clutched roller is feeding the card too late because the roller is slipping (which is the problem we saw before with the reader checks). The consequence is that the card gets to the second clutched roller a bit too late so the second clutched roller doesn't pull the card beyond the unclutched roller. I believe the second clutched roller and the unclutched roller are working properly.

Re: “a bit too late,” any thoughts on the duration of the lateness, about half the height of a card?

Does it makes sense to validate this hypothesis, perhaps using Marc’s high-speed camera?


— Robert

From Ken Shirriff - 10/18/2023. 4:33 PM

My hypothesis is this is the same problem we had before with the slipping roller, and the fix was temporary. The roller has lost its grip again and the problem shows up.

I estimate it is slipping about 3 rows. The slippage should show up if the scope is put on the first set of brushes, which will reveal if the card reaches the brushes too late.

A few weeks ago, David suggested the possibility of putting instrumentation between the card reader and the 1401 permanently, which could log what is going on and help debug problems. (Essentially a 160-channel logic analyzer to monitor what is happening with the brushes.) This is a case where that would be helpful. Implementing this would require two "sacrificial" cables so we could insert the monitoring in the brush lines. I can't come up with a practical alternative for getting at the signals.


from Robert Garner - 10/18/2023. 5:47 PM

> My hypothesis is this is the same problem we had before with the slipping roller, and the fix was temporary. The roller has lost its grip again and the problem shows up.

I though David had replaced the roller back in August?


Am I confusing your replacement of the “contact roller” with the #1 clutched roller (that you got from the donor 088 in the warehouse)?

From your August 11th status: "John and Sam and I met at the Yosemite warehouse and were able to pull two pairs of picker knives and one contact roller from a donor machine.”

> Implementing this would require two "sacrificial" cables so we could insert the monitoring in the brush lines. I can't come up with a practical alternative for getting at the signals.

Excellent! :)

— Robert

Restoration Report for 10/18/2023 - from David Clementson
New Volunteers:
We spent the first part of the day orienting our four (!) new volunteers. Welcome guys. BTW, can someone please add their email addresses to this mail list?

DE 1402 Punch:
After lunch, I was able to modify a spring to replace the incorrect one installed on the front side card pressure finger at the punch alignment station. I matched the wire gauge, outside diameter, and turn cound of the proper one installed on the rear-side finger. Cranking cards manually showed that the alignment was fine, however when we installed the punch unit and tried it under power, the alignment was still off. So something is still not right. Maybe the punch itself is misaligned? There are adjustments for this, but we haven't touched them since beginning work on the machine. It is also possible that we are having a roller slip issue, or possibly a pinch roller bearing problem.

CT 1402 Reader Checks & card mutilation:
I spoke with some of the other team members and I think there is consensus that we should drop the DE Punch project for now and focus on the CT Reader. Its misbehavior is starting to affect the demos.

The current theory is that the #1 clutched drive roller is slipping and causing the cards to arrive too late to be grabbed by the #2 clutched roller. Instead, the unclutched roller is jamming them into the #2 roller after is has stopped, causing general mayhem. The roller probably needs tpo be replaced.

I looked at the McMaster-Carr catalog and could not find a suitable roller candidate. However Misumi has one by the name of RMC35-15-15. It is a 35mm OD x 15 mm long x 15mm ID plain roller. It has an aluminum hub and the tire material is Shore-A 90 trethane. We would need to bore the ID to an appropriate size to press fit on the 1402's shaft, then grind the OD to the correct 1.210" outside diameter. Maybe Grant can help with that, unless I decide to finally build a tool post grinder for my lathe. The rollers are $26.47 each, and we need two per shaft. I think I will order a pair of them to give them a try, seeing as how we have almost no other ideas.

That's it for this week.

10/18/2023 3pm Demo ~ from Samuel Plainfield
Duane Sand and I gave a demo to a small group of about 25 people. Lots of international folks from France, Germany, India ~ about 50+ more people came after the demo all the way until 5:15 in which a lively group of ~15 folks from Uruguay, Chile, Spain and Colombia arrived and I was able to give them a nearly full demo in Spanish; quite a treat.

The microphones worked very well. CT is still jamming cards in the transport, so we used DE which worked spectacularly.

The Liebert A/C unit at one point was beeping and the error message indicated "High Pressure" with the option to press ENTER to stop the alarm. I did so, and the beeping stopped. Later in the day I told Robert about it and we checked the screen and the error had disappeared. The system worked fine all day long despite the message.

The sorter appears to be working well, yet still needs more calibration/testing at some point but for demo purposes is doing just fine.

Tape units on DE 2 out of 3 worked very well. CT tape units were not tested or used.

An older gentleman appeared late in the day and announced that he ought to be a fixture himself here in the museum because he used to give an operator his mathematical calculations to be processed on a 1401. He said that he never operated it himself, but would give his calculations to the operator for processing all the time.

Another fellow, an aspiring software engineer, was riveted by the BigPrint software and was keenly interested to see how the object code worked. I explained it in some detail -- and provided him with a Storage Printout so that he could see what it looked like residing in core memory. Since his souvenir printout was the last done, it contained his name visible in the core memory dump. He said it made for a fantastic souvenir.

I'd say that is all for now. I am anxious to see about getting the CT1402 back up and running again.

~Samuel Plainfield

Re: 10/14/2023 Status Note
from David Clementson
HI Ken:

I concur with your theory about what is happening. see this link The role of the 2nd clutched roller (the third roller in the series of four, just after the #2 card lever) is to take control of the leading edge of the card just as it clears the prior (unclutched) roller. Once it captures the card, it stops there and holds the card still, waiting for the 1401 to trip the clutch again. When this happens, this roller starts and sends the card through the second set of brushes. If the card slips at any of the rollers prior to this one, the card will pass through the unclutched roller too late, which will happily drive it into the clutched roller after it has already stopped. This bends the card as the video shows. Here is a diagram of the rollers. Note that CT is not a Mod 2 machine, hence its final roller is unclutched.

So it looks like we will need to revisit the slipping roller issue, and will probably need to cultivate a source for a modern equivalent for our decaying rubber rollers.

BTW, did anyone happen to notice any scuffing on the affected cards' surfaces that might roller slippage?


from David Bennet < kvxw89a @ prodigy . net >

Regarding the material that may have been used to create those rollers back in the day, I was involved with a similar problem with the conical pinion that drives the two magnetic powder clutches in RAMAC. We were advised that the original material was similar in durometer to that of the head of a mallet as in the kind used in a tire shop. If you decide to make new rollers I can give you some info on the subject, including the name of our consultant at the time.

Dave Bennet

IBM 1401 Demonstrations Saturday - 10/14/23
for Saturday, 10/14/23 - 10:30 am - Stephen Madson wrote
Peter Chang and I demonstrated to 23 visitors.
Keypunches: We used the one farthest from the closet, and it worked fine.
083 Sorter: Worked fine.
We used CT.
  • 1402 worked fine.
  • 1403 worked fine.
  • Tapes 1, 2, and 4 worked fine. #3 was marked Not working.
    Microphones: Worked fine.
    We did not use DE.

    Stephen H. Madsen
  • - from Larry Hara. the 2 PM Demo

    Paul Laughton and I delivered the IBM 1401 demo today, October 14, 2023, at the special Tech-Fest time of 2PM. There was recurring confusion at the front desk for the start time: The Tech-Fest / Creativity Festival agenda stated 2PM, while the monitor showed 1PM and could not be changed. Nevertheless, we had 45 visitors during and after the demo from San Diego, UK, Australia, Poland, Chile, Canada, Germany and France.

    All the keypunch machines worked and we used #3 for the demo. The ink from keypunch machine #2 was light but readable.

    Sorter 083 worked fine prior to the demo but jammed in the middle of running, so Paul described what the sorter would have done. After the demo, Sam Plainfield un-jammed it and got it to work properly. Thank you, Sam!

    The morning demo team used CT with no issues. However, just after they left, CT 1402 jammed and could not be recovered. We used DE for our 2PM demo and ran BigPrint with no issues, but had a few recoverable issues with reader checks post-demo.

    DE 729 worked well.


    Oct 11, 2023 - Re: Demo programs on Tape project
    - also video of CT1402 Card Jamming & Comments
    On Wed, Oct 11, 2023 at 4:35 PM - John Howard wrote
    Frank King and I started the day by testing the CT tape drives with the TAU, all four drives tested good. Jack Ghiselli made a tape test program based on the inner loop of Ron’s tape exerciser. This program consistently hangs when using tape drives on CT. We demonstrated this behavior to Ken Sherriff please refer to his report.


    - from Ken Shirriff

    I looked at John and Jack's CT tape program issue. The program writes 1000 characters. Then it branches if end of reel. Then it branches if tape write error. It looks like the 729 stays busy for some reason and the program executes the first branch but hangs on the second branch.

    There's a bit of tricky stuff going on, so I'll explain. During the tape write, the CPU is blocked (interlocked). The CPU continues when the write completes, testing the first branch. However, the tape operation isn't completely done at this point; it is still checking if the write is okay. The "branch if tape write error (L)" is special. It blocks until the tape has decided if it was successful or not. It appears that the tape never makes this decision, so the second branch hangs.

    (From the 1401 reference manual page 152)

    I studied the circuitry in the ILDs and scoped some signals. There is special circuitry to detect this branch and set an interlock trigger to stop processing if the tape is still busy. Some more investigation will be needed to see why the tape never fully completes the write. (This program works okay on DE.)

    Other tape drive news: CT#3 (I think) won't unload. DE#3 (I think) has a fidgeting right reel that was twitching back and forth slightly.


    - David Clementson wrote

    DE 1402 Punch:

    We continued to debug the card alignment issue which results in punched rows not being parallel to the card edge. We checked timings and clearances on the four rollers responsible for positioning the card beneath the punch, and checked the forward positioning knives and the side alignment positioner. Everything measured okay, yet the cards still were getting misaligned just after leaving the alignment station. There are two spring-loaded fingers that are supposed to hold the card in place as position control passes from the aligners to the first stepped roller. I noticed that the springs on the two fingers were different, with one obviously a replacement for the original. The replacement spring was incorrectly sized, resulting in that finger not providing any holding force. This could definitely cause a misaligned card. Next week we will install a more appropriate spring and see if that fixes the alignment problem.

    That's it for this week.


    - also video of CT1402 Card Jamming & Comments

    from Samuel Plainfield

    For the first time, the CT1402 card jamming issue was repeatable enough to where I was able to note some symptoms. As Larry mentioned, CT was jamming badly just prior to his demo starting. It messed up the first 3 cards of a BigPrint deck, so I repaired those and started some testing.

    Setting up a single card to perform a non-process runout would consistently jam. So, I removed the center card detector plate and performed another non-process runout with a fresh card and it instantly jammed again. It seems that there's likely an extremely slight delay in the second clutched rollers engaging to keep the card moving that is just barely not fast enough resulting in the card appearing to crush into it.

    I note that the pinch roller is of the `not original` rubber and it does feel a little sticky. Perhaps this slight extra grippiness is causing it to stick ever-so-slightly enough to result in the jam.

    Here is a video of the jam occurring with the plate removed:

    Since the plate is removed, the jam isn't as dramatic since the card has some space to move up when colliding.

    Perhaps sanding down the roller might help this. Alternatively, giving it a go with Marc's ultra high-speed camera to see if there's a delay when that roller engages might be a good idea.

    I moved a card through by manually tripping the clutch through and it didn't have any problems with that.

    Anyway, just some thoughts to consider before Wednesday.

    ~Samuel Plainfield

    from Ken Shirriff

    After examining the video, here's what I think is happening:
    1. Motor starts
    2. Clutch trips for one cycle. The first clutched roller (not visible) feeds the card through the first read station. The unclutched roller (visible) grabs the card and feeds it to the second roller.
    3. The card reaches the second roller (left of video), which is spinning but stops just as the card reaches it. Because this roller is stopped but the unclutched roller is still spinning, the card gets folded. This roller shouldn't stop until the card has cleared the unclutched roller. Since the first and second clutched rollers are driven together, there shouldn't be any timing difference between them.

    My conclusion is that the first clutched roller is feeding the card too late because the roller is slipping (which is the problem we saw before with the reader checks). The consequence is that the card gets to the second clutched roller a bit too late so the second clutched roller doesn't pull the card beyond the unclutched roller. I believe the second clutched roller and the unclutched roller are working properly.

    Here is the frame where everything goes wrong. The clutched rollers on the left were rotating in the previous frame, but they have stopped in this frame. The unclutched roller on the right is still spinning, so the card gets bent. At this point, the card should be maybe 3 rows farther to the left so it would be clear of the spinning unclutched roller, and ready to go through the second read brushes on the next cycle.


    1401 3 pm demo on October 11
    - from Scott Stauter
    Jim Maurer and I gave the 1401 tour today to 42 guests at 3 pm, and 2 people afterwards. The guests came from Japan, the UK, Brazil, Germany, Russia, and Canada. We used the Keypunches farthest from the closet, and nearest to the closet. The sorter worked fine, and the CT 1401, 1402, and 1403 performed correctly. The CT tapes worked except for number 3, which would not even unload. So we marked it "out of service".
    Scott Stauter

    IBM 1401 Special Demo - 10/10/2023, from Pat Buder
    On 10/10/23 Karen Sun, Larry Hara, and I ran the IBM 1401 lab machines for a crew filming an upcomning episode of a Nova Science show tentatively titled "Your Data and You." The host is television personality Dr. Alok Patel. We did not do a formal demo, but just staged shots of various machines running.

    We helped Dr. Patel punch a BigPrint name card. We had tested running on CT before the team arrived, but when reloading BigPrint during filming, we got read checks on two different decks. We moved to DE, which ran perfectly. Fortunately modern video equipment is relatively portable so this move wasn't a problem.

    Later we successfully ran TAU tape demos on the CT drives. They also filmed the 083 card sorter. We festooned Dr. Patel with the 1401 cable and the obligatory USB cable for a shot.

    After the filming was complete we ran BigPrints for several crew members.

    The video team earlier filmed in the PDP-1 room. We'll see how much footage survives editing into the final program. The filming was an interesting experience. Do we need sunglasses for the celebrity 1401's ?


    Saturday October 7 - 1401 Live Demos
    11:00 AM - from Karen Sun
    Peter Chang and I gave the demo to 32 visitors including several coming before/after the session.

    Before the demo we preloaded the cards in CT 1402. We ran the CT 1402 for Big Print and it loaded smoothly. We turned on the 3 keypunches for testing and all worked well. We mainly used the keypunch printing farthest from the closest door. CT 729 tapes 1,2, and 4 worked well, as #3 has its in-op light on, we didn't use it. The CT 1403 worked well.

    As we had already set up the room by 10:20am, we had some very nice visitors coming to the lab to check on the 1401 devices and chat with us. Among them a former IBMer Carlos Robinson really warmed our hearts by giving us a full box of printer paper. You can still see the price tag on the box, $34.85. He told us he had this box stored at home for decades yet never used. He drove from Santa Cruz for the Latino Leadership Summit today at the CHM and he was happy he remembered to put this heavy box in his trunk. Peter hosted him and introduced him to our volunteer hour-tracking board. He recognized some of the names, one being Ron Williams. Thank you Jesse for lending us the cart so that Peter moved the box of paper into the A/C room.

    Carlos Robinson
    and Peter Chang

    at volunteer
    hour-tracking board

    THE box of
    printer paper

    Another fun pair is an 88-year-old grandpa with his grandson. He was full of energy introducing those ancient 1401 machines to his grandson. He greeted us in Chinese and told us he traveled to China and visited Wuhan University. He left us his name card when being asked his name. I attached his name card here as a reference.
    The image of his name card is not posted on this web page.

    We had visitors from Switzerland, Peru, London, Croatian, China Taiwan, the Bay Area and other parts of California.

    1:00 PM - from Larry Hara

    Duane Sand and I gave the 1PM demo today, October 7, 2023, to 42 visitors and another 20 after. We had visitors from Canada and the UK, but most were from the Bay Area.

    Great day today!

    • All the key punch machines worked well. Keypunch machine #2 was light at first but Duane managed to address that by getting the ribbon to a more heavily inked section
    • Sorter 083 worked and gave a nice distribution of cards
    • We ran BigPrint. CT 1401, 1402, 1403 and 729 (#1, 2, & 4) worked superbly! CT 729 #3 was out of service.
    • No A/V problems.
    • Prior to the demo we had DE 1401 prepared as a backup in case we ran into problems but did not need to use this.

    Restoration Report for 10/4/23

    - from David Clementson
    CT 729 #3:

    Having purchased the Loctite Form-A-Thread repair kit, I started the repair task on the CT 729 #3 head down bracket mounting screws. I cleaned the holes with acetone and small swabs, then before applying the repair compound I thought I'd do a "dry fit" to check the threads using a pair of proper sized screws I brought from home. When I tried the screws, they fit fine with no evidence of thread damage in the casting. So the threads were not stripped after all, but the screws were just wrong. So I installed the correct screws using a bit of Loctite 271 (red) and tightened them snugly. The bracket should stay put for a while.

    DE 1402 punch:

    After last week's session, it was clear that the punch unit was still not assembled correctly. So Frank and I took the punch out again and put it on the bench. Card analysis showed that all but one of the fail-to-punch columns were on armature Bank C. We removed the Bank C magnet assembly and re-gapped it using the same paper shim technique used successfully on Bank D. We were able to reinstall the assembly and test each punch for proper punch operation using an external power supply to energize each magnet.

    We then traced the remaining fail-to-punch column to a broken wire on the harness, which we were able to resolder.

    We tried to reproduce the double-punch-on-column-80 problem but were unable to. Frank suggested that we refresh the grease in the punch area, so he found the grease gun and pumped some fresh lube in. We then reinstalled the punch unit back into the machine and retimed it. On testing, we found that all columns punched correctly and there were no double-punches.

    However, we noticed that the punched row was not parallel to the edge of the card. Further investigation showed that the card aligner knives beneath the punch were out of time and the cards were being skewed as they entered the punch. We must have inadvertently slipped a tooth on the belt that controls those knives. So next week we will retime the aligner knife shaft.

    That's it for this week.


    - from Tim Robinson

    After the demo Frank King showed us how to determine whether a reader check was happening on the first or second set of brushes. What we found for several successive checks was that there was no pattern. We got cases of both the first and second set on several different columns. We then tried a different deck and it read flawlessly. The bad deck is marked.


    - from Tom Szolygz

    Today I continued work on the interface between a PC and the 1401. The interface has a LCD display to show Arduino system status and info.
    Unfortunately, the LCD display made it difficult to access the Arduino I/O’s. I found and bought a different panel that allows better access. I built it into the system and rewrote the Arduino code for the new panel.


    - from Ken Shirriff

    Not much for me to report. The CT#1 tape drive still has weird behavior where on the very first tape load it will immediately unload. I suspected a bad selenium diode, but I tested the diode under load and it was fine. I also replaced a broken neon status bulb. Frank found a box of neons in the lab, but they fire at 120 V and the ones in the 729 need to fire at 75 V, so they didn't work. (I labeled the ones in the box for future reference.) David had a bag with 75 V neons that seem to work so I'll replace more bad bulbs next time.


    Wednesday October 4 1401 demo

    - from Scott Stauter
    Tim Robinson and I gave the tour to 39 people at the scheduled time and 20 after that tour. The CT 1402 had about 6 reader checks while we were reading in the Bigprint program, so we left the program in memory for the demo. The middle 026 keypunch printing is too light. CT 729 tapes 1, 2, and 4 worked nicely, but # 3 kept stopping so we made it not available. The CT 1403 worked well.
    We had visitors from Germany, France, the Netherlands, Switzerland, Poland, the Czech Republic, Slovakia, Canada, Venezuela, Thailand, and Australia.
    Scott Stauter.

    - from Samuel Plainfield

    I am told, per Ken, that the 1406 would've cost as much as an entire house in San Francisco if you wished to purchase it outright,

    A fun fact that I intend to mention in my demos unless any of you have information to counter Ken's research :)

    ~Samuel Plainfield

    - from John Howard

    This week Jack Ghiselli and I worked on the demo to tape project. We were unable to write a tape with demo programs intended to reside in high core. Issues with the server/PCWriter software and tape drives were encountered. We need to put some hooks into server software to allow better debug of the tape write process. In addition, further work on boot cards that do not clear all of memory is needed for each of the demo programs.

    Saturday September 30 tours

    from Karen Sun - 11:00 AM tour

    Peter Chang and I gave the tour to 43 people, and 10 after the official tour.

    The audio worked great. The three 026s worked, with the middle one having a bit of light printing. The sorter worked fine. We ran Big Print smoothly and the CT 1402 and CT 1403 worked well. We had powered on the DE 1401. Three of the CT 729s worked beautifully.

    Our international visitors were from Sweden, China, and Canada. After the tour when the last three visitors lingered in, the CT 1402 got card jammed pretty seriously and as the DE was on we switched quickly to the DE 1401 to finish printing the Big Print for our visitors.

    Before we checked out, we ran some quick troubleshooting yet it still doesn't function properly. We let the afternoon Lead know it.

    Multiple reports for the 1:00 PM Demo. ;--))

    Received 8:52 PM - from Jim Maurer

    Larry Hara and I gave a demo to around 26 people today at 2:00 PM so I could qualify as a Lead Operator. And there were around another 20 or so after the demo that came by.

    Audio was great. We used 026’s 1 and 2. The printing on number 2 was light. The sorter worked well. We used DE and everything worked well. Tape drive #1 was the only one in use on DE. The 1402 and 1403 had no problems.

    Visitors came from places like Buenos Aires, Argentina and Stanford University.

    Jim Maurer

    Received 11:54 PM - from Larry Hara
    Hey, that's me...the afternoon Lead ;--))

    To follow up what Karen had described and what we did after the 11 AM demo was completed: the jammed card was removed (thanks, Peter!). Then we did an NPRO, but there was no action whatsoever. After 15 minutes, we tried the NRPO again and it appeared to be working although there were no cards stuck in the machine. Feeling optimistic, we tried to load Bigprint but the 1402 again scrunched cards and got jammed. We carefully removed the damaged cards and no longer attempted further actions prior to the PM demo (report on the 1PM demo forthcoming).


    Received Sunday Oct 1 12:51 AM - from Larry Hara

    On September 30, 2023, Duane Sand and I gave the 1PM demo to 52 visitors including those who stopped by after the demo. We had visitors from the Bay Area, Ireland, China, and Germany.

    The ink from the ribbon on keypunch machine #2 was a bit light but readable. The direction of the ribbon was changed, but there may not have been sufficient cards printed before the more heavily inked part of the ribbon was reached. Keypunch #3 (furthest from the closet) was used for the demo.

    The 083 sorter worked well. Nice distribution and colors - shout out to Sam for creating this deck.

    Prior to the demo, the 11AM demo team experienced problems with CT jamming so we used DE. The 1401, 1402, 1403, and 729 worked beautifully!

    The audio worked perfectly - thank you!


    Restoration Report for 09/27/2023
    from David Clementson
    DE 1402 Punch:
    I started the day by using a DMM to check continuity of the punch magnet wires. The current fault is fail-to-punch behavior on certain columns, so a broken wire might be a possible explanation. However it was not the fault, as all of the magnets showed the proper resistance value when measured at the four 'miniature' internal connectors.

    So Frank and I removed the punch unit again and attempted to check punching by manually energizing the magnets on the bench with an external power supply. We were able to confirm that the columns that would not punch in the machine also failed to punch on the bench. We were able to determine that the reason the columns were failing was that the gaps between the magnet cores and the armatures on those columns was too large. The reason the gaps were too large is that the armature two pivot wires had gotten misaligned during a prior repair attempt. Once we realized this, we were able to reposition the pivot wires to set the core/armature gap to the specified 0.002"-0.004". We were able to confirm that the affected columns did indeed punch. During testing, I accidentally broke one of the leaf contacts on the male miniature connector. I was able to fabricate a brass "bridge" piece from an unused connector terminal and solder it across the broken leaf. The repair worked extremely well.

    We reinstalled and retimed the punch and found that there were still a few columns on one bank that refused to punch. So it looks like we missed something and will need to go back over the gap adjustment procedure on the affected bank next week.

    CT 729 #3:
    Ken drew my attention back to the two stripped threaded holes in the main casting that mount part of the head-down mechanism. After a few load cycles, the screws that go into these holes fall out and get wedged under the head lowering mechanism which prevents the completion of the tape load process. I removed one of the screws from the same location on CT #4 and measured it to confirm the thread spec is 6-32 x 1/2".

    I did a bit of research into thread repair techniques and found two viable options.

    1. Helicoil insert: this entails using a special drill and tap to create oversized threads in the casting, then using a special tool to install stainless steel coils that have a 6-32 internal thread profile. The cost of the drill, tap, installation tool, and 10 inserts is about $51.
    2. Loctite 3967 Form-a-Thread: this is a 2-part dimethacrylate ester paste is mixed and applied into the damaged bores. The screws are coated with a liquid release agent, then inserted into the paste. The paste is allowed to harden for 5 minutes, after which the screws are removed. The past is then allowed an additional 30 minutes to fully cure. The cost of the repair kit is about $35.

    The Helicoil has the advantage of probably being a stronger repair, but the disadvantage is that the hole drilling and tapping would need to be done very carefully in order to maintain the correct screw location and spacing. Since the repair is to the main casting, the drilling would have to be done in-situ, and we would need to first fabricate a drill guide to enforce proper drill locations.

    The Loctite repair has the advantage that we could use the mounted part itself to control the screw location and spacing. Another advantage is that the repair would probably be more readily reversible in case things didn't work out. The Loctite disadvantage is that it is probably weaker than the all-metal Helicoil repair.

    Another repair option would be to redrill for a larger screw, however we would also need to modify the mounted component as well. However there is very little room to accommodate a larger screw, so the repair could go badly. Also, the larger screw size (8-32) major diameter is larger than the Helicoil drill, so tapping for 8-32 would preclude the proper Helicoil installation.

    Based primarily on the reversibility argument, I would recommend the Loctite repair as Plan A and the Helicoil as Plan B.

    I would normally just go ahead and buy the Loctite, but since the museum has not yet paid the reimbursement request I submitted for the CT1402 roller repair, I think I will hold off this Loctite purchase until that prior bill has been paid.

    That's it for this week.

    from Ken Shirriff
    My restoration report:
    I mostly fixed CT#1 729. This drive has been a problem for weeks; when performing a load-rewind, it would load but then hang up before the rewind. Last week Bhushan determined that the reset switch was the problem. I replaced the reset switch with one that David obtained for me. The switch has normally-open contacts on one side and normally-closed contacts on the other. The two sides are wired together to make a toggle switch. The normally-closed side seemed to be stuck open. Confusingly, there is nothing to distinguish the two sides. I put the replacement switch in what I thought was the right way, but it didn't work, so I flipped it over and then it worked. The relay's normally-closed contact is part of the path for holding R104 during the rewind process, so without this signal the relay drops and the rewind doesn't happen.

    Second issue is CT #3 729. The symptom was that it wouldn't load correctly. The tape would go into the left column but not the right. Frank quickly diagnosed that the prolays weren't making contact with the roller to hold the tape, because the head wasn't going down all the way. The root cause was that a little cross of metal behind the head had come loose, blocking it. This problem had occurred a few months before and the piece of metal came loose again. This piece of metal has a setscrew to control the head down position, so it has a fair bit of force on it. I put the piece of metal in a bag and taped it to the back of the drive. David discussed long-term fixes in his report.


    about reimbursement for expenses
    From Robert Garner


    Thanks for the great report, as usual!

    > I would normally just go ahead and buy the Loctite [$35], but since the museum has not yet paid the reimbursement request I submitted for the CT1402 roller repair, I think I will hold off this Loctite purchase until that prior bill has been paid.

    Sorry to hear you haven’t been reimbursed yet for your CT 1402 related purchase (nearly two months ago).

    To whom did you submit the bill?

    George (Holmes) —> Are you still the best person to handle the 1401 expanse reimbursements?
           Is Anges Tong, accounts payable, also an option? >P> Best,

    — Robert

    from George Holmes

    Yes – please let us know to whom the reimbursement request was sent.
    Regardless, you can send it my way.
    Send copies of the receipt if you have them.



    from David Clementson

    I gave the reimbursement request to Jessie at the front desk.


    from George Holmes

    Thanks David

    Can you send it to me?

    Best regards,


    Wednesday September 27 3:00 pm tour - from Scott Stauter
    Jim Maurer and I gave the tour today to 24 people, and 4 after the official tour.
    The audio worked great. The three 026s worked, with the middle one having very light printing. The sorter worked fine. We ran Bigprint fine and the CT 1402 and CT 1403 worked. We had powered on the DE 1401, but it was not needed. Three of the CT 729s worked.
    Our visitors were from Canada, Mexico, and China. After the tour, we had a discussion with a man who had worked with computers in the Soviet Union.
    Warmest regards,
    Scott Stauter

    Demo, September 23, 2023
    11:00 am - from Stephen Madsen
    Karen Sun and I demonstrated to 60 visitors plus 20 after the demonstration. International visitors were from Belgium, Japan, Korea, Slovakia, China, and France.

    026 keypunches: Worked OK.
    083 sorter: Worked OK.
    CT 1401: We had a reader stop when loading BigPrint, but it worked OK on the second try. We left BigPrint running, so we did not have to load it during the demo. Name cards were read OK. We did not attempt to run Powers of 2. The printer and tapes worked OK.

    DE 1401: Was not used.

    Stephen H. Madsen

    1:00 pm Demo & 2:00 pm Demo Lead Training Qualification - from Karen Sun

    Samuel Plainfield and I demonstrated to 50+ visitors plus 20 after the demonstration. International visitors were from India, China, Korea, Japan, Germany, and the UK.

    As this is a Training Qualification session, we flipped the room quickly right after the official 1pm session with every lead and operator's help.
    We used the 026 keypunch farthest from the closet for the demo. It works fine although it is a bit light compared to the middle one. I bet this one is used most during and after the demo.
    083 sorter worked fine with a big colorful deck sorted in every numerical pocket.
    CT 1401: We preloaded the cards from the previous session to save time and left it there. Big Print runs smoothly. We did not attempt to run Powers of 2. The printer and tapes worked perfectly.

    DE 1401: Was not used.

    Thank you all the leads for being there, supporting the whole session, giving me useful feedback such as improving on space management with such a big crowd and answering questions for the big group.
    I always have the chance to learn one or two tricks or new information from you. Practice is the best way for me to gain experience.
    Thank you Samuel for stepping up to be my operator, which made you play the great operator in a row for a whole Saturday afternoon. You know a lot about 1401 and I shall keep learning from you.

    - September 20, 2023

    Demo Programs - from John Howard
    Samuel Plainfield and I are collaborating on a project that will allow demonstrations and test programs to be resident in 1401 core memory and started with sense switch selection. Tom is bringing up new hardware for DE. As reported last week we are adding demo programs to the SERVER.S software that resides in the 1401.

    BigPrint was added to the server code and modified to assemble and simulate in the ROPE system. The software supports ending BigPrint when a card with EOF is read. This works in the simulator, but BigPrint does not correctly end on the EOF card on the CT hardware.

    Practical issues with the size of the new server card deck began to slow progress (consumption of cards, and problematic reader and punch operations frustrate the debug process). The assembler does not support limited scope of variables so there are changes needed to some debug programs which will make version management more difficult.

    With Tom we will take a look at changes to the overall architecture of the server.s / PCWriter.c++ system. It would be better to find a way to boot this system (without the 1402) from scratch rather than expect Server to be always resident in core, and also some kind of a link editor/manager to handle each demo software’s use of the same symbols (for example START).


    Demo Programs - from Jack Ghiselli

    Hi John,
    Good to hear that you're making progress on your project. You and I talked about a month ago, and I mentioned that some of the 1401 demonstrators had been looking into loading demos from tape, possibly with several demos on one tape. This is different from your project but shares lots of the same issues and problems. Perhaps we can collaborate.


    Jack Ghiselli mobile 1-408-839-1051

    9/20/2023 Wednesday Demo~
    -- from Samuel Plainfield

    Tim Robinson and I gave a demo to 49 people + another 25 or so afterwards.

    One guest in particular was from Mexico and used to program for the 1401. He made a special request for the first three bootloader cards so that he could see the code and frame them to share with others. Jack has been very generous with his time in explaining to me how those bootloader cards work. Yes, I've read Ken's excellent write-up on them, but Jack's character-by-character analysis is extremely helpful nevertheless. Thank you again, Jack!

    In any event ~ the sorter is working well for demo purposes. We used CT for magnetic tapes which worked well #2 and #4. CT produced a large number of reader checks for Tim when attempting to run Powers of Two -- but he eventually got it going, much to the enjoyment of the crowd. I am still in disbelief that CT can read a single card at all, let alone a whole deck. :)

    I think all of the keypunches are working well. Frank reminds us to reverse the ribbon when faint printing is first observed. The keypunch furthest from the closet is having a little difficulty grabbing the card to pop it up into the stacker. Frank and I performed a mini repair to it, but it needs a more thorough resurfacing of the roller to fix it for another while longer.

    By next Wednesday, I should have a second sort deck ready for Operators to optionally use which will sort a deck of cards "by color." Operators can then give an example to the audience and provide the visual satisfaction of seeing a deck of disparate cards become obviously "sorted" for a specific purpose, if so inclined.

    ~Samuel Plainfield

    - from Frank King

    Great writeup Sam. It makes one feel good about the work we do.


    9/20/2023 1401 Restoration Status Reports
    - from Ken Shirriff
    Summary: Bhushan and I worked on 729 tape drive CT #1. The main problem appears to be the reset switch isn't working correctly and should be replaced, but there are multiple issues.

    Details: When you push load-rewind, the tape drive performs the load, but then halts before the rewind. The problem is that relay R104 is supposed to be held across the load and rewind, but when R101 drops at the end of the load, R104 drops too.

    The following diagram (adapted from the ALD) shows what's going on. The yellow path is R104 which is supposed to be held. During the load phase, it is picked through the blue path. During the rewind phase, it is supposed to be held through the purple path. I found a bad relay, but Bhushan cleaned the contacts and the tape drive still failed. I checked the selenium diode D2 with a multimeter and it appeared fine (but I am suspicious). Swapping relays didn't help. The reset switch showed continuity (but apparently the wrong continuity). Voltage measurements didn't make sense: there should be -48 volts at D2 B, which there was, but it dropped at the end of load. CE17 showed -48 volts all the time. There was -48 volts at the reset switch (PB).

    Eventually I put a jumper across the reset button and everything worked! That shows the reset switch is faulty and seems to be switching the wrong contacts. I don't understand the topology of the switch. It has four screw terminals, even though the schematic shows three connections. The switch is constructed from layers of flimsy material. The screws are very tight and I'm afraid I'll break the board trying to remove the screws. So it might be better if someone more mechanical removes the switch.

    The remaining mystery is why we measured -48 volts on both sides of the diode, flowing backward from the blue line to the purple line. It seems like the diode is not blocking the -48 volts, even though it measured okay with the multimeter's diode setting. I suspect the selenium diode is breaking down under load (Zener-like), but I'm not sure how to test this. If the diode isn't working, there's probably a weird corner case that will go wrong, so we should probably fix this.

    To summarize, it appears that there was a bad relay, a bad switch, and a bad diode, all contributing to this problem.


    - from David Clementson

    DE1402 Punch:

    The day started by observing the latest symptom: chronic punching of a column regardless of any software command. This is what we saw the prior week, although the faulty column had moved from 4 to 68. I had initially thought that the problem was due to a wiring fault, but Frank brilliantly suggested we run it with all of the punch magnets unplugged at the four internal rectangular connectors. The problem persisted, proving that it was mechanical in nature. So out came the punch unit again.

    Upon removing a magnet subassembly from the punch, Bhushan noticed that some of the armatures were sticking to their magnets more so than others. Inspection revealed some sticky contaminant on the back side of the affected armatures. So we removed all four of the magnet assemblies, then removed and cleaned all 80 armatures with alcohol. We cleaned the magnet cores and yokes as well. After reassembly, the sticking was gone. So with great difficulty we reinstalled the magnet subassemblies back into the punch. We were careful to inspect and test each row of armatures to make sure they moved correctly as the punch cam was operated.

    With the punch reassembled, we reinstalled it in the machine and retimed the cog belts. I also took the opportunity to clean the area below the punch die, and I also redrilled the mounting holes of the chad chute so that the chad funnel now seats properly in its recess. I guess that chute was from another model, since it was clearly not mounted properly.

    Upon testing, we found that the chronic punching problem was gone, however we were not getting any punching at all on a number of columns. All of the columns associated with connector "D" were not punching, and only about half of the connector "C" columns were punching. Connector "A" and "B" punches were okay. The connector mating checked okay, so it looks like we may have broken a wire in the magnet assembly. Either that or we somehow mis-assembled the punch. We will try to do a continuity check of the magnets next week to see if we can find the root cause.

    We also saw the recurrence of the "extra" punch on column 80, where a row punched at column 80 gets one additional punch on the subsequent row. Marc reported that he found burrs on the column 80 select linkages that may be responsible, so he may need to do his magic with his files.

    729 parts harvesting:

    I went to the Yosemite warehouse on Thursday and was able to harvest these parts from the 729s:

    > Tape Down motor and casting assembly
    > replacement vent hose for the upper cooling fan
    > complete set of front panel switches so that Ken can repair the CT #1 reset switch problem

    That's it for this week.


    - from Robert Garner
    Re: Selenium rectifier (was Re: 9/13/2023 1401 Restoration Status Report)
    Marc, Ken,
    > [Ken] The selenium rectifiers are specified as 78V AC 112mA. Do we have any silicon diodes that would function as good replacements?

    > [Marc] A garden variety 1N4003 or higher should do the trick?

    I concur: a good ole’ 1N4003 should work just fine in place of the selenium rectifier:

    Let’s please replace the selenium monsters before they smoke.

    — Robert

    p.s. Just in case we don’t have any lying around, I bought 50 for $2:
    Geeez, I used 1N4000x in grade school… ;

    CHM 1401 Demo, Saturday 9/16/2023
    - plus
    techie comments from Sunday the 17th
    - 11:00 AM - from Jack Ghiselli
    Duane Sand and I gave the 1401 Demo to 30 people, including international visitors from Belarus, Brazil, Canada, China and Germany. It is nice to have a smaller group than the 60 or so we've seen in the past. The demo is much more personal.

    We used CT. We had a few Reader Check errors on the CT1402, but with careful card handling we recovered from all of them. Otherwise the system ran well, as did all three 026 Keypunches and the 083 Sorter.

    Jack Ghiselli mobile 1-408-839-1051

    - 1:00 PM - from Jack Ghiselli
    Steve Madsen and I gave the 1401 Demo on Saturday 9/26/2023 at 1:00 PM to 50 visitors, plus mini-demos to a surprising 55 additional people who wandered in afterwards. We had an amazing number of international visitors from Australia, Canada, China, Denmark, Germany, Greece, Hong Kong, India, Japan, Korea, Poland, Russia, Switzerland, Turkey, and the UK.

    We ran on CT. We had a few CT1401 Reader Check errors but were able to recover and continue loading. Otherwise, all hardware ran well.

    Worried about the CT1402 Reader Check problems getting worse, we powered on DE as a backup. While preparing, when we tried to load a card deck, the DE1402 Punch took off punching cards on its own, with the cards having all punches in one column. Not sure how that happened, since I don't think DE has the Column Binary feature, but it looks like the Restoration Team is working on the DE1402 Punch. We turned off the CT1402 Punch rocker switch and reset, and the DE1402 Reader then worked OK. As it happened, CT did not get worse, so we didn't need to use DE.

    Following the demo, I needed to punch an object deck on the CT1402 and got two Punch Check errors. Again, with proper card handling, we were able to discard the duplicate punched cards and continue, so this is not a major problem.

    It look like somebody has installed a new belt unit for Mic #3, and the microphones worked perfectly! There is a note on the new Mic#2 saying "Use GREEN rechargeable batteries". Could someone please explain this -- other than the two batteries in the unit, there are no other Green rechargeable batteries, so it's not easy to swap them. Are these batteries different?

    Jack Ghiselli mobile 1-408-839-105

    - plus techie comments from Sunday the 17th

    - from David Clementson, received Sunday the 17th

    Thanks for the detailed report, Jack. The DE 1402 runaway punch problem correlates with my current theory that there is an electrical fault causing a punch to fire chronically regardless of the CPU state. Do you recall which column was affected? My guess is that it was #3. I’m going to look at that on Wednesday. Meanwhile, leaving the punch switch in the off position is the right thing to do. I just need to remember to turn it back on when I test it.

    About the mics, I believe Dennis (the museum’s IT expert) brought a new belt pack from one of the other exhibits for testing. He must have left it. It should be no different than the others as long as its switch settings are correct. Glad it all sounded good.


    Hi Dave,
    The DE1402 Punch was loaded with green cards. I left the multi-punched cards on top of the DE1402. It was a column towards the left of the cards.

    Jack Ghiselli mobile 1-408-839-1051

    - from Frank King - received Sunday the 17th
    - This is a seeming update of an e-mail sent a few hours before this one

    HI guys, did anyone do a scan to determine which brush in witch set caused the reader checks?
    1. Take the last card in the hopper to the console.
    2. To do a scan, turn the cpu switch all the way to the right to scan.
    3. Press start once.
    4. The address will be displayed. 001 to 080.
    5. The B reg will have the data displayed.
      If the data displayed is the same as punched in the card, then it is the first set of brushes that failed. If the data is incorrect, the second set of brushes failed.
    6. Remember the number, so we can check or replace the brush.
    7. Now press start again. This will progress the scan.
    8. Repeat the scan a few times. If there are greater than 2 or 3, the card probably read crooked, or maybe the cards were not joggled well? Or maybe a feed knife miss?
    9. If the computer continues to scan while you hold the start key, you have finished.
      It is the job of the first set of brushes to count the holes in the card.
      It is the job of second set of brushes to read the data into memory. Top card in Hopper.
    10. Remember to turn the switch back to run. - Always my mistake. No biggie.
    11. Take the cards from the hopper, set aside, these are successfully read cards.
    12. Take the cards from the feed, set aside, then NPRO- there will be 2 cards. Place the card in your hand in front of the 2 NPRO cards, then place these 3 cards on the bottom of the remaining deck, joggle, check reset and start.

    Frank King

    9/13/2023 1401 Restoration Status Reports
    - also see
    techie comments from Sunday the 17th
    - from Ken Shirriff
    Summary: I worked on CT#1 tape drive but didn't accomplish anything.
    The problem is that when you do a load-rewind on CT#1, it does the load but hangs before doing the rewind. Last week, I figured the problem must be relay R104, which needs to be picked for this transition to work. I cleaned that relay and also swapped it with a different one, but it made no difference, so back to the drawing board.
    I studied the neons in slow motion at home, along with studying the manual, and my new theory is that the problem is diode D2, which feeds R104. Multiple things can pick R104 or block it from picking, but I think D2 is the relevant one.

    Diode D2 is one of the selenium rectifiers, which I will test next week and hopefully for sure that will fix the tape drive :-)

    I also probed the CE connector, to see if any of the signals there provided clues. This connector is on the lower left, above the circuit breakers. I had to reverse-engineer the numbering scheme. The sockets are numbered 1 through 24 *vertically*, starting in the upper right and going down the rightmost column. This is a Jones plug, by the way, which I learned on Twitter. I'm sure many of you already knew this :-)


    from Robert Garner

    > Diode D2 is one of the selenium rectifiers,
    Ah, an excellent reminder: We really need to replace or bypass all the selenium rectifiers in our tape drives (with silicon ones).

    Perhaps beginning with the ones in CT#1?

    — Robert

    p.s. Perhaps we’ll wish we had gas mask when diddling with this potentially faulty one? :-|
    - from Ken Shirriff

    The selenium rectifiers are specified as 78V AC 112mA. Do we have any silicon diodes that would function as good replacements?

    - from Marc Verdiell

    A garden variety 1N4003 or higher should do the trick?

    - from David Clementson

    I started the session by checking each of the keypunches for print quality and loading errors. I found them all to be okay.

    Frank and I then went to try to find why the DE 1402 was generating Punch Check errors. It turns out that when I timed the cam belt, I inadvertently timed it 120 degrees off. There is a plunger that can be depressed that pushes a pin into a detent in the clutch shaft, locking it at the 0 degree position. With the shaft so locked, the punch and camshaft sprockets can then set to 0 degrees. Much to my surprise, however, there are actually TWO detents in the clutch shaft, one at 0 degrees and one at 120 degrees. So after realizing this, it was a simple matter to retime the sprockets to the proper angle.

    We tried duplicating a card with this new timing and found that the original problem - column #80 punch sticking and double punching - did not happen, but rather a new pathology developed. Executing a punch command resulted in a card being produced that matched (we believe) the contents of the punch buffer, followed by two cards both with Column #3 punched in every row. Not only were all rows punched, but even the row locations between adjacent cards were punched, leaving partial holes at the top and bottom edges of the cards:

    I removed the punch assembly again and inspected the selector latch and interposer for column 3, but found no problems. I was able to manually select the column 3 punch and it deselected normally. So I reinstalled the punch. I had marked the cam belt and sprocket before the removal, so the timing was still correct.

    What is interesting about this fault pattern is that the two rows prior to the start of the problem (rows 8 and 9) are not punched in column 3. This rules out the possibility that the #3 selector latch or interposer is getting stuck like was the case for the prior column 80 problem. It is as if the #3 punch magnet is getting energized and staying energized throughout the end of the 3-card cycle. Resetting the 1401 and executing the punch instruction a second time yielded a trio of identical cards, so we can rule out an electrical or wiring fault where the punch magnet #3 is always energized, as would happen if signal +U PCH MAG 3 were shorted to ground. At this point my strongest suspicion is that the problem is electrical rather than mechanical. Next week I will dive into the bowels of the 1401 and attempt to put a scope on +U PCH MAG 3 to see if it has the proper waveform.

    After the demo, I met with Ablert and Dennis, the museum's audio and IT experts respectively. They were very generous with their time and walked me through the hardware and software setup of the exhibit's audio system. I have a bit of expertise in this area from my former life. I reviewed the settings for the microphone processor and saw that Albert did an excellent job setting it up originally. I made one suggestion to reduce the mic compression ratio from 4:1 to 2:1 to allow the voice to punch through the room's high background noise a little better. So we will see if this helps the demos. I will make a point to listen to the audio on the demo next week and see if I can find any other improvements to make. As an aside, it turns out that the mic processor preset we use does not have a feedback eliminator as I originally thought, but only uses EQ, compression, and gating.

    I also realized that due to the high level of background noise in the room (especially with the printers going), microphone placement is going to be extremely important for proper sound reinforcement. So I want to underscore to the docents that they should be mindful when placing their mics. The headset should be adjusted so that the mic capsule is positioned near and slightly above the corner of the mouth as shown below.

    That's it for this week.

    - from Marc Verdiell
    David, When I removed and partially disassembled the punch I did not have time to complete the adjustments per the CE instructions. The first one of them seemed suspicious. It’s the clearance for the interposers. You check for them at either end of the block through a little window. It looks like there was not enough clearance. I’m not sure if it could explain the problem you are seeing though.

    Wednesday, Sept 13, 3:00 pm 1401 demo
    - from Scott. Stauter
    Today Jim Maurer and I demonstrated the CT 1401 system to 38 people, and 12 more people before and after the demo.
    All keypunches and the sorter worked fine. We ran the Bigprint program on the CT 1401, 1402, and 1403, which worked well. CT tapes 1 and 3 are labeled out of service, so we used 2 and 4. The DE 1401, 1402, and 1403 ran the Bigprint program in case we needed a backup, but they weren't needed.
    Our visitors were from Japan, Singapore, China, India, and England.
    Scott Stauter

    CHM 1401 Demo Saturday 9/9/2023
    11:00 - from Jack Ghiselli
    On Saturday 9/9/2023 at 11:00 AM Peter Chang and I gave the 1401 demo to 46 people, plus mini demos to 4 more who wandered in afterwards. International visitors were from Germany, India, Japan, and Mexico.

    We ran on CT. We had one "freeze" on the CT1402. The symptoms are that during loading a program, the CT1402 simply stops reading cards. There are no CT1402 error light (no READER CHECK, etc.). The 1401 console OP shows "1" (trying to read a card). We could recover by doing a reader NON PROCESS RUNOUT (which raised the READER STOP error light) to run out the two cards in the mechanism, and reloading starting with those two cards. Apparently, all the cards in the output stacker had been read and processed correctly (that is, the last card in the stacker was NOT bad).

    We demonstrated CT 729 tape drives #2 and #4. All three 026 Keypunches and the 083 sorter worked OK. Some later hardware problems are in Tim Robinson's report.

    Jack Ghiselli mobile 1-408-839-1051

    - 1:00 PM - from Scott Stauter

    Duane Sand and I did the 1:00 demo. Things went well, although the middle 026 prints very lightly. We used the CT 1401, 1402, 1403, and two 729s.
    We had 36 visitors during the demo and another 10 afterward. The visitors were from Brazil, Canada, Germany, India, and many states.
    Scott Stauter

    2:30 PM - from Tim Robinson

    Scott Stauter and I did an extra demonstration on Saturday September 9 at 2:30pm (my lead qualification demo).

    We had 36 visitors including international visitors from Turkey, Sweden, Korea, and Canada, and domestic visitors from as far afield as Florida and Alaska.

    All three keypunches worked, but the middle one was printing a little faintly. A visitor tried to punch a card on the 001 but some punches came out partly overlapped so the card was not usable. May just have been operator error.

    The sorter worked fine.

    We ran Bigprint and powers of two on CT, but part way through the post demo Bigprints the printing became faint on the left side so we switched to DE for the remainder which worked fine. After the demo one of the experienced leads (I forget who) commented that it may just have been that the printer gate was not closed tightly enough - at any rate it should be checked before the next demo. We used CT tape drives 2 and 4 which worked well.

    Before the demo we did have trouble with a reader check loading the first powers of two deck. It turned out a card was upside down, but correcting that did not fix it. A second deck loaded OK. After the demo Jack Ghiselli looked at the bad deck and found card 78 was missing and several others were out of order. Card 78 was apparently also missing from the third deck (which we had not tried before the demo). He duplicated new cards and put the rest back in order so all three should be good again.

    The sound system worked great, even with both mics turned on at the same time.

    Tim Robinson

    IBM 1401 Special Private Demonstration September 7, 2023
    - from Larry Hara
    Today Thursday, September 7 at 10:45 AM, Jim Mauer and I did a special/private 1401 demo to 13 students from a St. Helena, CA high school technology class. We also had 8 additional drop-in visitors from Chile, Washington, and the Bay Area.

    The ink from the ribbon on keypunch machine #1 (farthest from the closet) was slightly faint at first but after punching a few decoder cards, it got darker as the ribbon progressed. Jim used this keypunch for the demo. The keypunch #3 closest to the closet works well; keypunch #2 is down for repair.

    The 083 sorter worked well.

    We ran Big Print on CT 1401 and while there was a 1402 reader check at first, Jim's second attempt was successful. We also ran Powers of Two and had no issues. As a backup, we had DE powered up and tested prior the demo. Since CT ran well, we didn't need to use DE.

    The 1403 and 729 worked flawlessly.

    We had absolutely no problems with the A/V and mics. Thanks to those who made this possible. It was a welcomed relief!


    9/6/2023 1401 Demo Report
    - from Samuel Plainfield

    Pat Bruder and I gave a demo to a very small but interested group of 15 and another 12 or so wandered in during/just after. We used CT, which worked extraordinarily well -- not a single reader check!!
    Moreover, not a single card jammed as I reported last time. Frank and I discussed that a bit and did a little testing, but we were unable to replicate the issue or explain how it came to be.

    Ken fixed the CT729 #2 and it worked brilliantly. #1 and #4 remain inoperable.

    Keypunch closest to the closet worked brilliantly, #2 still inoperable, and #3 is now repaired (see restoration report below).

    The microphones both worked well enough after some last-minute finagling.

    A/C working. Per Robert, this is actually called CRAC -- Computer Room Air Conditioning, not to be confused with AC, Alternating Current.

    The museum was surprisingly empty today.

    9/6/2023 1401 Restoration Status Reports

    - from Samuel Plainfield

    Frank and I worked together on 026 #3, furthest from the closet. He was trying to feed the ribbon through but it was getting caught on an upper area of the punch register block that it shouldn't be able to get caught on. So, we loosed off the register block and there was a ton of chads piled in there:

    There was also a piece of ribbon wedged in that was cleared:

    After that was vacuumed up, the register block was put back on. The register block contains a very delicate spring assembly that must be held to prevent the spring from falling out lest it never be seen again! So, when removing the register block, do so slowly and carefully to keep it all together. We re-threaded and placed on a new ribbon. Good as new.

    Finally figured out why the star wheels are called star wheels:

    That's it for the hardware.

    On the software side: John and I successfully punched out a custom server deck which loads into address space 3000 among many other changes. John created an incredible baseline structure "demo prep" type code that we plan to load several demo programs into so that one can simply flip Sense Switches and toggle between the various "apps" and ought to be quite useful when the 1402 isn't working as a backup plan.

    So, that's step one. We'll continue on this and do more testing next week and keep y'all posted.

    ~Samuel Plainfield

    from David Clementson

    And I can report that I was finally able to remove the tape down motor from the DE #3 tape drive. Disassembling the motor revealed charred winding, so it will need to be replaced with a donor from the warehouse. I contacted Aurora about scheduling a harvest session. John and I also had a close look at the DE 1402 punch and found that Marc has apparently fixed the sticking #80 selector nail problem. We were unable to make it stick anyway. So we reinstalled it and retimed the two cog belts, which was surprisingly easy to do. When we tested it with a duplicate program, the 1401 hung on the punch opcode but with no error lights. At this point we ran out of time, so we will try again next time.


    from Ken Shirriff

    My status report: Looked at the CT#1 tape drive, which gets stuck in the middle of load rewind, putting the tape into the column but not rewinding. I suspect relay 104 is the problem.

    I thought relay 116 might be the problem, so I swapped it with relay 126, but it made no difference. (I found that relay 126 had sticky gunk on the pins, so I cleaned that off.)

    The CE Manual of Instruction is the most useful manual for debugging this. It describes the load rewind process in extreme detail (pages C40-C45). It also describes the function of each relay (pages C68-C76). I examined the relay sequences and everything looks okay for 5 pages until the point where the load completes and the rewinds starts. A lot of relays change status at this point, and the SMS logic (load point detection) is also involved. I compared with working CT#2. I think this oscilloscope trace below is an important clue. This shows the "manual go" signal, controlled by relay 119, measured on B15D (01.07.1). It goes low when load-rewind is pressed (as expected). When the load phase completes, manual go is raised (which is good), but immediately falls (bad), making the spike in the middle. It stays low until I pressed "unload" near the end of the trace.

    So the question is why does relay 119 immediately drop manual go? A complex chain of relay logic controls this (of course). See ALD page 02.02.1 1D (upper right). A problem with load point detection circuit (i.e. detecting the foil on the tape) might cause this, but the scope showed no load point detection. (On a working machine, the load point triggers a 10ms drop in the signal on C15F, but the signal stays high on the bad machine, as expected.) Looking at the relay lights in slow motion shows R101 drops as expected, but then R104 drops (bad) causing R119 to drop, causing manual go to drop. The function of R104 is to hold the rewind status through the load-rewind operation, so it should not be dropping. The R104 circuitry (02.01.1 3B) shows that R104 should be holding itself closed until R116 picks at the load point (which doesn't happen). A failure of the R104-2 contacts would explain the problem and I don't see any other reasons that R104 would drop. Therefore, it seems most likely to me that R104 is the problem. I'll check this next time.

    I also took photos of the the bad motor windings in the motor that David removed. There are multiple charred sections.

    Here is the motor nameplate for reference. I couldn't find this motor online.


    1401 demonstration on September 4 - from Scott Stauter
    Jack Ghiselli and I gave the 3:00 p.m. demonstration on Labor Day. There were 52 visitors: from Japan, Israel, New Zealand, Russia, Switzerland, India, Austria, Germany, Somalia, and Mexico.
    The two keypunches nearest the door worked. The one farthest from the door is placarded that it doesn't always register correctly. The one nearest the door is not on the KP circuit breaker, as it continues to run when that CB is off.
    The CT 1401, 1402, and 1403 ran well. CT tape drives 1 and 3 were placarded INOP, but 2 and 4 worked well.
    We were able to run BIGPRINT on the DE system, but it was not needed.
    There is hydraulic fluid on the floor from the DE 1403.

    Scott Stauter

    IBM 1401 Demonstration Saturday 9/02/23
    from Stephen Madsen - 11:00 am Demo
    Jack Ghiselli and I demonstrated to 32 visitors from Argentina, Australia, Brazil, Canada, Turkey, and USA. Seven more came after the demo.

    Keypunches: #1 (farthest from closet) has faint printing, #2 will not feed.
    Sorter: Worked OK
    We used CT.
    C1402 had one card jam. It was cleared and we recovered OK.
    729 tape drives: #1 and #3 are INOP. #2 had to be re-threaded on the take-up reel. Then it worked OK.
    BigPrint #1 would not load.

    Stephen H. Madsen

    Also, we had microphone problems. Before the demo both mic #1 and mic #2 worked OK. Just before the demo mic #2 would not work, so Jack used a docent mic.

    from Jesse Nichols

    Hey Stephen,

    I sent a message to our IT dept and Jon Plutte so they can take a look this week. Thanks for the heads up like always!


    Jesse Nichols III
    Museum Services Supervisor and Volunteer Coordinator

    from Jack Ghiselli

    Hi Jon, Dennis, and Jesse,

    I was one of the 1401 demonstrators today, and saw first-hand the audio system problems. At 10:25 AM we tried out the mics. The sound was PERFECT. Both Mic1 and Mic2 sounded great. All levels on the rack (Mic1, Mic2, and Master) were set at the suggested "red-dots", and the radio mic boxes had their side buttons set to MIC (not -10dB). We took off the mics and continued preparing the demo, and at 10:50, we put the mics back on. That's when Mic2 went bad. No change to anything as far as we could tell, but to our surprise, Mic#2 was now inaudible ("Hey, we just tested this!"). We tried turning up the Mic2 level, but no joy. Tried powering off and on the rack and the battery pack units. Still no joy. So, we ended up turning Mic2 OFF, and using a shoulder-mounted stand-alone mic instead of #2.

    We might be doing something wrong, but doggone if we can figure out what. When we talk into Mic2, we see reasonable level displays on the battery pack tiny screen, and we see reasonable level displays on the Shure H5 audio receivers on the rack. So, we think Mic2 sound is getting through the microphone, and through the radio link, and into the rack. But, it isn't getting to the speakers.

    Jack Ghiselli mobile 1-408-839-1051

    from Samuel Plainfield - 1 pm Demo

    Quite a large crowd of 85 for the demo and another 80+ thereafter thanks to superb front-desk marketing and Michael Lenihan bringing in his docent group! Thanks y’all!

    Larry Hara and I gave a relatively smooth demo to the large group. Unfortunately, Mic #2 was out as noted earlier by Jack, so Larry used the portable mic/speaker which is sufficient for smaller groups but I could tell some folks were struggling to hear him who were much further away.

    We used both CT and DE for the demo. CT was having quite a few reader checks, as with DE, but DE just a few fewer so we switched systems mid-demo seamlessly.

    Sorter looks great in demos with the Sort-25 deck, to which I added a few more cards to earlier. However, closer examination of a few test cards shows that it’s often off by a row: putting 4 punches in the 5 stack, for example. Guests certainly cannot tell, but let’s be sure not to try and sort anything of any importance for now :)

    (Crushed card in CT)

    The crushed card phenomenon continues with CT1402. It is intermittent and only occurs with guest cards. I observed it four times over the course of the day. It does not occur during continuous read operations.

    Looks like we are down to only one keypunch ~ the one closest to the closet is working great. KP#3 is jamming up after the first couple characters and KP#2 is having intermittent difficulty feeding cards.

    ~Samuel Plainfield

    IBM 1401 Demonstration Wednesday 8/30/23 3:00 PM
    8/30/23 3:00 PM - from Larry Hara
    On Wednesday, August 30, Duane Sand and I gave the 1401 Demo to 43 visitors plus an additional 20 who wandered in before and after. They included visitors from the Bay Area, Boston, Colorado, Japan and Taiwan.

    The ink from the ribbon on keypunch machine #1 (farthest from the closet) was a bit light so Duane used keypunch machine # 2 for our demo. Post demo, I tested all the keypunch machines and found that the ink on keypunches #1 and #2 were both light.

    The 083 sorter worked well.

    Prior to the demo, there were some issues of not loading the first card of Big Print on CT, but deck #3 worked. There were also issues with the tapes dumping on the take-up side so to be cautious, Duane used DE to demo Big Print and the tapes drives.

    The 1402 and 1403 worked well.

    DE 749 Tape

    There were problems loading the tapes but they eventually loaded properly . We used units # 1 and 2 as unit 3 was down for repair.

    A/V system

    We tested the mics prior to the demo and they appeared reasonable. However despite balancing the volumes of Mic 1, 2 and the Master, the sound level was too low. Duane used his booming voice when demonstrating the machines as I supplemented and narrated as he showed the various equipment. Overall that worked OK. Until the A/V system works properly, I suggest that Mic1 be used with the PA system, but instead of using Mic 2, use the portable mic/PA for the Operator. Caution: as Sam Plainfield discovered, the portable system mic is not omnidirectional and the mic needs to be positioned in the proper orientation, i.e., towards your mouth.


    from Duane Sand - "The 083 Sorter moves cards around in an erratic nonrepeatable way. "

    The 083 Sorter moves cards around in an erratic nonrepeatable way. It looks okay to visitors but it definitely is not sorting.
    When a deck has been "sorted" and then run through again on the same column, it should fill slot 0 first, then slot 1, ... and finally slot 9, with no rejects.
    Instead, the "sorted" deck is not put into any order, and if processed again, it again puts cards into various bins in some different scrambled order.
    With a different set of reject cards each time.
    I suspect that it is getting random noise rather than clear readings of holes.

    Others have been using A/V mic 2 successfully. I did not succeed today.
    I believe the method used well by others is:

    1. Ignore the goal markings on the A/V amps.
    2. Set up mic 2 first, not mic 1.
    3. Set mic 2 amp to maximum.
    4. Set system amp to a level that has mic 2 heard without feedback.
    5. Now set mic 1's amp to a level that works with that system amp setting.

    The ribbon on the 026 keypunch furthest from the A/V closet was stuck at the ribbon end and did not reverse automatically.
    The symptom is faint or no printing.
    I tried to manually flip the ribbon's direction and manually move it away from the worn end, but was unsure how much force was okay.

    Larry had to scrounge around to find a table where he could set down the demo materials.

    -- Duane

    from Karen Sun - A/V issues

    For the A/V issues, would it be better to have a 3rd person sit by the closet and help the demo lead and operator adjust the volume when there is a mic feedback or unheard issue happening during the demo? It's a bit miserable to keep walking around to adjust the volume back and forth during the demo while the audience is watching.

    Restoration Reports for 08/30/2023
    My restoration report for 08/30/2023: tape drive stuff - from Ken Shirriff
    1. I replaced the file protect light on CT729 #2, which Jack noticed was burned out.
    2. David noticed that the air hose at the top of tape drive DE#3 is broken. This is for the pressurizing blower. I took a photo:
    3. Right before the demo, I was informed that tape drive CT#3 was dumping tape into the column during load. I confirmed this problem, but didn't have time to investigate.
    4. I mostly worked on tape drive CT#1 with Bhushan. This tape drive loads the tape but then doesn't proceed to rewind and ends up in a bad state. Not all the neons work on the back, which make it harder to debug. There's a 729 manual that explains the operation of the relays in detail (but I couldn't find a scan to link to). I followed the sequence and the load sequence goes well until the bottom of page C44, where the tape drive finishes the load phase and switches to rewind. In particular, I verified that R117 picks, R3 drops, R101 drops, and R119 picks, as should happen at the end of the load.
    But it seems that R116 is not picking and this is probably where the problem happens. This relay is associated with the tape break and end-of-tape indicator. There could be a problem with one of those sensors, but I think Bhushan ruled that out. So I think we are pretty close to finding the problem but not quite there.


    My restoration report for 08/30/2023: tape drive stuff - from David Clementson

    I'll add my report to Ken's.
    1. Bhushan and I started by working on 026 keypunch #1 (furthest from the closet) which was intermittently jamming on load. It turns out to have had three problems: a bit of card stuck in the card path (under the clear plastic guide, I believe), a stray piece of electrical tape on the center bakelite card platen, and a whole bunch of punch chaff stuck behind the punch die. Apparently there is supposed to be a feed screw in the chaff path to help "pump" it to the waste hopper. On this unit, that piece is missing. So we will need to ultimately try to find a replacement screw, but in the meantime, we'll need to periodically disassemble and clean the die area. There was also a problem with the cycle clutch pawl not fully retracting from its cog wheel, resulting in an awful chattering noise. We lubricated the pawl and adjusted its clearance, and the problem went away. But it will be something to keep an eye (ear?) on going forward.
    2. We then turned our attention to removing the (confirmed shorted) tape down motor on 029 DE#3. We removed the belts, the high-speed rewind motor, and the speed sensor switch just to keep them out of the way. Per the drawing below, this subassembly (140A) is built around its own casting (140D) which is fastened to the main tape transport casting by four screws (118) and two taper pins (121). This subassembly must be removed whole in order to get the motor out.

      We took out the casting mounting screws, but the taper pins held fast; we were not able to apply enough tappy-tap to free them. There is probably some corrosion adhesion helping to hold them. We studied the situation and discussed it at length. We agreed that the best plan would be to fabricate a slide hammer that can supply a rearward impact on the front side of casting 140D at the center top, close to the pins. Otherwise, we would need to take the machine apart far enough to access the front side of the main transport casting so that we can remove the taper pins using their threaded ends.

      This photo taken from the rear of the unit shows the motor and its casting. The force needs to be applied to the backside of casting 140D, seen just above the tape down motor (the motor furthest from the camera). So I will work on that for next week.

    Please note that the bits and pieces for the 029 are in a bin in the Liebert room near where Stan works. One of the parts in that bin is a (fragile, dangerous, and irreplaceable) glass mercury tilt switch. So be careful to watch out for this bin!


    8/30/2023 (Software) Restoration~ from Samuel Plainfield


    John and I met a lovely lady who was a certified Autocoder programmer in Brazil back in the 1960's!

    John and I continued our efforts with Stan's PC-Server-to-1401 software to create modifications to our magical tools such as the one-card 80-80 list. We accidentally punched out the source code onto cards, successfully loaded the tool into memory (separately), and then recursively used the tool itself to print out its own source code from the cards:

    ... just to see if that was indeed what we punched out by accident, and sure enough. (Yes, there are easier ways to look at the source, LOL.)

    Fixed the HALT loop, changed around the memory locations, etc. One thing I was able to confirm for sure is that BigPrint clears all core memory when it runs. I imagine this is not necessary and I am going to try and see where this takes place and see if it is possible to change it so that: (1) it can be loaded into high memory "permanently" and not delete itself; and (2) not delete other programs that we intend to have also residing in high memory and avoid any address collisions.

    (Set Word Mark)

    This cheat sheet, by the way, is fantastic:

    ~Samuel Plainfield

    Re: 8/30/2023 (Software) Restoration~ from Jack Ghiselli/B>

    Hi Samuel,

    The BigPrint program decks we use at CHM were created using ROPE, and specifying memory clear for a 16K machine. The Autocoder assembler in ROPE creates a 3-card loader at the beginning of the output object deck. You can see it in the Autocoder listing. Here's an example:

    The yellow highlighted area is the Clear Storage routine. You can see it starts clearing at 1401 Core Storage location "I9I" (15,999). You can take an existing CHM demo object deck (such as BigPrint) and patch this card (Card #2) to start clearing at a lower core address, leaving higher core un-cleared. That's what you want to do if you're starting with an object deck.

    If you're starting from scratch, by using ROPE to create and assemble an Autocoder source deck, you have other options. IBM's Autocoder reference manual is this one:

    You can find this manual on BitSavers, or probably on Ed Thelan's extensive archives. Or there might be a copy kicking around in CHM. Buried in that manual is the fragment shown below, a description of how to code your Autocoder Source deck card #2 (CTL). You can see an example on the listing fragment above (just below the JOB card).

    Most of the ROPE-created demo decks we use at CHM (such as BigPrint) were assembled for 16K machines, since that's what we have. However, if you specify CTL values properly in your Autocoder source, ROPE's Autocoder will create your three Clear/Loader cards to start clearing from a lower-than-15999 address. Then you won't have to patch your output object deck.

    Ain't this fun?


    CHM IBM 1401 Demo Saturday, 8/26/2023
    11:00 AM - from Jack Ghiselli
    On Saturday, 8/26/2023 at 11:00 AM Larry Hara and I gave the IBM 1401 demo to 53 visitors, plus mini-demos to 20 more who wandered in before or after. We had a whole lot of international visitors, from Algeria, Chile, Finland, France, Germany, Greece, Ireland, Israel, Japan, the Netherlands, Mauritania (wow!), Spain, and the UK.

    We ran the demo on CT, which generally operated well. We had one CT1402 refusal to read (with no error lights on the 1402) in the middle of loading a deck, but were able to reset and reload successfully. We had one CT1402 reader card jam, requiring us to open the CT1402 and remove the read brushes and center unit to remove the card. Subsequently, the CT1402 ran OK. 729 Tape #1 (left-most) was dialed NOT OPERATIONAL, but Tapes #2, #3, and #4 ran fine with the TAU.

    Since we were a little worried about the CT1402, we powered up DE as a potential demo backup. the DE1402 ran fine, but the DE 729 tapes would not run under TAU control. In the actual demo, CT ran fine, so we did not need DE.

    The 083 Card Sorter and all three 026 Keypunches were operational, although K/P #1 (furthest from the closet) still sometimes fails to register the card at its Read Station, and has to be helped by hand.

    The audio mics displayed the chronic problem of Mic #2 being too soft, and we solved it with our familiar technique of turning Mic#2 volume all the way up, turning Master Volume up a few notches, and then turning Mic#1 down far enough to prevent squeal. With this setting, the mics worked OK for the demo.

    Jack Ghiselli mobile 1-408-839-1051

    1:00 pm - from Stephen Madsen
    Scott Stauter and I demonstrated to 45 guests. There were some from Virginia and Georgia. A woman from Virginia said she is head of ARPA H (health).

    Keypunches: We used the middle one. The one farthest from the closet does not register properly sometimes.
    Sorter: Worked OK.
    Microphones: Surprisingly worked OK.
    We used CT. 729 #1 is INOP.

    Stephen H. Madsen

    IBM 1401 Special Demonstration 8/26/23 2:30 PM - from Larry Hara
    On Saturday August 26, Sam Plainfield and I gave a 1401 Demo to 43 visitors plus an additional 12 who wandered in afterwards. They included visitors from the Bay Area, NJ, Ireland and the UK.

    Unit record machines

    • The read station of keypunch machine #1 (farthest from the closet) had periodic issues of not advancing the card from the punch to the read station, so during the demonstration, Sam used keypunch #2.
    • The 083 sorter worked very well. Thanks to Sam, there was a wonderful distribution of colorful punchcards when set on column 25.

    CT 1401, 1402 & 1403

    The 1401 worked fine.

    We encountered intermittent card read problems with the 1402 earlier in the afternoon but it seemed to work properly and settled down. As a backup, we had DE set up and were prepared to switch to this machine if we encountered repeated and/or unsolved problems with CT during the demo. Fortunately, we had no problems and continued using CT.

    The 1403, as usual, worked very well.

    CT 749 Tape

    Unit #1 (farthest to the left) was inoperable but the remaining 3 worked flawlessly.

    A/V system

    By carefully balancing the volumes of Mic 1, Mic 2 and the Master, we were able to successfully use both mics during the demo. No feedback/screeching!


    3:30 pm Bonus 1401 Demo Report - from Samuel Plainfield
    Paul Laughton & I gave a bonus 1401 demo today at 3:30p to 15 guests and 6 more afterwards. Most guests were local except for one couple from Indonesia.

    Earlier in the morning I prepared a sort deck that is just large enough and whooshes cards-to-and-fro. Simply sort on column 25 and it makes for an excellent presentation for the guests. Some cards keep going (randomly) into the Reject stacker and I cannot figure out why as they most certainly have punches in relevant columns. Maybe the lone brush needs some fine adjustment -- I'll try to do this with Frank on Wednesday if he's in.

    The microphones miraculously worked perfectly for the duration of our demo ... but this is due to luck as it was hit or miss earlier in the day. As Jack jokes: "our 60 year old computer works well, but our two year old microphones ... not so much." I spent some time with the portable mic and I still can't quite figure out how to adjust the volume very well. When plugging in the headset, be sure to use the side that has the microphone icon and not the side with the headphone jack icon. This could prove frustrating and easy to miss when in a panic to fix a mic problem mid-demo, so get it set up in advance.

    CT729 #1 is still INOP, 2-4 worked well.

    029 furthest from the closet is not feeding cards so I shut it off for the demo as it is also still rattling rather loudly.

    CT1402 is exhibiting some curious behavior with respect to crushing guest cards (the "adequate media") and requiring a manual removal. I can probably re-create the issue on Wednesday and hopefully we can figure out what is causing the jams. The cards become completely crushed in the second clutch cycle, necessitating: (1) removing the second set of brushes (read) and the card detector plate (I forget what that is called) and either removing the card right there or manually tripping the clutch to remove the card by feeding it through. Most of the time, though, it works well -- until the occasional guest card gets smashed during a one-off cycle.

    DE1401 worked well, I did not attempt to make use of the tape drives there.

    ~Samuel Plainfield

    IBM 1401 Demo Status - 8/23/2023 - from Pat Buder
    also, Re: Rolffson's 3D 1401 CGI simulation (was Re: Has anyone run this Autocoder program on the CHM machines? August 23
    IBM 1401 Demo Status - 8/23/2023 - from Pat Buder
    On Wednesday, 8/23, Jim Maurer and I gave the demo to 53 guests from China, Taiwan, Argentina, Canada, and the states. Another 42 came by before or after the demo.

    We ran on CT which generally ran well. We used tapes #2-#4; #1 was marked INOP. We did have a BigPrint deck that refused to start loading. Switching to another deck solved the problem. I later noticed that the first card of the failed deck was one of the "adequate" cards that had been duplicated. As we know, we should be using good NOS for this. We also got a reader check about 2/3 of the way through reading the program, but this cleared upon reloading. Powers of 2 ran fine.

    Keypunches #1 & #3 were usable. After the demo we noticed that KP #2 was printing somewhat lightly. Before the demo I had a discussion with Frank King regarding the ribbon reverser issue. While we can manually toggle the ribbon reverser to bypass the problem, Frank explained the end of ribbon fastener issues they are addressing.

    The 001 and 083 sorters worked well.

    The audio system worked acceptably for us. Literally 2 minutes before demo start Albert (A/V contractor) walked in. I had a brief discussion with him. He said he would be returning on Friday to work on the A/V system.

    As usual, thanks to the restoration team for all their hard work.


    Re: Rolffson's 3D 1401 CGI simulation (was Re: Has anyone run this Autocoder program on the CHM machines? August 23
    Hi Robert,

    I put Michael Schütz's Divide program into ROPE, assembled and ran a simulated execution. Unsurprisingly, the output (attached) looks like his. I am too lazy to hand-code an object deck on the keypunch, and Marc is still working on our CHM 1402 Punches. So, I can't yet run it for speed testing on CHM's actual 1401. Perhaps in the near future.

    Mit freundlichen Grüßen,


    Jack Ghiselli mobile 1-408-839-1051

    Hi again Robert,

    Today was a short opportunity when CHM 1401 hardware was available. I took the ROPE object file from Michael Schütz's "Divide" program, and punched it into actual cards at CHM.
    Then, I loaded and ran the program on an actual 1401. The printout is identical to Michael's, of course. See attached photo. The computation took about 3.5 seconds, measured with a stopwatch from printing the "Hello" message to starting to print the resulting quotient. We could get a more accurate timing by programming a loop and doing the calculations several times, but that's probably not needed.

    It's nice that the CHM has two 1401s. Today, our Connecticut machine refused to cooperate. But the program ran fine on our German machine. Do you suppose Michael put in some secret German-only code?


    Jack Ghiselli mobile 1-408-839-1051

    Restoration Report for Wed. 08/23/2023
    from Marc Verdiell
    I worked on the punch unit that had been taken out from the DE (?) 1402. It was reported that punch 80 sometimes double punched (if it had been activated in one row, it would punch another hole in the next row too). This could be explained by an interposer link not returning freely. Sure enough, all the interposers returned freely except for the #80 interposer, which had its setting link catching sometimes.

    You can see the link (the protruding triangular black metal part) has burrs that rubbed and scored the shiny metal retaining plate next to it, which caused them to sometimes lock into each other. That could explain the reported behavior.

    I disassembled the punch one step further, which is pretty tricky. I like the part where they tell you to use a rubber band to prevent the interposers from flying out, but give you not idea how to put it on nor how the links would fly out. At least I had been warned.

    I filed the offending burrs the best I could. I did not have the best micro files nor burnisher on hand, so I’ll work on it some more with the correct tools next week. But it seemed to have removed most of the catching.

    I put the punch back together in a safe state. I’ll do the fine burnishing next time, then a few critical adjustments have to be checked after the punch is put back together, then we can try it in the machine.


    from Samuel Plainfield
    Today, John and I plugged away at attempting to punch out a custom deck of a "high-core" Lincoln that John modified (recompiled) to make use of our fully loaded, maxed-out-memory 1401s!

    (John checking the code in various address spaces from the test output decks)

    The idea is that once you load up these custom decks, then the address is "permanent" and can be called up at any time without any need to load up the actual card deck and won't be overwritten. We used Stan's "server" program and then had several failed punch attempts. (Note: we need a backup of this server deck). Sometimes the program would punch way too many cards and it was unclear what it was punching ... other times it would punch and then stop mysteriously midway. Although we figured out that maybe there was a punch check that we didn't notice ... so, it is unclear if it was completely user error or not. Eventually, John had to go, but I stayed to continue testing the resulting deck -- with success!

    I ran it on DE and it loaded up successfully. John attempted to modify in a "start" loop after the final HALT, so that the program could continuously print by simply hitting START, but it doesn't work as intended and still needs to be debugged. For now, the operation ends and you must start reset and then press START. Not a big deal, of course, but not the intended operation.

    So, as of this moment, you can boot up the DE1401, navigate manually to address 14355 in high-core, switch the CPU to ALTER, hit the Instruction Register button, press START to load the address, switch to RUN mode, engage the printer, then press START and a Lincoln should print immediately. So long as nobody "formats" the core memory -- this should work indefinitely. I am hopeful more decks are to follow.

    In the meantime, Ken is taking on the task of reverse-engineering Robert's new plugboard. I suspect it'll only take him twenty minutes or so ;)

    ~Samuel Plainfield

    from Ken Shirriff
    received Friday, the 25th
    I looked at the bad tape down motor on DE #3. With the motor disconnected, I measured the resistances between the phases: 6 ohm, 6 ohm, and 9 ohm. For comparison, on a good drive, the resistances are 260 ohm. This would explain why the motor has a 50A spike that trips the circuit breakers. It doesn't explain why the motor has all three phases shorted, which seems like a strange failure. One hypothesis is that it got shorted by magnetic clutch particles, which are covering the surfaces around the motor.

    Removing the motor is somewhat tricky, so I'll leave that to Marc since he went through a similar process to remove the clutches. I loosened the four bolts that clamp down the motor, but that didn't seem to help at all.


    from Allen Palmer
    received Saturday, the 26th
    to Ken,

    if you have magnetic clutch powder covering the motor then you also have a clutch problem. You need to pull the clutch assembly and you should be able to see which clutch is leaking. You need to pull, open the clutch and reload the powder. The powder leak is most likely from the area shaft passes through the clutch in the front area of the clutch. There is a ‘felt not really felt) wash between the powder area and shaft.

    Allen Palmer

    Not strictly a report, but historical background for the IBM 1401
    Robert Garner has purchased a plugboard for the IBM 402
    from Robert Garner
    1401 crew,

    For years, some of you have said that it would be befitting if we had an IBM 402/403 Accounting Machine plugboard available to show visitors what "programming" was really like before the “stored-program” 1401.

    Your wish has materialized. :)
    This week I procured a vintage, 70-year-old, maddeningly wired 402/403 plugboard from an eBay vendor, photos:

    When I asked the seller (ARG-Tech, Indiana) for the story behind it, he replied: "It was given to us by a lady who worked for a company in charge of payroll. She was very proud of it and told us all about her time there. Thank you so much for sharing the [1401 website] link and so excited it will be shown for others to enjoy. Thank you so much!”

    I’ll bring the treasure in this Wednesday,

    — Robert

    p.s. I have no clue how to wire up such a thing. I’ve even tried to read/grok the 402 manual.

    this triggered maybe eight responses from "old timers", reminiscing

    Here are a few links about the IBM 402 Accounting Machine

    A formal write up

    Four restorers visit a working, in service, IBM 402 Accounting Machine, July 2010

    From BitSavers

    Demonstration Reports for week ending Saturday August 19, 2023
    from Pat Buder - IBM 1401 Demo Status - 08/16/2023
    received Saturday August 19, 2023
    On Wednesday, 8/16/2023, Duane Sand and I gave the demo to 63 visitors from Canberra, Australia; UK (who used to work at Bletchley); France; Korea; China; and various US states. Another 30 dropped by before or after the formal demo.

    Many visitors used the 001, including one woman who artfully punched her name with spaces between the letters. She was crestfallen when I explained that BigPrint wasn't designed for that. She then retyped her name in the normal fashion on an 026. All 026s and the 083 ran fine.

    We ran on CT, which performed well. During the demo we loaded BigPrint and its name cards. The 1402 read all cards perfectly. We only used tapes #1, #2, and #4; drive #3 was marked inop. Only #2 went into high speed rewind.

    New docent Michael Lenihan dropped by after his Revolution tour. He expressed interest in joining the IBM 1401 Restoration Team. I gave him Robert Garner's email address. Later Robert told me where his business cards are located: in a box in the rack in the A/V closet.


    from Stephen Madson - IBM 1401 Demonstration Saturday 8/19/2023 11:00 am
    Peter Chang and I demonstrated to 29 visitors plus five more after the demo. International visitors were from Brazil and France.

    Keypunches: Worked OK
    Sorter: Worked OK
    Microphones: Worked OK. We checked all the settings.
    CT1402: We had multiple reader checks. We tried re-try, re-start, other decks. We finally got a BigPrint program to load and left it running for the demonstration. After the demonstration Jack Ghiselli was able to clear the reader. Then it worked OK. I will let Jack report on what he found.

    Stephen H. Madsen

    from Jack Ghiselli - CHM 1401 Demo 8/19/2023 1:00 PM
    On 8/19/2023 at 1:00 PM, Scott Stauter and I gave the 1401 demo to 58 people, plus 47 (wow!) who wandered in afterwards. After powering off, we powered back up twice for visitors who REALLY wanted a card. In addition to visitors from around the USA, we had international visitors from Canada, Dubai, France, Germany, Israel, Italy, Japan, Korea, and Switzerland.

    We used CT, which generally performed quite well. When we checked in with the morning team after their demo, the CT1402 was getting READER CHECK errors. Eventually, an input card jammed in the read mechanism and turned on all the CT1402 reader error lights. We opened the CT1402 and removed both sets of read brushes and the thingy (technical term) between them. Then we were able to remove the jammed card. In the process, we found a small wad of blue paper-towel material which fell out of the mechanism, which might have caused the original problems. See attached photo.

    Scott arrived to help reinstall the read brushes, and declared them correctly seated and locked. During our demo, the CT1402 worked flawlessly, without any more READER CHECK errors.

    The CT1403 is leaking lubricating oil on the floor. Scott insisted we report this, although it's a chronic condition.

    We demonstrated all four CT 729 Tape Drives. All worked flawlessly with the TAU, and all executed high-speed-rewind correctly. Tiny note of no importance to the demo: CT729 #2 has its FILE PROTECT lamp burned out.

    NOT during the demo, we tried to run the Tape Exerciser RON 2.1 on the CT tapes. The program "hung", but as in the past we didn't have enough time to investigate. The tapes seem to have problems responding to software control, but demo great with the TAU.

    We were able to use all three 026 Keypunches, a good thing given so many visitors. KP#1 (farthest from the closet) did jam one card in the input feed, but we were able to remove it with pliers and continue visitors punching cards. KP#1 erratically did fail to register the card at the punch station or the read station, but pushing the card along with a finger recovered. KP#2 has very light printing, but only at ribbon reverse -- the rest of the time it's fine. The 083 Card Sorter worked fine.

    Audio microphones: Per Jon Plutte's recommendation, we checked both microphone transmitters to be sure the side switch was NOT set to -10dB. It appears that this slide switch has THREE positions: -10dB, 0, and "mic". I think we had both switches set to "mic". Nevertheless, the mic#2 level was too soft. Our fix was to turn the mic#2 level switch in the audio panel all the way up, and advance the Master Volume a couple of clicks. Then, mic#2 was audible. See attached photo of our panel settings.

    The morning team had reported that one of the BigPrint decks (#4) seemed always to get READER CHECK errors. We tried it and agreed -- always a READER CHECK on card #2. We duplicated a new Card #2, and BigPrint #4 runs OK now.

    Jack Ghiselli mobile 1-408-839-1051

    from Marc Verdiell - advise against using Ron’s tape exerciser
    Thanks for the report. I would advise against using Ron’s tape exerciser without having a good reason to do so. It writes really small records, goes back and forth, generally stresses the tape drives and prolays, and wears out the magnetic tapes. Well, it’s a stress test. We are acutely aware that the tapes don’t read and write properly, and we don’t like it either. We will get to it eventually.

    Restoration Report for Wednesday 08/16/2023
    from Ken Shirriff, about DE tape #3 tripping circuit breakers
    coments from several restorers
    from Ken Shirriff, about DE tape #3 tripping circuit breakers
    I looked at the DE tape drive #3 that has been tripping the circuit breakers. Using David's fancy current probe, I measured 50 A through the circuit breaker, tripping it in 5ms. (I don't guarantee that I'm reading the value correctly; I should probably calibrate against a working 729.)

    CP9 and CP10 trip simultaneously. After deciphering the schematic, the problem is the Tape Take Up motor, a three-phase 208V motor. (This motor turns the reels in opposite directions to load tape into the columns during loading and pull tape out of the columns during unloading.) Relay 7 swaps phase 2 and phase 3 to reverse it. CP9 and CP10 protect phase 2 and 3 respectively. So it appears that when the motor is activated, it draws way too much current, tripping both breakers. Frank and I turned the motor by hand and it turns freely. (There's a lot of gunk on the gears and shaft, probably clutch powder, but it doesn't seem to be causing friction.) I disconnected the motor and fed the tape into the columns manually and the drive works fine, so this motor is clearly the problem. Frank and I measured the motor's resistance last week and it didn't seem shorted.

    My hypotheses:

    1. The motor is bad and needs to be replaced.
    2. The motor is okay but something (clutch? friction?) is putting too much load on it.

    It seems most likely that the motor is bad. If I could disconnect the motor from the gears, I could see if it runs or not. The motor is way at the back, with worm gears attached. I don't know if the whole frame needs to be removed (like when Marc fixed the clutches) or if there is an easier way to get the motor out.


    from Merc Verdiell, received Thurs Aug 17
    50A in a brushless AC motor that’s still moving OK? I’d think you have a short in a cable or a cap leading to the motor.
    from David Clementson, received Thurs Aug 17
    Yes a cap indeed. From the napkin:

    50A x 5ms = 0.25 coulombs ESR = 200V / 50A = 4 ohms

    Seems reasonable for a motor-related cap. But if such a cap were part of the original design, it would guarantee a popped breaker every time. Maybe there is a cap with a series resistor (like an EMI snubber) where the resistor has become shorted.

    With the motor unplugged and isolated, you could try putting an incandescent light bulb in series with each winding and applying a 50/60Hz AC line voltage. The bulb brightness will give an indication of the steady-state current the winding would actually draw, independent of any back EMF caused by motor rotation. Using different bulb wattages you can narrow down the actual power draw. I have a rig with an isolation transformer, a Variac, and switchable series bulbs that I can bring in if you want to try it. Let me know. But don't tell anyone because incandescent bulbs are now illegal!


    from Ken Shirriff, received Thurs Aug 17
    Here's my math on the current probe. I had it on the 10mV/A range. I plugged it into the scope and put the scope on 1x input. The scope showed 500mV. So I think that works out to 50 A for 5 ms, but I wouldn't be surprised if I got an order of magnitude wrong somewhere. I should probably redo the measurement on a good tape drive to see what the current is supposed to be.

    I unplugged the flat cable between the motor and the AC connections and the breakers did not trip. With the motor plugged in, the breakers trip, so the problem is in the motor. The cable goes directly to the motor; as far as I know, there aren't any capacitors in the motor, which is 3-phase, 220 V, 50 Hz. There are RC snubbers across the relay contacts, but those shouldn't have an effect.


    from David Clementson, received Thurs Aug 17
    Hi Ken:

    I concur with your interpretation of the ammeter scale factor. I also agree that it looks like the motor may have developed an internal short, possibly a short from a winding to the case. You might be able to use a 4-wire ohmmeter to prove it by comparing readings to a known good motor. I have such a meter (HP3478A), so let me know if you want me to bring it in. Incidentally I will not be able to make it to the museum next week, but if you do want the meter, I can leave it in the workshop for you over the weekend.

    BTW it just now occurs to me that the 5ms current pulse duration likely represents the circuit breaker’s reaction time. The shorted motor draws 50A but the current drops to zero when the breaker trips. Duh.


    IBM 1401 Demonstration Saturday 8/12/2023
    Microphones ordered by Jon Plutte arrived "just in time"
    11:00 am - from Stephen Madsen
    Peter Chang and I demonstrated to 43 visitors from France, Spain, and throughout the USA.

    Keypunches: Worked OK.

    083 Sorter: Worked OK.

    CT: Worked OK. We were able to run BigPrint without any reader checks, Yay! Thank you, restoration team for your persistent and expert efforts to get the CT 1402 working again! The logistics of the demonstration work much better when we can use CT. Thank you again!

    Microphones: I got the new microphones from Jesse. We used two new ones. The other four are stored in a box in the 1401 closet. We had trouble with microphone #2. It worked before the demo. During the dem it worked sporadically.

    Stephen H. Madsen

    1:00 PM - from Jack Ghiselli

    Larry Hara and I gave the 1401 Demo Saturday 08/12/2023 1:00 PM to 58 people, plus mini-demos to another 29 who wandered in afterwards. We had visitors from around the USA, and international visitors from Canada, China, Costa Rica, France, India, Italy, Japan, South Korea, Taiwan, Turkey, and the UK. Larry was able to converse with our Japanese visitors in Japanese, which impressed me.

    We ran on CT, whose 1402 Card Reader has newly been refurbished by Dave Clementson and Samuel Plainfield (Yay, Restoration Team!). We did get several READER CHECK errors, but nowhere near as bad as before the refurbishing, and these seemed mostly to occur on cards punched using our "adequate but not REALLY good" newly manufactured card stock. Dave Clementson had warned that this might occur. We also had two instances of a read error I personally had never seen before: In the middle of loading a card deck, the CT1402 would read one card into the mechanism and then refuse to read the following card. The CT1402 sat there, with NO error indicated and motors running, but refused to pick the next card in the hopper. We recovered both times by using NON PROCESS RUNOUT to run out the one card (not the expected two cards) in the mechanism, pressing CHECK RESET (to clear the READER STOP that RUNOUT caused), reloading the hopper starting with the card from the mechanism and pressing CT1402 START. Of course, we were running with I/O CHECK STOP ON (Normal) on the 1401 front panel. Despite these problems, we were able to demo both BigPrint and Powers-Of-Two successfully. It's really nice to be back on CT. Thanks again, guys.

    Before the demo, we decided to investigate the status of the CT729 Tape Drives. So, we ran the Tape Exerciser (RON 2.1) on all four tapes, to see how they ran with actual software control.
    We set Tape Drives #1, #2, and #3 to the recommended LOW DENSITY. However, Tape #4 refused to switch and remained on HIGH DENSITY.
    We ran the program successfully until Tape #3 reached End-of-Reel, and then the program hung, on a Branch instruction which we think was conditional "Branch on End of Reel". Since the Demo time was approaching, we didn't have time to investigate further. We manually rewound Tape #3, switched it to NOT OPERATIONAL, and ran the demo using the TAU on the other 3 tapes. We suspect that Tape #3 would also have run with the TAU, but we didn't want to risk it. Tape #3 is the drive with its Read/Write Head cover removed.

    After the demo when visitors temporarily cleared out, we decided to try to punch a new copy of BigPrint using our "Excellent" quality card stock from the back room and see if that would make READER CHECK errors disappear. Unfortunately, we got a series of CT1402 PUNCH CHECK errors, and more visitors wandered in, so we abandoned this effort. As time permits, we hope someone can look at the 1402 Punch unit on both CT and DE. These DO NOT cause problems for the demos, so it's low priority -- we'd just like to punch some new decks.

    All three 026 Keypunches and the 083 Card Sorter worked flawlessly, K/P printing is very good, so thanks to whoever inked the ribbons.

    After the demo, we found that several of our demo copies of BigPrint and Powers-Of-Two were scrambled. Depending on the deck, cards were missing at the front, at the back, or in the middle. One object deck had an incorrectly-duplicated card, where some of the data was missing (we always recommend after duplicating a card on the keypunch you hold the two cards up to the light and see if any holes are missing). This situation is probably caused by demonstrators frantically attempting to recover from Read Errors, and incorrectly reassembling the decks. Larry and I carefully investigated, ran VOBJ, and corrected and verified four BigPrint Decks (#1, #2, #3, and #4), and two Powers-Of-Two decks. We marked them "GOOD as of 8/12" and left them in the demo trays, ready for the next demo. I think some additional training for demonstrators on card read error recovery would help. Larry is getting REALLY GOOD at it.

    The new audio headsets which Jon Plutte provided worked great! Yay, Jon! They actually fit over your ears and the mic doesn't flop around. The morning demo team reported problems with Mic #2, but it worked well for us. We did find the chronic audio-levels problem: Mic #2 was too soft, so we set Mic#2 level all the way up, increased MASTER VOLUME up a little, and set Mic #1 level lower to stop the squeal. With these settings, the audio was fine for the demo.

    Jack Ghiselli mobile 1-408-839-1051

    from Robert Garner


    > Larry and I carefully investigated, ran VOBJ, and corrected and verified four BigPrint Decks (#1, #2, #3, and #4), and two Powers-Of-Two decks.
    > We marked them "GOOD as of 8/12" and left them in the demo trays, ready for the next demo.

    This is fantastic and thankless house keeping. Your VOBJ program is a gold star!

    Let's also make sure, for the demo and program decks, that we only use the period-IBM-card-stock-based (5081 style) cards, and not the "adequate but not really good" newly manufactured cards from TimeCardsUSA. This could easily happen when duplicating a single card.

    The new cards seem acceptable for single-use name/date cards, but not for repeated reading of program decks. The new cards are slightly bowed and slightly slippier than the official card paper stock (and we don’t quality sample them for variations in thickness. Note: there is a micrometer in the workshop...)

    We’ll be making a trip to the warehouse in the next couple of weeks to retrieve several boxes of the "really good" 5081 cards. (John and Sam were hoping to do so last Thursday, but Aurora noted that: "The punch cards are up in the steel and will not be available Thursday. I am in the process of scheduling some forklifting in a couple of weeks and will add the punch cards to my to-do list.” Aurora —> Thanks!!)

    I can’t praise and thank you and your demo team enough for your amazing and top-notch “1401 demo lab prowess!" :))


    — Robert

    Restoration Report for Thurs. 8/10/2023
    from David Clementson, Frank King says we have a picker knife go/nogo gauge.
    Jon Plutte is ordering new microphones
    John and Sam and I met at the Yosemite warehouse and were able to pull two pairs of picker knives and one contact roller from a donor machine.

    After cleaning them , I was able to measure the knife step sizes. True to IBM's amazing design knowhow, the knife assemblies were apparently designed for inspection: they have features in the support casting that allow them to sit flat on a surface plate. A test indicator can then be used to show the step height of the actual knife "blade."

    One set showed little wear, and had a step height of about 0.0044". The other set had signs of wear on its corners, and had a step of about 0.0040". Both sets had good step height matching within the pair., within 0.0001".

    I'm not sure what the wear limits are for these parts, though. Anyone?

    A big shout out goes to Aurora for generously taking time out of her day to assist us with this!


    Bottom of the step, reading set to = "0"
    Top of the step, reading = 0.00044"

    Frank King says we have a picker knife go/nogo gauge.
    Received Sun Aug 13

    Dave, I am glad you were able to get some picker knives. You may not be aware that we have a go, no go gauge in the special tools drawer of the big red tool box to the left of the circuit breaker panel in the Liebert room. It is about 1” by 1/2” square. After you find the go, no go gauge, with the dial indicator you should be able to tell the wear tolerance.

    When adjusting picker knives, I never had a dial indicator. And after IBM came out with the fixed settings only on the old machines, was it necessary to make the adjustment.


    IBM 1401 Demo Status - 8/9/2023
    from Pat Buder
    On Wednesday, 8/9/2023, Jim Maurer and I gave the demo to 38 visitors from Korea, Japan, and China. Another 35 came in before or after the demo.

    We were running on DE before the demo. It had reader checks and the punch check problem. This meant that several guests got tired of watching us struggle with the reader and left without their BigPrint listings.

    About 20 minutes before the demo the restoration team informed us that the CT 1402 was fixed. This was very welcome news indeed. Kudos to the team for their skill and persistence in fixing the problems. We used CT for the demo and the 1402 read cards flawlessly. Yea!

    We only used tapes #1 & #4 for the demo. #4 did the expected high speed rewind, but #1 did not.

    All three 026s, the 001, and the 083 worked well.

    Sometime later in the day there was an audible alarm on the Leibert air conditioner. The panel had an over temperature message.

    We're sure glad to be able to do demos on CT again. It's been so long that we forgot which floor tile to remove to show the cables underneath. (It's the one closest to the 001 wood stand.)

    All in all, a great day.


    from Jim Maurer

    One additional thing happened at yesterday's demo. I was trying to adjust the #1 mic so the microphone was near my mouth and the wire broke. I shouted instead. So we're down to just one usable mic.

    Jim Maurer

    Restoration Reports for Wednesday 08/09/2023
    from Ken Shirriff and others. from David Clementson
    from Ken Shirriff and others
    Mostly tape drives. All four CT drives work from the TAU, although #2 sometimes doesn't respond.
    I ordered GE 55B2 lightbulbs, replaced the Select bulb in DE #1 and it lights up now.
    I couldn't reproduce the reported problem with DE #2; it does high-speed and low-speed rewind correctly.

    DE #3 still has fuse problems. I looked at the problems with Frank but didn't resolve anything. There are two problems. First, CP#4 has been randomly tripping for several weeks. Second, CP#8 and CP#9 repeatably trip as soon as you try to load a tape.

    First CP#4. There's a label saying to check the Power Factor capacitors for a short, so I figured I should do that. (I just noticed that #4 is crossed out and replaced with #3.)

    I had to search all over to find the capacitors. The manual gives no clue as to where they are. Note that there are a lot of wires on TB7-4, TB7-6, and TB7-9.

    It turns out that there is a large metal can that contains the three capacitors in one unit, behind a panel on the side of the tape drive.

    The capacitors are wired to TP 7-4, 7-6, and 7-9 along with many other wires. I removed the capacitor wires and checked with a voltmeter and I didn't detect a short. (I couldn't check in-circuit, since everything goes to transformers and has about 1 ohm resistance to everything else. So there's an intermittent problem but it doesn't seem to be the capacitor. I don't know what the problem is; it could be the circuit breaker.

    The second problem is CP#8 and CP#9 repeatably trip when loading a tape. The problem seems to be the tape down motor, which rotates the tape reels during loading to lower the tape into the column. Unplugging that motor prevents the circuit breakers from tripping (but of course the load doesn't proceed). This motor is in the depths of the tape drive. Maybe Marc can remove it using his skills from taking out the clutches. I'm not sure how to test this motor. It's unclear why this motor trips two circuit breakers.

    Finally, DE was giving punch check errors when reading, as it has done before. It's unclear how you could get a punch check during a read, so I was going to look at it with the scope. However, John glared at the card reader and the problem went away.


    from Stephen Madsen

    We have been having random reader checks and punch checks with DE1402 for a while. We have tried various things like non-process runout and restart. Glaring at it is a new technique that we will add to our tool kit.

    Stephen H. Madsen

    from Lyle Bickley

    FWIW, we on the PDP-1 Team have found that circuit breakers tend to "wear" in time and begin to "flip" before they reach their stated current limit.
    We've had to replace CB's in a two or three PDP-1 Power Supplies.

    When we observe a CB flipping, we now check the actual current flow before spending a lot of time trying to diagnose the problem in rectifiers, capacitors or ferroresonant transformers :)


    from Ignacio Menendez

    My 2 cents worth, on DE tape#3 tripping CPs #8 & #9…

    There is a possibility that after a long time, the worm gears of the motor and shaft, as well as the 2 clutches are dry caked in; this may place a heavy load on the motor…

    it would not hurt to clean out all the old grease and regrease these worm gears.

    Also oil the 4 bearings that the shaft goes through to get to the clutches.

    Just a thought.


    from David Clementson
    I think we can declare conditional success on the CT 1402 Reader Check error problem! I say conditional because it still is somewhat unaccepting of "bad" media, and still has the potential to generate Reader Checks in the future.

    We started the morning by attempting to view the common brush signal while running a "one-hot" deck. It turns out that my understanding of the common brush amplifier is incomplete, and that the common bruch waveform does not display any "signature" of the bruch connectivity. Bummer.

    But when we re-ran the "print all 5's" deck, it showed a rather dramatically improved output, only missing a few 5's here and there. We did get Reader Checks, though, and a scan of memory showed that the problem was coming from Brush #3 of Roller #1. I cleaned both rollers and reseated both brush interposer plates (the connectors that allow the brush assembly to be disconnected from the machine.) That seemed to eliminate both the printing errors and the Reader Check errors. We were able to run Lincoln and Big Print decks with no errors. So the machine is running way better than it did when we started this project. We left it in the hands of the Demo operators for further testing.

    We would still like to replace the cracked codewheel, so Marc agreed to push the order of new codewheels up his to-do list.

    Finally, John and I are off to Yosemite tomorrow to hunt for replacement picker knives.

    That's it for now. Next week, if the CT machine is stable we should consider going over the DE 1402 to perform basic adjustments and check its brush timing. Since it is not a solar cell machine, we will have to do some figuring out how to scope its brushes.


    Restoration Report for Saturday 08/05/2023
    - from David Clementson
    Sam ( Plainfield ) and I arrived at the museum on Saturday with grand plans to scope all 160 brushes. Naturally, the 1402 had other ideas.

    I wanted to try a new technique whereby we observe the voltage waveform of the #1 and #2 common brushes as they scan a deck where only one brush at a time contacts the roller. I used a keypunch machine to create an 8-card deck where each card had ten total punches, one in each of the 9-0 numeric rows. These punches were progressively offset on each card by ten columns so that when the whole deck is scanned, all 80 brushes are presented to the rollers one at a time and in order. In theory, we should (I hope) be able to carefully examine these common brush waveforms for evidence of poor brush contact, excessive brush bounce, broken or intermittent brush connections, etc. If we also print the deck contents, we should be able to see correlation between any misreads and dodgy brush waveforms.

    We attached the scope to the solar cell and clutch drive signals as usual, but connected scope channels 2 and 3 to the common brushes instead of the usual core brushes. However when we tried to run this deck using a simple read loop, the machine would either not feed at all, or would stop mid-deck, often on the second card. It would then generate a Reader Stop error.

    After (once again WAY too much) troubleshooting, we realized that the card media that is currently stocked in the keypunches doesn't pick well on this machine. Very often the pick knives fail to grab the first card altogether, or else they fail to grab a card mid-deck. The machine's generation of a Reader Stop error is just its way of telling us "hey, I just clutched a card in, and the hopper is not empty, yet nothing showed up at Card Lever #1. What gives?" I checked the knife "reach" (the distance the knife edge travels past the back edge of the card when it is up against the rear hopper posts) and all was in spec.

    When I flipped the test deck upside down (print side up), it ran normally. This tells me that either these cards have curled or soft or rounded edges (maybe a dull cutting die?) that the knives can't grab, or our knives are worn, or maybe both. The knives are made of an extremely hard material (tungsten carbide, I believe), but wear is not impossible. I'm imagining an edge interaction like this with the card in blue and the knife in yellow:

    This sketch is pretty much to scale, with the card edge radius of only 0.0015" and the knife wear radius of 0.001"

    So it might be a good idea to remove the knives for an intensive inspection under the microscope. It also might be a good idea to see if there are any other knife sets at Yosemite that might work better with this card stock. It may be possible to diamond hone the knives to restore their edge geometry, but that is a science project we should probably save until there are no other options.

    Unfortunately, we did not have time to do the actual brush scope experiment, but next week we should try again. But this time we'll use a new deck made with our very best card stock. Also, we should add two blank cards at the end of the deck so that the eight cards we are interested in all scan end-to-end for the benefit of the escope trace.

    That's it for now.


    later in the day, David added

    It turns out that picker knife wear is not only possible, but something IBM was aware of. Note the last sentence from this section from the 1402 CE Manual of Instruction:

    We should be able to make a fixture to measure the knife projection using a 'tenths' dial indicator, but we don't know what the wear limit is. It would be great to know what the original specification was, though. But a fixture would be useful to compare knives from different units so we can at least pick the ones with the least wear. Again, a trip to Yosemite may be in order.

    And Carboloy is indeed a tungsten carbide composite.


    and more

    Knife wear on our 1402s is apparently something we have encountered before. See this conversation from Wed March 21 2007:

    But at least I now know that the knife projection spec is 0.00425".

    Adding Grant since he was part of the prior discussion.


    CHM 1401 Demo Saturday, 8/5/2023
    11:00 AM - from Jack Ghiselli, comment from Paul Laughton
    1:00 PM - from Stephen Madsen
    11:00 AM - from Jack Ghiselli
    On Saturday, 8/5/2023 11:00 AM, Larry Hara and I gave the 1401 demo to 53 CHM visitors and attendees from the Vintage Computer Faire. We also gave mini-demos to about 20 people who wandered in before or after the main demo. We had international visitors from China, Finland, Germany, and Taiwan.

    We ran on DE, since the Restoration Team is still working on the CT1402.

    The DE1402 gave us a few READER CHECKS, but then worked well during the demo. Unfortunately at the end when we were loading BigPrint name cards, we started to get many READER CHECKS. Larry managed to retry until all the name cards had been processed, but we ran until almost 12:30 PM.

    The DE1401 and 1403 worked perfectly.

    DE 729 Tape Drives #2 and #3 were NOT OPERATIONAL for previously-reported reasons. Tape Drive #1 worked OK with the TAU, but instead of High Speed Rewind, it did a low-speed rewind all the way.

    All three 026 Keypunches, the 083 Card Sorter, and the 001 Manual Card Punch worked perfectly.

    Yesterday's failure of the A/V to get any sound to the speakers appears to have been a Lead Demo person failure (some guy named Jack). Today, Jesse Nichols made it work, and the A/V system functioned properly for the demo. Yesterday's problem seems to have been that I had failed to press an inconspicuous POWER button on the second rack (CROWN CDI 1000) above the RACK POWER switch. This panel does NOT power up automatically on a total rack power-up if this button has not been previously pressed. See red arrow below. When pressed, the bright blue POWER lamp on this rack should be on. and sound will travel from the rack to the speakers. Once pressed, the power button on this rack should stay on until pressed again.

    I think I will volunteer to improve our training document "CHM IBM 1401 Machine Operator Manual, Section 5: 1401 Demo Audio Equipment. Operator's Guide to the A/V rack", which currently does not cover this issue.

    Jack Ghiselli mobile 1-408-839-1051

    Jack Ghiselli talked with Lawrence Kesteloot about Laurence's Ray Tracing program.
    Lawrence used Ron Mak's "ROPE" to create and run the program.

    comment from Paul Laughton
    >" a Lead Demo person failure (some guy named Jack)"

    Don't beat yourself up. There were three Leads (You, Pat and Me) plus Samuel trying to figure this out. In my 10 years of giving demos and having power cycled to the whole console several times, I have never experienced this problem.

    1:00 PM - from Stephen Madsen

    Duane Sand and I demonstrated the 1401 to 50 visitors. plus 150 after the demonstration. Following the demonstration, we had a steady stream of visitors until closing time.
    • Microphones: Jesse found a switch that was off. Turning the switch on fixed the microphone problem. Thank you, Jesse.
    • Key punches: Worked OK
    • 083 sorter: Worked OK.
    • We used DE for the demonstration.
    • Tapes drives: Only one was working, and it worked OK.
    • 1402 card reader: We had occasional reader checks but were able to get past them and proceed. There are mysterious intermittent reader checks.

    Stephen H. Madsen

    CHM 1401 Demo Friday 8/4/2023 11:00 AM
    - from Jack Ghiselli
    Karen Sun and I gave the 1401 demo at 11:00 AM today to 30 visitors, plus mini-demos to another 50 who wandered in before and after. We had international visitors from Argentina, Bangladesh, Belgium, Brazil, Canada, China, France, Germany, Kuwait, Poland, Russia, Turkey, and the UK. Wow!

    We ran on DE since the CT1402 is still being repaired. The DE1402 gave us a few READER CHECK errors, but we were able to recover. DE 729 Tape Drive #3 is still INOP. Tapes #1 and #2 seemed to work OK during the demo, but when we did a high-speed rewind on Tape #2, it did not stop and ended with a bang and a tangle of tape. After the demo, we removed the tangle, snipped off about 40 feet of damaged tape, put on a new reflective spot, re-mounted the tape, and set it to NOT OPERATIONAL. We suspect this is the same problem we saw before with a fail of the optical sensor which is supposed to tell the drive when it's near the front of the reel. We made a bunch of demo strips from the discarded tape (Re-use, Re-Cycle, etc.).

    All three 029 Keypunches, the 083 Card Sorter, and the 001 Manual Card Punch worked perfectly.

    The Audio system failed completely. Both radio microphones showed that sound was reaching the audio rack (LEVEL displays showed that). But no sound came from the speakers from either of the two mics or from the video. We tried various level settings, re-booting, etc., but were unable to make it work. For the afternoon 1:00 demo, Pat used a belt amplifier and mic from the front desk. The rest of us just shouted.

    Also a shout-out to Dave Clementson and Samuel Plainfield, who worked all day trying to fix the CT1402. You guys are GREAT!

    Jack Ghiselli mobile 1-408-839-1051

    Restoration Report for Friday 08/04/2023
    - from David Clementson and Samual Plainfield
    , comments from Bhushan Mohan and Robert Garner
    Sam ( Plainfield ) and I were able to retime the solar/picker/camshaft with the clutch shaft. It was surprisingly easy:
    1. connect a scope to the solar cell's output and power up the machine
    2. manually advance the Dynamic Analyzer dial to put the machine at ~300 degrees
    3. manually trip the clutch and advance the machine until the clutch just engages
    4. confirm on the Analyzer dial that the machine is at 315 degrees, the correct clutch engagement angle
    5. continue to manually advance the machine to 13 degrees, the center of the 9 row read window
    6. loosen the clamp screws on the solar/picker/camshaft cog pulley
    7. using the slotted screw head at the front of the machine, rotate the solar shaft backwards (unlike the brushes, it is okay for this shaft to go either direction) while observing the solar cell output
    8. count (backward) the solar cell pulses until you reach the 9 row pulse. Stop rotating the shaft when the the solar cell in in the center of the 9 pulse
    9. tighten the clamp screws on the solar cog pulley.
    10. do a Non-Process Runout and use the Dynamic Analyzer to confirm that the solar pulses are at the correct angles

    Once the shaft was properly aligned, the Reader Stop errors on power-up ceased. Hooray!

    Next, we noticed that the Non-Process Runout process was sporadic and did not halt when the hopper switch was un-tripped after the last card. We traced this to a broken wire on the hopper microswitch, something that must have happened when the rollers were replaced. We re-soldered the wire, and the Non-Processes Runout started behaving normally.

    We then scoped the brushes and noticed that the Common Brush #2 signal was missing. After WAY too much troubleshooting, we found that the Card Lever #2 holder had not been fully seated in place. Once fixed, the brush timing waveforms all looked perfect.

    So we were able to run the "all 5's deck. No Reader Checks! We saw no evidence of any of the row errors that we think were being caused by slipping cards, but we did see the usual column errors that we think are caused by intermittent brushes. But then we knew that brush problems were waiting for us once the roller issues were resolved. So we'll start on that next week.


    comment from Bhushan Mohan
    Excellent work David. Our reader seems to have been finally fixed. Hats off to you and the team.
    I shall be in Bay area by the end of this month. Will definitely visit on the first Wednesday on reaching there.

    With best wishes

    comment from Robert Garner

    David, Sam, and 1402 crew,

    Congratulations on bringing our tired CT 1402 back from the dark side!

    It’s been an arduous journey and a marathon.
    Your persistence paid off and is much appreciated!

    — Robert

    p.s. It’s a good thing that we didn’t know what was lying in wait when you joined our team last year! :)
    Because the 1401 supports arbitrarly long numbers (up to 16K), we'll keep adding 0’s to your salaries for some time to come! :))

    from Samuel Plainfield

    The behavior that the 1402 was exhibiting was curious on two levels: (1) after the full re-timing, running a deck would behave consistent with a "last-read cycle after the hopper is empty, but cards remain in the transport" when in fact the hopper was not empty which I surmised could only happen if the machine was erroneously believing that the hopper was empty; compounded further by (2) looking at the 1401 console, the usual Instruction > B to > A register lights were not oscillating during the read cycles but only the logic data was updating.

    After we figured out that the second set of brushes (read) were not detecting any data, it made sense that the weird behavior we were seeing on the 1401 console was just the limited hole-count/sum logic of the first set of brushes (read check).

    (David soldering the errant hopper microswitch wire which is quite difficult to reach).

    In the morning, Eric came by and provided us a FORTRAN codewheel for the 026s and two boxes of pearl-fresh new-old stock cards for our object decks. I placed the boxes on top of the new card filing cabinet in the Liebert room where they ought not to be disturbed until ready for use:

    The green cards are originally from the Lick Observatory.

    ~Samuel Plainfield

    Restoration Status 08/02/2023
    from David Clementson, Paul Laughton, Ken Shirriff and Tom Szolyga
    from David Clementson
    • We were able to get new bearings fitted onto the 4102's two clutched drive roller shafts and get them reinstalled into the machine along with their pinch rollers. Drive Roller #1 has been fitted with "new" rubber rollers from a donor machine, a fix that we hope will eliminate the card slipping problem. Reinstallation was quite a time consuming process, and we finished just before the 3:00 demo. When we went to test the machine after the demo, it generated Reader Stop errors immediately and chronically upon power-on. We theorize that the clutched cam / picker knife / solar cell shaft is out of phase with the clutch shaft, since those cams are involved in the Reader Stop logic. This condition is to be expected when the clutch timing belt is removed. Unfortunately, we ran out of time trying to retime those shafts. Next session we will manually advance the machine to the proper 12 degree angle corresponding to when the first solar cell pulse should begin, loosen the clamp on the cam shaft's cog pulley, and rotate the shaft until the first codewheel slit registers on the optical sensor. Hopefully that will put the cams in the proper phase and eliminate Reader Stop errors, allowing us to fine-tune the timing with actual brush reads.
    • I was also able to deliver three freshly inked keypunch ribbons to the workshop, along with some homemade eyelets and a hole punch to cut eyelet holes in the ribbons. That stuff is together in a plastic bag on the main workshop bench.
    That's it for this week.


    from Paul Laughton
    It would be really great if CT could be fixed by Friday. We are expecting many dozens of guests from the West Coast Vintage Computer Faire. The Faire is taking place on Friday and Saturday.


    from David Clementson


    from Ken Shirriff

    My status:
    The select light on DE#1 tape drive was burnt out, but I couldn't find a replacement in the workshop. We have dozens of bulbs, but I couldn't find this one. Should I order some or is there a secret stash? This is a GE 55C, 55V 50mA T2 wedge.

    Coincidentally, the manual says not to use 55C because they don't last as long. But 55C are easier to find than 55B.

    The other interesting thing I found is related to last week's problem with the tape drive doing a high-speed rewind out of control. It turns out that if the tape sensing bulb burns out, the 729 has a safety feature to prevent high-speed rewind. But if the light is obstructed by a sticker (as was the case last week), the safety feature won't help :-)


    from Tom Szolyga

    Today I completed the Interface board between the 1401 and the Arduino/PC. Its power supply is the bottom board and the interface electronics are the top board. Next step is connect It to the 1401 and to the Arduino.

    Best regards,

    CHM 1401 Demos Saturday, July 29, 2023
    from Stephen Madsen and Jack Ghiselli
    from Stephen Madsen, 11:00 AM Demo
    Peter Chang and I gave a demo to 63 visitors. We had visitors from China, Russia, and throughout the USA.

    Keypunches: The center one has faint printing.

    Sorter: Worked fine.

    DE 1402: When we first tried to load BigPrint, we had a punch check. We were able to recover and proceed.

    DE 1403: The supply of printer paper is running low.

    Stephen H. Madsen

    from Jack Ghiselli, 1:00 PM Demo

    Jim Maurer and I gave the CHM 1401 Demo Saturday, July 29, 2023 1:00 PM to 62 people, plus mini-demos to another 15 who wandered in afterwards. We had visitors from all over the USA, and international visitors from Argentina, Brazil, China, Germany, India, Japan, Korea, and New Zealand.

    We ran on DE, which performed well. The DE1402 got a few READER CHECK errors but we were able to recover and continue. The DE1403 was almost out of paper, and there was no additional supply in the back room. So, we swapped the almost-full box from the CT1403 for the almost-empty box from the DE1403. DE 729 Tape Drives #1 and #2 performed well (#3 is down for repairs). All three 026 Keypunches and the 083 Card Sorter worked well, although KP #2 printing is a little faint. The Audio Microphones worked great.

    Here are some tiny nitpicks that don't hurt the demos: DE 729 Tape #1 sometimes "jitters" (moves a tiny amount back and forth) when the tape drive is not being used. We suspect that there is a minor problem with adjustment of the lower vacuum sensor in the right-hand vacuum column. Also, the bulb behind the SELECT light on Tape #1 appears to be out.

    For my edification, who's the right person to ask about this?

    Jack Ghiselli mobile 1-408-839-1051

    Received Sunday July 30, 2023


    > How did you get to be the guy who replaces paper clips and pencils and paper?

    No worries, doing so grows my resume! :)

    Kate used to order the paper, but I doubt Homer Alaska has an OfficeDepot?

    Thanks for procuring it! (Submit bill to George Holmes for reimbursement).

    - Robert

    On Jul 30, 2023, at 12:16 PM, Jack Ghiselli wrote:

    Hi Robert, Sorry to annoy you while you're out of town. Hope you're somewhere good.

    How did you get to be the guy who replaces paper clips and pencils and paper? Since you're my role model, I just want to learn how to move up.

    I've ordered a few boxes of paper and hope to bring them in on Tuesday.

    Thanks for the link to Ed's stuff. I love the story of ribbon supplier Burlington Mills complaining about poor quality ribbons.

    Jack Ghiselli mobile 1-408-839-1051

    7/26/2023 1401 Restoration Status
    - from David Clementson, Ken Shirriff, Robert Garner, John Howard
    - from David Clementson

    In a curious turn of events, it appears that our first drive roller in the CT1402 is not original. The material is suspected to be made out of a rubber & cork composite of some sort and most likely came from a 088 Collator. Robert believes Buzz may have replaced this at some point long ago (?).

    On the right, the roller from an 088, and on the left is the correct rubber that is period specific — the same type on the German machine.

    David is going to do some experimenting with a spare part to see if it is possible to re-tread the rubber and test it by feel rather than by using a durometer. I admit I am rather tempted to get one so that we can have a known value to work towards from various good rollers.

    Close-up photo of the suspected rubber/cork roller.

    As an aside, today was a very busy day with well over 80 people or so for the 3pm demo and at least 30-40 more afterwards. One lady came in and described her experience being a 029 keypunch operator and how much she enjoyed the fancy print buffer feature at the time. She was beside herself to discover that we have one!

    The A/C worked brilliantly and no smoke smell was anywhere to be found. I don’t believe we ever figured out the source of that…

    John did a fantastic and period-specific aesthetic fix of the punch check issue on the DE1402 which perhaps he’ll describe separately.

    ~Samuel Plainfield

    received Thurs July 27th

    John went to the Yosemite warehouse today and was able to retrieve a shaft with some appropriate rubber rollers on it. Unfortunately the shaft they are on won’t work in our machine, so we need to swap these rollers onto the correct shaft.

    I went to the museum this afternoon and attempted to use the big arbor press in the workshop to press the rollers off, but I couldn’t generate enough force to budge them. A close look at the roller/shaft interface shows that the shaft has a straight knurl under the roller hub, proving that it is indeed a press fit. We just need more force.

    So we have some options:

    1. Continue trying to use the big arbor press in the workshop That will require bolting it to the workbench. Would it be okay to drill some holes in that bench?

    2. Gain access to a small hydraulic press. Anybody have one?

    3. Fabricate a gear puller using threaded rod and some steel plates.
    Unless I hear back about options 1 or 2, I will start with this option over the weekend and see how far I get.


    received Friday July 28th

    I believe we have some progress. Using a gear puller and some considerable persuasion, I was able to get the four rollers off of their shafts. Getting the rubber rollers back on the proper shafts was a little easier. I used the lathe tailstock to get them started square on the shaft, then a bar clamp and some stout tubing to squeeze them the rest of the way. Checking them for trueness in the lathe shows about 0.003” of runout on each roller, and the shaft itself shows about 0.005” of bow. Not sure if that is a result of the rework or if it was that way before we started.

    New ball bearings arrive from McMaster tomorrow, so we should be able to install it next Wednesday.


    - from Ken Shirriff
    I looked at the DE tape drives today. Summary: #1 was working, I fixed the high-speed rewind light in #2, and #3 is tripping circuit breakers (different ones from before) and is not operational. The demo team couldn't get any drives working at the start of today's demo, but the problem turned out to be that #3 was off and messed up the termination.

    When unloading drive #2, it would go into high-speed rewind the whole time rather than slowing down. High-speed rewind is controlled by a light sensor that is blocked if there is a lot of tape on the right-hand reel. The light shines from above as shown by the arrow.

    The light is supposed to be bright and focused on the light sensor, but the light was providing just a faint orange glow. I assumed the bulb was burnt out, so I removed it with Frank's help. For most of the drives, the light panel swings out, providing easy access to the tape light. Unfortunately, this drive is different. The light panel swings down, which doesn't give enough access. Instead, you can get in through the top of the drive, remove the light cover, and get access to the light. I tested the resistance and, surprisingly, the bulb was not burnt out. And it illuminated brightly in the lab. The bulb is much more spherical than the indicator bulbs.

    I removed the lens assembly and very strangely, there was a red adhesive sticker blocking the light path. (Robert has a photo.) I removed the sticker and rewind now works fine on drive #2. The assembly is underneath a black plastic cover, so there's no way a sticker could just fall into there. I don't have an explanation, unless the demo team is creating puzzles for us :-)

    Drive #3 has been tripping circuit breaker #6 (and lighting the fuse light on the panel) periodically. But now it immediately trips both #9 and #10.

    These circuit breakers are documented as "phase 2 cap and take up" and "phase 3 cap and take up".

    Note that there is a head take up motor and a tape take up motor. Frank took over debugging of drive #3 so he can provide more details.

    Right before the demo started, the demo team reported none of the drives worked, which was a puzzle since drives #1 and #2 had just been working. The behavior seemed random: Selecting a drive had a mismatch between the drive number on the 1401 knob and the selected drive. Drive #2 showed both low density and high density at the same time. I figured there must be some signal error, and I suspected termination. Turning on drive #3 restored proper behavior for drives #1 and #2. So the moral is to make sure drive #3 is turned on even if it is not operational.


    - from Robert Garner
    Sam, et al, Here another photo of our extracted feed rollers:
    • Front: Feed roller #2 from the CT 1402
    • Middle: Feed roller #1 from the CT 1402, and
    • Back: Feed roller from (the left side of) the 088 collator in the warehouse.
    (Fyi, the design of the 1402 was based on a modified 088).

    Note the latter two (#1 and 088) have the same brown rollers. The one with the black rollers (#2) looks like the two black ones in the DE 1402, which are a latter model.

    David had us test out the friction of the newer black vs. older brown rollers (by dragging them over a punched card): the black/newer ones had a noticeably higher coefficient of friction.

    Given that the 088 was missing one of its rolls, we suspect that someone long ago, before we acquired it (possibly under Buzz’s care) removed it from the (right side of the) 088 and put it into the front #1 position in the CT 1402.

    Here’s a photo of David tapping out feed roller #2 from the CT 1402.
    (John had removed feed roller #1 in the morning and the also the one from the 088 last week — now a qualified expert at dong that! :)


    — Robert

    - from John Howard
    In April, using an old switch, we replaced the microswitch that conducts when the punch die is correctly installed, and the error rate seemed to reduce. DE1402 is again throwing punch checks while not punching. This week I replaced the used switch with a new uxcell TM-1701 SPDT 1NO+1NC long hinge lever switch.


    IBM 1401 Demonstration Saturday 7/22/2023 - from Stephen Madsen. and Jack Ghiselli
    11:00 am - from Stephen Madsen
    Karen Sun and I demonstrated to 55 visitors form China, Korea, Japan, Brazil, India, UK, France, Canada, and the US.

    We used DE since CT is still being repaired. We had problems with the card reader. We successfully ran BigPrint before the demo, but the program would not load during the demo. WE had reader checks and punch checks. After the demo, Jack got it working. I am not sure if the problems were due to a bad deck or hardware. There was a problem with tape #2. When doing an unload, the tape ran off the reel.

    When running the 083 sorter, many cards were rejected. Later Jack discovered that the switches were not set correctly. That is a reminder to check that the switches are set correctly.

    Stephen H. Madsen

    1:00 PM - from Jack Ghiselli

    Duane Sand and I gave the 1401 Demo 7/22/2023 1:00 PM to a crowded 52 visitors, plus mini-demos to another 38 who wandered in later. In addition to visitors from the USA, we had a veritable United Nations of foreign visitors from Austria, Bulgaria, Canada, China, Dubai, Germany, Montenegro, Portugal, Romania, Russia, and the UK.

    Due to the continuing Restoration work on CT, we ran on DE. The DE1401 ran perfectly. Many thanks to Ken Shirriff who fixed the DE Sense Switches, although we didn't get to use them. Yay, Restoration Team! The morning demo team had problems with the DE1402, but perhaps they fixed it, because it worked perfectly for us. We did find two BigPrint decks that would not load their first card, but BigPrint Deck #1 worked perfectly. At Wayne's suggestion, we put a Trojan card (extra do-nothing card) in front of the deck, so if the first card got damaged it would be the Trojan card. We were so busy with after-demo walk-in visitors that we didn't have time to investigate the bad BigPrint decks.

    We purposely did not try to use the DE1402 punch, since it caused problems a week ago. The DE1403 printer worked well, except we had a another break in the paper supply, so had to reload paper and re-run one visitor's messed-up BigPrint. Back in the 1960's we would have called to the vendor of "continuous forms" paper to complain. But I suspect that today COSTCO would have no idea what we were talking about.

    All three 026 Keypunches worked, although the printing on #2 (middle) was a little faint.

    The morning demo team found the 083 Card Sorter was not directing cards to the correct output stackers. After investigating, we found the problem was that the 083 front-panel controls had been messed with. Several of the digit-suppression keys had been pushed IN (should all be OUT), and the Sort Select knob had been turned to ZONE (should be NUMERIC). We all put on Sherlock Holmes Detective hats and noticed that when the unit-record machine was removed from the area a week ago, the 083 Sorter had been pushed closer to the rail. We suspect that subsequently visitor(s) had reached over the rail and manipulated the 083 controls. We combined morning and afternoon demo teams and shoved the 083 back farther from the rail. We hope this will help reduce undesired fingering. Also a reminder to demonstrators to check the 083 switch settings before each demo. We do NOT think there are any hardware problems with the 083.

    The DE 729 Tape Drives are seemingly sadly slowly slipping into senility. I feel the same way myself. Tape #3 (right-most) won't unload, so the morning team had switched it to NON OPERATIONAL. They found Tape #1 (left-most) would not load, so they also switched #1 to NON OPERATIONAL and used Tape #2 for their demo. Unfortunately when they tried to demo high-speed rewind on Tape #2 it failed to slow down at the beginning of the reel, and loudly shredded the front end of the tape, to the amusement of the visitors. In prepping for our demo, we tried to get Tape #2 working. We pulled about 40 feet of shredded and tangled tape off the take-up reel, and installed a new beginning-of-tape reflective spot. Then we were able to move Tape #2 using the TAU. But, when we tried to LOAD REWIND, the tape attempted to do a high-speed rewind, although near the front of the tape. So we reset Tape #2 and switched it to NON OPERATIONAL. We suspect that Tape #2 has a sensor failure. I think there is an optical sensor beam that looks at how much tape is on the take-up reel during rewind. When it sees only a little tape on the take-up reel, it switches to low-speed rewind. Tape #2 is failing to do this, high-speeds all the way, and crashes. Now all three tapes were set NON-OPERATIONAL, so we decided to try Tape #1 (Left-most) again. It seemed to move OK under TAU control, so we ran our demo using Tape #1. We still see some "reluctance" (is that a technical term?) from Tape #1 to LOAD REWIND. Sometimes it works; sometimes not. After our demo, when we did LOAD REWIND on Tape #1, it performed a low-speed rewind all the way. So, we are down to one demonstratable 729 Tape drive in the Lab, and it's a "maybe".

    Neither the morning nor the afternoon demo teams turned on the Liebert air conditioner, since we were worried about reports of its problems. We had only DE, the Keypunches, and the 083 Sorter powered up, but by the afternoon, the Lab got fairly warm. Everything seemed to work OK, though. After our 1:00-1:30 PM demo, we had an unusually large number of additional people wander in. Perhaps unwisely, we had them punch cards and printed BigPrint reports for them. It's difficult to refuse international visitors who are only here for one day. We did not power off until about 2:45 PM.

    The Audio microphones worked very well. We got a little bit of feedback squeal, but found we had set the MASTER VOLUME slightly over its recommended setting. Fixing that eliminated the squeal. Thanks to whoever in CHM staff has fixed the audio system. Yay, CHM staff!

    Final note: The 120-year-old 001 Manual Keypunch seems to have jammed. We cannot get a blank card to load. This is NOT a problem for our demos.

    Jack Ghiselli mobile 1-408-839-1051

    IBM 1401 Demo Status - 7/19/2023 - from Pat Buder
    Scott Stauter and I gave the demo to a packed house of 65 people. We had guests from Kenya, Romania, Czech Republic, Brazil, and Mexico. Ad additional 30 people dropped by before of after the main demo. We ran on DE due to continuing work on CT.

    The Liebert air conditioning unit was not working well and the room temperature was noticeably hot. Before 2:00 pm Robert Garner suggested turning DE off so that the restoration team could keep working on CT. We turned it on again about 10 minutes before the 3:00 demo. BigPrint loaded and ran fine during the demo and afterward. We did not run Powers of 2. Many visitors left the room before the demo ended due to the heat.

    The 083 sorter and 001 keypunch ran well. The 026 keypunch nearest the door ran fine. The middle keypunch often would not feed from the card hopper to the punch station. The other 026 started the day with extremely faint printing. Frank King worked on it and made great improvement.

    Tapes #1 and #3 were marked out of service so we used only #2 running from the TAU. I set it up with about 1/3 of the tape read and ready for the demo. Whoever powered off DE to help avoid heat didn't unload the tape before turning off the power. Neither Scott nor I (nor Robert Garner) powered off the machine, so it was someone else in the room. When we powered the machine back up for the demo, the tape was already part of the way down the tape. During the demo the forward motion worked as usual. However, the fast rewind snapped the tape, which was noticed by the audience. The tape was pulled along the inside of the left reel, and so is unusable as it is. We left it that way due to subsequent issues. Thus, DE has no usable tapes until the left reel on #2 is replaced.

    Shortly after the formal demo and while we were running BigPrints for the visitors, the restoration team returned to continue working on CT. Approximately 1/2 hour later we noticed a smoke smell. We shut everything down immediately. The team went around the main lab and the back room trying to sniff the source of the odor but we couldn't pin it down.

    Shortly before I left the AC technician arrived. He removed both Liebert end covers and started working. Unfortunately I had to leave for another appointment so I couldn't stay to get further information from him.

    Please see Robert's subsequent reports regarding further AC repair status.


    7/19/2023 CT1401/1402 Restoration Status ~
    a series including Samual Plainfield, Ken Shirriff, David Clementson
    also status of air conditioner (Liebert) from Robert Garner
    11:00 am - from Samual Plainfield
    Welp folks,

    There appears to be a light at the end of the tunnel, albeit somewhat obscure. This morning Frank and I replaced (swapped) the ink ribbons on the 1403s so that DE would print better for the demo today.

    A snafu which perhaps David will elaborate on resulted in the 1401 not interpreting any data coming from the 1402 as a result of a wire being knocked loose during the re-installation of the pinch roller mechanism. Fortunately, that was an “easy” fix. Once that was resolved…

    After careful consideration by all, David concluded that the first drive rollers ought to be scored evenly with some rougher sandpaper. An amusing three-man job, Ken rotated the main drive roller assembly, David carefully and evenly scored the rollers and I continuously tripped the clutch.

    Afterwards, we printed out a fresh all-5’s test deck (with I/O check off) and to our somewhat-surprise, every single line printed perfectly.

    Turning on I/O check, however, resulted in read check errors. A Storage Scan showed that the data was all correctly being read into core memory, which indicates a problem with the read check brushes (the first set of brushes).

    David put the scope back on with the program still in memory, ran it again and we analyzed the results: 3 perfectly printed lines and the 4th card resulting in a read check.

    The scope showed that the reads were absolutely ideal for the first 3 cards, but at the end of the last read there was some weird extra noise/fluctuations followed by some erratic clutch behavior.

    Unfortunately, there was a smoke incident and so we quickly powered everything down. The A/C system had been not working and acting up all day; as such we decided not to power anything back up until we determine if the A/C system was the source of the smoke smell. As a result, we don’t have a capture of the scope data mentioned above except for the perfectly timed one I just so happened to have snapped here:

    As you can see, the solar cell (yellow) fires exactly center of the card hole (cyan, purple; first and second set brushes respectively).

    Promising progress~

    ~Samuel Plainfield

    from Ken Shirriff
    My status:
    David and I fixed the sense switches on DE. Two of the wires to the switches had broken.
    I looked at the DE #3 tape drive. As reported, it wouldn't unload. This is the machine that has had circuit breaker problems, but the circuit breakers were all fine. I didn't have time to investigate it further.
    I helped investigate the CT card reader, but I don't have anything to add to David and Samuel's report.

    Samuel, you were asking how the CARD TO PRINT single-card program works, so I took a look at the code.
    The idea is that it first sets up word marks. Then it clears the print buffer. It copies the code for the main loop from the read buffer to 381. Then it clears the read buffer.
    The main loop at 381 sets up word marks, moves the card image to the print buffer, does a print and read, and then repeats the loop.

    Details of the code, starting at address 1.

    • 1: ,008015: puts words marks at 8 and 15
    • 8: ,22026: puts word marks at 22 and 26
    • 15: ,027034: puts words marks at 27 and 34
    • 22: /399: clears storage from 399 to 300, i.e. top of the print buffer
    • 26: /: clears storage from 299 to 200, i.e. bottom of the print buffer
    • 27: ,041048: puts word marks at 41 and 48
    • 34: ,055062: puts word marks at 55 and 62
    • 41: L080399: load: copies from 080-62, stopping at the word mark at 62. This ends up in 399-381
    • 48: ,388395: puts word marks at 388 and 395
    • 55: /381080: clears storage from 80 to 0, branches to 381. This ensures that the first line printed is blank, not the program card itself.
    • 381: This code was copied from the read buffer starting at 62. This becomes the loop entry point 381: ,001399: puts word marks at 1 and 399
    • 388: M080300: Moves from 080-1 to 300-221. This copies the card image to the print buffer, indenting it.
    • 395: 3381: Print and read, jump to 381
    Thus, you should be able to restart the program at address 331.


    from David Clementson
    Thanks for the reports, guys.

    As Sam said, it seems that the connector carrying -12V to the solar cell PCB came unplugged when I reinstalled the #! pinch roller. A look at the 1401 I/O read timing diagram shows that the solar cell signal is necessary in order for the 1401's read process to complete. Without a solar cell signal, the read instruction could not complete. The software said "read" and the hardware said "not so fast." So that explains why the 1401 seemed to be stuck on the read command.

    After repairing that, we tested and found the same old problem with every third row of the "print next card" deck failing to read properly. So we resurfaced the #1 drive roller as Sam described with me lightly scrubbing (not scoring) the roller surface with 150 grit (all we had besides 600) as Ken rotated it slowly. After the resurfacing, the "print next card" program correctly printed an all-fives deck, something we haven't seen in months (apologies for the crummy photo):

    This is indeed progress, and it also shows that the roller surface quality does seem to influence the read process. However the test did generate a Reader Check, so we are not yet out of the woods yet. We tried to capture the failure by scoping the brushes, and found what looked like a strange termination of the 3rd card read. The scope showed that immediately after the card exited the first brush, the clutch signal became active. Maybe not active enough to trigger a clutch cycle, but the clutch waveform did not match the usual clutched card read cycle. So there may be something awry with the handshake process that governs exactly when the clutch solenoid is fired.

    But just as we made this discovery, everyone in the room smelled smoke, so we immediately shut off everything, including the scope with the error waveform. We lost the scope data, but at least we didn't burn the museum to the ground.

    The smoke event coincided with a tape malfunction on DE #2 where the unit went into a full speed wind and sent the end of the tape into the reel. We had also been experiencing HVAC troubles all day, with the AC unit displaying warnings on its display. We don't know which machine caused the smoke, but I felt that the smell was strongest near the tape machine. By the time we were able try to pinpoint the smoke's source, it had dissipated enough to make finding it impossible.

    At this point the HVAC tech arrived. I explained to him about the smoke event and asked that if he finds evidence of some smoke generation within his machine that he report it back to the Museum staff who hopefully will report it to us. If he finds no such evidence, it is likely that it was one of our machines that smoked. We should power-up things very carefully next time and monitor the room for more smoke. We should also give a very careful visual inspection to DE#2 looking for evidence of smoke. Interestingly, the smell was more like wood or paper smoke as opposed to the familliar electronic magic smoke smell. That may provide a clue as to where in the unit to search.

    NB: We also turned off the rear AC power switches on all of the CT tape drives. No point in adding to the heat load of an already AC-challenged room.

    So that was it for the day. Next week we can pick up and try to recreate the brush timing measurement.


    status of air conditioner (Liebert) from Robert Garner
    Re: Hot 1401 Demo Lab! / failing Liebert CRAC (was Re: Warm 1401 Demo Lab last Wednseday


    Thanks for just now (!) contacting ACCO (HVAC firm) to address the overheated 1401 Demo Lab! I understand they’re dispatching a tech now.

    Here are the alarms showing:

    High Head Pressure
    High Temperature

    - Robert


    Thanks for the update that the Liebert won’t be repaired until next week. Any indication of which day next week? Before Weds? Did the ACCO technician share a diagnosis?

    Regarding the Saturday demos tmrw, my recommendation is that the DE 1401 be powered up only long enough to do some BigPrints, depending on how well the building A/C can keep the Demo Lab temp under control (and, of course, the CT 1401 should be kept off).

    “An ounce of prudence is worth a pound of cure."

    — Robert

    p.s. The ACCO technician last Weds:

    IBM 1401 Demonstrations Saturday 7/15/2023 - from Stephen Madsen and Jack Ghiselli
    11:00 am - from Stephen Madsen
    Michele Yee and I demonstrated to 55 visitors.

    Keypunches worked OK.

    083 Sorter rejected many cards even though it looked like there were valid holes in the column being sorted.

    We used DE.

    1402 reader/punch: We had punch checks. We pushed many buttons, re-booted, tried many things, and finally got it to go off. I am not sure what we did to clear it.

    Printer: The output is faint. The latch on the gate sometimes needs to be held in place.

    Tapes: #3 is not working.

    Stephen H. Madsen

    1:00 PM - from Stephen Madsen
    Larry Hara and I demonstrated to 65 visitors.

    Keypunches worked OK.

    083 Sorter rejected many cards even though it looked like there were valid holes in the column being sorted.

    We used DE.

    1402 reader/punch: We had punch checks. We pushed many buttons, re-booted, tried many things, and finally got it to go off. I am not sure what we did to clear it.

    Printer: The output is faint. The latch on the gate sometimes needs to be held in place.

    Tapes: #3 is not working.

    Stephen H. Madsen

    2:15 PM - from Jack Ghiselli
    Larry Hara, Michele Yu, and I gave a special 1401 Demo 7/14/2023 2:15 PM to a group of SMASH high school students from Stanford, with group leader Laura. We also had a group from U.C. Berkeley and a number of other visitors join in, for a total of 74 people. There were international visitors from Belarus, France, India, and New Zealand. After the demo, I touched base with Laura of SMASH who said the 1401 demo was exactly what she was hoping for. Yay us!

    Because CT is still down, we ran the demo on DE.

    The DE1402 got a PUNCH CHECK condition, causing the Reader to refuse to read cards. Pressing CHECK RESET on the 1402 turned it off temporarily, but as soon as we released the CHECK RESET button, PUNCH CHECK came back on. In desperation, we opened the covers, tried re-seating the brush assemblies, tried to insure that all cover interlocks sensors were OK. Then we powered down the DE1401. When we powered back up, PUNCH CHECK was off and we were able to read cards and do the demo. Larry Hara was also present, and he seems to have a calming influence on the DE1402. After the demo, we tried to use the DE1402 punch to create a new sort deck, but it would not punch cads and PUNCH CHECK reappeared.

    DE 729 Tape Drive #1 refused to Load, and Tape #3 refused to unload, so we set them both OUT OF OPERATION, and did the demo using only Tape #2. After the demo, Tape #1 finally decided to "heal" and properly loaded and unloaded. However, we were unable to get Tape #3 unloaded, so had to power off DE with Tape #3 still loaded.

    The Liebert air conditioner was on, but sounding an audible alarm. Its screen was difficult to read but seemed to display HIGH PRESSURE error.

    When shutting down, due to a miscommunication among our demonstration team, we accidentally turned off power to the 60-to-50 Hertz power converter BEFORE powering off the DE1401, causing an abrupt power-off. We turned it back on, and the DE1401 seemed to work OK. We hope we have not damaged it.

    All three 029 Keypunches worked OK. However, we noticed that the new card stock (newly purchased carton recently opened) had skewed printing of columns and rows. When punching, it looks like the punch holes in these cards are improperly offset, but checking with the punch alignment jig showed the punches are correct but the printing is skewed.

    The 083 Sorter moved cards convincingly, but we noticed that many cards went into the REJECT pocket despite having correct punches in the selected column.

    The audio microphones operated perfectly. Last Wednesday, we had to use non-suggested volume settings to get Mic #2 to be audible. However, today, we set everything at suggested levels (red dots on the dials) and they worked perfectly. THANKS to whomever fixed this.

    Jack Ghiselli mobile 1-408-839-1051

    From Marc Verdiell

    Now how to repair the 1401s and 026s faster than they break down…


    from Jack Ghiselli

    The Restoration Team does an AMAZING job keeping this ancient iron working! We in the demonstration team need to treat it gently. Our reports of problems are intended only as information, and in no way mean we don't appreciate all the hard work you do. Today, FOUR different visitors came up to me and said "Seeing this stuff is REALLY COOL."

    Jack Ghiselli mobile 1-408-839-1051

    Restoration Report 7/14/2023 - from David Clementson w Marc Verdiell
    from David Clementson
    After way too much fiddling, I was able to reinstall the refurbished #1 pinch roller. I was also able to clean an lubricante the roller pivot bushings, one of which was quite sticky. I did not have enough time to test it however.

    I also calculated the error budget for resurfacing the drive roller. In order for the card to remain in place within three degrees (a reasonable tolerance per Ken) over a machine cycle, the drive roller needs to be within 0010" of its theoretical diameter. So we can do some abrading to improve the surface, but we need to be careful not to go too far.

    Clutch teeth (per 360 degree cycle) 25
    Drive roller teeth 19
    Row spacing (degrees) 18
    Row spacing (inches) 0.250
    Roller circumference (inches) 3.800
    Roller diameter (inches) 1.210
    Row spacing error budget (degrees) 3
    Roller circumference tolerance (inches) 0.032
    Roller diameter tolerance (inches) 0.010
    from Marc Verdiell
    How did the drive roller look? Does it also have a flat?
    from David Clementson
    I didn’t measure the drive roller roundness, but I am pretty sure that it has some minor dents in it. Not as bad as the pinch roller though. I will endeavor to make a quantitative analysis next session.


    Status report 7/12/23
    from Ken Shirriff, Marc Verdiell, Frank King and David Clementson
    from Ken Shirriff
    I replaced the reset switch on DE #2. At least I think it was DE #2 but Jack said it was DE #3 so maybe I'm mistaken :-) The switch had failed, making it impossible to deselect the drive and unload it. I replaced it with a switch from the scrap 729 switch panel in the workshop. Here's a photo inside the dead switch:

    I determined the problem with the sense switches on DE: a broken wire going between the switches. I didn't have time to resolder it.

    I studied Marc's high-speed video of the CT 1402 frame-by-frame and tried to line up images from a good feed and a bad feed. It looks like the card going into the first brushes is a bit slower to start up and ends up delayed about 5 degrees. But it's really hard to be sure because of the camera motion and perspective.


    from Marc Verdiell

    I borrowed a high speed camera and got some spectacular slo-mo footage from the 1402 card transport. With Sam’s and David’s help, I compared the DE 1402 card transport and the CT 1402 card transport, while we introduced clutch wait cycles.

    Good news, the card always stops at the correct wait position before the first brushes, implying that knife timing and unclutching are A-OK. Bad news, the card sometimes stops short in the wait position before the second brushes. I estimate sometimes half a row, sometimes a full row. Ken got similar results with a less high tech method involving pencil marks and rulers.

    Since the card ends up late (only once out of 4/5 times) at the second wait station, while starting from the correct first station position, it must be slipping in the first set of rollers on re-clutch. Note that this roller fault would not manifest itself on the first clutch cycle, since the card is accelerated by the knifes into the rollers. Which is consistent with the card stopping under the first set of rollers at the right position. However, on the second clutch cycle after a wait cycle, the card relies on the first set of rollers for acceleration to restart its motion. And it sometimes gets late, consistent with slippage. Also, when the clutch is operating continuously, the card never stops and never needs to be reaccelerated by said rollers, so everything works fine. So that would also explain why we only see problems after a clutch wait cycle.

    We therefore looked inquisitively at the first set of rollers. It consists of a pinch roller on top, and a driven roller underneath. They are very worn. There is a very pronounced flat on the pinch roller. It’s harder to see the bottom roller, but it looks equally worn out. A flat could certainly explain why we see cards arriving late once in a while.

    Next step will be to take the top pinch roller out, remove the flat in a lathe or by dressing it, and look at whether we need to roughen the bottom driven roller (we have less options for correcting the bottom driving roller, as we cannot reduce its diameter). Robert and Frank will also be looking at possibly getting another set of rollers from our parts machines in Yosemite.

    Also, the cards were coming down slightly skewed. David corrected by refining the alignment of the knifes. That was not optimal, but was likely not the root cause of our timing problem.

    I’ll call it good progress.


    from Frank King
    I found a bad 25L6 tube in the keypunch. After replacing it with with a tube from one of the features on the keypunch, It seemed to run ok. So we took the borrowed 029 back to the Babbage closet.


    from David Clementson
    And for my part, I readjusted the 1402's picker knives to improve the cards' rotational alignment (yaw,)

    I also removed the 1st pinch roller so that I could true it up in the lathe. In the lathe, a dial indicator showed about 0.010" of total runout on both rollers with noticeable flat spots that were aligned with each other at the same rotational position. I turned down the rollers until the flats just disappeared. I also turned the white plastic guide roller diameters to match so the cards can lie perfectly flat.

    It might be a good idea to check the roundness of the remaining rollers. I will bring in a dial indicator to do that next week.


    status of air conditioner (Liebert) from Robert Garner

    CHM 1401 Demo Wednesday 7/12 3:00 PM
    - from Jack Ghiselli, comments by Robert Garner
    from Jack Ghiselli
    Sam Plainfield and I gave the 1401 demo Wednesday 7/12 3:00 PM to 58 people plus 10 who wandered in before or after. We had visitors from all over the USA, and international visitors from Australia, Belgium, China, France, Germany, Hong Kong, Switzerland, and Turkey.

    The Amazing Restoration Team fixed 026 Keypunch #3 (nearest the A/V closet) and removed the 029 Keypunch we had been using temporarily. There's a lot more space now. Yay, Restoration Team! All three 026 Keypunches and the 083 Sorter work great.

    CT is still down, but a large number of the Restoration Team are working HARD to fix it. So, we used DE for the demo. Ken Shirriff found and fixed the problem with the RESET button on DE 729 Tape Drive #3 (right-most). Yay, Ken! During our demo, all three DE Tape Drives worked perfectly with the TAU. Unfortunately, at the end of our demo, Tape #3 refused to LOAD REWIND or UNLOAD. We were able to use RESET and change the DENSITY, so this looks like a new problem, not the one Ken fixed. Eventually, we had to power off DE with Tape #3 still loaded. I hope the Restoration Team doesn't shoot us. The DE1402 worked very well. We encountered two breaks in the DE1403 paper supply box while printing BigPrint pages, but were able to reload the paper quickly and recover. Ken was also looking into the minor problem with the DE Sense Switches, but didn't have time to fix it. We are blessed to have this Amazing Restoration Team.

    Mic #2 is still inaudibly soft, so we again had to use unusual audio settings: (1) Turn Mic #2 Audio all the way up, (2) Turn Master Volume much higher than its suggested setting until Mic #2 is audible, (3) turn on Mic #1 and turn its volume much lower than suggested until the squealing stops. Then, both mics are audible.

    Jack Ghiselli mobile 1-408-839-1051

    As usual, Ken is correct and I am wrong. The problem with the RESET switch was indeed on Tape #2 as Ken said. Not #3 as I mistakenly mis-remembered.
    from Robert Garner
    Sam, Jack,

    Six pictures not included here

    Your audience presentation and engagement style is compelling, educational, skillful, and down right delightful!

    Jack —> I particularly like your rhetorical questions — What does a bit weight? What color is a bit? — before showing the audience a jar of cores. And your remark about why the 1401 needed to reliability print paychecks whereas astronomical simulations could wait another day if the larger $million computer was down. Your presentation style, with arms waving, light up the visitors' imagination, bring out a smile, and draw ‘em in.

    Thanks for being such great 1401 demo’ers! (I’ll share a 1-minute video clip next, but I need/would like to record an entire demo sessions….)

    CHM 1401 Demonstrations, Saturday 7/8/2023
    from Jack Ghiselli, Duane Sand and Stephen Madsen
    from Jack Ghiselli - 11:00 Demonstration
    Duane Sand and I gave the demo to 54 people, plus mini-demos to 10 additional people who wandered in before or after. Michelle Yu also came in to shadow and refresh her 1401 Operation skills. We had international visitors from Brazil, Georgia (the country, not the state), Japan, Peru, and Saudi Arabia. We also had a contingent of uniformed young Sea Cadets from Moffett Field, and several ex-TANDEM employees.

    The demo did not go well. Since the CT1402 is still down, we ran on DE, but we encountered DE1402 problems. When we first powered up DE, the DE1402 would not load decks, although we tried several different ones. We powered DE down and up again, and then the DE1402 would load decks, but got sporadic READER CHECK errors. By using careful card handling, we were able to recover and continue from the errors, and we successfully ran a BigPrint and a Powers-of-Two. Unfortunately, during the demo itself, the DE1402 completely refused to read cards. The mechanism would start, but would not read the first card. We tried four (4) BigPrint decks, two Powers-of-Two decks, and a Lincoln, and none would load. So we gave up and had visitors punch name cards, but apologized that we were unable to print any BigPrint output. After the demo, we tried repeatedly, and finally the DE1402 "healed" and began to load decks. We have no explanation for the problem, but hoped the afternoon team would have better luck. Larry Hara of the afternoon team seemed to have a calming effect on the DE1402, and it worked better for him (thanks, Larry).

    DE 729 Tape #2 became INOP. In preparation for the demo, we used the TAU to begin moving all three DE tapes part-way down the reels. When they were far enough down, we pressed RESET to stop the motion and turn off READY. Drives #1 and #3 stopped normally. However Drive #2 refused to stop, and its READY light stayed on. Pressing RESET repeatedly had no effect. LOAD REWIND and UNLOAD also had no effect (probably because READY was on). To avoid the tape running off the feed reel, we switched the dial to OUT OF OPERATON. This stopped the tape motion, but READY remained on and RESET, LOAD REWIND and UNLOAD buttons had no effect. We informed the afternoon team that Tape #2 was INOP, and that they would probably have to power off DE with Tape #2 still loaded. We were able to demo DE Tapes #1 and #3 using the TAU.

    All three Keypunches (two 026s and one 029) worked OK.

    The 083 Sorter worked OK. We demo people need to create a better sort data deck when we get time.

    Previous minor problems with DE (which do NOT affect the demo) remain. Sense Switches E, F, and G are INOP. Tape #3 does not respond to software commands (but works with the TAU).

    We had the usual problems finding workable audio levels for the microphones. Mic #2 was inaudibly soft. Our solution was to turn the Mic #2 volume full up, and also turn up the MASTER VOLUME past its suggested level. This made Mic #2 audible. Then, we turned Mic #1 volume below its suggested level until it stopped squealing. In this way we were able to use both mics.

    Jack Ghiselli mobile 1-408-839-1051

    from Duane Sand - about the 11:00 Demonstration
    Jack's adjustments to the mic amps seemed to be workable before the demo started, but we then had feedback squeals. I gave up on mic #2 and spoke without the mike. My unaided voice was apparently not loud enough for all initially, but okay at the end.

    Mechanical feeding did not work on some of the keypunches. The workaround was to feed each blank card manually.

    The top of the sorter was littered with many random piles of useless cards with random internal organizations. I would like to toss them all, and have any current restoration team test decks clearly organized elsewhere.

    I wonder if we have any examples to show of large plugboards with complex wiring. Replacing plugboards with stored programs was a major step in designing the 1401, despite the costs involved.

    from Stephen Madsen - 1:00 Demonstration
    Larry Hara and I gave a demonstration to 65 worldwide visitors. One guy from the East Bay told me he has a collection of personal computers of the 1970s through 1990s.

    Since CT is INOP, we used DE. The morning team said they had problems with DE 1402 not reading cards. However, we managed to get it working between demos and were able to process numerous BigPrints. (Unexplained behavior). As reported by the morning team, tape drive #2 would not unload. Unfortunately, we powered down with the tape still loaded.

    Keypunch #2 has faint printing; the other keypunches worked OK. The sorter worked OK.

    Stephen H. Madsen

    Status report 7/5/23 - from Ken Shirriff and David Clementson
    from Ken Shirriff
    I mostly worked on the CT 1402 which still has problems. Specifically, after a cycle where the clutch stops and starts, the card is delayed by about 6 degrees.

    Here's the result of reading and printing cards with all 5's. There are a lot of errors. The vertical problems indicate problems with a particular brush. But more interesting is the pattern of horizontal errors: every third row (marked with a line) is catastrophically bad. It has a lot of blanks, indicating that the card got to the brushes late and the brushes read the gap, or it has 4's, indicating that the card was so late that the hole arrived when the next row was being strobed. The important thing is that when reading and printing, reading pauses every third card so the printer can catch up. Thus, this shows that the errors are correlated to the clutch stops.

    Looking at oscilloscope traces, we saw that after a clutch stop and start, the card gets to the first read brushes about 6 degrees too late. Next cycle, that card gets to the second read brushes also about 6 degrees too late. This shows that the delay happens before the first read brushes and after the picker knives. Between the first brushes and the second brushes, the card moves at the right speed, preserving the delay.

    So we're left with the question of why does a card get delayed when the clutch stops and starts? We have various theories but haven't found the answer.

    An interesting experiment for next time:

    • Read one card and then stop. Look at the physical positions of the two cards inside the card reader. These should be correct.
    • Read one more card and then stop. Look at the positions again. Based on what we've seen, the card from the hopper should be in the correct position, but the card between the first and second brushes should be delayed by 6 degrees because the clutch was stopped.
    This would let us verify that the card position is wrong. If the card is in the right position, then we'd know that the problem is dynamic, not static. Either way, it would narrow down the problem. (The benefit of this approach is we don't need a high-speed camera, since everything is stationary when we examine the cards.)

    Another interesting experiment would be to check the brush timing on the DE machine, to see how much variation happens on a working machine. This would give us a baseline to compare against.


    from David Clementson

    Thanks, Ken. One little piece to add. Since the card seems to be getting out of position as the first drive roller accelerates from a stop, Sam and I reasoned that the first roller may be losing traction and slipping. The roller itself progresses correctly because it is driven by a cog belt, but because of slippage, the card does not keep up with the roller. So after everyone left, we inspected that roller closely and carefully cleaned it with alcohol. The roller surface looks pretty bad, with significant glazing and surface pitting. We should compare it to the DE roller. We could consider resurfacing the roller, but because its diameter is critical to maintain the correct card position, we would have to proceed very carefully.


    One other thing: it seems to me that if the card is indeed slipping at the first drive roller (rollers, actually, since there are two of them along the width of the card,) the rollers will have left slight abrasions at very specific locations on the backside of the card. If we run a deck of virgin cards, we would expect to see surface abrasions on every third card. We might even be able to treat the back surface of the cards with something to help reveal the abrasions. If we can prove that the roller is indeed slipping, then we have no choice but to replace/remanufacture the roller.


    CHM 1401 Demos Wednesday 7/5/2023 (10:30 AM and 3:00 PM) - from Jack Ghiselli
    When we arrived, CHM staff was in process of removing one of the Unit Record equipment and the 024 Keypunch which was outside the gated area. One Unit Record Collator equipment unit and the 024 Keypunch which was outside the gated area have now been moved away to CHM's Yosemite building.

    When we arrived, we had only one working Keypunch (KP #2). This was concerning since we expected to punch a lot of BigPrint cards. We ended up moving a bunch of equipment around, pulling up floor panels, and relocating power cords. At Kate McGregor's suggestion, we got the mobile 029 Keypunch from the Babbage storeroom and moved it into the demo area. It is now located at KP #3 position (next to the A/V closet). We disconnected the INOP 026 Keypunch which was previously there and moved it about ten feet over to where the Collater used to be. The Restoration Team got 026 Keypunch #1 (farthest from the A/V closet) reassembled and installed a new print ribbon, so it now works. With these improvements, we had three working keypunches.

    The 029 Keypunch controls are slightly different from the 026 Keypunches, so it was a little unfamiliar to our demo Operators. One nuisance is that the 029 keyboard is mounted rigidly to its table-top, so you cannot rotate the keyboard for use by visitors outside the rail (as we do with the 026's). Instead, you have to rotate the entire keypunch table so visitors can reach it. If we can get the INOP 026 Keypunch fixed, we might want to put the 029 back in the Babbage storeroom.

    We gave two 1401 demos today. The Restoration Team was still working on CT, so we ran both demos on DE.

    At 10:30 AM, Peter Chang, Duane Sand, and I gave a private demo to 65 students from Glenn Fajardo's Stanford summer program for young entrepreneurs. At Glenn's request, we modified the normal 1401 demo to emphasize aspects of 1401 history which were of interest to entrepreneurs. We tried to split the large group into two separate demos, but that did not go well, and we ended up bringing the students from outside into the demo room with the others. During this time we were attempting to communicate what we were doing to Kate (in Homer Alaska) via the Beam robot. We did a poor job of communicating and Kate was not happy. We apologize for that.

    In between the two main demos, Duane Sand gave mini-demos to several people who wandered in.

    At 3:00 PM, Scott Stauter and I gave the normal demo to 42 people, plus another half dozen who came by. We had international visitors from Canada, Dubai, Finland, New Zealand, Poland, Switzerland, and the UK.

    Towards the end of the morning demo, the DE1402 began giving erratic READER CHECK and READER STOP errors, and eventually we were unable to process any more BigPrint cards. So, we took the name cards from the students and said we'd run them later and get the printouts to them through Glenn. Between the two demos, Ken Shirriff, Samuel Plainfield and Dave Clementson came over to help us. Dave found and removed one particle jammed in the DE 1402 input mechanism, and readjusted the card clearance. This helped a lot. Yay, Ken, Dave and Sam! We were able to run all the students' cards and left the cards and printouts at the front desk for Glenn. Then, we were able to run the 3:00 demo. We still get infrequent DE1402 READER CHECK and READER STOP errors, but if we are careful we can recover from them.

    Some BigPrint object decks didn't work correctly, so after the 3:00 demo, Scott and I used the VOBJ diagnostic program to examine all the decks. We found some out-of-sequence cards and one missing card. We corrected the errors, and now all four (4) BigPrint decks work OK.

    We had minor trouble adjusting audio volumes on the microphones. Mic #2 was so soft it was inaudible, so we had to resort to turning up the Master Volume beyond the suggested setting, until we could hear Mic #2, then turning Mic #1 volume down to avoid feedback. Scott found a foam cover for Mic #2 and installed it.

    Since it was one day after July 4, we had the LINCOLN program ready to run. As written, you have to reload the program each time you want to print one Lincoln face. We patched the program so that when it terminates with a programmed HALT, you merely press START to print another Lincoln. Great preparation, but as things turned out we didn't have time to run LINCOLN anyway. Oh well.

    Jack Ghiselli mobile 1-408-839-1051

    IBM 1401 Demonstration 7/01/23
    11:00 AM - from Stephen Madsen
    Karen Sun and I demonstrated to 45 visitors from China, India, Korea, NY, and other parts of the USA.

    Since the CT1402 is not working, we used DE. The tape on drive #2 was off the take-up reel. When we discovered this there was not enough time to fix it before we had to start the demonstration. This was fixed later by Peter. Please check the gate handle on the DE 1403. I found that I had to hold the handle closed for printing to work.

    Microphone #2 was a problem. We could not get it to work for the demo. Later Jack found the magic settings. There were only three batteries in the charger.

    Stephen H. Madsen

    1:00 PM - from Jack Ghiselli
    On 7/1/2023 at 1:00 PM Peter Chang and I demonstrated the 1401 to 63 people. We had international visitors from China, Germany, India, Russia, and Syria. Peter was able to talk Mandarin to the visitors from China.

    We ran on DE, since the CT1402 is still down. DE Tape #2 had run off the take-up reel and the 11:00 team didn't have time to re-thread it. So, Peter fixed that. Otherwise, DE ran OK, with minor issues reported previously.

    When preparing for the demo, Peter found that one BigPrint deck had a damaged first card which wouldn't load, so he replaced it. Then he found that one of the Powers-of-Two decks was missing its Last Card, so he made a new one and fixed that. Yay, Peter!

    Keypunches have got trouble. KP#1 (farthest from the closet) is disassembled and INOP. KP#3 won't punch, so we marked it INOP. KP#2, the only surviving unit, had infrequent card feed problems and one case of incorrect DUP. With so many visitors and only one Keypunch, it takes a LONG time to make BigPrint cards. It appears that some of the "adequate" card stock is better and some worse -- switching input cards corrected some problems. We did open the new case of "adequate" cards (in the A/V closet).

    As advised by the 11:00 team, we had trouble with audio mic #2. We found it was "working" but VERY soft. Our solution was to turn mic #2 all the way up, turn MASTER VOL up beyond its recommended setting, and then turn MIC1 volume way down to stop its squealing. We got through the demo with those settings.

    Duane Sand came in after the demo to help us with BigPrint cards. Thank you Duane. Duane also noticed that the DE1403 Printer back glass door (covering the downward paper flow) has a broken latch. Not a serious problem, just a nuisance.

    Among the visitors was an interesting youth. Enzo Damato lives near Poughkeepsie, NY. He just graduated from High School and will attend Rice University. He owns an IBM Mainframe. I didn't have time to understand exactly what kind, but he says it's a much more modern "360-like" unit, about the size of a 729 Tape Drive. He showed me a photo. He had watched the CHM videos (probably Marc's) about building our Tape Emulator. Enzo wants to build a similar device for his IBM mainframe, and would like to talk about some hardware details. I will send his contact info to Robert Garner and perhaps one of our Amazing Restoration Team could contact him.

    Jack Ghiselli mobile 1-408-839-1051

    CHM 1401 Demo Wednesday 6/28/2023 - from Jack Ghiselli
    On Wednesday 6/28/2023, Samuel Plainfield and I gave the 1401 demo to 25 people, plus 8 more who wandered in. Even Len Shustek came by. We had international visitors from Canada, China, France, India, and Italy.

    Since the Restoration Team is still working on CT, we ran the demo on DE. Only minor problems on DE.


    DE 729 Tape Drive #3 (right-most) will not write under program control, although it will move under TAU control.

    DE 729 #1 has its SELECT lamp INOP.

    We ran the RON 2.1 tape exerciser on 729 Tapes #1 and 2 at LOW DENSITY. Tape #1 wrote 4578 blocks with 19 write errors; 4579 blocks with 10 errors, 3940 blocks with 0 errors, and 4590 blocks with 5 errors. Tape #2 wrote 3933 blocks with 16 errors; 4584 blocks with 17 errors. To summarize, DE Tape drives would be marginal for attempting Tape-resident demo programs.

    DE 1401 Sense Switches E, F, and G are INOP.

    DE 1403 Printer ribbon need re-inking. BigPrint demos are coming out rather light.


    Jesse brought in a new carton of 6 boxes of "adequate" quality unused cards, for punching BigPrint name cards and similar. The carton is unopened and in the A/V closet.

    Keypunch #1 (farthest from the closet) is INOP and being repaired.

    We had some problems with feeding cards in Keypunches #2 and #3. However, we think the problem was related to the particular input card stock. We recommend that Saturday demonstrators try out the keypunches, and try swapping input cards if problems. Try looking on the bottom edge of the cards and avoid cards with dark colored blotching there.

    A/V Audio: When we arrived, there were only two batteries in the charger, and one of the mics had no batteries in it. We found enough good batteries to last through our demo, and afterwards we left batteries in both mics, and loaded 4 new ones in the charger. Recommend demonstrators try to remember to load batteries into the charger after the demo.

    The CT1402 skin panels had been removed for Restoration and leaned against other equipment. Sometime during the demo or the restoration work, a panel fell over and broke the plastic pocket which holds all the 1-card-wonder programs (80/80 list, reproduce, etc.). We need a new storage pocket.

    Jack Ghiselli mobile 1-408-839-1051

    6/28/2023 Restoration
    - from Ken Shirriff
    I investigated a problem from last week, where the LOAD button had no effect and the card reader wouldn't even try to read. Bhushan pointed out that I had looked at the same problem in 2019, but the problem resolved itself before I could track it down:
    The same thing happened this time: the problem resolved itself. But I took scope measurements so at least we can see what the correct behavior is.

    Here's the relevant part of the 1401's read circuitry. We want the clutch to fire in the card reader (READ CLUTCH MAGNET). This is controlled by the READ FEED trigger. This trigger checks if the card reader is ready for a clutch cycle (PROC FEED) and if the 1401 wants a clutch cycle, and energizes the clutch if everything is okay. (This is what synchronizes the clutch solenoid with the 1401 and the card reader.)

    The problem where the card reader doesn't start at all seems to be because of INLK STOP This interlock trigger is high if the card reader can't run and low if the card reader can run. If the 1401 is stopped or the card reader has a problem, INLK STOP will prevent the card reader from running. But if you hit LOAD or START, INLK STOP should go low, allowing the card reader to run. My hypothesis is that the intermittent problem where LOAD does nothing can be traced to INLK STOP.
    I measured under good behavior and found that the inputs are:
    A: STOP OPR. pulse input to set the trigger (card reader blocked). This input is high (0V) if the card reader has a READ CHECK and low (-12V) if the card reader is okay.

    D: START: pulse input to clear the trigger (enable card reader). This is normally -10V but gets a 10µs pulse when the START button is pressed.

    F: LOAD KEY: clear input (enable card reader). Normally -5V, but a 3ms pulse to +6V when LOAD is pressed on the card reader.

    G: START RESET. set input (block card reader). Normally -5V, but +7 while START RESET is pressed on the console.

    So now we just need the problem to occur again and see what's going wrong. My guess is that the card reader is probably energizing STOP OPR or not energizing the LOAD key due to some relay issue.

    I also took a photo of the brush timing that the rest of the team was working on. The cyan line should look like the purple line, but the brush bounced. We also saw the brush entirely missing the hole. However, this was apparently due to the brush block not seated correctly. (cyan is first brush, purple is second brush, yellow is solar cell)


    - from Marc Verdiell
    On my side, I spent time with David to see if the timing of the cards had improved after his readjustment of the knifes and throat roller. The answer is yes, very much so! The cards now appear to consistently arrive at the correct time under both brushes, which is a significant progress.

    A deck with all blanks now runs all the way through.
    A deck with 5’s or 0’s still had problems sometimes. As Ken showed, the 2nd brush scope reads were always good, but the 1st brush were not.

    Now that we have good transport and card timing, it should be much easier to get the first set of brushes to behave.

    (As a side story, we got sidetracked as we found two badly frayed wires hanging by a single thread to the 1402 solar cell, and managed to trip fuse FS7, probably from the frayed wire whiskers touching something. FS7 in the -20V supply that goes to the solar cell and the brushes – now that I think of it, I believe we have had this fuse blow a few times before. But quite incredibly, the fault showed up *in the 1401* as an inability to toggle our test program into memory plus some lights not working on the front panel. That kept us on our toes for while, as we traced our way back to power supplies and breakers we didn’t even know existed. We eventually found the blown fuse on the 1402, David made a clean wire repair with proper insulation and strain relief, and all is good.)


    - from David Clementson
    And on my side, the only thing I can add is that I discovered that the last card in the deck will not pick unless the correct card weight is used. There are two kinds of weights: one with a flat platen spring, and one with a formed platen spring. The formed spring is recessed in the center. The 1402 wants the weight with the recessed platen.


    Hi Grant:

    The code wheels arrived today but too late for me to take them to the museum. So I will give them a try next week. They look great!

    On Jun 22, 2023, at 11:36 AM, F. Grant Saviers wrote:

    Hi David,

    I printed two code wheel with the correct slots. They look pretty good, still a bit of first layer bulge. I think they should be tried to see if ok. If not, some tweaking of printing parameters might reduce the narrowing. I might have printed them wrong side down since the boss seems a bit thin. Easy to do some more.

    Worth a 1402 try to see what needs tweaked.

    Send me you snail mail address and I will USPS them to you.



    On Monday, June 12, 2023 at 03:10:09 PM PDT, F. Grant Saviers wrote:

    Acetal/delrin machines well, so milling from sheet stock makes more sense. I have a 2 axis and 3 axis CNC mills. Fusion360 can do the cad and cam tool paths.

    I'm pretty sure the printing will work, am waiting for black PLA filament to arrive to make a couple more to print. It might need a tweek of the slot width, we'll know after measuring the new slots. How critical is that width?

    I can mail them to you, your address please.


    IBM 1401 Demonstration 6/24/2023
    11:00 AM Demo, from Jack Ghiselli
    Jim Maurer and I gave the 1401 demo Saturday 6/24/2023 at 11:00AM to 40 people. We had international visitors from Germany, Switzerland, and Wales.

    We used DE since the CT1402 is still INOP.

    026 Keypunch #1 (farthest from the door was disassembled, so we used #2 and #3. #2 was a little flaky, sometime working and sometimes not. The 083 Sorter ran fine.

    DE ran well, with only a few minor problems which did not interfere with the demo. On the DE1401, Sense Switches E, F, and G seem still INOP. 729 Tape #1 (left most) take-up reel "shimmys", probably a problem with the right-hand column lower vacuum sensor. The SELECT lamp is INOP on #1. Tape #3 is noisy at low speeds.

    Jack Ghiselli mobile 1-408-839-1051

    1:00 PM Demo, from Stephen Madsen
    Larry Hara and I demonstrated to 103 visitors. There was a large group from UC Berkeley.

    We used DE because the CT 1402 is being repaired. We had reader checks on the DE 1402, but after retrying it worked OK.
    The printer and the tapes worked OK. The keypunch near the door worked OK. Keypunch #2 had intermittent feeding problems. The cover is off of Keypunch #1. I found a BigPrint deck labeled BAD-NO L/C. I made a L/C for it and tested that it worked OK. I discarded the BAD-NO L/C label.

    Stephen H. Madsen

    comment from Jack Ghiselli

    Wow! Steve and Larry get the award for the largest group of 1401 Demo visitors. This definitely shows that we need to finish training additional 1401 Lead demonstrators and possibly schedule additional 1401 demos during the week.

    Jack Ghiselli mobile 1-408-839-1051

    IBM 1401 Demo Status Report 6/21/2023 - Pat Buder & Samual Plainfield
    with comments about Frank King making an 027 keypunch work
    from Pat Buder
    On Wednesday, 6/21/2023, Scott Stauter and I gave the demo to a diverse group of 37 visitors. An additional 30 came by before and after the main demo. Our guests were from the Czech Republic, Turkey, Scotland, France, India, and of course Canada and the states.

    We ran on the German machine due to the CT 1402 issue. DE performed very well, including all three tapes controlled from the TAU. The 001 and 083 also were fine. The 026 keypunch closest to the door is still down. The one furthest from the door had very faint printing. Tripping the ribbon reverser only helped a little, as the end of the ribbon was by then pretty ink depleted.

    Before and after the demo Samuel Plainfield and new restoration volunteer Henry Strickland helped the visitors punch their BigPrint name cards and then sent them down to us run on DE. Many thanks for the help.


    from Samuel Plainfield

    You bet -- Henry is great with the guests!

    With Henry's help, Frank and I had some time to test the vacuum tubes on the keypunch closest to the closet. Frank has a clever trick by which he makes use of #3 socket to test the tubes since it is connected to the ESCAPE MAGNET and thus requires a strong signal to activate the relay.

    So, by putting a suspected bad tube into socket #3 and measuring it, it is readily apparent whether the tube is at fault or not. Turns out, tube #7 was weak (not fully bad...yet). The second part of Frank's trick is to make use of the "bad" tube by placing it in socket #8, ALPHA FIELD where it is only responsible for activating the number/alpha characters and doesn't require a strong signal to do so.

    By the way, Frank is so tough he doesn't use gloves to remove the hot tubes!

    ~Samuel Plainfield

    a place to hold info until June 21
    from Ken Shirriff - in response to this Demo Report
    One more piece of status. Jack mentioned the fuse light on DE drive #3 and that it was making more noise than the others. The problem is circuit breaker #6, which I've reset several times (by pushing it in). This circuit breaker is for the vacuum pump and blower. I suspect that the vacuum pump or pressure blower has a problem that is making it noisy and eventually tripping the circuit breaker. It probably needs some maintenance.


    from Marc Verdiell
    Oh I’ve been in that vacuum pump before. It’s a previous offender. I cleaned it mostly, but never figured out the root cause for sure. These pumps are very weird!

    CHM 1401 Demo Report -- Saturday 6/17/2023 at 11:00 AM and 1:00 PM - from Jack Ghiselli
    11:00 AM DEMO: Duane Sand and I gave the 1401 demo Saturday 6/17/2023 at 11:00 AM to 44 people, plus mini-demos before and after to 7 more. We had a group of very interested young techies from NASA Ames Research center, who were surprised to learn the CHM had once been housed there. We had international visitors from Canada, Switzerland, and Taiwan. Since the CT1402 is still not working, we gave the demo on DE.

    Prior to the demo, we used the Ron 2.1 Tape exerciser to test the 729 Tape Drives on DE. DE Sense Switches E, F, and G are still inoperative, so we patched the Ron 2.1 deck so that it's not necessary to turn on SS F to print statistics.

    Tape drive #1 (left-most) ran OK, writing 4944 1000-byte Low Density blocks with no tape errors. It appears that the SELECT lamp on Tape #1 is burned out.

    Tape drive #2 (center) ran fairly well, writing once cycle of 4606 Low Density blocks with 16 Tape Write Errors, and a second cycle of 4599 blocks with 6 Tape Read Errors. We don't know whether the errors are due to the particular reel or the drive.

    Tape drive #3 (right-most) would not run at all under software command with Ron 2.1.

    The statistics seem reasonable. One 1000-byte block at Low Density (200 bytes/inch) takes about 5 inches of tape, plus an 0.75-inch Inter-Record Gap. So, the total blocks written on Tape #1 should take about 2,369 feet, which is about right for a 2,400-foot reel up to the end-of-tape reflective spot.

    We decided to use the TAU for the demo, and all three tapes did move under control of the TAU for the demo itself. Tape #3 is very noisy.

    We noted that the print quality on the DE 1403 is getting very faint. Is it possible to re-ink this ribbon? Here are today's tape statistics printouts:

    Audio Headset #1 broke when Duane was removing it after the demo, so we opened one of the packaged spares and replaced it. Hooray for spares!

    1:00 PM DEMO: Yash Lala and I gave the 1401 demo Saturday 6/17/2023 at 1:00 PM to 59 people, plus mini-demos afterwards to 6 more. We had international visitors from Austria, France, Germany, India, Singapore, Slovakia, South Africa, and Turkey.

    I dropped and broke one of the demo vacuum tubes. After the demo, we vacuumed up the broken glass, and replaced it with a new vacuum tube from the Babbage supply room.

    Keypunch #3 (closest to the closet) is still Inoperative. It feeds, but doesn't punch cards. Keypunch #1 (farthest from the closet) sometimes prints very faint when near the ribbon-reverse point. However, once back to the main portion of the ribbon, the print is very good.

    After the demo, I spent some time copying parts of Stan's disk from the CT machine PCWRITE computer. I'll look at these at home. They appear to be ROPE source files for some of our demos.

    Jack Ghiselli mobile 1-408-839-1051

    CHM 1401 Demo Friday 6/16/2023 10:15 AM - from Jack Ghiselli
    Karen Sun and I gave the 1401 demo to some special visitors arranged by Kate McGregor. We combined two small groups Kate had invited.

    From The Tech Interactive were: ... (3)
    From Sanford, we had: ... (1)
    Via the Robot Avatar, linked in from beautiful Homer Alaska, we had Kate McGregor.
    On the left is me, in the center is Kate McGregor on the Robot Avatar, and on the right is Glenn Fajardo, Chief Learning Officer for the Global Innovation Race.

    Glenn Fajardo plans to bring a special group of about 60 high school entrepreneurial students from his program to CHM on Wednesday 7/5. Kate would like to arrange a special demo for this group, hopefully not to conflict with the normal 3:00 PM demo, nor the Restoration group's work. I spent some time talking to Glenn, and he would like the demo for his group to emphasize entrepreneurial aspects of the 1401, and how it led in to following stuff like the SY/360. We think this large group should have a Lead and at least two Operator volunteer demonstrators.

    Since the CT1402 is still down, we ran the demo on DE. Last Wednesday, Ken Shirriff (yay, Ken!) fixed the FUSE error on DE 729 #3 (right-most), and we were able to run it from the TAU, although it made more noise than the other two drives. We were NOT able to get Tape #3 to operate with the Ron 2.1 Tape Exerciser program -- that is, to operate from actual tape software instructions. Keypunch #3 (closest to the closet) is still INOPERATIVE.

    As a side issue in working on tape-resident demo software, I created a card deck with all 63 possible BCD card-code punches (skipping Substitute Blank), successfully read it on the DE 1402 and listed it on the DE 1403. I'll use this to investigate the ROPE character encoding used on Stan's PCWRITE software on CT when CT is back up.

    Jack Ghiselli mobile 1-408-839-1051

    IBM 1401 Demo Status Report - 6/14/2023 - from Pat Buder
    On Wednesday 6/14, Yash Lala and I gave the demo to 63 visitors. An additional 23 dropped by before or after the demo. Many of them were highly technical, including four who work on compilers. They were very interested in the multi-phase technique used by the 1401 Fortran compiler. Others included a group of teenage girls, whose apparent leader said the 1401 was cool. We also had a mom (dentist) with her extremely curious ~8 year old stop by in the morning. I gave them an extensive, personal mini-demo.

    The 026 closest to the door was marked Inoperative and the one furthest from the door was printing faintly. I jiggled the ribbon reverse, which helped some. The 001 keypunch and the 083 sorter worked well. We used the DE machine because the CT 1402 is still down.

    At the start of the demo Frank King was just leaving, so we had the audience give him a hand on behalf of the entire restoration team.

    During the demo DE ran BigPrint, Powers of Two, and the tapes via the TAU without a hitch. After the demo, Yash and Jack Ghiselli handled running BigPrints while I answered many questions from the audience. Thanks for helping out, Jack.

    When shutting down we had to hunt for the horseshoe keys. We eventually found them inside the restoration room.


    Restoration Reports for Wednesday 6/14/23
    - from Robert Garner -
    Summary Weds, 6/14/23
    - from Robert Garner - Liebert Air Conditioner
    - from Samuel Plainfield - CT1402 Code Wheel
    - from Marc Verdiell
    - from Grant Saviers
    - from David Clementson
    - from Ken Shirriff
    - from Bhushan Mohan
    - from Robert Garner - Summary Weds, 6/14/23
    Here's the 1401 restoration team’s weekly report: volunteer hours, repair work synopsis, photos, and detailed individual status reports for last Wed, June 14th, 2023. Our heated battle with the recalcitrant CT 1402 continues...

    1401 Restoration Hours: 6/14/23
    Clementson, David 6
    Garner, Robert 4
    Howard, John 6
    King, Frank 6
    Plainfield, Sam 8
    Shirriff, Ken 7
    Verdiell, Marc 6

    Repair Work Synopsis:

    • David, Ken, Marc, Sam, and John continued their valiant effort to repair our recalcitrant CT 1402 reader.
      • David (temporarily) repaired the code wheel crack via superglue and some splints.
      • Cards intermittently pause during continuous reads (1401 test program: read/branch back), arriving late at the first brush and getting missed (by both brushes).
      • One of the throat feed roller bearings was immobile. The bearing block was removed and the suspect bearing freed up. David had freed and oiled the stuck bearing last week, but perhaps due to metal shards from a broken keeper, it had seized up again. Plan is to measure the bearing ID and order a new bearing pair. Nevertheless, in a quick check with time running out, freeing up the bearing didn’t solve the problem: the 1402 threw Reader Checks (not Stops). Grrr...
      • Using Bhushan’s brush timing measurement method, Ken captured traces and later wrote some some analysis software. He found that solar cell pulse width varies from 2.30 - 2.98 degrees, and pulse jitter varies by up to 3.20 degrees. The card arrival time at the first brush varied from 0° (excellent), 7 degrees (bad), to 44 degrees (catastrophic).
      • Grant Saviers and Mike Stewart (Apollo equipment restoration colleague of Marc & Ken) will be manufacturing new code wheels on their Stereolithography (SLA) 3D printers.
    • Frank worked on repairing 026 keypunch #3 (closest to door) that is not feeding and exhibiting other unexplainable behavior.
    • ACCO Engineered Systems repaired our Liebert. The Demo Lab was sufficiently cool, even with both systems running and a large demo crowd.
    • Reminder: The Turing Conference room upstairs is reserved for the 1401 restoration and demo team every Wednesday, 12 noon to 4 pm. It’s a nice quite place to shoot the breeze, brainstorm problems, and enjoy lunch. :)


    John, Ken, Mace, David, and Sam solemnly mull over strategies to fix our recalcitrant CT 1042 reader: (Take no notice of the large hammer on the front left side of the 1402. :)

    Ken, John, Marc, and David (Pat in background):

    Ken (off camera), Marc and John discussing measurements from Marc’s fancy scope. (USB stick, lower left, to record traces):

    Marc and crew adjusting the reader timing. Scope probes record solar cell pulse timing):

    Frank working on 026 keypunch #3 and Jack punching up a program:

    Demo crowd enjoying the DE 1401 at work, valiantly covering for his CT sibling:


    Detailed Individual Status Reports:

    from Robert Garner - Liebert Air Conditioner
    In case you hadn’t heard/experienced today — thanks to quick action by the museum staff — the Liebert has been repaired! The room was cool for today’s demo, even with a big crow and both 1401s running.

    According to Jennifer:
         "Both circuits for Liebert were low on charge due to leaks. ACCO evacuated the system, checked/repaired leaks, recharged with refrigerant.”


    — Robert

    p.s. When I turned the Liebert on this afternoon, while plenty of cool air was flowing into the Demo Lab, I noticed that its alarm was still sounding. I presume because half the system (i.e, one of the compressors) is still inoperative? I didn’t note the error code…

    - from Samuel Plainfield - CT1402 Code Wheel
    David removed the CT1402 code wheel to attempt a fix. The fix was successful using super glue and a series of clever clampings.

    In case any of you were curious what the code wheel looked like under magnification, wonder no further!

    As you can see, the crack is quite pronounced. The 3D printed code wheels look like they might work if we need them, but for now it seems like this specific problem is fixed as I am sure Ken & David will elaborate further on.

    Here it is again after the glue fix has been applied. David also "flushed out" all the other sockets that were filled with grease, dust and gunk.

    After making myriad timing adjustments, the CT1402 is oddly pausing at the second clutch cycle (intermittently) when continuous read mode is manually inputted into the CPU. That is, set to repeatedly request a card (Opcode 1), branch and loop indefinitely. The only way this could happen, we theorize, is because it is waiting for a signal from the CPU to permit the clutch to engage. There is no READER STOP error, the continuous rollers keep going and the clutched rollers are paused. So, in addition to all the hardware 1402 conditions, there's also myriad conditions that have to be met on the software side to permit the clutch to engage -- all/many of which will be tested next week with Ken's unmatched understanding of the CPU.

    Moreover, it has been discovered that the throat bearing (which we also believe to be the culprit for a dramatic card jam) is badly worn, likely preventing cards from feeding intermittently. It is hoped that we can get a replacement from Yosemite before next Wednesday.

    ~Samuel Plainfield

    - from Marc Verdiell
    Summary of my day
    • David did a convincing fix of the code wheel with crafty application of glue. Seeing that the original part is in plastic, I think we should make a new one using a high resolution SLA print. I could do one at work, but Mike Stewart (our star Apollo restorer crew member) was visiting the Museum today with his co-workers, and has his own SLA printer, so we just gave him the 3D file to print. We should get a high quality part shortly.
    • I verified that the clutch was not only latching, but also unlatching exactly as it should (it has a two-step unlatch that’s very clever). The clutch appears to work and be adjusted perfectly.
    • With the repaired wheel, the “good” cards read in the middle of the pulse on both brushes. However we still see some cards that arrive late at the first brush and get missed (by both brushes). We are running out of things that can cause this: knives appear well adjusted, throat clearance is smack on, clutch is good, rollers are good.
    • However, we found that one of the throat feed roller bearings was stuck hard, not moving at all! This could certainly cause a card arriving late at the first brush. David had noticed this during last session, and thought he had freed it up. This time we took the entire bearing block out, got the offending bearing loose again. Once loose, it was perfectly smooth, which surprised me. We will replace it with a new bearing.
    • Anyhow, running short on time, we put the temporarily well-behaved bearing back in, and gave it a quick try. We were hoping that it would finally solve our problem. It didn’t.

    The reader now seems consistent in its behavior, and the timing fault is easy to observe on the scope. Also, the reader appears to sense when a card is out of timing and stops on its own. Curiously it stops with a Reader Check, and not a Reader Stop as we’d expect (we had disabled stops on IO check). Maybe that’s a clue.

    Probably one remaining gremlin to be found next time.


    Received Thursday afternoon

    I’m tempted to revisit our assumption that the feed knives are working correctly. I need to noodle over this a little bit on how we would debug this problem. The stroboscope idea would seem right.


    - from Grant Saviers
    Black PLA filament has arrived, so I will print some wheels shortly.

    Congrats on the wheel bandaid.

    Is the wear on the wheel shown from rubbing on other parts or from accumulated debris? What is the clearance wheel to mask? Since the wheel has a boss on one side, presumably as a spacer to prevent rubbing, was it installed correctly? Also, what is the estimated temperature of the wheel in operation?

    Rear the feed bearing, using a donor bearing with 60+ year old dried out grease is inviting problems. The solvent flushing and oil is an ok emergency fix, but replacing it with a premium quality (not Chinese) bearing is far superior.


    - from David Clementson
    I’ve got nothing else to add to Marc’s and Sam’s excellent reports. To answer Grant’s questions, we checked and found ~2-3 mm of clearance all around the code wheel, so the wear marks must be from prior misalignments. The boss on the wheel is fairly worn, so we assembled it with the boss on the washer side of the assembly, furthest from the shaft. It seems to run true enough, but a nice new SLA part would be welcome.

    The wheel runs at slightly elevated room temperature, maybe 100 F max when the AC is malfunctioning. BTW thanks to the museum staff for fixing the room AC!

    In my experience with ball bearings, it is not uncommon for the keeper inside the bearing to break and leave behind metal shards that can get in the way of the balls. The shards mostly stay out of the way and can fool you into thinking that the bearing is okay. But it is just a matter of time before a shard gets between a ball and the race and locks up the bearing. Replacing the bearing is the only fix. The bearing OD is 0.500” and the width looks to be 0.250”, but we would need to press out the pin and disassemble the block to measure the bearing ID. I would guess that there is a spacer between the bearing ID and the pin, which we need to measure. We can then order a new bearing pair from McMaster or even Amazon.

    That’s it for me. 6 hours.


    - from Ken Shirriff
    I made a program to analyze the oscilloscope traces and measure various factors. Summary: all the measurements have about 2° of fluctuation (which is probably okay). The fixed solar cell wheel looks better than before. The card arrival time is all over the place, up to 44° off, which is disastrous. The feed issue is the critical thing to fix.

    Solar cell pulse width: from 2.3° to 2.98°
    Solar cell pulse jitter up to 3.2°
    For the jitter, I consider the first pulse to be aligned and then look at how far the remaining pulses are from where they should be (18° spacing). There's no consistency to the jitter, so it doesn't seem like a flaw in the wheel. I suspect it's due to vibration and irregularities in the drive speed.

    The card width (the time when the card is under the brush) has about 2° of jitter.
    The hole width has about 1° of jitter.
    The hole is about 13° wide, so with a 3° pulse we have about +/- 5° of flexibility in total.
    I suspect many of these jitters are correlated, if they are due to the overall drive speed. That would be good, since they will cancel out. In other words, if the drive fluctuates 1°, the solar cell and hole position will also fluctuate 1° and these will cancel out.

    The big problem is the card arrival time at the first brush which is all over the place. For the data I got, I saw 0° (good), 7° delay (bad), and 44° delay (catastrophic). I don't know exactly why this would trigger a reader check instead of a reader stop, but it's so far off that anything could happen. It's probably not worth investigating why this causes a reader check until we get the feed working better.

    It looks like the arrival time at the second brush is within 1°-2°, so I think the feed between the two brushes is okay and the brushes are aligned okay. But since we didn't run many cards successfully, the sample size is small.

    Time: 7 hours (a lot of analysis time.

    from David Clementson

    Nice data analysis! One question: how does the average solar cell pulse width compare to the 600us spec? We can calibrate this with potentiometer R16 (located below the Dynamic Analyzer) if needed. Also, we should have a look at the illuminator bulb to make sure that it’s securely mounted and relatively immune to vibration.

    Hopefully replacing the throat bearings will stabilize the card arrival times.


    reply from Ken Shirriff

    The pulses are a bit curved, but at the narrow straight part, I measure 550 to 700 microseconds, corresponding to 2.3° to 2.98°.


    - from Bhushan Mohan
    Excellent observations and analysis on 1402 transport.
    Feed throat and Solar cell disk seem to be easily manageable. However the erratic timing of card feed is the root of the problem.
    A few observations would be useful
    1. Scan the memory when machine give reader check due to mis- timing. Is it any particular column giving error or the scan goes without displaying any errors
    2. When machine stops with reader check please observe the last fed card in the hopper. Manual trip the clutch at 315 Index and see the timing of trailing edge at the throat. Normally when belt timing is out by one cog, the reader would give reader check on the first feed cycle itself. Could such an issue be manifesting intermittently? Try examining from that angle also

    3. Any other observations when the timings on scope goes really out?
    Please take care, the more we work on the machine more likely to introduce other problems!

    Best wishes


    Restoration Report for Sat. 6/10/23 - from David Clementson
    ( Robert's Weekly Summary is
    here )
    - info from Stan Paddock
    - info from Grant Saviers
    Summary: no victory yet, but some more stuff found and fixed.

    I went in to have a look at the Solar Cell output pulse width. I found that the adjustment pot was pretty much in the fully clockwise (maximum width) position, yet the pulses were all considerably shorter than the target 600us. Some pulses were only 300us. Here is an infinite-persistence display of the pulse waveform with the cursors set at about 600us. Notice the nearly 2:1 variation in pulse widths!

    I was also able to confirm that the Row 4 aperture on our code wheel is about twice as wide as it should be (Row 9 is the first pulse):

    I was able to confirm that adjusting the pot counterclockwise shortened the pulse. I then recalled that the manual said the Solar Cell assembly is very sensitive to the position of its light bulb. I pushed on the bulb's wire lead a little and remeasured. The pulse width increased to almost 900us average. So I was able to set the pot for an average "short" pulse (not Row 4) to 600us. But we should do something to stabilize the mounting of the light bulb so that vibration doesn't knock it out of whack again. Bulb vibration could also be a cause of the pulse width jitter.

    I also noticed that there is a visible change in the duration of the pulse depending on if the machine is in continuous clutch operation (holding the Non-Process Runout button down) vs. when it is started and stopped:



    I believe the difference in these two plots shows the belt stretch and other clutch timing irregularities due to clutch startup. Note that these plots were captured before I moved the bulb and adjusted its brightness for 600us pulses.

    After I made all of these changes, I still got Reader Checks.

    I then started to get set up for a brush timing capture. When I loaded Sam's "all 5" deck, the machine refused to read the first card at all. We've seen this many times before so I decided now was the time to look into it.

    I started by trying to turn the two ball bearings that support the card as it goes through the throat. Using a dental tool, I could only get them to turn about 1/8 turn before they seized up. I removed the throat plate so I could get a finger on the bearing to see how they felt. I would describe their feel as "crunchy." It was pretty obvious that they were full of grit and barely able to turn. So I spent about 15 minutes carefully instilling isopropyl alcohol drop by drop while turning the bearings. I was eventually able to flush out all of the crud so that the bearings spun freely. After that, I added the tiniest amount of light machine oil. The bearings now feel really good.

    I reinstalled the throat plate and set its clearance to 0.010" (0.009 is a go, 0.011 is a no-go). After that, the deck started every time. However I realized that this deck needs some 1401 setup to allow it to run in spite of the Reader Checks. Since I don't know how to do that, I packed up everything and left for the day.

    I think I'd recommend that we replace the code wheel before we re-time the brushes. Either that or we should fix it or remanufacture a new wheel. We could have one 3D printed, but I think we would need to use one of the more advanced commercial printing processes in order to get the requisite accuracy. If I get a chance, I will make a 3D model and have a 3D print quoted.

    Finally, I found these notes in the binder indicating that we are not the first ones down this path.


    Sent an hour later

    I did a quick 3D CAD model for a new code wheel based on the sketch in the document binder. Should we decide to go this route, we should check the sketch against the actual part before ordering.

    Here is the quote. I chose the HP MJF process in black Nylon 12. I have had good luck with this process and material. I'll bring in a part I did in that process recently for the team to inspect.

    The cost for 10 pieces is the same as for a single piece in case you wonder why I quoted 10.

    However I think it would be preferable to get a genuine IBM part if we have any spares at Yosemite.


    info from Stan Paddock

    In the past, we have had problems with the optical wheel on the CT1402.
    The existing wheel has a crack in it.

    With permission from the staff at the museum, we removed the optical units from the parts machines in the warehouse.

    At the time the CT1402 was working just fine so we decided to let the sleeping dog lie.

    There is a box with optical unit parts in the workshop.
    Don't know where in the workshop the box is.


    info from Grant Saviers

    I checked my Raise3d Pro2 3d filament printer specs against the HP process - identical. Since I've never tried such a thin and precision part , I asked David for the STL file of his model. It seemed like a good learning project. I sliced it at highest density and printed it in red PLA since that was in the printer.

    OD 1.120"
    ID 0.247" base layer/0.237" other layers
    Slots 0.57" base layer/0.052 other layers

    It seems more than strong enough for the application. Red has fair translucence, so probably should use black material.

    Pictures attached. There is a tiny thru hole between every slot seen at the lower right of the microscope slot picture. Likely an artifact of auto path generation of the G-code and shows pretty good accuracy in the printer XY motion. Plus a perfect V slot can't be filled 100% with a round extrusion.

    Some of the layer difference might be because I didn't calibrate Z against the blue 3M painters tape as the mount.

    Note that these slots are much wider than the 0.018" in the Ron Crane drawing, so am wondering if that is the target or is something off in the model, STL conversion, slicing, or printing.

    I think the process is adequate and am glad to try again.

    So I learned a bit about precision printing.

    As a last resort, end mills are available in 0.4mm and 0.5mm diameter (0.0158 & 0.0197") so ~0.018" slots can be CNC milled in 0.035 brass shim stock, which can be chemically converted to a black color. My guess is round slot ends don't matter.


    One other misc thought. The filament in the bulb possibly moves with vibration so it might be interesting to see what changes with a securely mounted LED.

    IBM 1401 Demonstrations Saturday 5/10/23
    11:00 AM - from Stephen Madsen
    - 1:00 PM - from Jack Ghiselli
    11:00 AM - from Stephen Madsen
    Peter Chang and I demonstrated to 63 visitors. Many were from California with others from Washington state, Mexico and China. Since the CT 1402 is not working, we used DE for the demonstration. DE, the keypunches, and sorter worked OK. The keypunch farthest from the door has faint printing. Mic #2 worked OK before the demonstration but stopped working when the demonstration started. After the demonstration, it started working again. There seems to be an intermittent problem.

    Stephen H. Madsen

    1:00 PM - from Jack Ghiselli
    Larry Hara and I gave the 1401 Demo 6/10/2023 1:00 PM to 53 people. We had visitors from all over the USA plus international visitors from Brazil, Canada, China, Germany, India, Japan, Korea, Mexico, Peru, and Spain. The guy from Spain was from the Barcelona Supercomputer Center, and showed us a photo of their installation in a historic church building. Very scenic, but they have more air conditioning problems than CHM.

    Since the CT1402 still won't load cards, we ran the demo on DE. Of the three 729 Tape Drives on DE, only #2 (center) was usable. Drive #3 (right side) had a FUSE error and also would not load. Drive #1 (left side) showed no errors, but also would not load.

    The Liebert air conditioner was not keeping the room very cool, and was sounding an audible alarm.

    The morning demo team had reported that BigPrint demo deck #4 was getting READER CHECK errors. We tried it and agree, but the errors are erratic. Sometimes, the deck loads OK, but other times, it gets READER CHECK errors, not always on the same cards. We checked the deck with VOBJ and the deck is complete and in the correct order. We noticed that this deck may have been punched using the "Adequate" (not "Good") quality card stock. It would help if we have a clear distinction between which card stock is recommended for object decks ("Good"), and which for name cards ("Adequate")

    The morning team reported that A/V mic #2 would not work, and substituted a stand-alone mic/speaker from the front desk. We found that mic #2 was working OK.

    Dave Clementson came in after the demo to continue work on the CT1402. Yay, Restoration Team!

    Jack Ghiselli mobile 1-408-839-1051

    Restoration Reports for Fri. 6/9/23 - from David Clementson and Bhushan Mohan
    ( Robert's Weekly Summary is
    here )
    - from David Clementson, 1st, response, Post Script,
    - from Bhushan Mohan, 1st, response,
    - from David Clementson, 1st,
    Frank, John and I met today to do a deep dive into the clutch. The big headline for the day is that we did not fix the machine, but we found and fixed a bunch of problems and the machine's behavior has changed.
    • We first removed the clutch assembly following the instructions in the Service Guide, paying particularly close attention to making sure that the positions of the rollers on the clutch cog belt position were well marked so that we could restore them to their original phase relations. Once apart, the clutch looked oily but actually pretty clean. The dogs were free to move and there was no stickiness, however we noticed that one of the two dog springs was missing:

    • After quite a bit of searching, John spied the errant spring deep inside the machine. We were able to retrieve it, clean the clutch, reinstall the spring, and reinstall the clutch. We also gave it some fresh grease. We then checked the solar cell timing with the Dynamic Analyzer and found it was still correct, which was expected since we had carefully reinstalled the belt to keep the pulleys in phase. But when we tried to run a test deck, we immediately got a Reader Check error.
    • During prior sessions, we had observed that when cranking the machine by hand with a manually-tripped clutch, the Latch Keeper would typically NOT fall back into place. After servicing the clutch and reinstalling the spring, this behavior is unchanged.
    • Next, we retired to a conference room to have a coffee and a discussion about how, exactly, the card progresses through the machine. We convinced ourselves that because the cards' positions are always under control of one or more roller/pinch roller pairs (some clutched and some continuous,) once the card has entered the chain of rollers, the clutch cannot change the card position relative to the rollers . In other words, while a dodgy clutch could cause a cycle to miss, we could not explain how it could cause a card to get out of position because it is continuously gripped by at least one roller, and all rollers turn in lockstep due to the cog belts. So we reasoned that the only thing that could knock a card out of position was either a sticking pinch roller or some other impediment in the card line.
    • We went back to the machine and unhooked all eight of the tension springs that force the four tension rollers against their driven roller counterparts. This allowed us to rotate each pinch roller to see if any bearings had excessive friction - enough to cause the card to slip with respect to its driven counterpart roller. All of the bearings felt smooth and friction free. We also inspected all of the driven and pinch rollers. Pinch roller #4 (2nd clutched roller) has some minor flat spots on it but the rollers all look fine other than the fact that they are old and somewhat glazed. Frank checked the grippiness of each pinch/roller pair and they all seemed fine.
    • Next, we reinstalled the springs, removed both sets of brushes, and removed the cover plate that holds the card lever switch. We then hand fed a few cards while observing the card line. I noticed an impediment near the roller immediately in front of the second contact roller. Sure enough there was a wad of ripped up card material seriously jammed between the roller and the frame. It took several minutes to dig it all out with a dental tool and tweezers:

      This could definitely explain the problems we have been seeing, but is not really a smoking gun. When we ran a test deck after removing this detritus, we got a Reader Check on the first card. In fact every subsequent error we got (and continue to get) are on the first card.

    • So we turned our attention to the brushes. John noticed that the wire connecting to Brush #1 of the first brush set had broken and was dangling in the air. It looks like this wire had broken before since it had been soldered in place instead of having a new terminal crimped on. So we re-soldered the wire and ran a test deck. Reader Error on the first card. Hmmmm.
    • So I removed both sets of brushes from the machine and took them to the workshop bench for rejuvenation. I replaced a total of eight suspect brushes (six from Set #1 and two from Set #2), and I adjusted any other brushes that were out of position. I also used 600 grit abrasive paper to remove any rust from the tippy tips of the new brushes BTW, we are very low on spare 2-group brushes and the ones we have are pretty corroded. We have LOTS of 3-group brushes, however, and it looks like it would just be a matter of cutting off the extra bristles to convert a 3-group to a 2-group brush. Does anyone know if this is true? Anyway, after reinstalling the brushes - you guessed it - Reader Check on Card #1.
    • Still suspecting the brushes, we used a DMM to measure the 1401's -20V bias on the brushes. A missing voltage would indicate an open-circuit condition (broken wire, bad connection, etc.). All 160 brushes showed proper bias.

    That was the last effort for the day, so we packed up. The big takeaway for me is that the behavior of the machine has now changed to where it generates a Reader Check immediately on the first card. I recommend that when we reconvene next week we check the brush timing with the scope like we did last Wednesday. We should be able to see if we still have timing irregularities now that the clutch has both springs and the wad of card remains have been removed. Or it is possible that the wad of card junk upset the timing for which we compensated by adjustment. Now that the wad is gone, the timing is off.

    I get the feeling we are missing something, like something is unplugged or incorrectly configured, and once that is fixed, the machine should read reliably. And besides glazed rollers, we are running out of things to investigate.

    That's it for today. 8 hours.


    - from Bhushan Mohan -- comment on above,
    My observations
    1. The clutch appears to be clean. The spring would have come out while removing the clutch from the shaft/ ratchet.
    2. Hope the thrust washers have been put back in place on reinstalling the clutch.
    3. Normally we oil the carbon contact roll and the brushes with IBM 6 oil. Wipe off to remove any excess oil. Have never burnished the brushes.
    4. Use only 2 group brushes. The older 3 group brushes are NOT to be used unless the 1st group is cut off. ( Used 3 Gr brushes once and landed up in major card jam and other problems)
    5. Need to scope to reconfirm the timing and transport
    6. Reader Check on first card with no indicative position on scan. This is very common after clutch/ belt is reinstalled. Please confirm the picker knife cam is vertical. Also please recheck trailing edge of card at the throat knife on 2nd clutch cycle is at 72 degrees. If not the reader clutch belt could be off by one cog. Happens very often.

    Just for clarification - did you dismantle the clutch by removing the dog, detent, and the intermediate arm to clean and lubricate?
    How are the pulleys?
    Latch keeper and the latch should be free. Hope it was checked.

    Best wishes


    David Clementson's response
    Hi Bushan:
    1. We are quite certain that the spring did not come out during clutch removal. When found it in the bottom of the machine, the spring was caked in dust and it was pretty obvious that it had been there for a long time.
    2. Yes, the thin thrust washers were in place and were returned to their original location after cleaning
    3. We inspected the surfaces of the contact rolls and found everything was okay. We did not oil them, though. I didn't see anything about oiling them in the documentation but will check again. Is this an undocumented procedure?
    4. Thanks for the advice on 2-group vs. 3-group brushes. And glad to hear that trimming 3-group brushes down to 2-group is a viable option. I will bring in some hard wire cutters and convert some.
    5. Yes, thanks to you we now have a reliable means to scope the brushes. We will recheck the timing next week.
    6. We are absolutely certain that the timing belt did not get off by a tooth. We used two colors of paint pens to put alignment marks on all four toothed rollers and the belt, so a misaligned tooth would be obvious. And the Dynamic Timer showed it was okay. I forgot to mention that after replacing the belt, we did check that the picker knives are adjusted so that the card's trailing edge lines up at the throat at 72 degrees +/- 1 degree. Although the more precise timing would be done by the scope per the manual's suggestion.

    We did not dismantle the clutch but we did verify that everything moved freely and was not at all sticky.

    The pulleys look fine and show only normal minor wear. The 2nd clutched drive roller has a chunk missing from its flange as I mentioned some weeks ago, but I think we agreed that that should not affect its functionality.

    And yes, we did check that the Keeper and Latch are okay and move freely.

    Thanks as always for the input!

    Bhushan Mohan's Response to David Clementson's Response (above),
    In case the spring was out then that is most likely the original problem.
    The present first card reader check appears to have got introduced while working. Well thats my guess!
    Oiling of the contact rolls must have come in one of the CEMs. Originally I think the machine came out with copper/ brass contact rolls and later were changed to the black carbon ones. Oil was recommended only for the carbon contact rolls.

    Best wishes


    Post Script - from David Clementson
    One more thing occurred to me after I published my report:

    Frank reported that before I arrived on Friday, he had adjusted the potentiometer that controls the Solar Cell illuminator brightness. This adjustment is used to control the duration of the Cell's output pulse. Increasing the illumination makes this pulse wider, which would degrade our already minimal timing margin. And this is a particular problem for our machine, since its cracked optical codewheel makes one of the row pulses already wider than spec. Making the pulses too narrow might not provide enough of a current impulse to reliably flip the memory cores (although this is pure speculation on my part; I have no actual knowledge of the cores' requirements.)

    So setting the Solar Cell pulse duration to its correct 600 uS value should be Step 1 when we scope the brushes next time. Incidentally, is there a way we can check the Yosemite inventory for a replacement codewheel?

    @Grant: We have inspected the cog pulleys and they all look good, plus we replaced the clutched cog belt with a NOS one that we had on hand. The new belt had no effect on the problem. There is no detectable play in the belt/roller combination. Besides, one of the symptoms has been that an entire row gets misread, with row 5's being read as 4's. That represents a 0.250" position error. If the belt/gog wear were causing that, I think it would be obvious. I am with you on the glazed rollers, although as I said we checked their static grip and they all seem okay. I would also like to measure the roller diameters, but I don't know the target value. My best guess is that the circumference should equal a card's width, but that is just a guess. All that said, my money is now on that wad of card debris at roller #4 as being the actual culprit. But we have made so many changes/fixes that we may never know the true cause once everything starts working again.

    @Bhushan: I concur that we must have introduced the first-card-fail symptom while working on it. I am a little loath to oil our rollers because our machine is used very infrequently (maybe 4 short decks per week) and I fear that oil would cause dust to collect on the rollers without a lot of use to keep them clean. Plus oil might get transferred to the drive rollers which we already suspect as being glazed and possibly lacking grip. Introducing lubrication there does not seem wise.


    CHM 1401 Restoration Status Reports - June 7, 2023
    - from
    Robert Garner (this week's summary)
    - - More Restoration items at 9 and 10
    - from Ken Shirriff (including update)
    - from Marc Verdiell
    from Robert Garner (this week's summary)
    Here's the 1401 restoration team’s weekly report of volunteer hours, maintenance work synopsis, and photos for last Wed, June 7th; Friday, June 9th; and Saturday, June 10th, 2023. Our vigorous battle with the recalcitrant CT 1402 continues...
    1401 Restoration Hours: 6/7/23 6/9/23 6/10/23
    Clementson, David 6 7 5
    Garner, Robert 4
    Howard, John 6 7
    King, Frank 8 7
    Luo, Mei 2
    Plainfield, Sam 6
    Shirriff, Ken 5
    Thelen, Ed
    - keyboarding ;--))
    Verdiell, Marc 4

    Maintenance Work Synopsis:

    • On Wednesday, Frank, David, Ken, John, Marc, Sam and Bhushan continued their valiant effort to repair our recalcitrant CT 1402 reader. Using Bhushan’s procedure for scoping brush timing, Ken and Marc noticed that the small crack the 1402’s code wheel (that we’ve know about for years) produces an out-of-spec/wide strobe pulse into core memory. Ken, Marc and Dave moved the brush stations closer into spec by adjusting the position of the 2nd brush set. They also adjusted the picker knifes timing (was slightly out of spec, but no play), putting “them back in the middle of the spec.”
    • On Friday, Frank, David, and John convened a special session to continue debugging the CT 1402 reader. Frank adjusted the potentiometer that controls the brightness of the solar cell, adjusting the width of the core strobe pulse. Frank, David and John removed and serviced the clutch assembly. While it appeared “oily, but pretty clean and not sticky,” one of its two dog springs was missing. John miraculously found it on the bottom of the machine "caked in dust.” Disappointingly, reinstalling the spring and clutch assembly didn’t fix the Reader Check errors. They then verified that the roller bearings were good and inspected the pinch rollers, finding some "minor flat spots” on pinch roller #4. While hand feeding cards, David discovered some “ripped up card material" jammed between the roller (immediately in front of the 2nd contact roller) and the frame — another smoking gun, but removing it didn’t solve the problem.
    • On Saturday, David investigated the solar cell output pulse width and the light source/bulb, initially finding a wide variation in pulse widths; that the code wheel’s row 4 aperture is ~2x too wide; and that the pulse width varied depending on whether its running continuously or not. He reseated the bulb and adjusted the control potentiometer for an average spec width of 600 microseconds. Sill Reader Checks. Since a 1st card wasn’t feeding, he then examined the card-support roller bearings; found them seizing up and full of grit; flushed them out with repeated drops of isopropyl alcohol; and then applied some light machine oil. Still, Reader Checks persist...
    • Using dimensions from an earlier hand-drawn code wheel diagram, David made a 3D CAD model and received a quote from Xometary ( for a new code wheel ("HP MJF process in black Nylon 12”) — just $33 for ten wheels. Stan pointed out/reminded us that several years ago, we had extracted (with permission) a code wheel from one of the 1402s in the Yosemite warehouse. Assuming we can locate it in the workshop, we’ll install it next Weds.
    • Bhushan Mohan, in India, contributed many suggestions and ideas for solving our 1401 Reader Checks.
    • Mei and her son Jaden met with Robert about redesigning, revamping, and refactoring the 1401 web site. Plan is that Jaden will prepare some tentative schema/layouts and distribute, with a broader discussion via Zoom and in the Turing Conference room on Weds, June 21st, 4 pm.
    • Jack ran up against our haphazard ASCII-to-BCD character mappings used in ROPE’s modified 1401 Autocoder and Stan’s PC utility (that uploads binaries into the CT 1401 through its serial port). Marc summarized the encodings — Pierce H, Pierce A, SIMH, Stan’s SIMH, and Icelandic — and noted that he had "semi-repaired” ROPE, but that it's "still in a confused state as far as the character options and naming in the interface.”
    • Kate reserved the upstairs Turing Conference room for the 1410 team every Wednesday, 12 noon to 4 pm. As in the past, it’s a nice, insulated, quite place to shoot the breeze, brainstorm problems, and enjoy lunch. :)


    David, Frank, John, and Marc & Ken (behind) stick their hands and noses into on our recalcitrant CT 1042 reader:

    John, David, Sam, Frank, Ken, Marc challenging our embattled 1402 reader:


    from Ken Shirriff
    Summary: I helped get oscilloscope evidence of the card reader problems. The card is delayed going into the first read station after a clutch stop/start. The second read station is too far from the first.


    Bhushan explained in email how to disconnect a brush and hook up the oscilloscope. The photo below shows the first clutch cycle after a pause.
    The yellow trace is 12 pulses from the solar cell corresponding to the 12 rows: 9, 8, 7, 6, 5, etc. The short low pulses are where the brush status is transferred to the core memory. So it is important that these pulses happen at the right point in the hole.

    The cyan trace shows one of the brushes at the first read station. You can see the curve go up when the card arrives. The hole (a 5 punch) shows up as does the solar cell pulse where the hole is read. The important thing is that the solar cell pulse happens during the hole (good), but note that the card arrives late. I.e. most of the hole is after the solar cell pulse rather than being centered.

    Next, one clutch cycle later, the same card reaches the second read station (purple):
    Now the card is entirely too late and the solar cell read (purple) hits the edge of the hole. Thus, the hole is not read and a reader check happens.

    The other important thing is that the second card (cyan) above is early to the first read station while the first card was late. This card turns up right on time at the second read station (photo omitted).

    To summarize:
    First card after a clutch pause: late to the first read station, too late to the second read station.
    Cards after clutch is running: early to the first read station, on time to the second read station.
    We looked at a lot of traces and these behaviors are consistent.


    1. A card always gets to the second read station later than the first read station by a fixed amount.
    2. The first card after a clutch pause is much later than the remaining ones. This matches what we saw previous weeks, that stopping and starting the clutch triggers the problem. This inconsistent timing is the main problem.

    David moved the second read station closer. The oscilloscope shows all reads happen inside the hole now, but just barely. Samuel's read of all 5 cards worked better, but running a program still encounters reader checks, so this doesn't fix the problem.

    The underlying problem happens when the first roller moves the card through the first read station after a clutch stop. Note that the picker knife moved the card the previous cycle, so the picker knife doesn't seem to be the issue. So maybe there's a problem with the first roller, or maybe there's a problem with the clutch. It seems that the card is somehow slipping or getting fed too late.

    Also, I have a blog post from a few years ago with diagrams of the clutch and some description that might be helpful:
    The green part is constantly spinning, while the rest of the mechanism is clutched. The clutch is geared so it turns 180 degrees during a 360-degree read cycle. Thus, the ratchet has 6 teeth so there are three engagement points per cycle.

    The idea is that the coil (orange) pulls the latch (purple). This releases the intermediate arm, which pivots with respect to the drive arm.
    The dog stud moves with respect to the dog pivot, causing the dogs to swing into the ratchet and engaging the clutch.


    I have some more thoughts on the reader problem.

    1. The solar cell is also an issue. Using the oscilloscope, we timed the system so the read strobes all fell within the hole, barely. Samuel could then read his deck of 5's almost flawlessly. But a real program hit a reader check on the first card? Why? The solar cell has a small flaw, but probably enough to throw off the timing of holes after hole three. (See photo.) If we test a deck of say, 0's, I bet they are all messed up. (Maybe we should add a bunch of 0 cards to the test deck.)

      The solar cell irregularity is probably small enough to not cause an issue if everything else is okay. But when there is a lot of jitter already, the solar cell probably exceeds our error budget and causes reads to fail.

    2. The clutch. Thinking more about the clutch, I don't see any way that you could get a cycle that isn't 360 degrees. The clutch starts and stops when the arm hits the latch, which forces the cycle to be exactly 360 degrees. (If the clutch latches early or late, you'll either get an extra cycle or miss a cycle, both of which are detected and trigger a reader stop.)

    3. The card path. We should manually move the reader through a full cycle and check the cards at each point to make sure they aren't slipping at any point. I think Frank did this, but not for the full path. I still think that a card slipping somewhere is the most likely problem.

    4. Saving oscilloscope traces. By putting the oscilloscope on 1 second per division, we were able to record multiple card cycles and still zoom in to see the details of each hole. It would be good to save this data for further analysis.
      To save data to a USB drive, the process is a bit tricky, so I've written out the steps:
      1. Insert a FAT32-formatted flash drive (i.e. DOS not Mac).
      2. Press Storage.
      3. Change the storage type to "Wave". This saves the entire waveform rather than a screenshot, so you can examine it later in detail.
      4. Then click the menu button for "Save".
      5. Then select the USB disk "Disk D".
      6. Then "New file".
      7. Then "OK". (No need to enter a filename.) The directory should then show "NewFile1.csv" under "D/".
      Alternatively, simply pressing the green printer button in the upper-right will save a screenshot, but then we can't zoom in later.


    from Marc Verdiell
    Helped with the 1492 debug. Bushan’s scoping method worked like a treat and clearly showed two timing problems:
    1. brushes too far apart (the problem enhancer)
    2. inconsistent arrival of the card at the first brush (the root cause)
    When the card arrives too late under the first brush, the second reader is even later and will simply miss the hole.

    We adjusted the 2nd brush timing, which made things slightly better, and leaves us with problem #2. It appears to be a transport problem. Fortunately the reader transport is far simpler than the punch transport, there are not that many adjustments.

    Timing of the 1st card is controlled by the picker knives and the clutch *unlatching*. We checked that the picker knives where adjusted properly. They had no play. They were very slightly out of spec in position, but barely. Not enough to explain the card position inconsistency. We adjusted them back in the middle of the spec nonetheless.

    Which leaves us with the clutch. David observed that it didn’t always unlatch properly when we hand-cranked the machine. Sluggish unlatching certainly could explain the problem. I think it’s time we finally take the clutch out and give it a proper service.


    CHM 1401 Demos Saturday 6/3/2023, 11:00 AM and 1:00 PM - from Jack Ghiselli
    On Saturday 6/3/2023 at 11:00 AM, Peter Chang and I gave the 1401 demo to 43 people, plus mini-demos to 3 more who wandered in late. On Saturday 6/3/2023 at 1:00 PM, Karen Sun and I gave the 1401 demo to 66 people (quite a full house). Paul Laughton had been scheduled as Lead, but he had some voice problems, so I substituted for him. We had visitors from all over the USA, and international visitors from Australia, Brazil, China, Italy, Japan, and Singapore.

    Since the CT1402 is still getting Reader Check errors, we ran the demos on DE. The DE hardware ran well, as did the three 026 Keypunches and the 083 Sorter. When setting up the demo, we found that BigPrint demo deck #4 would not load. We ran VOBJ to diagnose it and determined that cards #3 and #4 had been moved to just ahead of the last card (#111). Since Card #3 is part of the Bootstrap, the deck always failed. Peter Chang corrected the deck and now it works fine. We speculate that somebody got a Read Check loading this deck, and somehow shuffled the deck when using Non Process Runout on the 1402 to run out the two cards in the mechanism. As noted before, we might need more training for demonstrators in how to recover from a 1402 Reader Check error.

    Paul Laughton was brave enough to attempt to load software from tape, using one of Marc Verdiell's loadable tapes from the Restoration workshop, but was unable to get it to load. We'll have to keep looking into loading software from tape, but it's not yet ready for ordinary demos.

    After the demos, I spent some time perusing the disk on the IBM PC attached to CT. I found a large number of demo programs, including ROPE Autocoder source that seems close to matching our demo versions of BigPrint and Powers of Two. There might also be source for the PCWRITE software on the IBM PC and the SERVER software on the CT 1401. When we get more time, this is worth further investigation.

    Jack Ghiselli mobile 1-408-839-1051

    CHM 1401 Restoration Status Report 6/2/2023 from Jack Ghiselli
    Hi Marc,
    Thanks again for showing me the Tape Emulator, and the Loadable demo tapes you had already created. Unfortunately, I can't come in to the CHM next Wednesday (6/7), t but hopefully could continue another Wednesday in the near future. Instead, I came in today (Friday 6/2), to look into some of the tape-related issues.
    1. I was worried about the high frequency of magnetic tape errors. When we run the "Ron 2.1" Tape Exerciser program (which writes to mag tape from software) and look at its error statistics, we were seeing over 30% tape write errors. Such a high error rate would prevent writing useful tapes. However, we've been running at the default High Density, and Marc explained that the CHM drives run much better at Low Density. If I recall correctly, the CHM drives are set up so that High Density is 556 Bits/Inch, and Low Density is 200 Bits/Inch. Today, I tried running the Tape Exerciser at Low Density on the two DE tape drives that are working (Drives #2 and #3). Sure enough, as usual Marc was right. I was able to write over 12,000 records to each of the two drives without a single write error. Clearly, we should always be running in Low Density if we expect actually to use the tapes for data.
      1. Last Wednesday, we couldn't see the Tape Write Error statistics on DE because Sense Switch F (which enables printing on the Ron 2.1 program) was broken. So, today I patched the program so it always prints. Who needs Sense Switches anyway?

    2. Since we had some difficulties using the Tape Emulator on DE last Wednesday, I decided to try Stan's Serial (Paper Tape) interface system on CT, and see if it was a possible alternative method for writing loadable software demo tapes from ROPE object files. Marc, you were young, invincible, and pretty on DE last Wednesday, but today I was old, decrepit, and ugly on CT.
      1. The CT1402 is still getting Reader Check errors, but if you are VERY patient and careful with card-handling you can recover and continue from most Reader Check errors, and eventually get a deck to load on CT.
      2. I loaded the Ron 2.1 Tape Exerciser program, but it would not run on any of the CT tape drives, even at Low Density. Drive #3 is down with a disassembled read/write head, but none of the other three would write. They get maybe one Write-Tape instruction and then hang. You can move the tapes using the TAU, but you can't write to them with software.
      3. I loaded Stan's "Server" program (the CT1401-side software of the Serial Interface), and was able to use the Serial Interface to read a ROPE object deck from an IBM PC Thumb Drive, and punch an object deck on the CT1402 Punch. 2
      4. I was able to use the Serial Interface to print ROPE Autocoder source, card-object, tape-object, and assembly listing files to the CT1403 printer.
      5. I was able to use the Serial Interface to load a ROPE object file (Lincoln) directly into CT1401 memory and execute it. I suppose this could be a method of running a demo on CT even if the CT1402 and all the Tape Drives are down. 2
      6. The Serial Interface supposedly has the ability to write ROPE tape-object files to CT 729 Tape, and to write Tape Marks. Unfortunately, these functions didn't work today, possibly because the CT Tape Drives weren't writing correctly.
      7. When using the Serial Interface, I observed the IBM PC displaying some error messages regarding errors in translating certain characters from IBM PC ASCII to 1401 BCD. I asked Stan to see if he can find the source for the IBM PC and 1401 software, and with these perhaps we can track down what's happening there. The ROPE Autocoder Assembler does have assembly-time options for selecting any of three different character encodings. I've been using the one called "Traditional".

    3. The CHM does seem to have several private libraries of ROPE demo programs, with some slight differences. I found a source version of BigPrint, but it is a different revision that we've been using from object card decks, and the source uses some private macros which I haven't yet tracked down. You guys with more history with the Restoration effort probably have a better handle on this than I do.

    4. When you try to do Restoration work while the CHM is open, lots of interested visitors interrupt you and want to talk about the 1401. Today, we had visitors from all over the USA, and international visitors from Germany, India, Saudi Arabia, and Turkey.

    Jack Ghiselli mobile 1-408-839-1051

    1401 Restoration Status Reports, mostly Wednesday - 5/31/2023
    My 1401 Restoration Status Report 5/31/2023 - from Robert Garner
    - My 1401 Restoration Status Report 5/31/2023 - from Ken Shirriff
    - Restoration Report for 05/31/23 - from David Clementson
    - Restoration Report for 05/31/23 - from Marc Verdiell
    - Sense Switch trouble on DE - from Samuel Plainfield, - from Jack Ghiselli, - from Ken Shirriff,
    1401 Restoration Status Report 5/31/2023 - from Robert Garner
    Here's the 1401 restoration team’s weekly volunteer hours, status summary, photos, and detailed individual status reports for last Wednesday, May 31st:

    1401 Restoration Hours: 5/31/23
    Clementson, David 6
    Garner, Robert 4
    Howard, John 5
    Plainfield, Sam 6.5
    Shirriff, Ken 4
    Szolyga, Tom 6
    Verdiell, Marc 4

    Status Summary:

    • David, Ken, Samuel, John, Marc, and Tom continued to analyze and brainstorm the recalcitrant CT 1402 reader. Ken, David and Sam scoped the hole strobe timing (below), which looked good. However, our problem (the read sometimes tardy by an entire row) occurs when the 1401 pauses the 1402, so this particular measurement isn't fully demonstrative.
    • At the end of the day, David & Sam replaced the clutch belt, but that didn’t fix it. When checking the picker knife timing, as David hand-turned the motor pulley, we could see the clutch disengage sooner than expected, suggesting an issue with the clutch itself (perhaps adjustments, below, or contamination?).
    • Jack found that "if you're patient and careful with card-handling, you can recover and continue from most Reader Check errors" on the CT 1402, and eventually get a deck to load. :)
    • When Jack ran Ron Williams' tape exerciser program on the DE 1401, it didn’t respond to the sense switches. He also found that it only works reliably in low-density mode (200 bpi).
    • Jack also tried running the tape exercise program on the CT 1401, but the drive hung and didn't get beyond the first write-tape instruction. (Note that DE 729-3 is still down with a disassembled read/write head.)
    • Jack used Stan’s PC-to-serial interface to load the Lincoln demo program into the CT 1401.
    • Marc introduced Jack on run-in the Power-of-2 and Lincoln demo tapes, on both the DE 729-1 tape drive and our 729 Tape Emulator. Not to be bested, soon thereafter both the tape drive and the tape emulator died/failed. :(

    Photos and diagrams:

    David, Ken, Sam analyzing/psyching out our recalcitrant CT 1042 reader:

    Front-to-back diagram of the gears, cam shafts, contact & feed rollers, and clutch of the 1402 card read path: (The clutch is in the back, driving belt #609124)

    Back-to-front photographs of the 1402 card read mechanicals: (The large motor-driven pulley/disk in front.)

    1402 reader clutch diagram and principles of operation: (from I can’t say that I fully understand how it works. IBM enlisted quite clever mechanical designers.. :)

    My 1401 Restoration Status Report 5/31/2023 - from Ken Shirriff
    Summary: I worked on the CT card reader with Sam and David. We haven't figured out how to see the brush timings that we want. 4 hours.

    Our theory is that cards are read okay if reading is continuous, but the card gets delayed slightly if reading pauses. This could be a clutch problem, a belt problem, or a roller problem. We want to see the brush reading the hole on the oscilloscope so we can prove that the hole (and thus the card) is getting to the brush late.

    The problem is that in normal use, a brief signal is sent to the 1401 when the brush is in the middle of the hole so we can't see the rest of the hole. This is strobed by the solar cell, which generates 12 pulses, one for each row, as the card is read. We can see the entire hole when using the dynamic timer, but the card reader isn't controlled by the 1401 during this process, so we can't stop and start card motion, which triggers the problem.

    With the dynamic timer, we can see the brush contacting the hole (between the white vertical lines) and the strobe (negative yellow pulse from the solar cell). The strobe isn't exactly centered in the hole, but it seems close enough.

    I examined the schematics to fill in some of the details of what's going on with the strobe and the dynamic timer. First the solar cell and brushes circuit (Sections 7/8):

    I redrew the circuit to be clearer below, and you can see that it is a 5-transistor amplifier, pulling the output to ground on each pulse. The idea is that this circuit drives the common for the read station. Each brush is connected to the 1401 where it goes through a 150 ohm resistor, directly through a core, and then to -20 volts. Normally the driver below holds the brush common at -20 volts, so there is no current through the core. The solar cell triggers 600 microsecond pulses to ground, one for each row. If the brush makes contact, this will flip the core.

    One mystery is how the dynamic timer displays the whole brush rather than the 600 microsecond strobe. The answer is that the dynamic timer has a floating power supply (with vacuum tubes), so it can energize the brush independently of the -20 volts.

    In a bit more detail, the dynamic timer has two modes. In cam mode, the RD CAM DISPLAY SWITCH (A) pulls COM to ground, and thus pulls the grid to ground. SWITCH (B) connects the cam selector to COIL LO-V and then to the cathode (more or less). If the cam is open, the input is at ground, no current flows through the tube, and the light is off. If the cam is closed, the -20V cam input pulls the tube's cathode below ground, so the tube turns on and the neon indicator lights.

    Brush mode is completely different. First, the brush common is connected to a high-ish voltage through the diodes to the right of the tubes, and the brush common is disconnected from the solar cell. This is the same voltage on CONT. If the brush makes contact, this voltage comes back into the dynamic timer through the brush switch to COM, pulling the grid high, turning the tube on, and lighting the light. Note that in this case, there is no ground connection between the dynamic timer and the rest of the card reader, which is why we saw everything floating on the oscilloscope. This ensures that the timer's brush voltage doesn't affect the cores. (Sections 15/16 below)

    So how can we see the brushes while the 1401 is running? My idea is to inject a small AC signal into the brush common through a capacitor (e.g. <1 volt, 10 KHz through 100 nF). This signal should be small enough to not affect operation of the cores, but should be visible if we attach the scope to a brush.

    1402 schematics are here:


    Restoration Report for 05/31/23 - from David Clementson
    At the start of the session, the team met and discussed strategy. Marc pointed out correctly that a systematic, analytical approach to finding and fixing the root cause of a problem is usually the most foolproof debugging method, as opposed to simply replacing parts to see what happens. So instead of just proactively replacing the clutch drive belt (the prime suspect at the time) we pivoted to trying to scope the brush timing.

    As Ken described in his status report, the brushes are energized only at the proper row read times courtesy of the solar cell and a pair of amplifiers that drive the two contact roller's common brushes. Our initial scope effort was to confirm that this is indeed the case, and the waveforms showed that it is. As Ken also described, if we want to see the whole hole, the rollers would need to be energized continuously. We thought that a mode of the Dynamic Analyzer would do this, but it turns out that it does not, and all we could see on the common brushes was what appeared to be a floating no-connect. This is due to the fact that the whole Dynamic Timer is electrically isolated from the rest of the machine via an isolated power supply. The waveform looked like a random AC sine wave. But through some careful scope trickery, Ken was able to find scope artifacts that could rationally be interpreted as brush contact events. The timing of those events aligned well with what they are supposed to be and what the Dynamic Analyzer showed. So we did not see evidence of improper brush timing.

    HOWEVER, all of these observations were made when the machine was disconnected from the 1401 and therefore reading cards continuously. But our prior observations pointed to the Reader Check errors happening during intermittent reads, So we weren't really able to replicate the conditions under which the errors had been observed. We would need to be connected to the 1401 to do that. So we concluded that it was not easily possible for us to make the kind of brush timing analysis that we wanted. Bummer.

    By this time the Demo was about to begin, so the team retired to the workshop for more brainstorming. It became clear that there are several "camps" of proponents of the different root cause theories. "Camp Belt" thinks that belt stretch is the cause. Camp Clutch feels that the clutch is at fault. Camp Roller and Camp Spring think that the drive rollers or their pinch springs are at fault. So we talked about how we might add some metrology to the system to hopefully capture the problem red-handed.

    After the Demo had ended, the Camp Belt True Believers endeavored to replace the belt, even though doing so (per Marc) earns no points for style. Granted.

    Replacing the belt and retiming the solar cell was surprisingly simple, and took about 20 minutes. We carefully noted the solar cell's wheel orientation on its shaft with a couple of dots from a paint pen, and we were able to get its timing restored without a lot of hassle. The Dynamic Analyzer showed the solar cell pulses still occur at the correct angles. Unfortunately, when we tested the system, the same old Reader Check errors occurred at the usual 4th card in the Lincoln deck, which has become our standard test stimulus. So Camp Belt has been disbanded.

    While working on validating the Picker Knife timing, we noticed that while triggering the clutch by hand, it seemed to have trouble disengaging correctly. Proper clutch disengagement is not visible in the scope displays we have made to date since it occurs at the end of the read cycles when all of the solar cell pulses have come and gone. While a faulty disengagement itself may not generate misreads (because it happens after all of the holes have gone past), a bad disengagement may sow the seeds of a read error for the subsequent card (or the next set of brushes.) Camp Clutch may be on to something, and I would bet that the machine has a clutch teardown in its future.

    One other observation comes from Sam's printing of the "all 5's" deck. Sam prepped a deck with punches in all columns but only in row 5. When appended to a 'print the value of whatever card you read' program deck, the resulting printout shows three kinds of prints:

    1. a row of 5's, which is the correct/expected result (this happens most often by far)
    2. a row of only spaces (this happens less frequently than correct reads)
    3. a row of mostly blanks with occasional 4's (this happens less frequently than the blanks)

    If a 4 is ever read, this means that a brush made contact incorrectly during the "4 time" instead of the "5 time." As I understand it, the 1401 keeps track internally of the current row number based on the number of solar cell pulses it receives via wire RC188, so it knows when to expect each row and can file them accordingly. Since the row read order is 9, 8, 7, 6, etc., the "4 time" is after the "5 time", meaning the brush contacts is too late, and the card must be tardy by a whole row (0.25") as it goes through the transport. When spaces are read, I think the card is tardy by half of a row, meaning that the data is captured when the brushes are between rows and no punches are detected (i.e a space.)

    A second facet of this observation is that the error must be occurring at the 2nd brush set since the data is corrupted. It may have also been misread ar the first set of brushes, but it is clear that the problem is not restricted to the first set of brushes as seemed to be the case earlier.

    That's it for today.. 6 hours.


    David's comment on Ken's write up (above)

    Nice write-up Ken. I finally understand those transistor circuits!

    One other way to see the brush signal would be to first opto-isolate the solar cell reference signal going to the scope, then ground the scope to the common terminal of the Dynamic Analyzer while probing the brushes. Like the floating Dynamic Analyzer itself, floating the scope using a 2-wire power cord would keep it from interfering with the 1401.

    I made a little dual opto isolator board for viewing the signals on the 083 sorter that we could use to isolate the solar cell.


    David's note to Bhushan Mohan - May 26, 2023

    Hi Bhushan:

    I have been using the CE Reference Manual, in particular the section starting on page 3-1. It is online here: The errors are always happening on intermittent reads, so yes, the clutch is implicated. However, we have used a digital scope to compare the timing between the onset of the clutch solenoid drive signal ( the "input" to the clutch mechanism) and the first pulse generated by the solar cell (the "output" of the clutch mechanism plus the belts and pulleys that drive the solar cell.) We don't see any evidence of fluctuation in this clutch reaction time for both continuous and intermittent reads. This gives some insight into the health of the clutch, since any hesitation or missing cycles of the clutch would show up on the scope. What this test does not show is the positions of the drive rollers that transports the card under the brushes. For that we would need to observe the brush signals.

    I have not yet looked at the brush timing with the scope as is documented on the Service Index starting on page 2-17:

    I am not entirely clear on how this analysis is supposed to work though, since my understanding is that when the machine is in Online Mode (as controlled by the switch on the Dynamic Analyzer,) the common brush is energized only during solar cell impulses. I would think that this would obscure the actual brush make and break events, since the roller is not energized at those times. However I believe that putting the machine in Offline Mode constantly energizes the common brush, allowing the raw brush timing to be observed. I just don't know how to generate intermittent reads when the machine is Offline. Having said that, looking at the actual brush voltages may show some evidence of brush make and break events even in Online mode, since stray capacitance, etc. may leave a residual voltage on the roller that could be detected. Maybe temporarily adding a slight pull-up resistance to the common brushes may also help.

    All of this analysis may be a bit moot, though, since it turns out that we have an unused replacement belt that looks to be in excellent condition. So why not just replace the belt proactively? The only tricky thing about the belt replacement is that we will need to remove, reinstall, and re-time the solar cell. Retiming the solar cell after reinstallation should be easy enough using the Dynamic Analyzer. We just ran out of time this week. I agree it should be a quick job, but then nothing is quick for us, since we also have to tend to a constant stream of museum visitors while we work on the machines.


    Restoration Report for 05/31/23 - from Marc Verdiell
    I showed Jack Ghiselli the tapes I had written previously of Power of 2 and Lincoln. They loaded fine from DE tape 1 so yoi can run them as demo even if the 1402 is down.

    Then we hooked up the tape emulator to DE and did the same from emulated tape. So you could also demo with the 1402 down AND all the 729’s down.

    Then, feeling young, confident, invincible and pretty, we got ambitious and tried to use the emulator to make one new demo tape for Prime. That’s when everything went south. DE tape 1 failed, refusing to load, and then the emulator failed, becoming unresponsive.

    Therefore, we still feel young and pretty, but a little less confident, and have work for next week.


    from Robert Garner
    Computers get the best of us when we speak highly of them or feel confident 'round them … :|
    — Robert

    - Sense Switch trouble on DE - from Samuel Plainfield
    Of note, earlier in the day Jack was running Ron Williams' tape exerciser program. In so doing, he noted that the program wasn't printing the statistics as it is supposed to do with sense switch F enabled at end-of-reel for either machine. However, they do print when sense switch G is tripped (albeit, sometimes after a delay).

    Jack noted a large number of read/write errors on the media on CT. So, we loaded up a brand new tape to see if it was the media or the machine. The errors persisted even on a brand new tape. So, perhaps it is time for some head cleaning on CT.

    Tripping sense switch G did not stop the tapes or print the statistics on DE. Jack suspected the switches were not working and elected to load up the 8K core memory dump deck which revealed that sense switch G is registering as "off" when it is in fact on. So we flipped all sense switches on and re-ran the deck. The system erroneously reported that E F and G were off.

    ALSO our A/C seems to be having trouble; it was getting quite warm later on in the day. Robert and I both power-cycled the unit to no avail.

    - Sense Switch trouble on DE - from Jack Ghiselli
    As you reported, we found on the DE 1401 that Sense Switches E, F, and G don’t work. When they are physically turned ON (up), programs still see them as OFF. Sense Switches A, B, C, & D work correctly. As a quick diagnostic, we used the “8K Core Dump from Germany” deck from the diagnostic drawer in the Liebert room. Of course the main purpose of this program is to print Core Storage, but it also happens to display current Sense Switch settings. Attached is a printout when we had all Sense Switches turned ON (up).

    - Sense Switch trouble on DE - from Ken Shirriff,
    Some notes on the console sense switches to help with debugging next time.
    The switches are on ALD and go to where they are processed. There's nothing obvious in the logic that would cause E, F, G to fail. Maybe it's simply a loose wire on the switch connections?


    CHM IBM 1401 Demos Loaded from Tape - from Jack Ghiselli
    Given the on-going problems with the 1402 Card Readers on the CT and DE computers, Paul Laughton suggested we look into an ability to load demo programs from magnetic tape. Today, I met with Marc Verdiell, to understand what’s already available at the CHM, and what tools we might have to add more capability. Marc generously gave a lot of his time explaining his Tape Emulation equipment, and what he had already accomplished with it.

    Here’s a quick summary: Marc already has two loadable demo tapes: (1) Powers-of-Two, and (2) Lincoln. They are easy to run, and attached are operating instructions. This means even if BOTH CT and DE 1402 Card Readers were down, we could still demo major parts of the 1401. Yay, Marc. However, we would NOT be able run BigPrint, since Date and Name cards still would need to be loaded via the 1402.

    Although we tried today, we were unable to create additional demo tapes, due to problems with the 729 Tape Drives on DE and the Tape Emulator. I also talked to Stan Paddock about using his PCWRITE system on CT to create tape-loadable demo programs. That’s a second avenue to get what we want. I’ll continue to look into how we could add other demo programs in Tape-Loadable form, and possibly several demo programs on one reel.

    Currently the DE1402 seems to be running well, and the CT1402 is useable with some nuisance in recovering from intermittent READ CHECK errors. So, the use of tape-loadable demos might be moot right now.

    Jack Ghiselli mobile 1-408-839-1051

    Loading-Demo-Programs-From-Tape a pdf file

    CHM 1401 Demos, Saturday 5/27/2023 11:00 AM and 1:00 PM - from Jack Ghiselli
    Yash Lala and I gave the 1401 demo 5/27/2023 11:00 AM to 63 people. We had international visitors from Argentina, Brazil, Japan, South Korea, New Zealand, Scotland, and Turkey.

    Larry Hara and I gave the demo at 1:00 PM. Larry counted 75 people at the peak, probably a new attendance record for us. We had international visitors from Canada, China, Colombia, Honduras, India, and Russia.

    Since the CT1402 was still suspect, we ran both demos on DE. All DE hardware ran perfectly. (Thanks again to Frank King and Mariane Kim for their work yesterday, and the whole Restoration Team for ongoing efforts).

    Unit Record Equipment: We had one temporary card jam on 029 Keypunch #1 (farthest from the door), but easily cleared it. Otherwise, all three 029 Keypunches and the 083 Sorter worked fine. We weren't happy with the sort data deck, so we found an old BigPrint object Deck in the trash which had sequential numbers in columns 73-75 and used that as sort deck. It shows quite well.

    CT System: Before the 11:00 demo, we decided to try out CT, just in case. Frank King and Mariane Kim had warned us yesterday (Friday) that the CT1402 might be usable in a pinch, but would probably get Reader Check errors. Sure enough, it did, but we were able to load and execute BigPrint on CT with only 4 to 5 Read Checks. We carefully followed the standard card handling recovery after each Reader Check, and we were able to complete a BigPrint program load, execute, and print on CT. It makes a slightly clumsy demo, but CT is not in as bad a shape as we thought. We pre-set the CT Tape Drives and TAU as a possible backup in case we encountered problems demo'ing Tapes on DE. But it turned out we didn't need them. CT Tape #3 still has a disassembled read/write head and is dialed to NOT OPERATIONAL, but the other three drives worked fine. It seems that should DE fail during a demo, CT is a not-perfect but possible backup.

    Audio Equipment: Sometime during the morning demo, the audio headset for Mic #2 broke a wire and became unusable. We found an old headset outside the A/V closet to replace it for the afternoon demo. But the mic on this replacement was very weak. We had to turn the audio volume ALL THE WAY UP to get an audible voice on the speaker, and it still wasn't very good. We put a note on the broken headset and left it in the A/V closet. We apologize if our hard usage broke the wire. But it would be great if the CHM A/V staff could look at the mics before next Wednesday's demo.

    Wall Clock: Some Good Samaritan seems to have repaired the official "IBM" Wall Clock, and left it on the table. People complain that we demo guys never fix anything, but I want report that we successfully mounted the clock back on the wall, and no modifications to the nail it hangs on were needed. Thanks, Good Samaritan, whoever you are. We've been using a temporary non-IBM clock, but can now resume declaring that our demos start on Official IBM Time.

    Jack Ghiselli mobile 1-408-839-1051

    Restoration Reports for May 24 and 26, 2023
    - from
    Robert Garner - summary
    - from Bhushan Mohan - pre-work-session
    - from David Clementson - pre-work-session
    - from Ken Shirriff
    - from Lyle Bickley - comment on Circuit Breakers
    - from David Clementson and a comment
    - from Tom Szolyga
    - from Samuel Plainfield
    - from Jack Ghiselli - Friday, May 26, emergency work day
    - from Robert Garner - summary
    Here were our 1401 Restoration volunteer hours for last Wednesday, May 24th and Friday, May 26th:
    1401 Restoration Hours: 5/24/23 5/26/23
    Clementson, David 6
    Garner, Robert 4
    Howard, John 5
    Kim, Mariane 0 4
    King, Frank 8 4
    Plainfield, Sam 8.5
    Shirriff, Ken 4
    Szolyga, Tom 6

    Synopsis (details & photos below):

    • David, Samuel, Ken, Frank, and John continued to analyze, debug, and adjust the recalcitrant CT 1402. Bhushan offered detailed repair advice from India. (See reports below.)
    • Exhibiting sympathy towards its CT sibling, just as we were closing up on Wednesday, the DE 1402 seized up. Frank and Marianne graciously came in on Friday to coax it back in line.
    • Ken and David addressed two misbehaving 729s: DE#3 had tripped one of its circuit breakers and the CT#3 read/write head screw was loose.
    • Tom successfully powered up his serial interface board.
    At end of the day Weds, the DE 1402 tripped all the 1401 panel indicators red.
    Frank: Stay calm and don’t panic. :)

    Marianne and Frank, Friday after the DE 1402 was (Jack’s photo):

    from Bhushan Mohan - pre-work-session
    Very interesting articulation of all activities. Wish I could have been there to contribute.

    Some inputs on 1402 problems

    1. Clutch and feed knife timing. The trailing edge of the card aligns with the throat at 72 degrees ( I hope my memory is right). This shall happen in the 2nd clutch cycle when it is engaged at Index (315 degrees)
    2. As mentioned in my earlier mail the reader checks during intermittent reads are normally due to transport issues. Please check the following:
      1. Clutch belt- either worn out or loose.
      2. Worn out drive pulleys driven by the clutch belt.
      3. Sluggish Clutch. If the above two are ok it's advisable to clean and lubricate the reader clutch. I had demonstrated the PM of the reader clutch during one of my visits.
      4. Worn out feed rollers/ springs. (very rare)
    Any card jams problems also there?
    All above would easily show up scoping the brush timings. Transport problems normally show up mostly on intermittent reads and may not give any problems on continuous read cycles.

    Shall be eagerly awaiting further observations
    Best wishes


    from David Clementson - pre-work-session
    Thanks for the suggestion Bhushan.

    I think you are right to mention the clutch belt tension, which I will check today. The belt and pulleys don’t appear particularly worn, but then everything in the machine shows signs of wear. I felt the belt tension at each of the places where it spans pulleys, looking for evidence of broken internal cordage. I didn’t find any, but I will check that again. I will also attempt to check the feed knife timing, since that seems to determine the overall phase relationship between the card location and the solar cell signal. The documentation shows procedures for setting the belt tension and knife timing. Fortunately I have a force gauge which is required for the tension setting.

    About a sluggish clutch, the team reasoned that any clutch problems would produce timing irregularities in the solar cell signal waveform (variations between the start of clutch solenoid signal to the first solar pulse,) something that we do not see. So we put the clutch itself lower on the list of potential problems than the belt. I’m hopeful that the belt tension is out of spec, and tightening it will fix the problem.


    Later from Bhushan Mohan
    Hi David,
    Thanks for your mail. Hope you have been able to make some headway earlier today.
    In my experience one of the common reasons for erratic reader checks on intermittent read operations has been dirty/sluggish clutch. As a routine we used to clean and lubricate the reader clutch on the high usage machines on a monthly basis. I remember I had cleaned the CT 1402 reader clutch sometime in mid 2019. At that time there was some intermittent erratic behaviour of the reader.
    Since CT 1402 has Punch Feed Read (PFR) feature, try to eliminate any problem with the PM relays also.(bottom most row of PM relay although in field these have seldom given intermittent problems). Shall be awaiting the latest updates.
    Best wishes
    Bhushan Mohan

    from Ken Shirriff
    My 1401 Restoration Status Report 5/24/2023
    I looked at the tape drives that are causing problems: DE#3 had a tripped circuit breaker and CT#3 has a mechanical problem

    Samuel noticed that fuse light was illuminated on DE#3. I reset the circuit breaker on the back (I think #3) and it now works. I ran through a tape with writing and rewinding and couldn't reproduce the problem. The circuit breaker has tripped a couple of times in the past so it seems to be a recurring issue. It's unclear if the circuit breaker itself has an issue or if there is an overload. We should keep an eye on this and maybe replace the circuit breaker.

    CT#3 had a strange loading behavior: it would slowly continue spooling tape into the columns. This is unlike the usual tape dump, e.g. if you don't go past the start-of-tape indicator. I took some video to determine exactly what was happening. Normal behavior: the heads lower, grabbing the tape. Then the tape reels slowly rotate in opposite directions briefly until the tape enters the vacuum columns. Then the vacuum columns take control of the tape with the reels spinning as needed. Observed behavior: the heads start lowering but stop halfway. At the same time, the tape reels slowly rotate in opposite directions. The tape enters the left column but not the right. Once the left column gets a lot of tape, then it will suddenly get yanked into the right column. The issue is that the heads need to grab the tape so it gets forced into the column, which triggers the tape-in-column vacuum switches (up at the top, not the usual two vacuum switches), which switches the mode. None of this is happening in the bad drive.

    David and Frank investigated and found that a mechanism on the front of the drive under the heads had come loose and was blocking the head motion, so they could only lower half way. I suspect there's also something wrong with the head switch because the tape reels start rotating immediately, before the head starts moving.

    4 hours.

    from Lyle Bickley - comment on Circuit Breakers
    FYI, we on the PDP-1 Team have seen old Circuit Breakers fail in the same way.
    As you are doing, we checked the load and found it was in the correct range.
    New CB's solved the problem...


    from David Clementson
    David's comment on Lyle's suggestion above
    One thing we could try is putting an actual fuse of slightly smaller rating in series with the circuit breaker. A bona fide overcurrent will blow the fuse; a faulty breaker would not.


    I was able to reinstall the loose piece preventing the heads from lowering all the way, but the left screw’s tapped hole is mostly stripped so that it doesn’t tighten properly. I think a drop of JB Weld in that tapped hole would be an acceptable fix so I will bring some in next week. If that doesn’t work long term, we can always drill and re-tap for a slightly larger size screw.

    Here is a photo of the offending piece showing the stripped screw hole.


    from Tom Szolyga


    Today I powered up my interface board to connect the Arduino to the 1401. It did not smoke or catch fire and the current draw on all the voltage rails was within limits. None of the active components overheated. The only issue today was the power supply wiring to the board. I cobbled together some banana plug to alligator patch cords into a power harness. It came apart quite easily so I replaced it with dedicated power wires. The next step is to connect the Arduino to the interface board and the board to the 1401. Then write an Arduino sketch to blink the 1401 EXT ATN light on the 1401 front panel.

    A number of volunteers including myself want to write some Autocoder programs. The easiest way is to use the ROPE ide/assembler/simulator package that Stan created. Stan is the expert but with Stan out. Nobody knows how to run it. I worked on the installation on my notebook and it began to function. The main issue was installing the version of JAVA that works with Win 11 followed by configuring the directories that ROPE3 uses to access files. A text constant to name the directories must be put into the .bat file that executes ROPE3 and that same name must be put into the File->Preference directory locations. Once this is done, ROPE3 runs as expected.

    For the 1402 card read problem, I suggested a simple test program. Since the read check happens when 3 cards are read and the card reader pauses, let’s write a program that reads 3 cards, loads a constant into A, decrements it down to zero to pause the card reading and then loop back to the start. A slightly more advanced program would load the constant from the front panel switches. This would make the pause variable. This entire program would be about 10-12 memory locations long, so it could be loaded from the front panel switches. Ken was kind enough to assemble the program in his head to set the switches!

    To sense the position of 1402’s timing wheel, there is a reflective sensor used with an Arduino to detect a target. It consists of a LED and a photo transistor mounted next to each other. When target is in front of the sensor the LED illuminates it and the reflected light turns on the photo transistor. A small PCB with all the components mounted is widely available. (See attached). A package of 10 sensors cost $8.79. It works pretty well; I use it on my Lionel railroad to detect trains.

    Best regards,
    Tom Szolyga

    from Samuel Plainfield
    Overrun with students this morning (40+?) -- the DE1401 printed brilliantly, nonstop.

    Following spec, David thoroughly followed the full procedures to make all adjustments pursuant to the Service Checks section in the 1402 manual -- including double-checking the throat-gap clearance. Everything was completed. He also tightened a screw on the idler which also tightens the clutched belt somewhat.

    Center keypunch was having some difficulty feeding cards. Frank gave it a whack and proclaimed it fixed.

    Our 1402 is a "two group brush" type, which means there is only one scribed line. In order to see the scribed line, you've gotta look with a mega-magnifying lens. It looks like this:

    Checked and adjusted very slightly.

    A bent pin on a set of brush heads was located and replaced.

    Frank and I prepared a set of ~40 cards or so that have punches set in the 5 row only. We ran it through with the 1st and 2nd switches set and the RD BRUSH DISPLAY switch activated to show the timing light which has to be held during run (in OFFLINE mode). To do this, a non-proc runout won't work. Frank manually loaded a wordmark & 1 set into memory so that the system would simply read cards and do nothing with the resulting data.

    Here are the video links, being played back in slow mo.
    (Brush Check 1, first set)
    (Brush Check 2, second set)

    If you'd like to take a look at the original videos you can download them here:
    (Once downloaded, load into VLC player and use the [ key to slow down the footage to, say, 0.20% speed).

    It seems like the cards are being read just a little "late."

    After the demo concluded, we ran a test deck before deciding to completely replace the clutch belt (609124). To my surprise, the deck read and printed on the first try without a hitch. Ran it a few more times, and it still printed... and for the briefest of moments in a long while, both printers were printing BigPrints at the same time! Of course, this was short lived and the read checks resurfaced.

    Frank and I ran our test deck of 5's with I/O check on, scanning the memory and noticed an odd pattern in that the data was being read correctly by the second set of brushes (5's correctly loaded into memory) but that the first set of brushes on 30, 50, 51 (if I recall correctly) would continuously read incorrect data.

    I decided to switch off I/O check and simply one-card print the 5's deck to see what any variance might show us. The results, bad and inconclusive still:
    Note the row of 4's on the 13th card. Note the missing 5's on columns 61 and 80.

    When Frank and I left, DE1402 was failing to read cards beyond 1 or 2, throwing all manner of validity checks and the punch check light issue won't turn off again.

    As of this moment, it seems likely both systems won't work for Saturday's demo...

    That is, unfortunately, all for now. 8.5 hours.

    ~Samuel Plainfield

    from Jack Ghiselli - Friday, May 26, emergency work day
    The Amazing Restoration Team comes through again! The final reports from last Wednesday (5/14) were that BOTH the CT1402 and the DE1402 were inoperative. So, both of Saturday's upcoming demos were probably not going to work.

    But I came in today, Friday 5/26, to watch Frank King and Mariane Kim get the DE1402 working. I think the demos are saved. Yay! While they were here they also:

    1. Looked at the CT1402. They were able to get it to load a BigPrint deck and print. The CT1402 still gets Reader Check and Validity Check errors, but if we used careful card handling when recovering, we were able to get it to run. Unfortunately, Frank and Kim's "All 5s" diagnostic deck showed that sometimes CT1402 fails to read the correct data into CT 1401 memory, yet indicates no error. This means that even an apparently successful program load on CT1402 might have errors ("holes" in the program code).

    2. Un-jammed Keypunch #2. It was failing to advance cards, and we cleaned out the card slot.
    While we were working, several visitors wandered by. We talked to them, and printed a few BigPrint-outs. We had international visitors from Argentina, Germany, Nepal, and the UK.

    THANKS again to our Amazing Restoration Team!

    Jack Ghiselli mobile 1-408-839-1051

    IBM 1401 Demonstrations Saturday 5/20/2023
    11 AM - from Jack Ghiselli
    - 1 PM - from Stephen Madsen
    11 AM - from Jack Ghiselli
    Karen Sun and I gave the 1401 demo Saturday 5/20/2023 at 11:00 AM to 45 visitors. We had international visitors from China, Germany, India, and Russia.

    We ran most of the demo on DE, since the CT 1402 still can't read cards. But we ran tape demos on CT, using its TAU, since only two DE tapes were functional, and the CT tapes are more visible to visitors. DE hardware ran well except for Tape #3.

    729 Tape Drives: When we arrived, DE was powered down with 729 Tape #3 (right-most) still loaded. When we powered up DE, we were unable to get Tape #3 to unload or rewind, so we set it to INOP. The other two tape drives worked OK, but we demo'ed on the CT tapes, all of which worked.

    026 Keypunches: #1 and #3 worked well, but #2 (in the middle) failed to advance the card under the punch station. We didn't have time to see whether there was card material jammed, so we just marked it INOP.

    Microphones: The microphones worked very well. They were slightly soft, so we did raise the volume knob a couple of clicks. Last week we had lots of mic troubles, so if the CHM A/V staff adjusted the system, thanks!

    I had to leave at 12:15, so we just left everything on for the 1:00 PM demo volunteers.

    Jack Ghiselli mobile 1-408-839-1051

    1:00 pm - from Stephen Madsen
    Yash Lala and I demonstrated to 38 visitors. We used DE to run BigPrint and CT to demonstrate the tape drives.
    The keypunches, sorter, and microphones worked OK. CT tape #3 had a tape loading problem and is set offline.
    DE tape #3 would not start or unload and is set offline.

    Stephen H. Madsen

    IBM 1401 Demo Status - 5/17/2023 - from Pat. Buder
    On Wednesday, 5/17/2023, Duane Sand and I demonstrated DE 14091 system to a group of 28 visitors. Another 16 came in before or after the main demo. In addition, Samuel Plainfield reported a large student group visited in the morning.

    The system performed well, including the tapes and printer. The 083 sorter and keypunches #1 and #3 also worked well. Keypunch #2 had been marked as down due to a card advance issue.


    Restoration Reports for May 17, 2023
    - from
    Robert Garner
    - from Tom Szolyga
    - from David Clementson
    from Robert Garner
    1401 Restoration Hours: 5/17/2023
    Clementson, David 6
    Garner, Robert 4
    Howard, John 5
    King, Frank 6
    Plainfield, Sam 6
    Shirriff, Ken 6
    Szolyga, Tom 6
    Verdiell, Marc 4

    Synopsis (details & photos below):

    • David, Samuel, Ken, Frank, Marc, and John continued to brainstorm on why the CT 1402 produces Reader Checks. The working hypothesis is that the 1402’s first set of check brushes are not correctly sensing holes when the 1401 CPU has monetarily disengaged the clutch. See David’s terrific write-up last week, including two slow-motion videos.
    • Tom worked on installing power supplies for his serial interface board. (And found that the lab tri-supply -12V output needed trip current adjustment.)
    • All three demo-lab keypunches were fully functional and properly printing.
    Brainstorming over the CT 1402 reader checks.

    Tom and his three power supply modules for his serial interface unit:

    * Here’s Bob Metcalfe and Gordon Bell last evening:

    In 1971, Bob designed a serial interface board to connect MIT’s DEC PDP-6 to an Arpanet interface IMP (built by BBN, based on the Honeywell 516 mini) At DEC, Gordon was the principal designer of the PDP-6 (then the PDP-10, a mainstay of the Arpanet). In 1980, Bob convinced Gordon to write a memo to Xerox management to release Xerox's (Metcalfe’s & Boggs') Ethernet patent to the world.

    Bob Metcalfe hired me out of Stanford into Xerox SDD in 1977, to help commercialize the Xerox PARC Alto and Ethernet hardware. I co-designed the first 10-Mbps Ethernet adapters. Bob was my first boss. I thereafter (mistakenly) though that all my future bosses would be as cool, effective and charismatic. :)

    from Tom Szolyga
    I accomplished two things:
    - Fixed triple output power supply
    - Completed design of the power supply for the German Project

    The problem with the triple output supply was the current limit was set to zero. It took a screwdriver to adjust it.

    The power supply design uses two AC to DC power bricks to isolate the positive voltages from the negative voltages. One of the bricks provides +12V and connects to two DC to DC regulator boards to generate +5V and +6V (See attached). The other brick provides +24V and connects to a regulator board to generate -12V. This regulator has its +Vo voltage output connected to the common ground and the –Vo is the -12V output. Each board is rated at 5A and has 3 digit display to show voltage output.

    Best regards,

    from David Clementson
    The team one again focused on the CT 1402 Reader Check errors. Frank and Sam were able to organize a deck that would reliably (?) produce the problem on the 4th card in the deck. Ken hooked a scope to the 1401 to observe the read request (yellow), clutch solenoid drive (cyan), and solar cell signals (magenta.) These signals show the failing card read process. It takes three clutch cycles to fully process a card. In the first cycle, the picker knives shove a card from the hopper into the 1st feed roller. On the second cycle, that card is carried under the first set of brushes, where the card's hole count information is collected by the 1401 for later error checking. On the third cycle, the card is passed through the 2nd set of brushes, where the card's data is collected. If the hole count agrees with the prior cycle's, the card data is executed. If not, a Reader Check is generated. This Reader Check error is the one that is giving us grief.

    Since the read process is pipelined, each clutch cycle pushes a new card through the reader, meaning that there are typically three cards in process simultaneously. Looking at the scope display above, the six clutch cycles indicate that four cards have been processed; the first two cycles are just filling the pipeline. The last card read was the one that generated the error, which in turn stopped the whole read process.

    When examining the data captured by the 1401 for the misread card, we found that the data was actually correct, meaning that the read from the 2nd brush was error-free. Since a Reader Check is a disparity between the 1st and 2nd bruch reads, this means that the 1st brush read must have had an error. Unfortunately, the 1st brush data is not stored; only a "hash" of the hole count is retained.

    Looking at the scope capture, you can see that the 4th card's passage under the 1st set of brushes happened after a delay caused by the 1401 the execution of the third card's op code. You can see this as the long LOW portion of the yellow trace after the third card's passage through the 2nd brush set. During this time, the clutch is disengaged and the cards are held by the appropriate rollers, waiting for the next clutch cycle. This is the flow control that keeps the 1402 from overwhelming the 1401's limited processing bandwidth. The first cycle after this delay is where the fatal 4th card passes through the 1st set of brushes and (we think) gets misread. The current theory is that something about stopping then restarting the roller train causes the card to falter as it passes through the first set of brushes. Cards that are read back-to-back without any delay seem to read fine.

    We tried taking some high-speed video of this process. In order to also capture the electrical timing, we connected an LED to the clutch solenoid and placeed it in the video frame. We videoed the card path and the cluched belt to see if we could find any problems. Looking at the videos on my phone, we were unable to see anything obvious. Hopefully a more careful frame-by-frame analysis will show something. I have included the videos here.
    1st video, 2nd video - about 20 seconds, 1.5 MB each

    That's it for this week. 6 hours.

    CHM 1401 Demos Saturday 5/13/2023 11:00 AM and 1:00 PM - from Jack Ghiselli
    Scott Stauter and I gave the 1401 demo Saturday 5/13/2023 at 11:00 AM to 37 visitors. Yash Lala and I gave the demo at 1:00 to 38 visitors. We gave mini-demos to 8 people outside of the demos. We had international visitors from Belgium, China, Finland, France, Israel, Russia, Singapore, the UK, Ukraine, and Uruguay.

    We ran both demos, including tapes, on DE since the CT1402 is still not reading cards. DE ran well, as did all three 026 Keypunches and the 083 Card Sorter. Thank you, Restoration Team.

    Microphones: Emails from earlier this week suggested that the audio problems with Mic #2 had been fixed. We found this was NOT the case. Emails also said CHM A/V folks suggested that some mic problems might be due to rough handling of the delicate headset wires, and asked us NOT to wrap the headset wire around the battery box, and NOT to store the headsets in the A/V drawer where they might bang around. We followed their directions. However, we do NOT think this is the problem. When you speak into a mic, the LEVEL display on the A/V rack shows the audio level correctly, so there does not seem to be any problem with headsets, headset wires, battery packs, or with the radio communications from mics to the A/V panel. Rather, the problem seems to be somewhere INSIDE the audio panel or its connection to the speakers. For the morning demo, we set Mic 1 Volume, Mic 2 Volume, and Master Volume to their normal levels. Mic 1 was audible on the speakers but Mic 2 was not. To solve the problem we cranked Master Volume way up. Now Mic 2 was audible, but Mic 1 squealed. Cranking Mic 1 Volume way down corrected this, so those were the settings Scott and I used. Here's a photo of the panel Volume settings we used:

    In the afternoon, we started to get squeals from the morning setting, so Yash fooled around and finally found a combination of Volume settings that approximately worked. We had some feedback during the demo, and Yash had to re-adjust the Volume settings several times. Yay, Yash, you saved the demo! Here's a photo of the afternoon volume settings:

    Tapes: When we arrived and tried to LOAD/REWIND DE 729 Tape #3 (right-most), the tape fluttered down the right-hand vacuum column. We discovered this tape apparently had no beginning-of-tape reflective spot. We installed one, and all DE tapes worked OK for the demo.

    After the 1:00 PM demo, we looked at CT 729 Tape #4 (right-most), which still had the tape jammed from a week ago:

    When we cleared the jam and dismounted the tape, we discovered that the plastic reel had broken away from the reel hub. This was almost surely the cause of the jam:

    This cracked reel cannot be repaired, so we left it on top of the CT1406, together with the other cracked reel from several weeks ago. Can we discard them? We took the extra reel which is stored on top of the tape drives and used it instead, since it seemed good. This means we have NO extra tape reel to hold up and show during demos. Restoration Team: Do we have some more reels of Tape? Could we put a new one or two into the demo room?

    Jack Ghiselli mobile 1-408-839-1051

    IBM 1401 Demo Status - 5/10/2023 - from Pat Buder
    On May 10, Jim Maurer and I gave the demo to 36 visitors from Italy, Bulgaria, Germany, France, and Israel. Another 16 stopped by before or after the main demo.

    Because the CT 1402 is still down we ran on DE, which performed flawlessly including all three DE tapes. The 083 sorter and all three 026 keypunches worked well. Samuel warned us that the 026 furthest from the door sometimes drops an 8 or 9 punch when duplicating, but we didn't do any duplicating.

    In my pre-demo testing I found that BigPrint deck #1 gets a validity check at or near the last card. I didn't have time to diagnose this, so I just marked #1 bad and used #2.

    We found that both mics worked acceptably if not perfectly. We needed to make slight adjustments to the volume controls.


    Restoration Report for May 10, 2023
    - from
    Robert Garner
    - from Ken Shirriff
    - from Samuel Plainfield
    - - - suggestion from Ignacio (Iggy) Menendez
    - from David Clementson
    - from Mei Luo
    - from John Howard
    - from Tom Szolyga
    from Robert Garner
    Here’s the combined 1401 Restoration Status Report for Wednesday, May 10th:

    1401 Restoration Hours: 5/10/2023
    Clementson, David 6
    Garner, Robert 2
    Howard, John 4
    King, Frank 6
    Luo, May 5
    Plainfield, Sam 7.5
    Shirriff, Ken 6
    Szolyga, Tom 6

    Synopsis (details & photos below):

    • David, Samuel, Ken, Frank, John, and May continued to investigate why the CT 1402 is producing Reader Checks. After a team brainstorming session in a conference room, they came to the conclusion that the most likely problem is faulty timing for when to read the brushes; i.e., that the punched cards are lagging behind where they should be. Perhaps the timing of the card feed pick knife needs adjusting?
    • Ken examined the 1401 -> 1402 interface signal that activates the clutch and the 12 row pulses from the 1402’s solar cell. It all looked fine, scope traces below, suggesting that the clutch and "solar cell" sensor are working properly.
    • Frank adjusted the card throat gap on the CT 1402 down to 0.010 inches (spec’d at .0095" to .0150”). That should reduce the occurrence of card jams. He also manually aligned a card to the entrance of the throat gate, where the timing wheel read 311 degrees (is that correct?).
    • John brought in and showed off his awesome new relay tester, photo below.
    • Tom worked on designing his own -12V power supply for his serial interface board.
    • All three demo-lab keypunches were fully functional and properly printing.

    Detailed reports & photos:

    John’s awesome new relay tester. (Black pushbutton selects relay type, yellow does a quick rattle test, and green does a longer test and logs the (max?) contact resistance value. Photo courtesy of Samuel.)

    Photos of audience not included here.
    Ken, David, John, Sam,

    Thanks for the in-depth 1402 trouble shooting and brainstorming today and for the early bird status reports! (And thx for the hours, so I’m not guesstimating. :)

    Tom, Mariane, Mei, et al —> Thanks in advance for any status.

    — Robert

    p.s. My Ethernet-history interview with a legendary PARC & Adobe programmer, Ed Taft, delayed me getting in until ~3:40, at which time I couldn’t find anyone around at all! After lunch, Frank and Sam, brooding over the 1402, told me that you had all been in an upstairs conference room brainstorming about how to diagnose our errant 1402. Great move/thing to do! :))

    from Ken Shirriff
    To follow up on David's report: Frank and Samuel did an experiment of reading blank cards and printing what was read. About every 20 cards, instead of printing a blank line, it would print a line of all 9's. My interpretation of this is that the card is getting to the brushes too late. The first row read is the 9 row ("face down, 9 edge first"), so if the card has not arrived yet, all brushes will contact the roller and the computer will think the card has 80 punches in the 9 row.

    So the question is why does this happen? We had several theories:

    1. A problem with the rollers, causing the card to slip occasionally. Frank checked the rollers and they seem to grip the card firmly.
    2. A problem with the solar cell. The CT has a slotted disk (rather than the cams on DE) that generates a pulse for each row. If these pulses were at the wrong time or noisy, the computer might read the card incorrectly. We checked last week, and the pulses looked clean. I took another look today and the pulses seem fine. (photos below)
    3. A clutch problem. The clutch seems to be operating correctly. Moreover, since the clutch, the feed rollers, and the solar cell are all connected by a cogged belt, there doesn't seem to be any way they could get out of sync.
    4. Stretching in the cogged belt. It's plausible that if the belt is loose or stretching, the feed rollers and the solar cell could get out of sync. We should probably check the belts.
    5. A card bending or bowing, so it doesn't get to the brushes in time. This could explain the problem with the 9's getting printed, if the card doesn't get under the brushes fast enough. The amount of bending necessary seems unlikely to me.
    6. A problem with the feed knife, not pushing the card in far enough. If a card gets fed a bit late, this would explain the behavior we're seeing. We should probably check this.

    It would be helpful to have a way to match the physical location of the card against the timing pulses to see if an occasional card is delayed, if the card positions jitter, or if something else is going on. Two possibilities:

    1. David suggested using a strobe timing light, triggered off the timing signal. We could observe the card path and the strobe would "freeze" the card position. We could then see what's happening.
    2. Look at the brush signals to see how the physical hole locations match against the timing signals. The problem is that normally the brush common signal is gated by the solar cell, so we can't see the "raw" brush signal. The dynamic timer wheel might solve this for us, but I don't know the right switch combination to make the timer work.

    I did some oscilloscope traces to look at the signal from the 1401 to the 1402 to activate the clutch and the 12 row pulses from the solar cell. The blue trace shows the clutch pulses from the 1401 to the 1402. The purple trace shows the solar-cell pulses from the 1402 to the 1401. The key finding is that we didn't see anything bad or inconsistent in these signals. The clutch appears to activate properly and produces 12 uniform row timing signals each time. We could not find any glitches. This is evidence that the clutch and the solar cell are working properly.

    A bit more on the timing of the clutch in case you're curious: a card read cycle is supposed to be 75 ms (800 cards per minute). With the oscilloscope, we measured either 84 or 112 ms. The discrepancy is that Frank adjusted the motor pulley at some point, slowing it down to about 714 cards per minute (84 ms cycle). If the 1401 requests a card read too late, the read will happen at the next available clutch point. The clutch can activate every 120 degrees (unless the sync switch is on, in which case it can only activate once per revolution). In other words, if the read instruction is slightly delayed, there will be a 84/3 = 28ms delay, resulting in a slightly longer 112 ms cycle.

    The reason for the intermittent delays is that the line printer can only print 600 lines per minute (100 ms per line), but there is a print buffer. Thus, the first card is read and sent to the print buffer immediately, so the second read instruction executes as soon as possible with the card reader's 84 ms cycle. However, the second card cannot be printed until the first line is printed and the print buffer is available. By this time, it's too late to catch the first clutch opportunity so there is a 28 ms delay on the read. This delay, however, gives the print buffer time to clear, so the next print can immediately go to the print buffer. The result is alternating short and long read cycles, as shown on the oscilloscope.

    I wrote a blog post in 2018 about a card reader clutch problem. This post has a bunch of information on how the clutch works and may be useful reading, since the clutch is pretty tricky:

    My time: 6 hours

    from Samuel Plainfield

    This morning Frank was adjusting the card throat gap on CT1402. After multiple attempts to get it within spec (what's that, you ask? So glad you asked! Officially, the IBM "throat clearance" gap is ".0095 to .0150") Frank ended up cleverly placing the screwdriver on top of the metal frame in order to force it down on a 0.010 leaf feeler gauge. This was necessary because attempts to push it down using other methods resulted in the gap being too large. Frank thinks that 0.150 would be too large and result in jams, so, the goal is to keep it closer to 0.0095. Here is a photo of how his method worked to keep pressure on the metal:

    This seems to have mostly stopped the card jamming issue.

    John finished an awesome new standalone relay tester and promises even more new features to come!:

    Note the built-in OLED readout on the left! Black switches between relay type; yellow does a rattle/rapid test; green does a slower test and logs the resistance level.

    As David mentioned, we mused and tested myriad theories in connection with the reading errors. We tested single-card printing multiple completely blank cards and it is important to note that on multiple occasions, 80 columns of 9's would print and it would continue printing cards thereafter. This is with the check stop I/O options turned on.

    This is important because that means that the hole count from the first set of brushes (read check) is being agreed-upon by the second set of brushes (read) in order to permit the printing to occur -- otherwise it would stop right there.

    Ken came up with the idea to try and print cards with a single line of just the 11 position punched out so as to be able to note variance in either direction. Attempts to do this failed repeatedly with reader checks. I was only able to get two lines to print. Brief checks with storage scan revealed it sometimes recording no data and other times showing the 11 row (B) data.

    Ken wired in and reviewed the timing of the clutch via the 1401 panel:

    There's a lot to that, so I'll leave that for Ken to chime in. (Note that our timing is different also due to the motor being intentionally stepped slower). Lastly, the cables on the brushes concern me considerably. They're generally very sturdy, but the cables are frayed and look like they may snap off at any minute. So, let's continue to be sure to check them often and handle them with care:

    To determine the exact angle of the pick knife for the cams, Frank held the "RD CLU" switch (read clutch) and we rotated a card in manually until it aligned exactly with the throat gate; how exact, you ask?

    This corresponds to exactly 311°.

    Pretty sure that's all for now ~ 7.5 hours.

    ~Samuel Plainfield

    I keep forgetting to mention — the keypunch furthest from the closet I noticed occasionally misses punches when I was duplicating some cards. It only happens 5% of the time or so, but important to note when duplicating data cards. Specifically, I noticed it missing punches on the 8 and 9 columns.

    As for the timing wheel degrees, here’s the photo. Hopefully I’m reading that right :)


    - - - suggestion from Ignacio (Iggy) Menendez
    My 2 cents worth on the 1401 read checks…
    I remember around 6 years ago, similar problems were occurring, and there was something wrong with the timing disk on the 1402 reader.
    Now, my experience from 55 years ago:
    Working on the infamous 2321, AKA ‘Noodle Picker’, we had about 10 lamps and photo detectors timing the operation of this complex Rube Goldberg machine… the lamps were always a problem, noise from the filaments would create bad timing problems…
    We used to put a scope on the lamp leads, and banged the lamps against the frame, to take out the ones with loose filaments, you could actually see the noise on the scope….
    the problem was finally solved by installing a shock mounted quartz lamp and fiber optic light pipes, replacing all the lamps.
    So a slight possibility may be noise from the light bulb, be it a connection, the bulb itself, or even the power source.
    Just an old war story.


    from David Clementson
    Only one project today: determine the cause of the CT1402's Reader Check errors: The entire team worked on this effort, and we had very good communications about what may or may not be causing the problem. Through ample discussion, we together gained a pretty detailed understanding of how the card reading process works between the 1401 and the 1402, and how inconsistent card timing is the most likely cause for the errors we are seeing. We theorized a number of different possibilities for the root cause of the errors, but in most cases were able to prove (or at least convince ourselves) that the proposed causes were not actually at fault. The current thinking is that the actual card positions are somehow lagging behind where the 1402 thinks they are. In 1402 parlance, the "brush timing" is off. Late in the day, we found info in the documentation saying that the timing of the pick knife relative to the main camshaft is the main adjustment means for "timing the brushes." So we will attempt to make that adjustment next week.

    That's it for this week. 6 hours.



    from Mei Luo
    I was there about 5 hours.

    Worked with the team to debug the problem with card reader. In order to catch up on the basics, I read the IBM-1402 customer engineering manual to gain a better understanding of the mechanical and electrical principles of the card reader. In addition, I found Ken’s blog about card reader to be helpful information.


    from John Howard
    I worked 4 hours with the team on the card reader, and demonstrated the relay tester to Sam and Dave.

    from Tom Szolyga
    For the -12V supply, I decided to work on the design of the final supply for the product. The issue is the -12V output needs to be isolated from the other +5 and +6 supplies.

    The website migration is on hold pending on IT resource availability.

    Best regards,

    IBM 1401 demonstration 5/06/23
    -11:00 AM and 11:45 AM - from Jack Ghiselli
    - 1:00 pm - from Stephen Madsen
    -11:00 AM and 11:45 AM- from Jack Ghiselli
    Karen Sun and I gave the 1401 demo to a relatively small group of 20 people at 11:00 AM, and then continued with a private demo for Ron Mak and 6 of his SJSU students at 11:45. We had international visitors from Germany, India, and the UK. The UK people pretended they'd forgotten about King Charles' coronation.

    Since the CT 1402 still won't read cards, we ran on DE, which ran well, but we did TAU tape demos on CT. All three 026 Keypunches ran well. We did a manual ribbon reverse on the center one, and its printing darkness improved. The 083 Sorter ran well.

    Audio: Mic #1 worked normally, but Mic #2 was unusable. When you talk into Mic #2, you can see the level lights in the panel electronics respond, but no sound comes out the speakers (although Mic #1 works fine). On both the Mic #2 belt pack and the panel electronics, Mic #2 shows as "2" and channel "7", so we think it is set correctly. Batteries were OK. We tried powering off and on of the entire audio electronics stack, but that didn't help. Pat Buder reported this problem on last Wednesday's demo with Mic #1, but we found it on Mic #2. I asked Jesse to put in a request for CHM A/V staff to look at the problem. It's a real nuisance to have only one microphone.

    Tapes: When we arrived, we found DE 729 Tape #3 (right-most) had the tape jammed. See photo attached.

    We bypassed it by demo'ing tapes on CT. During Steve and Scott's 1:00 Demo, I cleared the jam, dismounted the reel, cut about 40 feet of leader off before the crinkled point, measured out some new tape leader, put on a new start-of-tape reflective spot, and remounted the tape. It worked file after that. However, when I left about 4:00, I noticed that although CT was powered off, CT 729 Tape #4 (right-most) had another similar tape jam. This seems to have occurred when Steve and Scott powered off CT after the 1:00 demo, and they didn't notice. I had already powered off DE and locked up, so I left it for the Wednesday crew to handle. I suggest 1401 demo volunteers carefully observe the 729 Tape Drives as they unload, and see if we can determine exactly how this jam happens. I fixed a similar jam on CT 729 #4 last Saturday, so this makes three occurrences I've seen within the last week or so.

    DE 1403 Printer: When we were testing printing before our demo, the DE1403 ran out of paper. It turned out that somebody had brought a new box of printer paper, but placed the last bit of paper from the previous box on top and loaded it into the printer. Luckily, we ran out of paper BEFORE the demo. Although it's admirable to be economical with paper, back in the day we used to stick a warning sign on the printer "Forms break pending" for the operator. Something like that would help.

    Wall Clock: The "IBM" wall clock is still missing. Several visitors asked us how many minutes until the demo would start. So, we found a wall clock in the back room, stole it, and mounted it in the demo room. It says "New Haven" instead of "IBM", but I guess that will have to do.

    Demo Program Decks: When we arrived, BigPrint decks #1, #3, and #4 were marked "Bad" and only deck #2 was marked "Good". So that's what we used during our demo. After the 1:00 PM demo, I stayed and investigated all the BigPrint decks.

    BigPrint Deck #2 was our "Good" deck. Analyzing it with VOBJ, it turned out that this deck had a small error. Card #108 had been incorrectly moved after Card #110. Due to the nature of this object program, this was not a fatal error, so the deck ran OK. However, I corrected the sequence, and reloaded BigPrint #2 as our "Known Good" deck.

    BigPrint Deck #1 got lots of READER STOP errors starting at Card #96 and following. I spent some time fooling with this deck, but couldn't explain the problems, so eventually, gave up, punched a new Deck #1 and discarded the old one. Possibly some cards were mis-aligned when the old deck was punched.

    BigPrint Deck #3 was marked as possibly missing cards. Sure enough, Cards 74-75 and 102-111 (end of deck) were missing. I re-created these cards from the good deck, and fixed Deck #3.

    BigPrint Deck #4 showed as good. No fixes were needed.

    To summarize, at the end of the day we have four (4) good BigPrint decks, numbered #1 through #4. They all show good with VOBJ, and they all LOAD and run correctly (on DE). They're in the demo card tray ready for Wednesday.

    To repeat an earlier suggestion, some of us demonstrators seem to have challenges handling card decks, especially recovering from read errors. Perhaps we could schedule some additional training?

    Jack Ghiselli mobile 1-408-839-1051

    from Ronald Mak / SJSU
    Thank you, Jack and Karen, for showing the 1401 to my students yesterday!

    My students this time were from China and India. They were very impressed by the system and the demos. The husband of one of my students who is a mechanical engineer came with her, and he was blown away by the card reader and the line printer. So you never know what aspects of the 1401 system will impress the visitors.

    — Ron

    1:00 pm - from Stephen Madsen
    Scott Stauter and I demonstrated to 52 visitors. Based on previous reports, we ran BigPrint on DE and demonstrated the tape drives on CT.

    Pat reported trouble with mic #1, but mic #1 worked OK for us. We were not able to get mic #2 to work. When we talked into the mic, the console lights flickered, but there was no audio output. We checked that the battery level was good and that the volume level controls were in the proper positions. The person without the mic cannot be heard. We tried sharing the mic, but that is awkward. I hope someone can look at and fix the mic problem soon.

    Stephen H. Madsen

    Tim Robinson suggests that it is microphone #2
    Kate McGregor added "Jon Plutte with our CHM Media Team here to loop him in. We'll work on addressing the mic and A/V issues as soon as possible."

    IBM 1401 Demo Status Report - 5/3/2023 - from Pat Buder
    On Wednesday, 5/3/2023, Tim Robinson and I gave the demo to 52 guests. They were from Romania, British Colombia, and other places. We had another 25 before or after the demo in the afternoon. I was told that several student groups totaling at least 75 dropped by in the morning. Frank King and May Luo took care of these visitors. Thanks!

    Due to the continuing work on CT we ran on DE, which performed flawlessly. We also ran tape drives #1 and #2 from the TAU.

    The two 026's furthest from the door had ribbon advancement issues and printed very faintly. May and Frank worked on them but didn't have enough time to complete repairs. We had most visitors use the 026 closet to the door, which prints fine.

    We couldn't get mic/transmitter #1 to work. When you talk into it, we could see level lights on the console flicker, but no audio. The transmitters had newly recharged batteries, and all volume level controls were in the proper positions. I believe I also tried power cycling the A/V chassis, but to no avail. Tim had to shout his part of the talk. He did his best, but it's impossible for such a large group to hear over the room noise.


    Restoration Reports for Wed 05/03/23
    Report from Robert Garner
    - Report from David Clementson
    - More from Ken Shirriff
    - More from David Clementson
    - Report from Tom Szolyga
    - Indicator Lamps from Marc Verdiell
    - Report from Mei Luo
    Report - from Robert Garner
    Here’s the (quite tardy, just back from a Maui vacation) 1401 Restoration Status Report for Wednesday, May 3rd:

    1401 Restoration Hours: 5/3/2023

    Clementson, David 6
    Howard, John 4
    King, Frank 6
    Luo, May 6
    Plainfield, Sam 6
    Shirriff, Ken 6
    Szolyga, Tom 6
    Verdiell, Marc 1
    Synopsys (details & photos below):
    • Sam, Frank, David, John, and Ken explored why the CT 1402 is (once again) producing Reader Checks. Using the 1-card print test program reading and printing Frank’s test cards, Sam noticed that occasionally a row wasn't read at all, and other times an entire row of holes were read where there were none in the card (photos below). The suspicion is a faulty card transport, causing a card to lag behind where the optical encoder thinks it is. (This is not the first time we have seen this problem in the CT 1402 !)
    • Ken, Sam, and John replaced a burned out lightbulb in the CT 1401 control panel. An on-line discussion followed about our spare bulb inventory and the long-ago-damaged CT 1401 control panel caused when someone replaced a burned out bulb with one whose resistance was too low and thus cooked the acrylic panel. I’ve also included below the Aug, 2021 status reports from Ken and Marc describing the original problem (in the "4" bit position in the 10’s column of the CT 1401’s Storage Address display) and Marc's attempt to repair the panel. [ Ed —> I couldn’t find these 2021 status reports posted on our web site? ]
      Only one of Marc's reports was there, so I copied in the second one from this e-mail.
    • David, John, Ken, and Tom discussed what the design for a new SMS card tester might look like.
    • Tom connected his 1401 serial interface adapter to the DE 1401. Unpowered, it didn’t crash the 1401 and no smoke. :) When he connected it to a 3-output power supply, the -12V supply tripped. Tom suspects a faulty power supply.
    • Ton Luong continued to work on migrating our 1401 web site from GoDaddy to a CHM-supported site, currently Azure Cloud. A checkpoint of the 1401 site (made on 2/8/23) is currently at . Tom will test the updating process, not unlike what Ed has done, by FTP’ing changes to the site (possibly using Cyberduc, "an open-source client for FTP and SFTP, WebDAV, and cloud storage, available for macOS and Windows.”)
    • All three demo-lab keypunches were fully functional and properly printing.

    Report from David Clementson

    1. We started the day with a conversation with John, Ken, and Tom about SMS card testing. The consensus was that developing a comprehensive testing system would be a huge effort that will likely require hundreds, possibly thousands of volunteer hours. The only feasible solution I can think of to reduce the effort is to devise a way to automate the creation of test setup and pass/fail limit files. For example, we may be able to generate pass/fail waveform masks using SPICE simulations of the card circuits. And the tester setup could be simplified by generating stimulus signals in all six logic level standards simultaneously instead of having the operator configure them for each test. This way the selection of which logic levels to use could be built into each cards' "personality adapter" (the thing that implements the crosspoint function for connecting card pins to tester I/O pins). Plugging in the adapter simultaneously maps to card pins to the tester and selects the appropriate logic levels.
    2. We next turned our attention to the CT1402 problems. It seems that there are several:
      1. cards seem to be getting stuck in the throat of the feeder, in particular the first card of a deck that doesn't even make it to the first set of brushes. Frank thinks that there is an adjustment that will resolve this.
      2. Reader Check errors
      3. Reader Stop errors
      4. Validity errors
    3. We think that the Reader Check error is the primary error, and the Reader Stop and Validity errors are a consequence of the Reader Check error (or at least they have the same root cause.) No proof of this, though.
    4. On several of the decks, we were seeing the Reader Check error happen even before the first card entered the first set of brushes. The team made some observations, then convened in the workshop to discuss possible causes. NB: we need to do this kind of discussion more often because it really helped crystallize the problem and point to possible causes. We theorized that the 1401's error check process, which is initiated by the 1401 receiving twelve "row data is ready" signals from the 1402, is getting triggered prematurely. This could potentially be caused by a faulty/noisy "ready" signal causing the row counter to miscount. This signal is generated by a 12-slit optical encoder on the camshaft, with each slit signalling the position where the brush is at the center of its corresponding row punch. But when we scoped it, this signal looked good both at the encoder and at the 1401 end of the cable. So that is not the cause.
    5. Meanwhile, Sam created and ran a deck that simply printed the contents of the deck. By comparing the printout to the actual cards, we found that some cards are indeed being misread. The nature of the misreads was a clue, though, since the errors were row-related rather than column related. So the current suspicion is that there is something awry in the card transport, and that the card is lagging behind where the optical encoder thinks it is. Ken forwarded an email from Bhushan Mohan who mentioned that card transport issues could indeed cause Reader Check errors. So Frank agreed to inspect the transport rollers next week.
    That's it for this week. 6 hours.


    More from Ken Shirriff
    Also, we replaced a bad lightbulb in the CT 1401 console that we noticed while investigating the reader problems.


    More from David Clementson
    This is the bulb that was replaced:
    The new bulb:

    … was the closest match I could find. David tested it and had a resistance level of 30 ohms. It is not an exact match.

    I don’t think that we have any more of these bulbs. Can we order new ones somewhere, somehow?
    See Marc Verdiell's response!

    After the grok session, the cards we ended up running through was a single-program print card + a mini deck of Frank’s brush-test cards. They’re sturdy and mostly repetitive. (I think we had I/O check turned off for this, but I don’t recall for sure).

    As you can see, there are two different sets of cards in Frank’s brush-deck. One with some punches area in the center, and another with just the sides. In any event, it was uniform enough so we could check discrepancies line by line.

    If you zoom in, you’ll note two things. The first, is that I duplicated one of Frank’s cards on the keypunch furthest from the closet (so that we could see what the characters should be on the print out) and it missed some of the holes on row 8, resulting in a few erroneous L’s that should have been $’s. This indicates that the keypunch needs some adjustment at some point.

    Secondly, the first three cards print correctly, thereafter, things get out of whack. Of particular interest is the areas where it prints no line at all, which indicates that the system “thinks” it has read no holes, like line 13.

    Moreover, take a look here:

    … at the first printout (we re-printed the deck repeatedly), and note the long string of 9’s at the bottom of the first printout; what could cause the system to print all 9’s *in an area where no holes exist*?

    It is for this reason that we can reckon that the transport system is misaligned. I note, however, that I have never seen the TRANSPORT light ever come on and I don’t yet know what triggers exist that can cause that particular light to activate.

    I think that’s it~


    Right, thanks Ken.

    Also, it occurs to me that we can check the health of the 1402’s card transport by comparing the relative timing of the signal from optical encoder with the brush signals. When fed a deck with a controlled punch pattern (like row 9 is always punched), any lagging cards should produce late pulses. A scope with infinite persistence would show that nicely. We can then tune/adjust the card rollers to yield the desired timing.

    This reminds me that we should also give our scope probes a little TLC, since it seems like they could use it.


    Report from Tom Szolyga
    Today I finished the cable from the 1401 Serial I/O port to the Arduino controller. I attached the biscuit connector inside the IBM clamping enclosure. Next I put the plastic covers on the DB25 connectors and labeled which cable was “IN” and which cable was “OUT”. The labels are relative to the device with the connect. For example the “OUT” cable from the 1401 connects to the “IN” connector of the Arduino controller. Finally, I pushed the 1401 OFF button, attached the cable assembly to the 1401 and pressed the ON button. There was no smoke so I declared victory!

    Second, I attempted to power up the controller board. I used the 3 output power supply in the workshop. When I turned in on, the -12V rail tripped and shutdown. After 45 min of searching for a problem on the board with no results, I began to look at the power supply. I turned down the output voltage to zero, switched on the supply and gradually increased the voltage to -12V. It did not trip. Turning the supply off and then on caused it to trip again. I believe there is something wrong with the current sense in the power supply causing it to trip. I will try a different supply.


    Indicator Lamps from Marc Verdiell
    We do have plenty of these bulbs. They must be taken from insides of popular telco bulbs, so they are a bit hidden. I have sorted out our collection. Be very careful, there are some of all voltages from 6V to 48V. They look the same. If you put some that are too low voltage, they might work, but they will eventually burn the colored plastic of the indicator. We ruined a 1401 front panel because of that. The ones I have sorted have been tested and their voltage is written on their bin.


    Report from Mei Luo
    I was there 5 hours from 10am to 3pm.

    Fixed the ribbon issue of keypunch machine #1 with Frank.
    Issue: The ink ribbon was broken.
    Fix: The ribbon on left spool is much shorter than on the right side. So we removed the ribbon on the left spool. Pulled the ribbon from the right spool, fed it between the punch die and the card bed by slicing it through the groove in the center of the card bed. Hooked the ribbon end in the slot in the center of empty left spool and wound it onto the spool. Made a reasonable size knot to work as reversing eyelet on the spool. Placed the spool on the left spindle.
    We tested it. It functions correctly.


    IBM 1401 demonstrations 4/29/2023
    IBM 1401 demonstration 4/29/2023 11:00 am from Stephen H. Madsen
    - CHM 1401 Demo Saturday 4/29/2023 1:00 PM - from Jack Ghiselli
    IBM 1401 demonstration 4/29/2023 11:00 am from Stephen H. Madsen
    Peter Chang and I demonstrated to 19 visitors. We used DE for BigPrint and CT for demonstrating the tape drives. Based on recent reports, we did not try reading cards on CT.

    Stephen H. Madsen

    CHM 1401 Demo Saturday 4/29/2023 1:00 PM - from Jack Ghiselli
    Duane Sand and I gave the 1401 demo to 28 visitors, plus mini-demos to 17 more who came in early (and couldn't stay) or afterwards. We had foreign visitors from Bulgaria, Canada, Colombia, Singapore, Spain, and Tajikistan. The group from Tajikistan came in early and was surprised to hear Duane explain he'd been there. So Duane talked to them before the demo, and I talked to some visitors from Milpitas, since I'd been there.

    After talking to the 11:00 AM team (Steve Madsen and Peter Chang), we understood that CT1402 was refusing to read cards, so we followed their lead and ran BigPrint on DE and the TAU tape demo on CT.

    When we arrived CT 729 #4 (far right) had the leader of the tape jammed into the front of the take-up reel, and had been marked "Out of Operation". We pulled the tape free and cut off about ten feet of crinkled tape. The Amazing Peter Chang stuck on a new beginning-of-reel reflective spot and re-threaded the tape (Peter is getting good). The tape drive now works, and we used it during the demo. For anybody who needs it, a supply of reflective spot tape is in the demo cart plastic box.

    When we demo'ed the 083 Sorter, the first card jammed. Duane was able to remove it, and we were able to complete the demo.

    After the demo, CT 729 #2 (second from left) refused to unload, although it had been working fine during the demo. So we powered off CT with 729 #2 tape still loaded. Back in the day, the computer room supervisor would have excavated me a new orifice, so I apologize. We set the drive to "Out of Operation".

    DE and all three 029 keypunches worked file. The printing on the keypunches is nice and dark -- thanks to the Restoration Team.

    Jack Ghiselli mobile 1-408-839-1051

    4/28 1401 Mini-Status Report - from Samuel Plainfield
    Prior to the commencement of the private demo today, I had some time to perform some more detailed tests on the CT1402. Feeding a known working deck in (my trusty green Lincoln!) resulted in four cards in the tray and two in the reader and it would stop with either a read check and/or a VALIDITY each time. I was unable to get any deck to fully read. I tried again with a second known working deck and again, four cards in the tray, two in the reader, errored out.

    With those symptoms, I assume that it is able to read the first four cards but able to continue past that.

    To test this theory, I ran the single-card 80-80 list and put four decoder cards behind it. Expected behavior is that two should print, and then after a START, another two should print, right?

    The cards went through, but only three lines printed. It’s somewhat inconsistent between each run.

    Maybe this is because of the VALIDITY error? DE1402 worked brilliantly, CT1402 remains a mystery … but at least we know it’s able to read some data preliminarily, I hope that helps us narrow it down somewhat?

    ~Samuel Plainfield

    1401 Restoration Status Reports, Weds, 4/26/2023
    from Robert Garner
    - from Samuel Plainfield
    from Robert Garner
    1401 Restoration Hours: 4/26/2023
    Clementson, David 3
    Garner, Robert 2
    Howard, John 3
    King, Frank 5
    Lion, Rob 5
    Paddock, Stan 5
    Szolyga, Tom 5
    Verdiell, Marc 3

    Synopsys (details & photos below):

    • Sam, Frank, and John investigated a Validity check stop on the DE 1402. A simple problem for once: the On-Line/Off-Line switch has been inadvertently left in the Off-Line position. ;~} Last week's microswitch replacement & adjustment is holding as the DE 1402 has yet to thrown a Punch Check.
    • The CT 1402 card reader seemed fine, but the demo docents shunned it for the 3pm demo. Perhaps coincidentally, the Demo Lab was quite warm by 3:45pm, when Robert turned on the CRAC unit. (A reminder to check that the AC is on before demos.)
    • Rob continued to adjust the print plate for the in-the-shop 026 keypunch. Printed characters have now only a few extra dots. :)
    • All three demo-lab keypunches were fully functional and properly printing.
    • Tom continued to assemble and wire-up his 1401 serial interface adapter.
    • We enjoyed Grant Saviers visitation! He graciously spoke and shared stories with each of us.
    • David and Robert checked out the Xerox PARC Alto emulators, setup for the Alto@50 event. Robert enjoyed talking with and sharing stories with Josh Dersch and friends. Robert was delighted to give Butler Lampson (of PARC fame) a short tour of the 1401 demo lab.

    Detailed reports & photos:

    Grant Saviers talks with Robb Lion about the 026 code plate:

    Pat Buder captivating visitors to the 1401 Demo Lab:

    1401 Demo Lab visitors happy with their time-machine ephemera/artifacts:

    Dan’l Lewin and Butler & Lois Lampson, before a short tour of the 1401 Demo Lab:

    from Samuel Plainfield
    Today, DE1402 was throwing some VALIDITY checks. Frank, John and I did myriad testing. Frank suspected brush problems and bad decks. I went for my trusty green (2015) Lincoln deck and even that threw a VALIDITY check.

    I ran the deck on CT1402 to verify/isolate whether the deck was the issue or not and it printed fine. We eventually figured out that the problem was that DE1402 was accidentally left in OFFLINE mode.

    Switched back ONLINE and everything worked fine again.

    The Lincoln decks are excellent for testing. The cards are sturdy and the program is short and it’s nice to not put additional wear on the BigPrint decks. :)

    Frank shared a tip he learned from a colleague at IBM to track/check brush paths — run a crayon along a row and feed the card face-up.

    Retrieve the card, hold it up to the light and look *very* closely, preferably with a magnifying glass and you’ll be able to see the faint brush strokes that graze the paper. This can show potential misalignment.

    Zoom in closely and you’ll see the brush strokes. I’ll try and read through what can be done about verifying how the brushes can be brought to spec… whatever that may be.

    One of the BigPrint decks had a flimsy first card, I duplicated it onto a sturdy card and re-labeled it.

    I didn’t encounter any problems with the 1402s after this, but Pat told me after the demo that they were still having read problems. . .

    ~Samuel Plainfield

    and a comment from David Clementson
    Not much to add to Sam's report this week. The 1402 is still generating Reader Check errors, but maybe not as frequently as in prior weeks.

    I checked the clutched belt tension per the instructions in the documentation. It was actually in spec, but on the loose end of its tolerance range. I adjusted it to the tight end of its tolerance range, but when I tested it immediately after, I got the usual Reader Check error. Bummer.

    So I decided to go through the entire reader timing adjustment procedure in the documentation. Most procedure items were feeler gauge checks of different mechanical clearances. All were within spec and I didn't have to make any adjustments except making a very slight change (~0.03") to advance the position of the first brush set relative to its scribe. Next, we used the in-built timing analyzer to check the brush and solar cell timings. There aren't good instructions on how to use this analyzer, but we were able to get some results that seem plausible. Sam's videos show the results, however it does look like there is an interaction between the camera shutter and the flashing lights that make the results appear more erratic than they actually are.

    I am still baffled by two aspects of the Analyzer, however:

    • Does the Online/Offline switch need to be in the Offline position in order for the Analyzer results to be valid? I think it does. I base this on the belief that when in Online mode, the contact rollers are energized using a signal that is derived from the solar cell. This belief comes from the study of the schematics and my best divination of the switching and transistor amplifiers that drive the common brushes. My understanding is that the "center cell clocking" of the raw brush signal is accomplished by using the solar cell pulses (which should occur in the center of the brush contact window for each row read) to energize the contact rollers. This then causes the resulting brush signals that go to the 1401 core to have well-behaved timing edges derived from the solar cell instead of the ragged edges that the raw brush contact wires would produce. If this is the case, then there is no way to observe the actual raw brush contact timings. I think that when the Analyzer is in Offline mode, the common brush is continuously energized, allowing the Analyzer to display the actual raw brush timing.
    • So if the Analyzer needs to be in Offline mode for proper timing display, what is the recommended procedure for running a deck to stimulate the test?

    After completing the timing adjustment procedure, the behavior of the machine was not a lot different than before: Reader Checks still occurred.

    At this point, Frank went to see if we had any spare belts on hand. He was able to find two new spares, both in great condition and marked with the correct IBM part number. So we decided to just change the belt, since it was still the prime suspect. I looked at the belt replacement procedure and estimated that replacing the belt would only take a few minutes, but retiming the machine with the new belt would likely take hours. So we elected to save that task for next week. Frank will not be in next week, so we will try to do it in his absence.

    We also talked about getting some photo interrupters (both reflective and transmissive type) to allow us to collect card and pulley position feedback using our digital scope. Triggering the scope from the solar cell then observing the timing of the card/pulley sensors effectively put the relevant mechanical components inside the observation loop. Any jitter on the sensor timing will directly correspond to fluctuations in the behavior of the mechanical components. So I will order some sensors and make a tester or two that we can play with next week.

    That's it for this week. 6 hours.


    IBM 1401 Demonstrations Saturday 4/22/2023
    11:00 AM - from Stephen Madsen
    - 3:00 PM - from Paul Laughton
    11:00 AM - from Stephen Madsen
    Larry Hara and I gave the demonstration to 21 visitors, including foreign visitors from Sweden and the UK.

    The key on the horseshoe is still missing, so we had the front desk let us into the back room. We used CT. Big Print deck #2 would not load, so we used Big Print deck #4. It worked OK. After the demonstration, we fixed and verified Big Print deck #2.

    All three key punches worked with good printing. The sorter worked.

    Stephen H. Madsen

    3:00 PM - from Paul Laughton
    Larry Hara and I gave the demo to about 55 people. Additional groups were serviced before and after the demo.

    DE, the three keypunches, the 083 and the CT Tapes were perfectly behaved. The CT card reader not so much.

    We were able to run Big Print on CT before the demo. During the demo it would not read the first card of the deck even with several Trojan cards on up front. Fortunately, we had preloaded Big Print on DE so we were able to trill the guests with Big Printing during and after the demo.

    CT 1403 ran out of paper while we were doing Big Prints before the demo. We snached the box of new paper from DE for CT. We left about 6" of paper loaded into the DE 1403.

    The Horseshoe with its keys remains missing. The AM shift was able to open up using a key from the front desk.

    Paul Laughton.

    IBM 1401 Demo Status Report - 4/19/2023 - from Pat Buder

    On Wednesday, 4/19/2023, Samuel Plainfield and I gave the demo to 42 guests. Another 15 came by before or after the main demo.

    All three keypunches, the 001 keypunch, and the 083 sorter all ran fine.

    We started the demo on CT but had DE powered on and ready to go if needed. We left BigPrint loaded in CT just before the demo. Our intention was to begin reading the name card during the demo and to forego loading the program because that has been problematic lately. When it came time to run BigPrint during the demo, the CT 1402 would not read the name card. We tried to reload the entire deck, but that didn't work either. We hastily transferred to DE, but no joy there. I had Samuel go back to CT to try to get BigPrint to load while I continued the description part of the demo. In short order he reported success on CT, so we moved back there to show BigPrint printing. We also ran all four tapes on CT without incident.

    After the demo when the crowd had cleared Mariane Kim, Samuel, and I attacked the BigPrint decks with Jack's VOBJ program. We found the usual assortment of missing or incorrect cards. Mariane applied fixes. We ran out of time but left with two BigPrint decks marked good and one marked bad. We didn't test the fourth deck.

    As usual, we had enlightening and fruitful discussions with various restoration team members before the demo. Thanks to them for all they do.


    1401 Restoration Status Reports, Weds, 4/19/2023
    - from
    Robert Garner
    - from Samuel Plainfield
    - from Ken Shirriff
    - from David Clementson

    1401 Restoration Status Report, Weds, 4/19/2023 - from Robert Garner
    Here’s the 1401 Restoration Status Report for Wednesday, April 19th:

    1401 Restoration Hours: 4/19/2023

    Clementson, David 6
    Garner, Robert 4
    Howard, John 5
    Kim, Mariane 6
    King, Frank 6
    Luo, May 5
    Paddock, Stan 6
    Shirriff, Ken 4
    Verdiell, Marc 3
    Synopsys (details & photos below):
    • David and John installed the refurbished motor back into the 083 sorter along with a new wiring harness. It’s now back up, ready for demo'ing again.
    • David, John, Frank, Marc, and Ken worked on the DE 1402 Punch Check error stop, presumed caused by a misfiring, sliding-pin-actuated microswitch. As the corresponding microswitch in the CT 1402 has a small restoring spring, David and Marc elected to attach a similar spring to the DE 1402’s microswitch. After adjusting its trip threshold, the microswitch appears to be working reliably. Notwithstanding the fix, Ken examined the ALDs but didn't see how the microswitch causes a Punch Check. (The documentation implies that the microswitch should trigger a Punch Stop, not a Punch Check.)
    • Sam, Frank, Ken and Stan worked on the belligerent CT 1402 card reader, finding bent and burnished pins on three relays. Frank used the 1401’s Storage Scan mode to assess hole brush misreads (and tried out his in-the-works diagnostic write-up/procedure). As usual, the 1402 seemed ready to go after the doting attention, but nevertheless performed erratically during the 3pm demo.
    • Mariane and May continued the tedious process of adjusting the print plate for the 026 keypunch in the workshop (photo below).
    • John, David, Frank, Marc, Stan, and Robert (photo below) discussed how to improve relay testing, including moving beyond a simple go/nogo test; assessing relay reliability over a larger number of test cycles (looking at variation in resistance across many samples); and converting the tester into a stand-alone unit without a PC umbilical. The discussion also considered whether the 1402 circuit breakers (CBs) might be impacting relay reliability, perhaps by not properly opening/closing to avoid contact arcing.
    • Ken reset a popped circuit breaker on DE 729 #3. Something to watch.
    • Ton Luong reported status of the CHM IT project to move the 1401 web site from GoDaddy to another cloud site, maintained by the CHM staff. (See his and Tom’s emails below.)
    • May and Sam fixed an auto-feed-enhanced card jam pile up on keypunch #3 (nearest to the closet). All three keypunches on the floor should now be fully functional and printing.
    Detailed reports & photos:

    May and Marianne work on the tedious task of realigning the 026 code plate:

    John and demonstrating the relay tester:

    The relay tester (John added a new power supply to Stan's original design):

    David, Ken, John, and Marc debate how to enhance our relay testing methodology:

    1401 Restoration Status Report, Weds, 4/19/2023 - from Samuel Plainfield
    Fully expecting the "mess" that Jack warned us about, Frank, Stan and I began by testing the CT 1402 with a known good BigPrint deck and found it to be intermittently working once, but then it started throwing read checks upon subsequent loads and failing to feed cards thereafter. Frank stepped through with the 1401 on Storage Scan mode and the results were inconclusive. Attempts to re-run the deck resulted in it just attempting to feed but not pulling any cards. Frank suspected that behavior is a result of a relay problem. As such, relay testing was continued...

    CT 1402 Relays:

    6 - 0.86
    7 - 0.9
    8 - 0.79
    9 - 0.93
    10 - 0.79
    11 - 0.75
    12 - 0.82
    13 - 0.94
    14 - 0.98
    15 - 0.74
    16 - 1.24
    17 - 1.44 (bent) #24 on official 1402 schematics
    18 - 1.90
    19 - 0.98
    20 - 0.38 (bent)
    21 - 0.57
    22 - 0.98
    23 - 0.81
    24 - 1.23
    25 - 1.52
    26 - 1.69
    27 - 0.92 (burnt looking pins on relay itself)
    28 - 0.99
    29 - 1.04
    30 - 1.87
    31 - 1.69
    I tried to put this into Mariane's spreadsheet from last week, but it's set to read only.

    I noted that the pins in relay #17 and #20 had a bent connecting pin on the lower right of the socket:

    Very difficult to photograph, but you can see the receiving pin is pushed in.

    With *extreme caution* I corrected it by ever-so-gently pulling it out back into position using this dental looking tool:

    Stan says "The "dental tool" is a spring tool."

    Ken brought over the schematics to see if the sockets with bent pins had any bearing on the intermittent issues we were seeing and noted that the numbering doesn't match the schematic itself. Hence relay #17 being relay #24 in the schematic... which also doesn't match the numbering you see on the relays themselves... so, take note. My numbering above is based on just going from left-to-right in order.

    ("BR" stands for Brush)
    There are 13 relays on the top row in the unit itself, I am not sure why it only shows 12 in the schematics, or why numbers 13 through 20 are skipped.

    Relay #27 has rather "burnt" looking pins, though it tested perfectly fine -- not sure how much that matters, if at all, but you can see they're quite darkened:

    The metal relay-puller/extractor tool was taken from -- and returned to -- Marc's complete IBM tool case.

    As a result of Storage Scan checks, Frank attempted to look directly at the brushes themselves to see if they needed alignment. They mostly looked fine, but there are some slight abnormalities that might be worth a look under a magnifying glass one day:

    The brushes are extremely fragile looking and it doesn't seem like it would take much to set them off alignment.

    After powering it back on, I was able to get a rando Lincoln deck to print perfectly fine... once, but not a second time:

    Thereafter, BigPrint worked after 3x tries so we left it loaded for the demo -- which of course still failed to load at the critical moment... but miraculously worked after a fresh load. There seems to be a common delay when the program switches from loading the data on program cards to the date card/guest cards that may just be attributed to the "guest" newer style punch cards(?). So... still intermittent.

    Separately: A ton of cards were continuously getting jammed due to the auto-feed on the keypunch nearest to the closet and May and I were able to get it fixed and stopped jamming -- one specific card was wedged just barely visible causing all the havoc. Auto-feed is turned off and the offending card discarded. :)

    Mariane and I reprinted some BigPrint cards and she and Pat ran the VBOJ deck to attempt to fix some suspect decks. The decks have been labeled accordingly.

    ~Samuel Plainfield

    1401 Restoration Status Report, Weds, 4/19/2023 - from Ken Shirriff
    Summary: Tape drives all run from the TAU. The DE Punch Check light is a mystery and I don't understand how it happens.

    Jack mentioned tape drive problems. I tested all the drives from the TAU. DE drive number 3 had the Fuse light on, and circuit breaker CP 3 had popped out. I pushed it back in and now all drives on DE and CT work. I don't know why the 3 is crossed out and 4 is penciled in. We should probably keep an eye on this drive in case the circuit breaker trips again. Maybe a problem with the breaker or maybe an electrical problem?

    I looked at the DE 1402 punch with David, John, and Frank. The Punch Check light was on. A mystery switch was attached but it turned out to be from Stan's debugging. The Punch Check light would go out briefly if I pushed Check Reset, but would immediately come back. After the others fiddled with the machine, the problem went away.

    I did some research and I'm confused as to how a Punch Check can happen when you're not punching, and how a microswitch problem can be related. Punch Check indicates that the 1401 detected a problem with the holes, while Punch Stop indicates a mechanical problem. So I'd expect to see a Punch Stop, not a Punch Check.

    I studied the ALDs and the 1042 schematics and I don't see how the microswitch could trigger Punch Check. I was going to trace the signal with the oscilloscope, but the problem went away. The Punch Check circuitry shows an input from RD REL CHK But we don't have ALD volume 56 and I don't think that feature is installed. So it's all very mysterious to me.


    1401 Restoration Status Report, Weds, 4/19/2023 - from David Clementson
    • John and I installed the newly refurbished motor back into the 083 sorter. It fired up right away and ran decks, although some warped cards refused to feed and had to be discarded. Unfortunately, all of the cards were routed to the reject pocket. As we were head scratching about a possible cause, we were sidetracked into a workshop discussion about relay test algorithms. We broke for lunch, and as we were reporting our progress to the team, Frank asked if we had reinstalled the brush. I replied that we had not removed the brush, to which Frank replied "I did." So after lunch we reinstalled the missing brush and the machine sorted normally with cards being routed to all pockets. So the sorter is back online.

    • We next turned our attention to the DE card punch check error situation. We admittedly don't know exactly why the punch check error is happening, but we looked at the punch lock interlock microswitch because toggling it has the effect of clearing the error. The switch is actuated by a sliding pin that passes through the main chassis plate. As it is rotated into the lock position, the punch lock handle moves a lever that pushes on the pin which then activates the switch. However when the lock handle is released, there is nothing to provide the force necessary to push the pin back to its home position. Looking at the switch and comparing it to the CT machine, it became apparent that the restoring force should come from the switch itself. Further, we found that the switch had provisions for a return spring, but the spring was missing. This may be because it is a replacement switch, since it is clearly newer than the CT switch. Marc helped us out by locating and installing a replacement spring. After reinstalling the switch and adjusting its trip threshold, the interlock now appears to be working reliably. We will need to monitor the punch check error condition to see if this fix is curative.

    • As mentioned above, we discussed relay test algorithms and how the current generation tester might be deployed. In summary, the consensus seemed to be:
      • Make the tester stand-alone (no PC needed) by adding an LCD and user interface switches.
      • Allow the tester to run continuously to enable the collection of reliability statistics.
      • Because we don't know the contact resistance requirements for every possible relay use location, we should elect to not build in go/no-go resistance thresholds, but rather just report the maximum resistance found since the start of the test (assuming we don't care much about the minimum resistance.) This will provide more of a figure-of-merit for the relay instead of just a good/bad indication.
      • John agreed to incorporate this feedback into his design
    That's it for this week. 6 hours.

    CHM 1401 Demo Reports, Saturday 4/15/2023 11:00 AM & 1:30 PM - from Jack Ghiselli
    with comments from David Clementson and Ignacio Menendez

    Bill Worthington and I gave the 11:00 AM demo to 22 people plus 8 more who wandered in late. We had foreign visitors from Belgium, Brazil, and China.

    Duane Sand and I gave the 1:00 PM demo to 26 people, plus 10 more who wandered in late. We had foreign visitors from Ecuador, Germany, India, Italy, Russia, and the UK.

    Horseshoe Key-ring: When we arrived, the horseshoe key-ring was missing from the A/V drawer, so we couldn't get in to the back room of the Demo Lab. We looked high and low for a lame horse, to no avail. Perhaps the Restoration Team took the horseshoe into the Restoration Room (where it used to be kept) to prevent us from demo-ing and perhaps breaking the equipment? But "neener, neener" -- we found another 1401 key at the front desk and got in.

    083 Sorter: The Sorter is still INOP, and is marked as such, so we skipped it in the demo.

    BigPrint Decks: Last Wednesday, Paul Laughton reported that BigPrint Deck #1 got read errors always on one particular card. We tried it on CT and got the same result. We ran BigPrint Deck #2 successfully, so we decided to punch a duplicate of it to replace BigPrint Deck #1. However, now we started to get Read Checks on CT 1402. Then we got a Punch Check on CT 1402. Now, when we tried to re-load BigPrint #2, the CT1402 refused to read the first card. We tried a Powers-of-Two and CT also refused to read the first card. Things getting worse and worse. So, we gave up on CT and moved to DE. When we tried to reproduce the BigPrint, the DE1401 got Punch Checks. So, we gave up trying to reproduce the deck. After the demos, we looked at BigPrint #3. Surprisingly, it was missing its Last Card (seq # 111). So, we copied the Last Card from BigPrint #2 and repaired BigPrint #3. Now, the DE1402 started acting up, and gave us lots of Read Checks when we tried to test our repaired BigPrint #3. Eventually, we gave up, and left the mess for Wednesday. Sorry about that.

    Tape Drives: When we tried the CT 729 Tape Drives, only #1 would work. #2 and #3 would not operate from the TAU. So, we used DE for the demo of card loading and printing, and used CT for tape demos. Although CT will not read cards, all four 729 Tape Drives worked fine with the TAU.

    1403 Printer: During our demo, the DE1403 Printer got Forms Checks. Sure enough, the supply box was down to the last inch stack of paper, and seemed to get frequent forms separations trying to use that last inch. We put a new box of 1411 forms in the DE 1403 and it works fine now. We should have checked before the demo.

    029 Keypunches: The keypunch farthest from the closet intermittently fails to feed a blank card correctly. All three keypunches had very light printing (almost illegible, and bad for the demo). We discovered that sometimes the keypunch ribbon seems to fail to reverse at end-of-ribbon. Also, the ribbon is folded near its end. When we forced a ribbon reverse and ran the ribbon a short way down, the printing returned to quite good. A big THANKS to whoever is inking the ribbons.

    Wall Clock: Our "Official IBM Wall Clock" has stopped. We tried replacing its two AA batteries with two different sets, but no luck. Is there something else needed? We removed the clock from the wall since it was showing the wrong time, and it's on top of the CT1406.

    A/V Battery Charger: We left four rechargeable AA batteries in the charger, and the red lights were ON.

    Status Summary for next Wednesday:

    • Keys: See if you can find the Horseshoe Key-ring

    • 083 Sorter: The Sorter is still INOP, and is marked as such.

    • CT1402 won't read first card. Hope you can fix it.

    • DE1402 gets lots of Reader Checks. Hope you can fix it.

    • Tapes: The TAUs will run one Tape Drive on DE, and all four on CT.

    Due to 1402 problems, we were UNABLE to verify BigPrint decks or punch new ones. Suggest you do this before your demo. BigPrint #2 is probably your best bet.

    Jack Ghiselli mobile 1-408-839-1051

    from David Clementson
    I was the first one in last Wednesday, and found then that the horseshoe key ring was missing from its usual place in the AV closet. I had to ask Jesse at the front desk to find someone with a key to open the workshop. Once the workshop was open, I searched but didn’t find the key ring. So it seems that it went missing sometime before last Wednesday.


    from Ignacio Menendez
    Just a small observation on the tape drives:
    If the simulator is connected, via the rear square connectors, to either of the DE or Conn. drives, the SIMULATOR MUST be turned ON as well, or many or all drives will fail to operate correctly….
    If in doubt, disconnect the cables from the simulator and connect a terminator on the last drive of the string.

    We have had this problem as far as I can remember, and somehow we seem to forget.


    1401 Restoration Status Report, Weds, 4/12/2023 from Robert Garner and others

    1401 Restoration Hours: 4/12/2023
    Clementson, David 6
    Garner, Robert 4
    Howard, John 4
    Kim, Mariane 6
    King, Frank 5
    Lion, Rob 6
    Paddock, Stan 5
    Shirriff, Ken 4
    Szolyga, Tom 6

    Synopsys (details & photos below):

    • David and John worked on the disabled 082 sorter. They removed the motor and and cleaned out its interior, suspecting that its centrifugal switch (that engages the start winding) isn’t properly functioning. The motor will be reinstalled next session. David also replaced its brittle and frayed AC wiring harness (photo below).
    • Marianne and Sam noticed that the 026 nearest the closet was printing “S" as “K" and “V" as “N,” indicative of vertical misalignment of the code plate. Adjusting the code plate alignment screws fixed the problem.
    • For the 026 keypunch in the shop, David reinstalled the 2nd code-plate-offset screw that he had fabricated. Marianne and Rob reassembled the print unit and began the arduous processes of precisely aligning the code plate (photos below).
    • Marianne, Stan and Sam tested five reader relays in the CT 1402 prior to the 3pm demo session. The plan is to continue testing the remaining reader relays next week. Marianne setup a Google docs spreadsheet to track relay health and repairs.
    • Marianne and John readjusted the DE 1402 punch die, alleviating yet another punch check stop. Further investigated is needed.
    • Tom’s Arduino-to-1401 serial port interface is fully stuffed/assembled and ready to begin PC-based testing.
    • The print quality is still faint for the 026 keypunch nearest the walkway. The other two keypunches on the floor should be fully functional.

    Detailed reports & photos:

    Marianne and Rob begin the arduous process of precisely realigning the 026 code plate:

    David examines the 082’s brittle and frayed 1/4-hp motor wiring harness:

    Tom’s fully assembled Arduino-to-1401 serial port interface:

    Visitors enjoy the post-demo, hands-on punched card experience:

    An enthusiastic father & son, post-demo:

    From: David Clementson
    Subject: Restoration Report for 04/12/2023
    • Installed a 2nd replacement code plate offsetscrew into the 029 keypunch in preparation for Rob to reassemble it
    • Worked with John on investigating the no-start condition of the 082 sorter:
      • confirmed that the Start Relay (R13) was not being picked and held. Tried swapping in a different Start relay (R13) but it had no effect
      • We noticed that in some cases, pressing and holding the Start button would cause the Power light to extinguish and the thermal relay to restart its power-on delay. We traced this to some kind of short that would hold down the +48V rail, possibly due to a case where a pair of relay contacts that are supposed to be mutually exclusive were incorrectly closed at the same time. However we could not pinpoint the problem, nor could we reproduce the problem reliably. The machine eventually stopped doing it.
      • we checked the operation of the two motor relays and they looked okay, but the motor still did not start
      • we suspected that the centrifugal switch inside the motor that engages the start winding (via the start capacitor) may not be closing so we started to remove the motor for service
      • while working with the motor, we found that its wiring harness insulation had become brittle and was flaking off in an unsafe manner, so we replaced the motor wiring with new THHN wires.
      • We also cleaned the inside of the motor, which was filled with dirt and lint that could easily prevent the centrifugal switch from working properly. We tested the motor start capacitor as good, and confirmed that the motor starts properly on the bench. We also oiled the motor bearings.
      • The motor awaits reinstallation next week.
    That's it for this week. 6 hours.

    From: Mariane Kim
    Subject: 2023-04-12 Restoration Report

    026 Keypunch nearest the audio closet
    Status: Operational
    Sam Plainfield and I started by duplicating some decoder cards. We noticed that the characters printed were, for the most part, correct. However, there were a few apparent outliers. The most obvious examples were a punched S or V printed a K and an N, respectively. Looking at the code plate chart provided by IBM, this indicated a vertical misalignment. We loosened the locking screws and made minor adjustments to the adjusting screws to reposition the code plate.

    We didn't verify using 500 cards, but duplicating approx. 15 cards showed that the printing problems were fixed. This unit can now be used for demonstration purposes until the keypunch in the workshop is repaired.

    026 Keypunch in workshop: Status: Not operational Rob Lion reassembled the print unit on this keypunch. Next week's challenge will be to finish readjusting the code plate.

    DE 1402 PUNCH CHECK light came on again John Howard helped us readjust the punch die, and the light went out. We might need to investigate why this keeps happening.

    CT 1402 intermittent card read problems CT 1402 Stan, Sam and I were able to test 5 relays prior to the 3pm demonstrations. The plan is to continue testing the remaining reader relays next week. We can use this spreadsheet to keep track of relay health, notes, and any repairs.

    Relay # Highest Resistance Contact (ohms)
                  2023-01-18 2023-04-12
    1 1.14 2.25
    2 1.7 0.94
    3 2.3 1.39
    4 0.77 0.75
    5 0.41 1
    6 0.37
    7 0.6
    8 0.39
    9 0.42
    10 0.53
    11 0.66
    12 0.89
    13 0.72

    [TWO]1401 Demos, Wednesday, 4/12 - from Paul Laughton

    Two demos were given. One was for a group of international diplomats at 1:20. The other was the normal 3:PM demo.

    Larry Hara, Mariane Kim and I did the diplomats' demo. Seven people showed up. The demo quickly evolved in a question and answer session. Mariane conducted a French speaking Q&A session with two young Swiss diplomats. Larry and [I] talked with five senior diplomats from a variety of nations.

    Larry and I gave the 3:00 PM demo. Larry counted a total of around 100 people that attended that demo. We did a lot, really a lot, of Big Prints after the demo. It would have been nice to have had another operator in the room.

    The 083 was labeled as out of service (which it was).

    The Keypunch nearest the AV closet was replaced by the education department's 029 on wheels. It had refreshed ink and worked perfectly.

    The middle Keypunch sometimes failed to feed cards. Mariane showed me that a good punch in the front of the card reservoir would convince it to feed properly.

    The ink on the remaining keypunch was too faint to use.

    CT was suffering from first card reading feed schizophrenia. It would not feed and then would feed. We kept DE in ready reserve but CT played nice for the demo. (Mariane and Sam Plainfield did some relay testing but did not find any abnormalities.

    One Big Print deck had consistent reader stops on the same card. I duplicated that card but to no avail. I have marked the deck.

    Paul Laughton

    IBM 1401 demonstration 4/08/2023 11:00 am - from Stephen Madsen

    Bill Worthington and I demonstrated to 43 people. We used CT, which worked OK.

    The 083 sorter would not read cards. I could hear a relay click when I pushed the START button. We just talked through the sorter demonstration.

    The 026 keypunch nearest the closet is marked INOP.

    Stephen H. Madsen

    CHM 1401 Demo Saturday 4/8/2023 1:00 PM Report - from Jack Ghiselli
    Peter Chang and I gave the 1401 Demo to 43 people, plus mini-demos to 8 more who wandered in later. We had foreign visitors from China, Germany, India, The Philippines, Russia, and Ukraine.

    CT1402: We ran on CT, which ran very well. We had a couple of failed Loads, but they appeared to be caused by worn first cards. One READER CHECK prior to the demo, but we were able to recover and continue the load. Apparently Ken Shirriff is correct that the frequent Reader Check problem has gone away.

    083 Sorter is inop. When we hit START, we hear and see a relay click (the cover is still off, as the Restoration Team left it last Wednesday), but no cards read. Today's earlier 11:00 AM demo found the same symptom. So we skipped the 083 in the demo.

    The 026 Keypunch nearest the closet remains inop, and is so marked. The other two work well, and the inked ribbons do excellent printing. Kudos to the Restoration Re-Inking Team.

    New (to me) Information: I've been incorrectly saying that the CHM has the only two restored and operational 1401s in the world. Apparently there are two (2) others, although they're harder to visit:

    IBM Deutschland: One of our visitors today was an ex-IBM'er from Böblingen, Germany. He was familiar with the restored IBM 1401 unit which was originally at IBM Sindelfingen, and which later was moved to IBM Böblingen. He says IBM has now closed the Böblingen facility, and the 1401 has been moved to the IBM financial centter at Ehningen, about 7 km southwest. He thinks ordinary mortals still cannot get in to see it unless they have an "in" with IBM.

    TechWorks!: If I understand correctly, there is another restored 1401 at TechWorks! in Binghamton NY, about 10 miles east of IBM Endicott, where the doggone things were originally built. Their website says you can see it by appointment on Wednesday evenings. They also supposedly have a restored 1440.

    Anybody know of other restored 1401s?

    Jack Ghiselli j mobile 1-408-839-1051

    1401 Restoration Status Report, Weds, 4/5/2023 - from Robert Garner

    Here’s the 1401 Restoration Status Report for Wednesday, April 5th:
    1401 Restoration Hours: 4/5/2023
    Clementson, David 6
    Howard, John 4
    King, Frank 5
    Lion, Rob 5
    Luo, May 5
    Paddock, Stan 5
    Shirriff, Ken 6
    Szolyga, Tom 6
    Synopsys (details & photos below):
    • Both of the 1402s pranked us on April Fools Day: Paul had reported that the DE 1402 refused read cards (while the punch check light was impertinently lit) while the CT 1402 chomped the only known-good Big Print deck, leaving him unable to run a demo deck on either system. :( Later on Saturday, Jack curated the four BigPrint decks, particularly repairing #4, successfully fixing all four.
    • On Weds, Ken successfully ran the BigPrint deck #4 on the CT 1402 three times (see photo).
    • Frank and Stan examined the DE 1402 punch check condition. After he pulled the punch die out and rotated it (which effected its interlock mechanism), and John Howard reinstalled it, the punch check light went out. Frank further adjusted the card lever that engages the interlock, which may fix the problem (we’ll see).
    • Ken, Frank and May cleaned all three DE 729s. While debugging a skew-error problem in 729 #3, the apparent cause, several volts of noise on the 2-bit signal, vanished. All three DE 729s were operational at end of day.
    • David and Robb installed a new code plate adjustment screw (that David had fabricated) into the disabled 026 keypunch in the workshop. They realized that a 2nd adjustment screw also should be replaced. (David will fabricate another).
    • The 083 sorter also thought it was April Fools Day, but began to work again on its own volition before the demo started.
    • Frank gave some advice on feeding cards into the 1402: do not to apply hand pressure on the deck in the feeding station, which can cause the card to go through crooked, resulting in a jam. He’ll be writing up two reader-check action step lists: one for running out and retrying the cards again, and a second for a more in-depth analysis of the failure. (See my summary below.*)
    • We may have reached the conclusion that we should be using oil-based ink for the keypunch ribbons (not water based).
    • We’re sorry to report that two 026 keypunches (out of 5 total) are still not printing: one in the workshop and one in Demo Lab.

    Detailed reports & photos: x
    From: Ken Shirriff
    Subject: CHM status April 5, 2023
    Date: April 5, 2023 at 7:42:30 PM PDT

    To: Robert Garner

    Summary: CT card reader working, DE tape drives cleaned. Two problems mysteriously went away.

    Jack left a detailed note describing the problems with the CT card reader.
    I ran the Bigprint #4 deck three times successfully (see photo), so the card reader seems to be working now.

    I tested the DE tape drives from the TAU panel. Drive #1 worked with minimal errors, but #2 and #3 had many errors.
    May and Frank cleaned the drives which fixed #2. #3 continued to have skew errors. I looked at the signals for the 1, 2, 4, 8 signals in the TAU. When drive #3 was selected, the 2-bit signal had several volts of noise (cyan below), even when not actively reading a tape. When a different drive was selected, there was no noise. I believe this noise was triggering the skew error, not an actual skew. And the problem appears to be in the tape drive.

    I swapped the K, L, and M amplifier cards in drive #3 between bits 1 and 2, expecting the noise to move, but it stayed on bit 2, which was very strange.
    I probed multiple signals in the drive and got puzzling results; bit 1 seemed to be dead and I couldn't find a source for the noise on bit 2. Then the drive started working properly. I suspect there was a bad connection somewhere in the amplifier circuitry in the drive, but the fix is a bit unsatisfying. Now all three DE drives can write mostly error-free.


    from: David Clementson
    Subject: Restoration Report for Weds. 04/05/03
    Date: April 6, 2023 at 11:54:00 AM PDT
    To: Robert Garner < >
    • Rob [Lion] and I tried to remove the broken code plate adjustment screw from the 029 keypunch machine, but we were unable to. But at least Rob was able to figure out how to remove the punch assembly from the machine, which then allowed us to drill the hole and re-tap it for a 4-40 thread. We installed an adjustment screw I had previously fabricated and it seemed to fit fine. The second screw (horizontal vs vertical adjust) had been similarly re-tapped in the past, and had an ill-fitting screw installed. I will fabricate a second screw which we can install next week prior to putting the machine back together. Hopefully once the adjustment mechanism is working properly, we can get the printing problem sorted out.
    • The 083 Sorter stopped working while the demo folks were working with it. The symptom was that pushing the start button would activate the start relay but nothing else. I opened the unit and measured some power supply voltages and everything looked okay - almost. I say almost because one rail that the documentation listed as -48V actually measured +48V. I suspect that the documentation I was looking at was for a different model, and that the machine we have is supposed to have a +48V rail. Some other documentation I found inside the machine hinted at a +48V rail, but I did not find anything definitive. Then when I went to press the Start button, the machine worked normally. Go figure. We ran several decks through it without a hitch, and it behaved well for the 3:00 demo.
    • I was able to wash some sample printer ribbon cloth to remove its ink. I believe I was successful, so we now have a stash of clean ribbon fabric to do ink testing with.
    • I tried dropping a metal letter punch onto the ribbon in order to test the concept of using it as a "calibrated" print hammer blow for ink testing. Unfortunately, the stamp cut right through the ribbon material. So we will need a new idea for ink testing. I brought in a 0.5" steel ball to see if it would work better than the punch, but I didn't get a chance to try it.
    That's it for this week. 6 hours.



    * Summary of Frank’s diagnostic action steps for addressing a persistent reader check error (to be printed up on a file card):

    Grab the checked card from the hopper, go to the 1401 panel, rotate the panel knob to Scan mode, push the Start button and the 1401 will stop on the faulty location in memory and display it. Compare what’s displayed against the card. If more than one bit position differs, then it’s likely that the card was read-in crooked. If errors consistently occur in the same position, that likely indicates a brush issue.

    1401 Demo, 4/1/23, PM - from Paul Laughton

    Scott Stauter, assisted by Duane Sand, and I gave the demo to about 50 guests. The guests appeared to be happy with the Demo despite the problem encountered.

    The 083, two of the keypunches and the CT tapes worked as planned.

    DE refused to read a card. The PUNCH check light was on.

    The first card of the (last) Big Print became jammed in the CT 1402. We did not clear the jam and thus no Big Print or any other program was run for the demo. We did have the guest punch cards after the demo.

    The (last) Big Print! All but one of the Big Print decks were marked as not working. The final working deck now has its first card jammed in the CT 1402.
    We have no working Big Prints to go along with no card reading 1401s.

    The microphone battery charger was found unplugged and outside of the AV room. Its batteries were lying next to it. We put the batteries in the charger and plugged it in. (I suspect that some unknown person is giving demos sometime after the Wednesday demos.) We used the rechargeable batteries that were in the mics for the demo. They worked for the duration of the demo.


    CHM 1401 Demo Update -- Tuesday 4/4/2023 - from Jack Ghiselli

    At the end of most recent demo, Saturday 4/1/2023, both 1401s were unusable. The DE1402 had a PUNCH CHECK error which prevented it from reading cards. The CT1402 had a card jam, so it also couldn't read cards. The demo team also reported problems with all four copies of BigPrint decks. And, the SF Giants baseball team wasn't doing well. Things were not looking auspicious for next Wednesday's demo. So I came in today (Tuesday 4/4/2023) to see if I could help.

    1. The DE1402 is still unusable due to the PUNCH CHECK.
    Hopefully, the Esteemed Restoration Team can look at this Wednesday morning.

    2. I cleared the two-card jam in the CT1402. The CT system now appears to run OK, except that the CT1402 intermittently gets a READER CHECK error every 20-100 cards or so.
         2A. Sometimes if you press down on the card weight with your thumb it seems to help, but sometimes not.
         2B. If you remember your card-handling training, and are very careful, you can recover from each READER CHECK. Thus you can run programs on CT, but you have to be patient and careful. A demo would be possible, but clumsy.
         2C. Hopefully, the Restoration Team can look at this Wednesday morning.

    3. I looked at all four of the BigPrint decks in the demo trays. They'd all been labelled "BAD".
         3A. We seem to have some confusion identifying specific decks, so I marked the four BigPrint Decks #1, #2, #3, and #4.
         3B. I checked all the decks by using VOBJ, and by trying to run them.
         3C. BigPrint Deck #1 was OK. Not sure if it actually caused problems. No fixes needed.
         3D. BigPrint Deck #2 was missing the last four (4) cards, sequence numbers 108, 109, 110, and 111. I recreated these, and the deck now works.
         3E. BigPrint Deck #3 had a damaged first card. I recreated it, and the deck now works.
         3F. BigPrint Deck #4 had a lot of problems:

    1. The first two cards were missing. This was probably the deck which jammed in CT1402, and these 2 cards are now the heap of fragments.
    2. Card #13 had been incorrectly marked "F/C". This doesn't cause a load problem, but it might indicated incorrect card handling.
    3. Cards 26-27 had been relocated to before Card 20. Due to the technical details of object decks, this doesn't make the deck unusable, but it again illustrates poor card handling.
    4. The last card was badly worn and wouldn't load.
    5. I finally gave up, threw out the whole deck, and punched a new BigPrint #4 deck. I tested it and it works.

         3G. There are now four (4) good BigPrint Decks in the Demo Cart Tray. I rubber-banded the run results to each deck as proof they're good.
         3H. I suggest we Lead Demo guys consider holding some additional training in card handling (especially recovery from Reader Errors) and in verifying object decks suspected of badness.

    4. No help for the SF Giants.

    I left a note on top of the CT1402 for the Restoration Team tomorrow. I won't be in tomorrow -- tied up in meetings.

    Jack Ghiselli mobile 1-408-839-1051

    Re: 1401 Restoration Status Report, Weds, 3/29/2023 - from Grant Saviers

    Read the report (below) and offer a couple of comments to pass on re 729s and TAU Emulator

    RE 729 cleaning - since I was an operator for same configuration as both CHM 1401s, it was required to clean each drive at the beginning of every 8 hour shift (we ran 24x7) - heads, pinch rollers, and columns using IBM cleaner with non linting pads. So monthly at CHM doesn't sound often enough.

    Dirty tapes - we threw them away when several errors occurred in a run or debris was observed. Only premium tape was used. (what now?) I bought a commercial tape cleaner for CHM which I would guess is in Al Kossow's collection.

    Given the planned investigation of read signal integrity - re TAU Emulator Read signals - a subtle item is the read signal bus drive emitter follower transistors MPS404A must have a high Vebo, so if random PNP replacements were used, it might cause problems.

    One capability never implemented in the TAU Emulator analog section is the ability to generate read signals with pulse crowding, single & multiple pulse drop outs, and drop ins over 16 analog signal levels. It wasn't implemented since Bob ran out of MIPS and memory in the real time code. So AFAIK, the analog read & read after write error detection system in the 1401 TAU (which is pretty clever) has never been checked for proper operation. It is one reason IBM had such impressive data reliability with NRZ encoding and simple parity checking.



    1401 Restoration Status Report, Weds, 3/29/2023 - Robert Garner

    1401 Restoration Hours: 3/29/2023
    Clementson, David 6
    Garner, Robert 4
    Howard, John 4
    Kim, Mariane 6
    King, Frank 5
    Lion, Rob 6
    Paddock, Stan 5
    Shirriff, Ken 6
    Szolyga, Tom 6
    Verdiell, Marc 3

    Synopsis (details & photos below):

    • David replaced the defective power supply in the 729 Tape Emulator. Marc verified that it's working again by loading and running a test deck image (Lincoln). He also confirmed that it didn’t interfere with an actual 729 drive doing I/O.
    • David showed John how to re-ink a ribbon (using his re-inking machine, for keypunch #2).
    • Marianne manually re-inked a ribbon in a bath of oil-based ink (with gloves, photo below).
    • David, Rob, Marianne and Frank attended to an accidentally broken print plate adjustment screw in keypunch #3. It was moved to the workshop (photo below) while the spare keypunch in the Babbage closet was wheeled in its place in the Demo Lab (although it exhibited printing issues.)
    • Ken tested the two repaired DE TAU SMS cards and single 1403 SMS card in the CT system (as identified faulty three weeks ago by Ken and Marianne. (Marc had already replaced the defective/weak transistors, characterized earlier by Robert and then re-confirmed by Marc on transistor I-V curve tracers.)
    • Ken found that CT #2 and #4 had errors when writing. Frank cleaned the heads on CT 729#2 and Ken found that CT 729#4’s problems were associated with the tape itself. We should try to clean the heads and go through Iggy’s 729 preventive maintenance list once a month (copied below).
    • Tom received his serial port interface PCB and began stuffing/soldering its components (photo below).
    Detailed reports & photos:
    Tom and his serial-port interface PCB card:

    David, Marianne, Rob, and Frank attending to the 026’s broken print plate adjustment screw:

    Stan grooming some card decks. (Looking contented after concocting a cocktail out of the three bottled liquids!? :)

    From: David Clementson
    Subject: Restoration Report for Weds. 03/29/03
    • Replaced the defective PSU in the Tape Emulator and confirmed a correct -6VDC termination voltage rail. Subsequent testing proved successful. We were able to both load and run an emulated tape, and were able to load and run an actual tape with the Emulator connected to the daisy chain. Next week we will try putting the Emulator at the end of a 3-machine daisy chain, and will begin investigation into the signal integrity on the read data lines.
    • Showed John how to re-ink a keypunch ribbon, which he successfully did for the #2 keypunch machine. The print quality is great!
    • While working on adjusting the code plate for the #3 keypunch machine, the head of a plate adjustment screw was broken off. We moved the ailing machine into the workshop where we will attempt to extract the broken screw. Once removed, we will confirm its thread size and order material with which to fabricate a replacement. We also discovered that this is probably not the first time an adjustment screw was broken in this machine. Accordingly, we will probably have to fabricate two new screws.
    • I will work on making some fixtures to help with the broken screw extraction.
    That's it for this week. 6 hours.


    From: Mariane Kim
    Subject: Re: Restoration Report for Weds. 03/29/03

    On my side:

    I started the morning by helping Frank test a 25L6 for the 026 Keypunches.

    Here are the instructions Frank demonstrated to test the tube: (can be applied to new tubes, or to tubes already existing in the system that we suspect might need to be replaced)

    • In the 026 Keypunch, we unplugged vacuum tube #2 which is linked to the Release key:

      Frank recommended we use this position to test the tube because the signal will stay on the longest in this position.
    • Measure the voltage across the two leads shown in the picture below when pressing REL
    • If the voltage is around 90VDC, then the vacuum tube is good. If it's less than 60VDC, it needs to be replaced.
    • Frank also mentioned that using a lower voltage on the meter (ex. 5V) was a good way to detect any leakage in the tubes after keys were pressed.
    • @Frank King please feel free to edit or improve any of the above
    • I brought in two types of oil-based inks today.
    • Using this ink, I manually re-inked a new ribbon (using gloves!)
    • My hypothesis was that each 2cc tube of oil-based ink should be enough to reink a whole ribbon. Visually, it looked like this was the case, the ribbon seemed to be sufficiently moist after I was done with it. That being said...
    • Unfortunately, the ribbon I re-inked went into the 026 keypunch that was decommissioned per Dave's email above, so I don't think we'll have a chance to qualify whether this ink improved the performance of the ribbons.


    From: Ken Shirriff
    Subject: My CHM status Mar 29, 2023

    1. Repaired SMS cards. Marc and I replaced transistors on 3 bad SMS cards a couple of weeks ago. I tested the cards in the CT machine and verified that they were fixed. First, the JMVB inverter card that Mariane determined was preventing line feeds in the printer, position B1 E12. Second, two DHF flip flop cards from the CT TAU that were preventing the write clock from running, position XB B19. Robert had previously examined the cards with his curve tracer and found the suspect transistors. They were weak but not completely failed.

    2. CT tape drive testing/cleaning. I found that CT #2 and #4 had a lot of errors when writing. Measuring the preamp output voltages showed that CT #2 had some outputs at 4.8V and 5.6V instead of around 10. Frank cleaned the heads and that fixed CT #2. CT #4 continued to have problems so we swapped the tape and found that the problem moved with the tape.

      Apparently the "IBM H" tape (currently on CT #2, photo below) is flaky and should be replaced. Frank also put another reflector on the tape that is currently on CT #4 because it would often dump the tape when loading, even though it had a start-of-tape reflective indicator.

    Conclusions: the tape drives worked a lot better when Iggy was around, and we should probably clean the heads periodically.


    (Robert included this 729 Preventative Maintenance Checklist from Ignacio Menendez - Nov 2, 2022)
    Link to original

    Demo, 3/25, 1:00 PM - from Paul Laughton

    Yash Lala and I gave the demo to about 50 people. Yash did an excellent job as a new operator. Pat Buder, who did the 11:00 AM demo, stayed around to help out. His help was greatly appreciated. Pat stayed after Yash and I left doing what Pat loves to do: mini demos.

    We used CT which worked well except for some small issues with one Big Print deck. For the 083 demo, we used the new sort deck generated by Pat. I worked great.

    We had a male guest pass out. Yash and Pat came to his assistance while I continued with the demo. His family indicated that this was a known reaction to certain fumes. Fumes that were evidently present in the 1401 room. A wheel car was brought in. He was taken out into the hall and quickly recovered.


    Demo Status Report -- 3/22/2023 - from Pat Buder

    On Wednesday Scott Stauter and I gave the demo to 38 visitors. We ran on CT, which performed well. Our only problem was that the printing on keypunch #2 was extremely faint, so we didn't use it.

    Pre-demo Visitors

    The time before the demo was quite busy. Three large buses parked outside were an indication of the large groups of students inside. Mariane Kim and Frank King handled the early visitors. I helped when I arrived shortly before noon. Mariane and I estimate that there were 50 guests before lunch and another 50 after. Thanks to Mariane and Frank for taking time to do mini-demos.

    IBM 083 Sorter Demo Deck

    Over the past weeks the card deck we use during the sorter demo has been shrinking due to worn out cards, etc. We needed a new, larger one to properly show the 1,000 card / minute speed of the sorter. I searched and found the program that Ken Ross wrote to generate such decks. After some minor card reordering the program ran to make a new deck of about 200 cards. After the demo Mariane duplicated the program deck and labeled both program decks. They are in the trays in the lower shelf of the shopping cart. Sort on card columns 12 & 13 of the new deck for demos.


    1401 Restoration Report, Weds, 3/22/2023 - Robert Garner

    1401 Restoration Hours 3/22/2023
    Clementson, David 6
    Garner, Robert 4
    Howard, John 4
    Kim, Mariane 6
    King, Frank 5
    Lion, Rob 5
    Luo, May 5
    Paddock, Stan 5
    Szolyga, Tom 6
    Verdiell, Marc 6
    Synopsys (details & photos below):
    • We welcomed May Luo, our new restoration team volunteer! :)
    • David, Mariane, Rob, Frank, and John performed an in-depth assay of the keypunch ribbons & proposed a ribbon QA test.
    • David, Rob, and John debugged the 729 Emulator box, finding that one of its power supplies has failed. (photo below).
    • Rob replaced several burned out bulbs in DE 729 #2 and continued his deep dive into the 729s and emulator box.
    • Tom submitted his serial port interface PCB for fab.
    • John's relay tester now functions for a wire relay (at his home workshop, photo below).
    • Mariane and May attempted to run the RADIO music deck (that electromagnetically induces eerie sounds into a nearby FM radio).
    Detailed reports & photos:
    Here’s a photo of the 729 Emulator with the culprit failed power supply:

    A bird’s eye view of the entire 729 Emulator/TAU analyzer (as designed by Bob Feretich and Grant Saviers):

    The 729 Emulator deployed in the DE 729:

    From: David Clementson - Restoration Report for Weds. 03/22/03
    • We received a report that two of the three keypunch machines were printing very light in spite of having been re-inked last week. At first, this called into question the longevity of the re-inked ribbons, and whether the ink I used had dried out in the intervening week. However Frank later retracted the report having found that the ribbons were not advancing correctly in the keypunch machines. It is not clear if the keypunch machine print quality is actually okay, though. Anyone?
    • This uncertainty about the proper type of ink (water-base, petroleum based, etc.) led to a discussion about how we don't actually know the appropriate ink formulation for our application. So we decided to obtain and test several different ink candidates. Rob devised a clever test method where a type "hammer simulator" (a steel rod ground with a small radiused point at one end) is dropped from a controlled height onto a test ribbon that is backed by a piece of card stock. The rod's impact leaves an ink dot on the card that can be inspected for print quality. Starting with clean ribbon swatches, different inks can then be applied at varying concentrations and tested for print quality. Tests can be repeated over time to determine ink longevity. Stan got me a piece of ribbon stock which I will clean and use for testing next week.
    • Then Marc arrived, so we turned our attention to the tape Emulator. We were able to make some progress, most notably by stabilizing the setup configuration with respect to data density settings and software initialization. It was also noted that the "Start from Tape" command appears to be only supported by logical drive #1. We need to check the documentation to see if this is an original IBM design constraint or not.
    • We also noted that changing the data slicing threshold network (the little 16-pin DIP header inside the Emulator) had an effect on the Emulator's behavior. Moreover, the network was affecting the Select logic, even though the Select signal receivers use a fixed -6V slicing threshold. These slicing threshold networks should have no effect on the Select signals.
    • On further investigation, Rob and I found that the -12V DC power supply in the Emulator that feeds the -6V regulator is dead. Out of circuit on the bench, it has zero output. In the system, it caused the -6V rail to sit at about -2.8V, most likely a result of being back-driven by other circuitry. Without a proper -6V termination voltage rail, it is rather no wonder that the Emulator was having problems. I will see if I have a spare 12V PSU in my stash and will bring a suitable replacement next week.
    That's it for this week. 6 hours.


    From: Mariane Kim - Restoration Report for Weds. 03/22/03
    Adding May.

    Dave, I'll piggyback off of your email.

    > It is not clear if the keypunch machine print quality is actually okay, though. Anyone?

    • The keypunch farthest from the door: remains quite dark, even smudging the text as the card is fed through the machine.
    • Middle keypunch: Frank was testing the advancement and correct reversal of ribbon. The movement seemed correct (it advanced and reversed as expected). The ink seemed OK in the middle of the ribbon, but during the demonstrations we did for student groups, the ink was too faint.
    • Keypunch closest to the door: The print quality on this was the best of all the keypunches. I'm not sure what was done differently when reinking this ribbon. Any memories?
    I agree that experimenting with different inks and different "soak" times. Have we already decided on ink candidates to purchase? I had found an oil-based ink on Amazon, I can purchase it and bring it in next week.

    Last week, I had wanted to try the 1403 music decks. The first deck we found didn't work, so I printed the deck with the intention of reviewing it.

    This week, our musical guest was interested in learning more about the 1401 "radio" music. I found a deck called "RADIO", and tried to run it. It wouldn't load more than 3 cards on either CT or DE. May and I printed it with the intention of reviewing it, but didn't have a chance as more guests came in right before closing (who wanted Big Prints), and we didn't have a chance.

    I'd like to focus on getting some of these music decks up and running and duplicate these decks for preservation. :)


    From: Rob Lion - Re: Restoration Report for Weds. 03/22/03
    A couple of things I wanted to add to Dave's great writeup from my own (largely overlapping) efforts and observations:
    • I think that getting a decent handle on printer ribbon performance & quality metrics will be important to us developing a reliable supply chain for maintaining those ribbons of various sorts. My hope is, given that typewriter ribbons were an important commodity for more than a century, we can find some good reference documents to inspire our own practices and procedures, for example ASTM F396 or NBS Circular No. 186. I think dropping a hammer/mass from a consistent height onto the ribbon over paper is a good approach, though we should make sure to collect some "bad" examples from dry ribbons for comparison.
    • On the center 729 tape unit on the DE machine, talking with Frank King I noticed a circuit breaker tripped, which also led us to realize that the "fuse" warning light on the front panel was not working. I damaged a second bulb in the process of swapping them around to confirm that the bulb was burned out. I replaced both bulbs, labeled "55B1", with spares from a baggie in the workshop containing those mixed in with "55C1" bulbs.
    • I don't think I'd encountered that light bulb design from the 729 front panel before, but subsequent research indicates that it is a "Telephone Slide #1" standard base that's still at least somewhat in production, with the 55B1 bulbs being 55V/5.5W rated and the 55C1 bulbs being 55W/2.48W rated. The 1401 front panel uses similar Telephone Slide type bulbs as well, but with different size, voltage, and wattage ratings, as Marc cautioned me. We should probably check the documentation and compile what bulbs should go where!
    • The rightmost 729 tape unit on the DE machine is a model that has two bus connections, which nobody around seemed to recall. Probably not much real value for simple demo applications, but it seems that the second ("Right") bus could be connected to a different computer, selectable with a toggle switch next to the bus connectors.
    • As Dave noted, a power supply in the Emulator seems to have failed. Most of the power rails are supplied by an AT standard computer power supply, but the -6VDC rail was supplied by a Digital Power US100-201 (datasheet) 5VDC/12VDC supply teed off the AC power switch, with the isolated 12VDC output referenced to the ground bus of the main supply to produce a -12VDC level, then into a regulator to produce the required -6VDC voltage bus.
    • From last week, I found that in the workshop we have two tape bus terminator plugs that have difference circuits within -- one (with Marc's "handle broken label") contains contact pins and capacitors to couple for the shield reference levels, and the other contains only resistor networks for terminating the signal pins.

    From: Frank King - Restoration Report for Weds. 03/22/03

    Hi, I’m gonna try to answer the question about the keypunch ribbons as best I can.
    #1 keypunch (third from door); it has too much ink but prints fine;
    #2 it did not reverse and was printing OK after I manually reversed it. I reversed it manually several times and it seamed to work fine. I did not figure out why it did not reverse.
    #3 it also did not reverse but was outside the lever that causes it to reverse. When I pulled the ribbon back to thread it through the reversing lever, it broke in two, next to the reversing grommet. I tied the ribbon back together close to the grommet. I then ran it through several reversing cycles.
    The #2 and #3 keypunches should be checked to insure they are not at the end of a reversing cycle and are printing OK, next time someone is in. I plan to be there next Wednesday.


    From: David Clementson
    Thanks for the clarification Frank. We should be able to remove the excess ink from machine #1 by spooling the ribbon past a paper towel blotter. We can do this on my ink machine or directly in the keypunch machine.

    One good thing about this machine still being overly inked even after several weeks is that it provides some evidence that this ink isn’t prone to drying out prematurely. That fear is what prompted me to question the appropriate ink formulation. Although I do still support the concept of auditioning and testing a variety of different inks.


    From: David Clementson
    Thanks for the update Rob. BTW I did not find a suitable replacement power supply in my basement so I ordered one from Amazon. It should arrive tomorrow.

    GALYGG 12V 3A Power Supply, 36W LED Driver Universal Regulated Transformer Adapter AC 110V-220V to DC 12V Low Voltage Output for LED Light, Radio, Computer Project


    From: John Howard - Progress
    This Weds I was involved with the team on inking, tape emulator debug, and congratulated Tom on his serial interface card release. In my basement the relay tester (engineering model) now functions for the wire relay and runs with a single 110 volt input power supply.

    AND Robert,
    The relay tester is not quite ready for use by others. On the plus side at least its all on a single board now.
    I will chat with Stan; it was my impression that the need for testing wire relays was relatively low. My plan was to focus on a graphical user interface as the next step, but we could put it into a box soon, and do incremental user interface upgrades.

    Demo Saturday 3/18/2023 1:00 PM - from Jack Ghiselli

    Larry Hara and I gave the 1401 demo to 60 people, plus a mini-demo for 2 who wandered in later. We had international visitors from Brazil, Italy, and Japan. We ran the demo on CT, which generally worked well.

    CT1402: We did have two instances where the CT1402 would not read the first card of a deck (once BigPrint and once Powers-of-Two), although the 11:00 AM demo team said they had run fine. We cleaned up the edges of the first cards and then both decks loaded OK. While fixing the problem during the demo, we used our stock excuse, "Sixty year-old computers, like sixty year-old people, are often grumpy." Two of the older visitors later said that had made them laugh. This problem was probably just a slightly worn edge on the first card. In the future, we might use some Trojan Cards at the front to help avoid this problem.

    Tapes: When we arrived, CT 729 Tape Drives #1 and #3 (counting from the left) had been set to Not Operational since they wouldn't load. We discovered that both drives had take-up reels whose tapes had been threaded improperly. We corrected this and both drives worked fine for the TAU demo. We think this is a demo operator problem and NOT a hardware problem. After the demo, remembering Ron Williams, we fooled around with running the Tape Exerciser program, with the tapes in normal mode (not using the TAU). This program ran perfectly, on all four CT 729 Tape Drives. For comparison, some weeks back we'd tried it and it hung trying to write to the first tape. Thanks to the Restoration Team for getting the CT Tapes "WRITE" function working again. We're not sure if we'll use this in the future as part of the demo. It gives a more realistic sense of tape operations, but the TAU saves demo time.

    Sorter: Prior to the demo, we tested the 083 Card Sorter and it was working fine. However, during the demo when we pressed START, nothing happened. We tried various things. but could not get the Sorter to work, so we skipped it. After the demo, Larry tried powering down the Sorter for a few minutes, and powering it back on. Then, it ran perfectly. We have no explanation.

    Keypunches: All three 029 Keypunches worked perfectly, and their print tapes re-inked by the (awesome) Restoration Team last Wednesday were great! Visitors really like the easy-to-read print at the top of the cards. It's their name, after all.

    Pi Demo Decks: We had hoped to try running the two demo decks I created and left for last Wednesday's Pi-Day demo, but we couldn't find the decks or the Autocoder listings. We understand that Mariane improved the patches on the graphic-print deck, and we'd like to see. Are these tucked away somewhere?

    Audio/Visual: We are back to using rechargeable AA batteries in the mics. We left four AA batteries in the charger for the next demo.

    COVID Masks: We're ignoring masks, per Kate's most recent direction about this subject.

    Jack Ghiselli mobile 1-408-839-1051

    Maintenance - 1401 Restoration Report for Wednesday, March 15th 2023 - from Robert Garner and David Clementson

    1401 Restoration Hours 3/15/2023
    Clementson, David 6
    Garner, Robert 4
    Howard, John 3
    Jelsema, Dale 5
    Kim, Mariane 6
    Lion, Rob 6
    Paddock, Stan 6
    Szolyga, Tom 6
    Synopsys (details & photos below):
    There wasn’t much that needed to be debugged, fixed, or repaired this work session! :)
    • Rob, Dale, David, and Mariane began restoring/reinvigorating the 552 interpreter.
    • David re-inked the ribbons on the two keypunches near the door. All three are as good as new now. :)
    • Tom continued working on his serial port interface for the DE 1401. His PCB layout is (really) ready for fabrication.
    • John continued to develop a potential new relay tester.
    • Mariane tried running one of Ron Mak's 1403 music desks (Clair de Lune).
    • David cleaned up Robert’s Tek 7CTN1 curve tracer and recommended a general-purpose “component tester” for the workshop (below).

    Detailed reports & photos:

    Rob and Dale taking on the 522 interpreter:

    from David Clementson

    • Re-inked the dry ribbons on the two keypunch machines nearest the door.
      Print quality was greatly improved.
    • I noticed that several of the ribbons no longer have their brass reversing eyelets, probably because they have been cut. We should probably figure out a way to re-eyelet ribbons.
    • Cleaned the switches and potentiometers in Robert's 7CTN1 curve tracer. It now seems to work more reliably than before servicing.
    • Helped Mariane and Rob with the 552 Interpreter. Removed the ribbon and washed it in isopropanol. Once dry, it should be ready for manual re-inking next week.
    • Fabricated a new ribbon roller ring to replace the pink tie wrap found in the unit.
    • Ordered more ink, and lots of it.
    • Ordered a suitable silicon bridge rectifier (GBPC2506-BP) to replace the selenium rectifier in the 552. At 25 A @ 600 PIV, this device is way overkill for the task, but I chose it because its package will make for a clean retrofit.
    That's it for this week. 6 hours.



    Here’s a happy and contented Tektronix 7CTN1 transistor curve tracer after David’s cleaning maintenance, free of charge! :) We agreed that this was overkill for our workshop needs.

    Robert has ordered a model GM328A an inexpensive, all-purpose component tester. (“Diode gone wild” youtube channel)

    Demo - Request for Pi Day - requested March 13th, 2023 - Highlight e-mails only, there were 5 more
    From KateMcGregor - March 13,2023 2:17 PM
    Hello 1401 Team I’m emailing today with a special request!

    Back in 2015 when we had the big Pi Day celebration on 3.14.15 (such a good date!) the 1401 team wrote special programs calculating pi and gave handouts to the visitors. It was lots of fun!

    I’m writing to ask if we could revive those programs and celebrate Pi Day a day late this Wednesday please! Would you all be up for it?

    Based on my notes, in 2015 in addition to the normal programs, the team ran: prime numbers, Ed Thelen's Pi calculator and Ken Sherriff's Pi printer, and printed lots of those as souvenirs.

    If you have those pi programs, and are willing to have some fun with pi this Wednesday, please confirm with me today? Our marketing team would love to promote our 1401 pi activities if you can do it!

    It looks like our demo team this Wednesday 3/15 is Paul Laughton as Lead and Samuel Plainfield as Operator. Maybe Ed and Ken can coordinate with you so you can run pi programs?


    Please let me know that you’ll be able to run these on Wednesday so that we can promote on social media tomorrow

    Thanks all,


    Kate McGregor
    Director of Education

    from Ed Thelen - March 13, 2023 - 3:09 PM
    The source, assembly and object files of what I hope you are talking about are

    Pi to 500 places, prints while computing
    so audience doesn't get bored

    Ken's "Prints Pretty PI"

    These object file decks might be hard to find and/or corrupted.

    They could be regenerated again by using Stan's PC to keypunch system.

    Good Fortune
    -Ed Thelen

    from Jack Ghiselli - March 14, 2023 - 9:08 PM
    I came into the CHM this morning and set up IBM 1401 pi demo decks for tomorrow (3/15) as Kate requested. I ROPE assembled the programs from Ed Thelan’s source archive, as Ed recommended, and punched new object decks on CT using Stan Paddock’s Server system. Then I tested them on CT. There are two programs:
    1. The first program computes pi to 500 digits. Ed Thelen wrote this. It prints a line after each 25 digits so visitors can see the progress. Testing today, the CT 1401 takes about 9 seconds to compute 25 digits, or about 2 minutes total. Demonstrators might want to review Ed’s emails explaining his method of computation, so you can explain to visitors how our non-scientific 1401 works.

    2. The second program prints a large graphic character of pi, suitable for handing out to visitors. Ken Shirriff wrote this one. As written it halts dead-end after one QA print and you have to reload to print again. With apologies to Ken, I patched the program to allow you to simply press START to print again. You should press RESTORE on the printer to skip to a new page first. I didn’t have time for a better patch.
    The two decks are on the CT 1402, with sample Print-outs and Autocoder listings in case any of you hotshots want to modify them.

    Most important: I set the wall clock to Daylight Savings Time. Be on time I say.

    I will NOT be in tomorrow. You guys have fun. Sorry for this late report. I lost power at home and couldn’t email.

    —Jack Ghiselli
    Sent from my iPhone

    1401 Restoration Report for Wednesday, March 8th, 2023 - from Robert Garner
    1401 Restoration Hours: 3/8/2023
    Clementson, David 2
    Garner, Robert 4
    Howard, John 3
    King, Frank 4
    Lion, Rob 5
    Paddock, Stan 4
    Shirriff, Ken 4
    Szolyga, Tom 5
    Verdiell, Marc 3

    Synopsys (details & photos below):
    There wasn’t much that needed to be debugged, fixed, or repaired this work session! :)

    • Robert and David worked on getting I-V curve traces for the faulty (and hopefully good-to-go as replacement) transistors in the two faulty SMS cards identified during the last two sessions. David brought in his compact home-brew I-V curve tracer while both struggled to coerce the workshop’s Tek 7934 scope plus curve tracer module to work. Eventually it did and David also got his unit to work at his home shop. (The 4-GHz lab scope didn’t want to display a persistent X-Y plot from Dave’s unit.)
    • Marc and Rob Lion continued analyzing and searching for the fault in our 729/TAU emulator box that brings down a string of 729s.
    • Tom continued working on his serial port interface for the DE 1401. His PCB layout is ready for fabrication.
    • Ken gave John Howard a review of the 1403 printer, its control unit, and links to the key documents.

    Detailed reports & photos:


    From: Robert Garner
    Subject: Re: DHF card (was Re: status report Mar 1, 2023
    Date: March 7, 2023 at 8:53:00 AM PST
    To: Ken Shirriff


    I curve-traced the rest of the transistors on the DHF card.
    I now suspect that only T2 is bad.

    It soon dawned on me that all the transistors have sneak paths that can mess up an I-V trace. :)

    The three 102 transistors T3, T6, T7 — not including T2 — have similarly shaped (weird) I-V curves … (although perhaps T6 doesn’t quite fit in.)

    … unlike T2, which just looks like a resistor (perhaps due to an open base?):

    I suspect that the PNP 102 I-V curves are weird because the transistors are cross-coupled.

    Also, the curves for the NPN transistors are slanted because the pairs T1/T5 and T4/T8 have their collectors tied together and their emitters are tied together through 1K resistors:

    So while we may only need to replace T2, it would be good to re-evaluate T2 and T6 using David’s home-brew curve tracer! (My Tek 7CT1N curve-tracer module went on the fritz last night too. :((

    I’ll bring in the card tmrw (and the one that prevented the 1403 from paper advancing).


    — Robert

    From: David Clementson
    Subject: Re: Curve tracer coerced into workjng
    Date: March 8, 2023 at 5:34:35 PM PST
    To: Robert Garner

    I also was able to show that my curve tracer works. However I would bet the Tek will give more accurate results if it gets a little TLC. If you want I can go over it next week and clean up the switches and pots. I believe I have the service manual already.


    From: Robert Garner
    Subject: Curve tracer coerced into workjng
    Date: March 8, 2023 at 5:28:09 PM PST
    To: Ken Shirriff


    Several minutes after you left, with David’s persistent fiddling/coercing with shady push button switches on the 7CT1N module (in my 2nd Tek 7834 scope in the workshop), it seems to work now(!), this nice looking trace for an 083:

    I think you took the 3 faulty SMS cards?

    - Robert

    From: Ken Shirriff
    Subject: Re: Curve tracer coerced into workjng
    Date: March 9, 2023 at 9:59:04 AM PST
    To: Robert Garner

    I'm glad to here that the curve tracer works. I took the SMS cards and I'll try to fix them.


    Demo Saturday 3/11/2023 - from Paul Laughton and Jack Ghiselli,
    from Paul Laughton - 11:00 AM Demo
    Peter Chang and I gave the demo to about 20 people. We loaded Big Print into DE in case something went wrong on CT. The demo was given using CT. Nothing went wrong.
    The 083 worked nicely. We used the reinked KP #3.

    After the demo Peter was able to chat in Mandarin with a sizable number of Chinese guests.

    I turned the room over to Jack and Tim for their 1:00 PM


    from Jack Ghiselli - 1:00 PM Demo

    Tim Robinson and I gave the demo to 40 Visitors, plus mini-demos to 15 others who wandered in before or after. We had international visitors from Bolivia, Canada, China, Georgia (the country), Italy, and Ukraine. We ran on CT, which ran very well. KP#1 (farthest from the door) had the darkest printing ink, KP#3 (closest to the closet) was adequate, but KP#2 (in the middle) was so faint it was unreadable, so we avoided using it. The 083 Sorter worked well. We had DE powered-up in case CT developed problems, but never needed it. Hooray to the Restoration Team.

    Bad demo decks: Since last Wednesday, two of our three demo BigPrint decks have been marked "Bad". We examined them using VOBJ, and repaired them. One had a worn-out card, which we replaced. The other had three cards missing, which we replaced. We tested all three BigPrint decks, marked them as "Good", and put them back in the demo tray. We also ran Powers-of-Two during the demo, so that deck is also good. All ready for next Wednesday.

    Audio-Visual: When we arrived there were no batteries in the charger, but the 11:00 AM team had loaded newly-recharged batteries into the mics for their demo. So, we just left those batteries in, and they lasted fine through our 1:00 demo. After the demo, we unpacked four (4) of the brand-new rechargeable batteries (they're in the A/V closet drawer, in a white box labelled "Rechargeable AA Batteries), put them in the charger, and left the charger with two good red "charging" lights on. They should be ready for next Wednesday.

    COVID masks: Per CHM staff instructions, our hand-written "Please wear a mask during the 1401 demo" sign has been removed. Some visitors chose to mask and some chose not to. We didn't interfere, and left this issue up to CHM staff to handle.

    Jack Ghiselli mobile 1-408-839-1051

    from Pat Buder - IBM 1401 Demo Status - 3/8/2023
    On Wednesday, 3/8, Scott Stauter and I gave the demo to 30 people.
    Another 15 came by before or after. They were from Germany, Japan, and Vietnam. I had a long conversation with a professor from the University of Nebraska before the demo. Frank King was just leaving as we started, so I had the audience give him a hand on behalf of the restoration team.

    All keypunches and the sorter were workable. The two 026s furthest from the door had extremely faint printing. They need to get the newly re-inked ribbon treatment. The furthest 026 from the door still has the problem where cards sometimes do not feed down into the punch station correctly.


    Before the demo, Scott attempted to run on DE, but it would not load cards. I had him power it off.

    We ran on CT during the demo. BigPrint and Powers of 2 ran fine. After the demo we tried two of the three BigPrint decks and they both had problems. One stopped loading about 85% of the way through. The other printed a single line about 1/4 of the way down the page. It was the last line of BigPrint: "This printout was generated on an IBM 1401 ..."
    Then it would skip to the next page and repeat. I believe both of these problems were due to shuffling the decks during the demo. Jack had run his verification program on the decks on Sunday, so they were good then. Jack, please do your magic on the decks again for Saturday.

    With these failures, I took the remaining (third) BigPrint deck (the one with square corners) to DE, which I powered on. It ran fine there to process name cards from the visitors.

    We had not switched on the Liebert air conditioner, so that was a possible factor.


    When I came in, and the charge lights were off. I power cycled the charger. One light came on and it stayed on for over 1.5 hours, so those batteries were clearly not fully charged. We found batteries to use for the demo, and the sound system worked satisfactorily. Scott found that two of the rechargeable batteries had corrosion on the negative end, which kept them from charging. We took them to the front desk for proper disposal. We left the charger with two sets of batteries and both charging lights lit.

    As usual, thanks to the restoration team for all their fine work.


    Demo - March 4, 2023 - from Jack Ghiselli and Stephen Madsen
    from Jack Ghiselli - morning demo
    In the morning Larry Hara and I gave the IBM 1401 demo to 50 people, plus mini-demos to 5 who wandered in before or after. We had international visitors from Argentina and India. We ran on CT, which worked well during the demo. However, when running BigPrint for visitors after the demo, the CT1402 stopped reading cards. We tried non-process runout of both the Reader and Punch sides, running non-process runout for an extended time, and changing the first card of the load decks. Nothing worked, so Larry moved over to DE to run the BigPrints.
    Robert Garner commented "Did you try power cycling? :)
    (The 1402’s aged/corroded relays can become bamboozled and lock up.)

    A big thank-you to Mariane for inking the 026 Keypunch print ribbon on one of the units. The printout was very readable and much better than in the past.

    Jack Ghiselli mobile 1-408-839-1051

    from Stephen Madsen - 1:00 demo

    Larry Hara and I demonstrated to 65 visitors. We used CT. We had some problems with CT reading cards but managed to get it working right. We had no other equipment problems.

    Stephen H. Madsen

    Maintenance - March 1, 2023 - from Robert Garner, Ken Shirriff, David Clementson, Mariane Kim
    from Robert Garner - 1401 Restoration Hours: 3/1/2023
    Clementson, David 6
    Garner, Robert 4
    Kim, Mariane 6
    King, Frank 6
    Lion, Rob 4
    Paddock, Stan 6
    Shirriff, Ken 6
    Szolyga, Tom 5
    Verdiell, Marc 3
    Synopsys (details & photos below):
    • Frank, Mariane, and David examined the stalled ribbon in the CT 1403 and discovered that it was slipping due to a worn-out cardboard core. Replacing it with a new ribbon assembly fixed it.
    • David and Mariane worked on re-inking the ribbons in 026 keypunches #1 and #2. Unexpectedly, printing on 026 #1 came out quasi-illegible and blotted. After David added a foam spreader below the syringe tip in his re-inking machine, keypunch 026 #2 printed legibly and not overly dark. Success!
    • Ken Shirriff identified a faulty SMS card (DHF) in the DE TAU that prevents the writing of data to the tape drive(s). Substituting one from our spare card inventory didn’t fix the problem, but swapping it with another of the same type in a different bit position showed that the fault followed the card. We’ll need to repair it.
    • Marc continued analyzing and searching for the problem in our 729/TAU emulator box that brings down a string of 729s. (It was designed by Bob Feretich & Grant Saviers over then years ago and first used to bring up the DE TAU).
    • Tom continued working on his serial port interface for the DE 1401 .
    • Robert analyzed the faulty DHF card using his Tek I-V curve tracer, which shows that two (T1 & T6) of the smaller TO-18, IBM 102, high-speed “drift” transistors, prevalent in the TAU, have drifted off into a some crazy chaotic space.
    Detailed reports & photos:
    From: Ken Shirriff - Subject: status report Mar 1, 2023
    Summary: I found a bad SMS board in the CT TAU that prevented writes from working. I gave Robert the board so he can test the transistors and fix the board.

    A few weeks ago, I noticed that the CT TAU didn't show any data on the panel when writing to any of the tape drives. Probing the drives and the TAU led to the Write Clock 1 trigger, which was stuck. The write clock triggers form a binary counter to time various things during the write cycle. But bit 1 was stuck. This problem is obvious from the TAU panel if you know what to look for, which I didn't. Specifically, the write clock below is stuck at 1 rather than resetting to blank and then all flashing during operation.

    Here's the trigger in ALD B9.20.20.1. The DHF board is the trigger card.

    I swapped the DHF board with the neighboring DHF board, which moved the problem to write clock bit 4, confirming the problem is with the card. The spare cards in the filing cabinet looked dodgy. I tried one but it didn't fix the problem.

    The DHF board is pretty complicated with 8 transistors.

    The DHF board implements 2 flip flops. The idea is that H is the clock signal, and it is gated by C to set the flip flop. The clock is gated by G to reset the flip-flop. The asynchronous reset is A, connected to the reset switch on the TAU. Output Q is connected to G, so when the output is high, the next clock flips it low, so it toggles.

    As far as the bad transistor, my guess is that T2 is weak, so the flip-flop stays in the on state. Or maybe T6 is bad. Less likely, T1 or T5 could be the problem.

    I also helped Frank put a reflective sticker on the end of a tape reel after tape 1 ran off the end.


    From: David Clementson - Subject: 1401 Restoration Report, Weds, 3/1/2023

    • Worked with Frank and Marianne on the slipping ribbon issue on the CT 1403. After getting a very comprehensive introduction on the workings of the 1401 ribbon from Frank, we discovered that slippage may be happening at the interface between the ribbon's cardboard roller and the spindle that drives it. We replaced the ribbon and its cardboard rollers with a new one from the store room, and that seemed to fix the problem. Subsequent test prints looked good.
    • Re-inked a second 029 ribbon and tested it. The ribbon was apparently over-inked, resulting in a badly smudged print.
    • Reviewed the inker design with Rob to identify some potential improvements. We added an open-cell foam ink spreader to the syringe needle tip to change the ink flow from dropwise to continuous. We also dramatically reduced (~10X) the ink flow rate by reducing the syringe drive speed. The resulting ribbon appeared to be more uniformly inked, and without any obvious excess ink. I did not have time to test it on a 029, so I left it sitting on the drill press bench with a note reading "ready to install."
    • Sent copies of the Inker User Manual to Ed for publication on the Web site.
    That's it for this week.
    6 hours.


    From: Mariane Kim - Subject: Re: any 1401 restoration status for last Weds March 1st?

    Brief report this week. I worked with Frank, Dave, Rob and Stan on the following inky projects:
    • CT 1403 Ink roll not spinning - Replaced the ink roll with a new one from the back room. It turns out that the cardboard had worn on the roll that was previously being used, and the latches were not holding. Fixed.
    • Keypunch reinking:
      • 026 Keypunch farthest from the door was replaced with the one we "re-inked" last week (broken keypunch returned to workshop). However, we noticed the re-inked ribbon was very frayed and decided this posed a threat to the printhead, so we removed the ribbon and installed one that Dave re-inked on Wednesday. Turns out there was too much ink, and the printing was quasi-illegible. We're hoping it'll even out over time. While working on this machine, we noticed the latch that dictates ribbon turn direction was pretty gunked up. I'd like to clean it in the coming weeks. Probably needs attention.
      • Changed the ink ribbons on 026 Keypunch in the middle using one of Dave's new re-inked ribbons. This one seemed to have a more adequate amount of ink on it, and the printing worked rather well (legible, and not too dark). Fixed.
    - Mariane

    From: Robert Garner to Ken Shirriff
    Subject: Re: DHF card (was Re: status report Mar 1, 2023
    Date: March 2, 2023 at 6:50:36 PM PST

    Ken, The DHF entry in your amazing SMS card database does not have the component placement. :)
    (Carl/Marc’s scan is also higher res. :)

    So far, both T2 and T6 I-V curves are outlandish, crazy chaos!

    A “normal” germanium PNP (Russian made!):

    And a PNP IBM 033, slightly loopy:

    3/3 update: Here’s T1, a NPN 083, not exactly saturating, perhaps more applicable in a linear amplifier. :)

    The remaining traces tomorrow...

    — Robert

    Update - March 7th

    I curve-traced the rest of the transistors on the DHF card.
    I now suspect that only T2 is bad.

    It soon dawned on me that all the transistors have sneak paths that can mess up an I-V trace. :)

    The three 102 transistors T3, T6, T7 — not including T2 — have similarly shaped (weird) I-V curves … (although perhaps T6 doesn’t quite fit in.)

    … unlike T2, which just looks like a resistor (perhaps due to an open base?):

    I suspect that the PNP 102 I-V curves are weird because the transistors are cross-coupled.

    Also, the curves for the NPN transistors are slanted because the pairs T1/T5 and T4/T8 have their collectors tied together and their emitters are tied together through 1K resistors:

    So while we may only need to replace T2, it would be good to re-evaluate T2 and T6 using David’s home-brew curve tracer! (My Tek 7CT1N curve-tracer module went on the fritz last night too. :((

    I’ll bring in the card tmrw (and the one that prevented the 1403 from paper advancing).


    — Robert

    Ken Shirriff wrote on Mar 2, 2023 , at 6:22 PM,

    Hi Robert,

    > ... It's interesting that the card is so much more complex than the typical SMS card. You can conveniently find scans of any of our SMS cards at (substitute the desired card name).

    Yes, the "B19 bad" in pencil is my note, so I probably gave you the right card :-)


    Robert Garner wrote on Thursday, Mar 2, 2023 at 5:31 PM


    I found the component placement diagram for DHF in our Carl/Marc-scanned "1401 (SN 26721) SMS Cards 229-2038-1 Supplement” pdf
    (It didn’t want to download from Ed's/our 1401 web site, so I got it directly from Carl’s dropbox.)

    And following additional info:

    And a higher-res scan of the schematic diagram:

    Btw, there’s a hand-written note “B1 9 bad” on the DFH card you gave me. That must be it’s gate location. Is that your writing?

    Next, checkout T2, T6, T1, and T5.


    — Robert

    Demo - March 1, 2023 - from Pat Buder
    Sam Plainfield and I gave the demo to 30 guests.
    Another 10 stopped by before or after the demo.

    We ran mostly on CT. It performed well during the demo, including 1403 and tapes. The two 026 keypunches nearest the door, the 001 keypunch, and the 083 sorter worked well. The middle 026 apparently has one of the newly re-inked ribbons. The solid black is a welcome change from the former faint printing we have seen. However, there may be a little too much ink now as the characters are a bit blurred.

    The microphones worked satisfactorily. Jack had been in earlier and left a box of non-rechargeable batteries.

    Immediately after the demo we have to load BigPrint to accommodate the demo guests who want a BigPrint. Despite loading the same BigPrint deck and Powers of 2 successfully during the demo, CT wouldn't load BigPrint again (no cards read). We didn't think to power cycle CT. Instead we moved to DE where the same BigPrint deck loaded and ran fine.


    Demo - February 25, 2023 - from Stephen Madsen (11:00 AM) and Jack Ghiselli (1:00 PM)
    Demo - from Stephen Madsen (11:00 AM)

    Bill Worthington and I gave a demonstration to 40 visitors. We used DE for Big Print and CT for the magnetic tape demonstration. It was great to be able to run Big Print, because the visitors really enjoy it. The 1403 printer on CT has a printer problem. The ribbon stops, and the printing gets lighter and lighter. Regarding batteries for the microphones, when I left there were four batteries in the charger, and I verified that the red charging lights were on. There are only four rechargeable batteries. Didn't we used to have eight?

    For other problems, refer to Jack's email below.

    Stephen H. Madsen

    Demo - from Jack Ghiselli (1:00 PM)

    David Riazati and I gave the 1401 demo today at 1:00 to 38 people, plus mini-demos for 20 who wandered in afterwards. We had foreign visitors from Canada, Finland, The Philippines, and Russia. David did really well.

    Due to printer problems on CT, we used DE for running programs, and CT for demonstrating tapes, the same as Steve Madsen and Bill Worthington had done for the morning demo.

    In the morning, we found no AA batteries in the charger, so we loaded both mics with disposable batteries. We're running out of disposables, so I'll buy some more. We left four rechargeable batteries in the charger, with the lights on. We couldn't find a second set of 4 rechargeable batteries, which we need. I think we need to go through the closet drawer and organize batteries -- throw out bad ones and categorize good ones (we didn't do this today).

    We verified all four (4) of the Powers-of-Two decks in the card tray in the demo cart. They did not have any problems, but that's good to know.

    We cleared the feed card jam on 029 Keypunch #1 (farthest from the closet), but KP#1 is still unusable. It feeds a card, but when you Register, the mechanism fails to clamp the card. KP #2 and #3 are OK.

    We managed to drop and break our demo vacuum tube. After vacuuming up the broken glass, we replaced it with two (2) new vacuum tubes in the demo box.

    We added another vial of cores to replace the one we'd lost a few weeks ago, so we are back to three (3) vials in the demo box.

    We added another foil of the "card warehouse" to replace the one we'd lost a few weeks ago, so we're back to two (2) foils of this.

    The Amazing Frank King explained the problem with the CT1403:
         On Saturday, February 25, 2023 at 03:01:04 PM PST, Frank King wrote:
         I told Pat that the printer ribbon clutch was slipping. I Should have left a note on the printer.
         I’m sorry about that. You may use the CT machine for BIG PRINT however you MUST keep the ribbon moving; Either by helping it along or reversing the ribbon. I will try to get it working Wednesday.
         Sorry for the inconvenience,

    This is exactly the problem we observed and that Pat reported last Wednesday. During printing, the CT1403 printer ribbon advances for a while, but then stops rolling. The result is that printing starts out nice and black, but quickly becomes unreadably faint. As a temporary workaround, open the sheet metal ribbon cover, grasp the ribbon roll and manually help it roll. It then starts moving again again for a while. Keep doing this and you can get readable printing from the CT1403, but you'll pretty much need to stand next to it all the time to watch. Note: You'll get your fingers inky. So we added a bag of vinyl gloves (latex-free in case anybody is latex allergic) to the demo cart box. I recommend you use one glove on your left hand when grasping the CT1403 ribbon roll to help it along. This will save your fingers from getting ink-stained. Remember: Looking good is everything!

    The DE system ran well during the morning demo, and part way through the afternoon demo, but then the DE1402 began to get read checks, and appeared to load BigPrint incorrectly (the printouts were scrambled). The same BigPrint decks ran OK on CT, so we think this is a problem with the DE1402. This leaves us in kind of a quandary -- DE is the better choice immediately after systems are powered up, since the CT1403 ribbon needs manual help. But after a few hours of use, the DE1402 seems to get tired, and then CT is the better choice. Next Wednesday's demonstrators (Pat Buder & Sam Plainfield) can decide.

    By the way, Mike Albaugh stopped by. He's been away from CHM for a while having a life, but says he's back now.

    Jack Ghiselli mobile 1-408-839-1051

    Demo - February 22 + 24, 2023 - from Jack Ghiselli
    On Wednesday 2/22, Pat Buder and Scott Stauter reported they had an "eventful" demo. Having started with CT they discovered its newly fixed 1403 printer had another problem, so they switched to DE. In the busy demo, some demo decks got shuffled, and they didn't have time to fix them. I was concerned for the demos upcoming Saturday 2/25, so, I came in today, Friday 2/24. I didn't have much time, since I had to take my wife to the doctor, but here's what I found:

    1. As Pat reported, some BigPrint decks didn't work due to shuffled and/or missing cards. I repaired them, and there are now three (3) good BigPrint decks in the card tray in the demo cart.

    2. I didn't have time to look at the Powers-of-Two decks, so recommend you test them before using them in Saturday demos.

    3. As Pat reported, the CT1403 printer still has a problem with its inked ribbon advance mechanism. During printing, the ribbon advances for a while, but then stops. The result is that printing starts out nice and black, but quickly becomes unreadably faint. I found a temporary workaround: If you open the sheet metal cover, grasp the ribbon roll and manually help it roll, it starts again for a while. Keep doing this and you can get readable printing from CT 1403. Note: You'll get your fingers inky. We demonstrators are supposed to keep our hands clean, lest we be mistaken for Restoration folks, so you might want to grab some latex gloves.

    4. For the Saturday demos, it might be better to use DE, whose 1403 should be working OK. However, I used CT today, and didn't try DE. It'd be a good idea to test all of DE before Saturday's demo.

    5. Keypunch #1 (farthest from the closet) is jammed. #2 and #3 are OK. I didn't have time to try to clear the jam, but we might try before the Saturday demo.

    For reference, Saturday demo people are:
           11:00 AM -- Steve Madsen & Bill Worthington
           1:00 PM -- Jack Ghiselli and Dave Riazati

    Jack Ghiselli mobile 1-408-839-1051

    Maintenance - February 22, 2023 - from Robert Garner, Mariane Kim, David Clementson, John Howard, Tom Szolyga
    Synopsis, from Robert Garner


    Here’s the 1401 Restoration Report (a tad tardy) for Wednesday, Feb 22nd — a busy and productive work session!!

    Synopsis (details & photos below):

    • Frank King, Mariane Kim, David Clementson, John Howard, and Rob Lion worked on the CT 1403’s refusal to advance paper. Narrowing the problem to several potentially faulty SMS print control cards in the 1401, Mariane elected to replace one (which Ken had earlier identified as being of potential interest), the JMVC card of inverters at 01.B1.E12. That fixed the problem!
    • Robert Garner analyzed the faulty card using his Tektronix I-V curve tracer, which showed that one of the card’s transistors (T2) has a low current gain.
    • Regarding the punch stop fault indication on the DE 1402, Frank removed the punch die and John and Mariane replaced it, clearing the fault.
    • Dave and John discovered and replaced three damaged Control Tape brushes in the CT 1403.
    • David brought in his ingenious keypunch ribbon re-inking machine that he has designed, built, programmed and tested. It perfectly re-inked a dried out 026 ribbon. It comprises two reel stepper motors, a stepper-driven ink-filled syringe, and two LCDs that show the ink flow rate and ribbon speed, all controlled by an Espressif ESP32 SoC industrial controller.
    • Mariane installed the newly re-inked ribbon into the 026 temporarily in the workshop, printing uniformly dark without any blotting. (That 026 will be moved back into the Demo Lab next Weds, while 026 #1 will be returned to the Babbage closet).
    • Marc Verdiell and Tom Szolyga worked on revitalizing Grant Saviers & Bob Feretich’s 029 tape emulator. It currently brings down the string of tape drives on either the DE or CT system. Marc studied the emulator’s terminator circuits and schematics in the workshop.
    • Tom downloaded a copy of our 1401 web site to a USB thumb drive and gave it to CHM IT support specialist Ton Luong (as part of the project to move the web site to a CHM hosted server.) He also made progress on his serial interface for the DE 1401.
    Detailed reports & photos (followed by the attendance/hours-volunteered table):

    Maintenance - February 22, 2023 - from Mariane Kim
    Hello team,

    Today was quite a successful day! Aside from giving mini demos to probably 50+ museum visitors, here is a somewhat long email with some of today's events:

    1. DE 1402 not reading cards
      Short summary: Problem solved! Interlock issue.
      Longer version: This was the first thing we worked on when we came in. We noticed that the PUNCH CHECK light was on. Stan and Frank believed this to be due to an improper interlock connection on the punch side. We secured a few of the easier interlocks to access without success. Frank then removed the punch die from the machine, and John and I worked to reinsert it into the 1402. Once secured, the PUNCH CHECK light turned off, and we were successfully able to run a Big Print.

    2. CT 1403 not moving paper
      Short summary: Problem solved (we think...)! SMS card issue.
      Long version: Everyone contributed in some way to the resolution of this issue. This problem was also approached from multiple sides.

      The LS Start, LS Stop, and HS Stop lights were on when the system was turned on:

      We expected the LS Stop and HS Stop lights to be on, but it seemed odd that both the LS Start and the LS Stop were on simultaneously since the logic indicated that they were mutually exclusive.
      Similarly, we had high confidence that this was an electrical issue, not a mechanical one. had some documentation of the Low Speed Start & Low Speed Start Indicator signals, so we tried to trace it back from there. While we did probe a few of the signals, the majority of our breakthroughs came from investigating the SMS cards themselves.

      • Card 1F05 (in green above): As expected, when this card was pulled out, all indicator lights went out. Seemed innocent in the grand scheme of things.
      • Card 1F25 (in blue above): When this card was removed, we found that it was still possible to push on the solenoids to activate the carriage movement. This puzzled us. Perhaps a bad output from 1E14 or somewhere upstream?
      • Card 1E12 (in red above): This signal also showed up in ILD 117 which Ken had identified as being one of interest.
        • When we replaced this card with a spare....IT WORKED! The LS Start light turned off, and the printer moved paper when the carriage restore and space buttons were pressed. Pulses were seen/felt on the solenoids as well. Successfully ran a Big Print to validate.
        • The faulty SMS card was a JMVB. Marc, Robert and I tested all the transistors and diodes on the card, and didn't find anything obviously broken. I also tested the continuity of the traces to the goldfingers, and didn't find any open connections. Perhaps a failing solder joint somewhere? Robert is planning to take home the SMS card and test for any "wonkiness".

      It was also discovered that one of the brushes was in pretty bad shape, so the team worked to replace it. I wasn't a part of this effort, maybe someone else has better pictures/documentation.

    3. 026 key punch without ribbon
      While the 3rd 026 unit (farthest from the door) awaited a new ribbon, it was brought to the workshop and one from storage took its place in the demonstration room. In the workshop, Dave was able to re-ink an old ribbon using his new re-inking machine!! The installation of the ribbon was messy (I believe Marc took a video of my hands), but when we powered on and tested the printer, the punched/printed cards passed Stan's rigorous QA.

      The following is from the 1401 website:

      @Ed, any feedback about point 2 would be greatly appreciated. My hands are still inky after multiple scrubbing attempts.
      ( see Stan's note below :--)) )

    Thank you, team!


    from Stan Paddock


    When we buy ribbons for the 1403, the box comes with a light pair of plastic gloves.

    I will see if I can ( find ) a box of them.


    from David Clementson
    • Checked CT 1403 for error lights and found LS START and LS STOP were both lit, which is an error condition. The team later traced this to a faulty card in the CT 1401.
    • Discovered and replaced three damaged Control Tape brushes in the CT 1403. Thanks to Marc for pointing me to our rich stash of replacement brushes.
    • Fired up the inker for the first time and re-inked a few ribbons with good success. The need for a few modifications became clear:
      • add a ribbon rewind capability (the ribbons are not reversible as I had assumed)
      • make the syringe refill process easier,
      • add a mild friction brake to tension the supply spool
      • (eventually) upgrade the spool motor to one with a 32:1 gearbox instead of the 64:1 installed now. This will halve the re-ink time which is currently about 15 minutes.
    That's it for this week. 6 hours.


    The Espressif ESP32 SoC is a dual-core, 32b industrial controller w/integrated motor control, WiFi and Bluetooth, and a plethora of features:

    Dave authored ~1500 lines of code(!):

    from John Howard
       I worked on a card punch check condition, fixed by R & R punch die and the clearing the machine. Also worked on the 1403 printer problem, issues with 3 carriage control brushes which were damaged and replaced. We learned that both a high speed and low speed operation were started and never stopped, pointing to specific logic errors in the control unit. Frank manipulated the hi low selection mechanism with the printer and found that the printer could single step and feed paper.

    from Tom Szolyga
    HI Robert,

    Today I helped with setting up the Tape Emulator on the Connecticut machine. Mark was debugging. Apparently connecting the box to either machine’s tape drives makes the drives fail. It was hard to make progress with all the activity and all the visitors in the room. Mark decided to take the interface box into the workshop to debug it

    On the copy and move the restoration web site, Ed made a copy of the website and sent me the flash drives. I copied them onto a hard disc and prepared a copy for Ton. At the end of the day, I put the copy on his desk. If he believes the copy is good and usable, I will make a copy for long term preservation. Overall, we are making good progress on completing the first AR for the project.

    Last, I made progress on the PC board for the German project. I started the PCB device placement. It seemed there were too many devices for easy trace routing. I decided to convert some individual resistors into SIP arrays. I modified the schematic, updated the PCB with the part changes and continued the device placement process.

    Best regards,
    Tom Szolyga

    from Marc Verdiell
    That was an impressive fix on the 1403. I was equally impressed by Dave’s computer-controlled-everything precision re-inking machine. The ribbon printed perfectly, uniformly dark without any blotting. It made Mariane’s fingers perfectly black too, and I have clips of the inking machine and Mariane’s hands indeed. It may make the rounds as a short YouTube video when I finally get power restored at our house…

    With Tom, I hooked up the tape emulator on the CT tape chain, and observed the same behavior as last week on DE: the emulator screws up tape selection, both when off and on. At this point I suspect an issue with the emulator’s termination circuits, or more prosaically with the emulator cable to the tape, which had a suspect nick. I brought the emulator to the lab to study the termination and interface circuits (completed) and further debugging (to be continued next week).


    from Robert Garner
    Subject: Transistor I-V curves for the faulty JMVB SMS card (was Re: 2023_02_22 Restoration Report

    > Robert is planning to take home the SMS card and test for any "wonkiness”.

    Yesterday, I tested the JMVB card in my Tektronix 7834 storage scope w/7CT1N I-V curve tracer and 7M13 character generator plugins, photos below. No loopy wonkiness this time, just a weak transistor. The two diodes are fine.
    For an example of "loopy", click here

    The I-V traces plot collector current on the vertical vs. collector voltage on the horizontal, plotted as a function of base current, with 2 microamps per base step and 500-microamps per vertical division

    Eyeballing the traces, dividing the number of vertical divisions over the number of base steps, show that T1, T3, and T4 have nominal Beta values of ~125 (=(5.5*500)/(11*2uA)), while T2, which feeds into the CARR INK signal (which feeds into LOW SPEED START) has a low Beta of ~68 (= (3.0*500uA) / (11*2uA)). It interesting that the circuits are this sensitive. (I was unhappy to find that my transistor tester isn’t working, which directly reads Beta values.)

    Here are photos of the I-V curves for T1, T2, T4, and T5 on the defective JMVB card: (They show a little touch of looniness, but that may be due to the leads to the curve tracer.)

    The Tek scope test setup:


    — Robert

    1401 Restoration Hours: 2/22/2023
    Clementson, David 6
    Garner, Robert 4
    Howard, John 4
    Kim, Mariane 6
    King, Frank 6
    Lion, Rob 4
    Paddock, Stan 6
    Szolyga, Tom 5
    Verdiell, Marc 6

    Demo - February 18, 2023 11:00 AM and 1:00 PM
    Stephen Madsen, February 18, 2023 11:00 AM

    Duane Sand and I gave the demonstration to 20 visitors. There were hardware problems with both CT and DE. The CT printer is not working.
    DE will not read cards. Consequently, we were not able to run any programs. Stan Paddock was there, and he could not get DE to read any cards either. For the demonstration, we had a volunteer punch a card, ran the sorter, ran the tapes, and explained the other parts as best we could.
    Unfortunately, not being able to run Big Print is a major loss to the demonstration.

    Also, KP#3 (farthest from the closet) has no ribbon and could not be used.

    Stephen H. Madsen

    From Mariane Kim

    I'm surprised to read that DE 1402 wasn't reading cards, we successfully tested Big Print on DE (Wednesday?) just before the start of the (Wednesday?) demonstration. I believe we used the "Happy Visitor" punched card. DE 1402 read the cards, and DE 1403 printed.

    What was the observed behavior?


    from Stan Paddock

    My daughter and family were visiting from Denver and I was showing them around the CHM.
    While we were in the 1401 demo room, one of the 1401 demo docents came over and asked if I could get the German machine to read cards.
    After trying several thing, it turns the PUNCH error light stays on.
    With this light on, the 1402 will not operate.
    I did not have time to try and fix it.
    With the Connecticut printer being down, I had neither systems for the docents to use today.


    from Stephen Madsen

    When we pressed LOAD, no cards were read. The PUNCH error light was on.
    We tried clearing the PUNCH error light but were not successful.
    We tried non-process run out and power off/on, but these attempts were not successful.

    Stephen H. Madsen

    from David Clementson ( good to know, maybe even a fix )

    Re: DE 1403 not advancing its paper, did anyone happen to notice if its "SHIFT INLK" indicator lamp is lit? From what I can tell, if the 6/8 line clutch knob is not properly engaged and is left in one of its two "neutral" positions, the paper won't advance. The SHIFT INLK lamp exists to indicate this error state. I found this on Page 9 of the 1403 Component Description Manual:

    Also have a look at Service Hint #42 on Page 33 (PDF page 14) of the 1403 Service Index:

    Apparently the collars that set the 6/8 clutch detents are prone to loosening and misalignment and may be worthy of inspection. Also there is a cryptic reference saying "1401 EC SEM 314 provides larger collars containing two set screws." In IBM-speak, is an "EC SEM" some kind of upgrade or field modification notice?


    Paul Laughton, February 18, 2023 1:00 PM

    Katheen O'Biren and I gave the demo to about 50 people.

    As Steven reported in the 11:00 AM demo report, CT 1403 was not working. DE 1402 was not reading cards. CT 1403 could LOAD programs so Kathleen demonstrated doing a program LOAD and ran it up to the point where the 1403 was needed. The guests were understanding and most of them stayed for the full demo. After the demo we had guests punch souvenir cards.

    Note: There were no microphone batteries in the charger. I found the rechargeable batteries tossed into the AV console drawer. Fortunately, the batteries that were in the microphones had enough charge to last the demo.


    Demo- February 15, 2023 - 3:00 PM
    From Pat Buder

    On Wednesday, 2/15/2023 Scott Stauter and I gave the demo to an engaged group of 12 visitors. Another 11 came by before the demo. Here is the equipment status.

    Due to the CT 1403 still being down, we ran programs on DE and showed the tapes on CT. They both ran fine. The programs we ran were:
         - BigPrint during demo
         - Powers of 2 during demo
         - BigPrint immediately after the demo for guest name cards

    At one point shortly before demo time DE wouldn't read cards. However, Mariane, Frank, and others did their magic and it worked fine for the demo.

    The keypunch furthest from the door was down. Stan had been working on a ribbon for it, but the ribbon was not usable.

    The headsets worked pretty well. When I was in the lab on 2/14 doing some new 1401 Operator training, I placed a set of rechargeable batteries in the charger and unplugged/replugged the charger at the charger, not the wall. Both lights came on solid red, to indicate charging. I left things that way. On 2/15 before the demo, the lights were off. I unplugged/replugged the charger and both lights came on solid red. I expected that to last only a short while, given that the batteries should have been fully charged from the day before. However, the charging continued. I didn't note if the lights ever went out. It was near demo time so we used the alkaline batteries that were already in the headsets. It seems like relying on the batteries to be fully charged is still problematic.


    Maintenance - February 15, 2023 - from Robert Garner, with Mariane Kim, Marc Verdiell, John Howard, and David Bennet
    Upated as per Feb 18, 5:29 PM
    Synopsys: Frank, Marianne, Ken, and Rob Lion worked on the CT 1403 that belligerently refuses to advance the paper and gleefully overprints on a single line. During bug shooting, it even frustratingly exhibited a hardware Heisenbug. Marc, at Tom’s request, attempted to get the 729 Tape Emulator/Analyzer up and running on the DE 1401, trying out several 729 cable terminators. John Howard continued his design of a new, more sensitive relay tester. (He located a 1957 IBM JR&D article "Development of the Permissive-Make Relay” that I procured.) Dave Bennet graciously procured 200 new 729 carbon clutch brushes for our future maintenance needs. Stan Paddock tried installing the silk 026 replacement ribbons that Mariane graciously procured, but right out of the box, it was apparent that each was defective in some way.

    Here are the detailed reports for this week, followed by the attendance/hours-volunteered table.

    From: Mariane Kim
    Subject: Re: 1401 restoration status for last Weds
    Unfortunately, I don't have a big update for this week, but here is a summary of what we worked on.

    On Wednesday, Feb 15th, Frank, Rob, Ken and I attempted to retrace the problem with CT 1403 which was not moving paper (no space or carriage return).

    We had previously had similar symptoms with this printer due to a blown fuse. However, Frank confirmed that all fuses were still intact, so we turned our attention to the logic that passes through the 1401.

    This logic was documented in ALD 36. Our initial goal was to trace the faulty signal back on CT. However, we decided this might result in some red herrings, so we decided to try comparing singles between CT and DE. We hit a few bumps in the road with the oscilloscopes. It would make it much easier to use the digital oscilloscope since we could leverage the memory and display multiple channels simultaneously. That being said, the oscilloscopes didn't always seem reliable (variances b/t digital and analog oscilloscope results). We also noticed that when we used a specific probe on DE, the printer began running away. The first time this happened, we blew a fuse... Blown fuses have since been replaced. This phenomenon to be investigated further next week.


    • CT 1403: Not much progress made. Next week, I suggest we systematically and consistently measure signals on DE 1403 for comparison to CT 1403.
    • DE 1403: Accidentally blew a fuse causing a runaway (note that symptoms mimicked the symptoms seen on broken CT 1403). But we replaced the fuse, and DE 1403 worked as expected.

    From: Marc Verdiell
    Subject: RE: 1401 restoration status for last Weds

    Worked on connecting the tape emulator with Tom to the DE 1401. When connected it would hang the tape bus on the DE machine. It prevented to select any tape. Suspect a termination problem. We tried the two termination adjustments inside the emulator (DE and CT) both had worked for be before. We tried to shorten up the tape chain – no joy. We’ll try it on the CT next week, but the tape emulator hardware might need some TLC. I had similar issues before which were traced to wires gone bad in the emulator.

    From John Howard

    Subject: Activity report
    Date: February 15, 2023

    This week I continued the design of a new relay tester.


    Subject: relay research - Journal article
    Date: February 18, 2023

    Robert, The journal article (See synopsys above) was very interesting, a nice job of describing relay bounce, the math behind it, and approach to the new structure which minimizes the moving mass and static forces. Not as much info regarding failure modes or contact characteristics as I had hoped, but that data probably did not exist at the time.

    We have another interesting data point in the “IBM 454198 Wire Contact Relay Tester”, used by customer engineers. This is a device with a series of switches and lights that could test each contact, giving an indicator light indication of conduction. Our tester does much the same thing using an A to D converter and Arduino to execute each step.


    Subject: 729 tape drive brushes.


    Today I received a small box containing 200 pieces, 729 carbon clutch brushes from Helwig Carbon Products. I will be at CHM tomorrow for the RAMAC demo and I will bring them along with me. I'll be there from about 12 noon until shortly after 2 PM. Will one of the 1401 team be there at that time to pick them up or should I leave them with Jesse, or what do you suggest?

    I also have a paid invoice in the amount of $1387.16 which I have covered with a credit card. This covers the parts, taxes and shipping. I expect that it will be on a bill which I have yet to receive which will probably not be due until March 16th, just to point out that there is no urgency.

    For your interest I have been in touch with the folks at Binghamton, and it seems that they are just bringing up their first 729 so they are not yet thinking about spare parts or potential usage. I have given them info on how to order brushes when they are ready to do so, and also have offered to order them if they wish.

    I will also attempt to file the info in a place that I can remember if this subject ever comes up again.


    1401 Restoration Hours: 2/15/2023

    Garner, Robert 2
    Howard, John 4
    Kim, Mariane 4
    King, Frank 4
    Lion, Rob 4
    Paddock, Stan 4
    Shirriff, Ken 2
    Szolyga, Tom 4
    Verdiell, Marc 4

    Maintenance - February 8, 2023 - from Stan Paddock
    People who attended the CHM were:
    Robert Garner 1.5
    Frank King 6.0
    Stan Paddock 6.0
    Marc Verdiell 6.0

    In any group of people, there are those who "Did not get the Memo". (About the museum being rented out for the day.)
    The people indicated above are a part of that group.

    Since we were there anyway we decided we decided to see if we could fix the Connecticut IBM 1403 printer.
    The printer will print but will not move the paper

    Pressing the carriage restore button on the printer or the single space button on the printer caused nothing caused nothing to happen.
    If we had the computer to print 132 characters of 2's, the printer printed the line of 2's but did not move the paper.

    I know this type of problem is the type Ken Shirriff likes to solve.


    Demo - from Steven Madsen, - February 4, 2023 - 11 AM
    There was no operator, so I did the demo alone. I used CT, and was not able to make the printer work, so I could run any programs.
    There was not enough time to switch to DE. There were 30 visitors.

    Stephen H. Madsen
    Demo - from Paul Laughton, - February 4, 2023 - 3 PM
    The demo was given by Paul Laughton and Kathleen O'Brien with Duan Sand as a backup.

    There were about 20 guests mostly from the Bay Area.

    The three 029s and the 083 worked perfectly.

    The CT 1403 was not working so we used CT for the Tape demo only.

    We did the printing from DE. Our first attempts at loading programs failed with reader check errors on the first card. After we recycled the power it loaded programs properly.

    The audio system was working reasonably well.

    Demo - from Pat Buder, - February 1, 2023
    On Wednesday, 2/1/2023, Larry Hara and I prepared to give the 1401 demo.
    We planned to use the CT machine. Larry set up to room and ran BigPrint to verify its operation. Tapes could be run from the TAU. Stan and others informed us that the CT tape drives could not write to tape. As long as the tapes move, that's sufficient for the demo.

    The Restoration team was largely back in their lair and not in the demo lab. While we were waiting for demo to begin Larry and I discussed tape capacity and blocking and other topics. During the demo there is only time to mention the nominal capacity of a reel of tape (12 MB is what we use) but not blocking or other efficiency issues.

    I had a nice discussion with Stan about several projects. One topic was the IBM 077 Collator and IBM 513 Reproducing Punch swap for an IBM 557 Interpreter. I said that most demonstrators do not even mention the 077 & 553 in their demos. I do but only spend less than a minute doing so. Swapping them for an IBM 557 will have no effect on demos.

    When the power failed shortly after 2:00 pm, we immediately began turning off circuit breakers and power switches on all equipment in the lab. Once it became clear that the power was not likely to return, we finished shutting down the room. It was only the second time that I remember having to cancel a 1401 demo. The other time was also due to power failure. That time the museum was full of student groups. When it became obvious there would not be a 1401 demo in the dark, the CHM staff drafted Bill Worthington and me into conducting Revolution tours with flashlights.

    The docent die-hard award of the day on 2/1/2023 goes to Dave Hoyt. He conducted the remainder of his power-interrupted Revolution tour in the lobby. Way to soldier on, Dave.

    Maintenance - February 1, 2023 - from Robert Garner, Ken Shirriff, David Clementson, Tom Szolyga, Stan Paddock
    from Robert Garner

    Here’s the 1401 restoration report for Wednesday, Feb 1st.

    Synopsys: The power went out at ~2:10pm! This may be only 2nd time in 10 years (since the remodeled Demo Lab opened in Nov, 2013) that we weren’t able to demo the 1401. (The 1st time also due to a power outage).

    Now that DE 729 #1 is “nominal" again, DE 729 #2 and #3 decided to act up, as did the CT 729 read/write circuit paths (possibly due to a faulty TAU?), this in spite of cleaning and lubricating the capstan bearings in all seven 729s. (No good deed goes unpunished. :) We also began to think about an enhanced relay tester, an 026 ribbon re-inking apparatus, getting familiar with the TAU emulator again (in order to run the 1401 Autocoder, COBOL, and FORTRAN tape images), moving the 077 Collator and 513 Reproducer to warehouse storage and initiating restoration of the 557 Interpreter.

    Here are the detailed reports for this week, followed by the attendance/hours-volunteered table.

    From Ken Shirriff

    Summary: lots of tape drive problems. Restoration ended abruptly when the power went out and we were plunged into darkness.

    DE#2: The drive select wheel switch had problems causing it to be always selected.
    DE#3: It had some problems loading and unloading because the left capstan was sticking.
    David and crew fixed these, so he can give details.

    The CT drives are messed up for writes (and maybe reads). They spin when doing writes, but show nothing on the TAU's bit display. Frank and I looked at the signals from the tape amplifies and there was nothing.

    Since this happens with all the CT drives, it's probably a TAU problem, unless it's a very strange wiring / termination problem. Frank, David, and I did some investigation. It's probably a bad write signal from the TAU causing everything to get gated off. Our investigation came to a sudden end when the power went off. None of the emergency lighting works in the demo room or the workshop, which is a bad situation. (I informed Kate.) We were able to get things cleaned up and turned off and we exited by cell-phone flashlights.


    From David Clementson

    Adding on to Ken's report:
    • I cleaned and lubricated all of the capstan bearings in all seven tape machines. It turns out that these bearings have little oil cups that all needed filling. John and I focused on DE#3 that had a particularly sticky left bearing. Inspection of the shaft revealed what looked like a tiny ding that I was able to polish out with 2500 grit emery followed by careful cleaning and lubrication. The sticking seems to be fixed, but is something to continue to watch out for.
    • The drive select switch on DE#2 was really dirty with lint and would cause the unit to select regardless of the switch setting. It also would select and deselect as the switch was wiggled. A generous squirt with compressed "air" followed by Deoxit fixed it. We should probably clean and condition the switches in all of the units.
    • DE#2 appeared dead until we found it had one of its circuit breakers (CP4) tripped. It must have tripped last week. Resetting it restored the unit to operation.
    • 100 replacement neon bulbs arrived from Amazon and checked out okay for size and color. So we have lots of spares, and they are easy to replace. A background task would be to replace all of the neon bulbs. starting with the obviously dead ones.
    • John and I were able to brainstorm about relay testing, and we had a very enjoyable and fruitful session. Some concepts we may explore are:
      • A next-generation tester with onboard LCD & touchscreen (?) to support the UI and eliminate the companion PC, a simplified power supply infrastructure, and more advanced testing capability.
      • Testing all of the relay's contacts in one measurement by connecting them all in series. This will not tell us which contact is bad, nor would we be able to reliably detect a stuck-closed contact. But for a pass/fail test we may not actually care which contact is faulty, and if stuck-closed failures are rare (are they?), this technique may result in a superior testing algorithm. It also will effectively increase the contact resistance measurement resolution by 4-6X, since that many contacts would be in series where their resistances add up.
      • Margining the coil voltage (which is related to the pull-in force) to detect spring issues. We would drive the coil with a slowly increasing voltage and measure the point where the contacts first close. This would give a numeric figure of merit instead of just a go/no-go indication.
      • Using an analog peak-detecting ohmmeter to try to infer the contact closure resistance waveform without needing a fast ADC. This would probably be good for individual contact testing, but not so good for the all-at-once series connected topology, since only the last contact to close would be measured.
      • Using two series current source resistors (one to Vcc and one to ground) to move the resistance measurement test voltage away from ground. This is essentially putting the relay connected contacts in one arm of a Wheatstone bridge. The Arduino's ADC almost certainly has poorer performance at its voltage extremes, so putting the measurement mid-scale would be preferred. We could also detect negative contact resistance, which would be useful for the perpetual motion project.
      • Adding an external opamp to boost the contact voltage drop measurement resolution. The existing tester has a resistance resolution of about 35 milliohms per LSB, which seems a tad high if we are looking for a "leading indicator" of imminent contact failure.
    • I discussed ribbon inking with Stan. I will probably throw together a simple fixture to do some experiments to try to determine just how much ink a ribbon needs, and how fast and evenly it can be applied. So I borrowed a sample spool to make a 3D model of:


    From Tom Szolyga

    Hi Robert,

    Before the power went off I made some progress on the tape emulator system. First I learned what TAU stands for and how to use the 1401 TAU to control the tape drives. Next I learned how to power up the emulator system, which app to run, and how the app works. Powering up was a project because there were 3 plug strips, daisy chained around the Connecticut machine’s memory going to a plug box under the floor attached to a breaker that was turned off. I learned how to connect it to the tape drives and which connectors to use. This was new knowledge—no one knew the answer. Unfortunately, the capstan on the third German machine tape drive started to stick. The drive started working again just before the power failed so I was not able to transfer data.

    The app can emulate any one of 6 drives. On anyone of these drives one can mount a “blank tape”, a “library tape” or a PC file and transfer data to or from the 1401. The tape library is collection of tape images transferred and stored in the box. They have names and can kept in sub-directories. The library already has tapes in it. For example, a copy of the AUTOCODER tape is in the library. To run AUTOCOER, one could configure the emulator to be drive 5 and mount the library tape for AUTOCODER. Then with a blank tape on drive 1, the 1401 could do a tape to tape copy from drive 5 to drive 1. This would produce the runnable tape of AUTOCODER. Alternatively, one could have the 1401 boot from drive 5 directly and run that copy. I think we could add the COBOL and FORTRAN tape images to the library easily.

    Stan said, “Good work! You’re going to document all this, right?” I replied, “In the restoration team, documenting the process would be ludicrous.” Next week I plan to try transferring data and writing some documentation.

    Best regards,
    P.S. One of the power strips has a plug with the insulation coming off. This is clearly a safety issue. I took it out of service and put it next to the door to throw away. After lunch, it was gone. “Someone” said they needed a power strip and were delighted to find one. Bottom line: The team needs to remember Safety First.

    From Stan Paddock
    Requesting movement to Warehouse

    We have an IBM 077 collator and an IBM 513 reproducing punch in the 1401 demonstration room.
    Neither machine has been turned on for the last two years and I don't know if either is able to work.
    Neither machine has a full set of covers.

    We have received a IBM 557 Interpreter with a full set of covers.
    Since the 1401 cannot print on the cards it punches, many sites had an IBM 557 to perform this task.

    I would like to suggest moving the IBM 077 collator and an IBM 513 reproducing punch to the 1401 area in the warehouse and move the IBM 557 from the CHM workshop to the 1401 demonstration room.

    We had an IBM 029 Keypunch open in the 1401 demonstration room.
    One Wednesday we came to find somebody had pounded on the IBM 029 keyboard and rendered the keypunch out of service.
    Marc Verdiell spent several weeks repairing the keypunch.
    The IBM 029 is in the Babbage closet now and an IBM 026 is in the 1401 demonstration room. (Wrapped To protect it from damage)

    Aurora was going to rent a truck to move items to shuffle other items between Milpitas and Mountain View.
    I was hoping that truck could be used could also be used to also move the three items listed above.


    1401 Restoration Hours: 2/1/2023

    Clementson, David 4
    Garner, Robert 0.3
    Howard, John 4
    Jelsema, Dale 0
    Kim, Mariane 0
    King, Frank 4
    Menendez, Iggy 0
    Paddock, Stan 4
    Shirriff, Ken 4
    Szolyga, Tom 4
    Thelen, Ed 0
    Verdiell, Marc 0

    Maintenance - January 25, 2023 - from Robert Garner, David Clementson & Ken Shirriff
    from Robert Garner

    Here’s the 1401 restoration report for Wednesday, Jan 25th.

    Focus this week was on DE 729#1’s faulty neon bulbs; DE 729#2’s refusal to load; and fixing DE 729#3 refusal to load/unload caused by deteriorated oil on its right-side capstan. The CT 1401 utterly behaved itself.

    Len Shustek dropped by to borrow some pre-1950, unit-record items for the Stanford Continuing Studies “The History of Computers” class that he’s teaching: 
    The Youtube sessions are being broadcast from the CHM (mostly in Lovelace, but sometimes in the lobby theater) on Monday evenings 6-8 pm. He graciously invited us to just show up to watch/participate in person if we’d like.
    (Len borrowed Franks’ Type 001 hand keypunch normally attached to the railing, 1402 card brush read assembly, two small control panels/plugboards, contact relay, 405 electromechanical decade counter, and a couple of reference punched cards.)

    Here are the detailed reports for this week, followed by the attendance/hours-volunteered table.

    From: David Clementson Subject: Restoration status report 2023/01/25

    • I started the day with the intention to replace the "failed" +62V PSU diode in the DE#1 729 tape machine with a modern 1N4004. I figured that if that fixes the issue, we can then discuss what kind of diode we want in the unit long-term. I took a soldering station from the workshop over to the unit, but found that the AC power was off for the unit and the courtesy outlet was not live. No problem, probably safer to work that way. I found an extension cord and began the search for a working AC outlet. It turns out the room doesn't actually have any, so I had to use the orange extension cord emerging from the floor beneath the sorter. I used an outlet tester and checked that it was live and wired properly. More on that tester later...
    • Replacing the diode had no effect on the problem. Ken and I proceeded to look at the rail waveform on the scope and found an interesting thing: the rail is not actually DC, but AC. No wonder the DVM recorded only a few volts DC. We compared the waveform with the +62V rail on the CT#1 machine. It had a half-wave rectified waveform. After deep diving into the schematics, we found that the DE machine does not actually have any path from the diode's cathode to ground. In contrast, the CT machine's cathode has a ~6k resistor to ground. So on the DE machine, when the transformer voltage reverse biases the diode, the cathode is free to float below ground; there is nothing to hold it at ground potential. Adding an external 6k2 load resistor to the DE machine resulted in the same half-wave rectified waveform.
    • So the conclusion Ken and I arrived at is that this is how IBM intended the system to work, since there is no harm to having the +63V rail go below ground. However it is a little weird, which is maybe why the load resistor was added on later models. Just because the documentation calls the rail "+62V," don't assume it will actually measure 62 VDC.
    • So I think it is safe to emerge from the +62V rabbit hole and get back to confirming the neon indicators.
    • I selected a random neon bulb from the indicator array and attempted to remove it to see what the replacement effort might be like. No problem: just pull the two pins from the back of the socket and bush the bulb out the front. Reassembly is just as easy. So I will buy a bag of neon bulbs from Digikey and replace any that are dodgy or outright broken.
    • While I had the bulb out, I thought I should try to test it by measuring its turn-on threshold. I went back to the workshop in search of a Variac or a DC supply that could produce a variable voltage in the ~80V range to "margin" the bulb candidates. The Variac looked pretty sketch and didn't have cabling that would be friendly for connecting bulbs to, but there was an HP 6299A that should do just the trick. I fired it up to find that the meter switch was clearly flaky. So I wasn't able to tell if the supply itself was working.
    • Meanwhile, Frank grabbed the Variac and attempted to test the neon bulb, although without any ballast resistor. About 10mm of the bulb's connection wire was vaporized, which is a much better outcome than Frank being vaporized.
    • I was able to partially disassemble the 6399A enough to access the back of the meter switch, which I doused with Deoxit. Meter fixed! After reassembling the 6399A and adding the requisite ballast resistor, I was able to check one of the spare neon bulbs I brought from home. I was able to show that 82 volts is a typical turn-on voltage for the bulbs I had. I checked a few more bulbs, and found pretty consistent results. So I reinstalled a known-good bulb into the 729.
    • I then reinstalled the original diode into the 729, so it remains period-correct. And I made sure to use period-correct Sn60/Pb40 solder with period-correct Kester 44 flux.
    • As mentioned before, I had my AC outlet tester handy, so I checked the 729's courtesy outlet and found that it does not conform to NEC standards. Neither did the CT machine. Ken did a deep dive into the schematics and discovered that the courtesy outlet voltages are actually generated by isolated windings from the main power transformers in the 1402s. But they are not truly floating, since the receptacles' ground sockets are indeed grounded. So even though they don't conform to the electrical code (neutral is not bonded to ground), the courtesy outlets seem fine to use.
    • Ken was working with DE#3 729 which was refusing to load/unload. He noticed that the right capstan was not retracting properly. We checked the shaft and found that the oil for the bronze bushing had dried to a VERY sticky honey-like substance. We were able to clean the shaft with isopropanol and re-lubricate with oil from the IBM repair kit. That fixed the load/unload problem nicely. So we should probably do this cleaning/oiling maintenance on all of the capstan bearings. I do not know exactly what oil IBM recommends for this application, but I imagine a high quality light spindle oil would be appropriate. I will bring in some Mobil DTE Light, which I use for my lathe headstock.
    • AC outlet tester:
    • HP 6299A repair:
    • Neon bulb under test:

    From: Ken Shirriff Subject: Re: Restoration status report 2023/01/25

    One other problem: DE drive #2 is refusing to load although it was working last week.
    I'd blame the relays like DE #1 except DE #2 has the NOR (SMS) logic.


    1401 Restoration Hours: 1/25/2023

    Clementson, Dave 5
    Garner, Robert 4
    Howard, John 4
    Jelsema, Dale 0
    Kim, Mariane 5
    King, Frank 4
    Menendez, Iggy 0
    Paddock, Stan 4
    Shirriff, Ken 4
    Szolyga, Tom 6
    Thelen, Ed 0
    Verdiell, Marc 0

    Demo - from Stephen Madsen, - January 21, 2023
    I was lead for the 11:00 am demo and Peter Chang was the Operator. Karen Sun and Jack Ghiselli were also there as helpers/observers. We had 32 visitors for the demonstration; two were from England.
    We used CT, and all equipment worked fine. My thanks to the restoration team for fixing the 1402 card reader.

    Stephen H. Madsen

    Maintenance - January 18, 2023 - from Robert Garner, Ken Shirriff, David Clementson, & Mariane Kim
    from Robert Garner

    Here’s the 1401 restoration status for Wednesday, Jan 18th.

    This week the focus was on testing the incalcitrant relays in the CT 1402 and on diagnosing non-functioning neon indicators in the DE 729 #1 tape drive and the DE 1401 TAU panel (the former due to a bad power supply and the latter due to a failed transistor). Here are the detailed reports, followed by the attendance/hours-volunteered table. (A welcome surprise: Ed Thelen made it in!):

     1401 Restoration Hours: 1/18/2023

    Clementson, Dave 5
    Garner, Robert 3
    Howard, John 0
    Jelsema, Dale 4
    Kim, Mariane 6
    King, Frank 6
    Menendez, Iggy 0
    Paddock, Stan 6
    Shirriff, Ken 5
    Szolyga, Tom 0
    Thelen, Ed 4
    Verdiell, Marc 0

    from Ken Shirriff
    I finally tracked down the problem with the B reg A-bit light not working on the German TAU. As you can see below, the A light is not lighting up, but it's not a problem with the bulb.

    The problem turned out to be the DHC hex inverter card in 00XC C11: the inverter output on pin L was stuck, which turned out to be a problem with transistor T9 (lower left).

    I replaced the card with the one spare in the filing cabinet. That one had several notes about replaced transistors, but it seems to be functioning. I didn't swap transistors because the card takes type 102 transistors and I couldn't find any in the workshop. Based on transistor replacement on other DHC cards in the machine, this card type seems a bit prone to failure.

    After replacing the card, the B reg A light works, showing both signal levels are getting processed (B reg is low and A reg is high). The TAU is still showing a bunch of errors from the tape (skew and R/W VRC), so the drives will need more adjusting.


    from David Clementson Subject: Restoration status report 2023/01/18
    • I began the day by dismantling a relay wiring harness that was extracted from some poor donor machine [as provided by Dale Jelsema?]. The goal was to extract enough relay connector pin wires to allow Stan to finish the modifications to his relay tester to allow it to test all types of relays. I spliced some wires to extend their length, and delivered everything to Stan. He should be unblocked from finishing his tester.
    • I next turned my attention to the 729 DE #1 tape machine. Last week, I had left the machine with its FUSE light lit. When I tried powering it up today, there were no front panel lights at all! I opened the clear side panel to measure the power supply voltages, whereupon I discovered that all of the power supply rails were zero. After a bit of sleuthing, I discovered that Circuit Interrupter (CP) #2, the one associated with AC input to the DC power supply, was open even though its reset button did not indicate a tripped condition. With the power off, I manually set and reset the protector several times and was eventually able to get it to close and stay closed. This brought back the power supply rails. So CP #2 could probably do with a rebuild, although it currently seems to be working. The machine now properly shows its front panel lamps, and the FUSE lamp is OFF.
    • I next looked into the missing +62V rail that could be affecting the neon indicators. I was able to confirm that the DC voltage of that rail was very low - less than 3 volts - and that the AC voltage of the rail measured 52 VRMS. I was able to isolate the rail from its load and measure the DC resistance looking back into the supply. It measured around 40k ohms, much higher than expected if the diode had failed short. I was also able to use a DVM diode test on the suspect rectifier, and it measured okay. The only explanation I have for these observations is that the diode is functional but has huge reverse leakage.
    • I discussed the situation with Ken and we agreed that the diode should probably be replaced, although we may disagree on the appropriate replacement part. Ken favors using a "period correct" diode, whereas I favor using a modern, reliable 1A 100 PIV diode, 1N4002 or equivalent. Thoughts? DC

    from Mariane Kim Subject: Re: Restoration status report 2023/01/18
    Hi all, 

    I'll piggyback off Dave's message to give our update for this week.

    This week, Frank and I spent most of our time working on the 1402 reader, with some time spent on the 026 and 083. 

    083 card sorter:

    Frank had previously noticed that the time for which the machine runs after processing the final card in a sort deck is quite long, running for seconds after the final card had been dropped in the farthest 9 slot. This duration can be modified using the run-out potentiometer. We modified the potentiometer such that the run-out duration is approximately 1s.

    1402 reader:

    1. A report from Paul Laughton on 2023/01/11 mentioned that CT refused to load any program decks.
    2. When we powered on the CT and attempted to run a deck through the 1402, the punch "chips" light went off. 
      We believe this light should go off when the container of discarded punched chads exceeds a certain weight. We opened the panels and inspected the bin containing punched chads, it was less than 50% full, so we believe the light was on by error. A mere restart of the system "fixed" this issue (possibly more on this later)
    3. Next, we re-attempted to load a program deck. This time, we noticed that the 1402, though running, was not processing cards. No error lights turned on on the panel, either. Frank immediately thought to test the reader relays because they have proved fussy in the past. 
    4. Using Stan's (AMAZING) Permissive Make Relay Tester, we tested relays 1-13 which were associated with the reader. Results included below for future reference:
      • Relay # Highest Resistance Contact (ohms) Notes
        1 1.14
        2 1.7
        3 2.3
        4 0.77
        5 0.41 The connector for this relay had a bent #1 and R pin 
        6 0.37
        7 0.6
        8 0.39 The connector for this relay had multiple bent pins
        9 0.42
        10 0.53
        11 0.66
        12 0.89
        13 0.72
      • We manually pushed any bent connector pins back into place to the best of our ability.
        • Note that based on the wiring diagrams: Relay 5 is connected to Punch Chip Stop function (possibly related to the error in point 2 we had seen)
        • Relay 8 is connected to Run - Delay - Read function (possibly the culprit for the card reader failing to load programs)
    5. On our next attempt to load a program, the cards were being processed as expected, but we did run into a Reader Check on Column 32. We checked the problematic card against the data stored by the CPU and found that it had been read correctly, this told us that it was a problem detected with the first set of brushes. Frank and I took out the first set of brushes and inspected them visually. They seemed OK. So we attempted to finish loading the program and found that it loaded correctly. 
    6. We concluded that the relay connectors must have been the culprit here, and once fixed, the reader worked as expected. 
    026 card punch:
    • We noticed that one of the card punches was making a rattling noise. Frank showed me that this usually occurred because the clutch had failed to latch properly after a card was released. In the future, this can be easily solved by releasing a card; this will cause a rotation and therefore a new latching event. 
    • RE: Ink ribbons. No promises are being made, but I have decided to attempt to create an automatic ribbon re-ink contraption. (Note that in my research, I also found 026 keypunch ribbon for sale here: , let me know if you feel we should purchase a sample or two).
    Let me know if you have any questions, or want further information about the above points.

    Demo - from Paul Laughton - January 11, 2023
    1401 Demo, 12:30, 1/11/23
    Samuel Planefield and I gave a private demo to  a group of 24 high school students (11th and 12th grade) from The Bay School of San Francisco.

    We used the three 029, the 083, CT for tape operations and DE for running programs.
    CT refused to load any program deck. 


    1401 Demo, 3:00 PM, 1/11/23
    Karen Sun and I gave the regularly scheduled demo about a dozen guests. 

    We used the three 029s, the 083, CT for tape operations and DE for running programs.
    CT refused to load any program deck. 

    Karen shadowed this demonstration performing all the required tasks to qualify as a 1401 Demo Operator. 


    Maintenance - January 11, 2023 - from Robert Garner, Ken Shirriff, & David Clementson
    from Robert Garner

    Here’s the 1401 restoration status for Wednesday, Jan 11th.

    Today’s focus was on relay testing; neon bulb/light & fuse indicator issues in DE 729 #1 and the DE 1401’s TAU control panel. (as it's done before, DE tape drive #1 mysteriously and inexplicitly returned to life, satisfactorily performing tape loads. Relays!&^*%$)

    Detailed reports and the attendance table:

    In the workshop, Tom continued designing and assembling his Arduino-based interface to the 1401’s serial I/O port, photo below:

    from Ken Shirriff

    The DE #1 tape drive was unexpectedly working today after its intermittent problems. Apparently, Frank has the magic touch and restored it to operation, David and John are investigating two neon bulbs that aren't lighting on the back panel.

    I looked into the TAU problem with the B register A bit light not lighting. (This corresponds to the "low" A bit signal.) This happens with multiple drives, so it's a TAU issue, not a drive issue. I traced the signals and the problem appears to be early in the signal processing. This problem is likely to cause bad data when reading so it's worth fixing.

    On the oscilloscope, the signal levels from the drives vary widely from 4.88V p-p to 8.16V. The A bit is in the middle at 5.84V, so that doesn't seem to be the issue. The signal goes through a DZA amplifier/clipper card and the low output looks maybe .5V lower than the others, but it's hard to tell if this is the problem. Next, the signals go through YCC peak detector/integrator cards. This is generating spike signals but they look 4 volts too weak. Later in the processing chain, the low A signal disappears entirely and the light doesn't light.

    My conclusion is that the input from the tape drive is okay but bit A low deteriorates after the first two cards. My plan is to swap out those cards to see which one is causing the issue.


    from David Clementson

    • I started the morning working with Stan to source some AMP crimp pins he needs for his relay tester project. The pins are needed to connect the relay sockets to the tester circuitry. Unfortunately, I was unable to find a suitable modern replacement for them, so it looks like we will need to harvest some from another machine. There was discussion about going to the Yosemite warehouse to raid pins from a 088 collator there, and I believe Tom agreed to get some pins the next time he went to the warehouse.

    • At lunch, a new volunteer, John Howard (I hope I got that name right) joined us and he and I agreed to work together on the 791 DE #1 tape unit. Talking with Ken, he suggested we focus on validating the neon indicators. After much discussion and head scratching about where "ground" is on a 729, we concluded that the chassis ground and circuit ground are the same. Next, we discovered that the +62V voltage rail that the neon indicators use measured only about +2.5 VDC. We manually tripped the +62V circuit protector and observed that the +62V rail was pulled by the neon ballast resistors to -48V as we predicted. When we reset the circuit protector, the rail returned to the fault value of +2.5V. I looked at the schematics and realized that +62V is generated by a half-wave rectifier off a main transformer tap. So I would guess that the rectifier diode has failed short and needs replacement. We should be able to confirm that by looking at the AC voltage of the +62V rail. Replacing that diode looks like it may entail some surgery, however, since the power supply is pretty deep inside the machine.

    • One troubling thing is that somehow during our debugging, something caused the FUSE indicator light on the front panel to illuminate. I power cycled the machine and the FUSE light remained lit, so we may have broken something else somehow.  @Ken, is there any known issue with FUSE light coming on for this machine?

    Demo - from Paul Laughton - January 7, 2023
    Steve Madsen and I gave the demo to about 40 people. We used CT, the 026s, and the 083. All equipment worked A-OK. Most of the guests were from the Bay Area with a few from outlier states like Wisconsin. There were also a couple of computer experts from Israel with some fascinating stories. 

    There was also a demo at 1:00 PM with a different team. I did not see the demo but I am guessing that they had a lot of guests from the number of cars in the parking lot.

    Paul Laughton

    Maintenance Report from Stan Paddock - Wed Jan 4, 2023
    People who attended the CHM, and hours, were:

    Frank King   6.0  
    Stan Paddock   6.0
    Tom Szolyga   6.0  
    Robert Garner   4.0

    Send comments etc. to