Wednesday, June 6, 2018

Restoration of 1401, MacBook Pro, Mac IIci, and work on Documation USB interface


This morning I dealt with the passwords on the system, many of which my daughter can't remember since years have passed since she used it. The solution was to boot to single user mode, remount the root partition to be writable, and delete the file that tells OS/X that it had completed setup.

With that file gone, it took me through a fresh setup dialog, including the chance to create an administrator account with a known password. From there I could replace all the other passwords, giving me the ability to do anything I need.

The existing system has 4GB of RAM and a 250GB internal hard drive which is choked to saturation with my daughters files. Once she has retrieved the files she wants I can clean up and have room to apply necessary updates.

8GB of RAM is inexpensive enough that I ordered it, along with a 1TB 7200 RPM hard drive. We shall see how well it performs, with those upgrades installed. I did get the upgrades and cloned the internal disk to the 1TB replacement, but the 8GB of RAM did not work. After trying everything suggested by the vendor's tech support staff, there is a replacement on the way.


I got the replacement FTDI based USB to parallel port boards and began to replace the damaged boards on my two interface PCBs. First step after installation was to verify that they communicate reliably with the PC side program, before wiring one into the card reader. Sadly, I damaged the first one while removing the original right angle header pins.

I worked more carefully on the second board I just received. Getting the old pins out was no problem but placing the new straight header pins took quite a bit more time. Although the soldering was fine, for some reason it wasn't able to communicate to the PC.

I did some continuity testing on the USB daughterboard and found that the external pin for signal D7 was not connected to the same signal pin on the FTDI chip onboard. The solder joint looked good and the trace was seemingly undamaged, but no connection.

Apparently good solder joint and trace leading from it
I scraped off a section of the trace at an accessible point on the edge of the board, verified connectivity, and then soldered a jumper wire. Now, D7 from the FTDI chip is connected to the external header.
Poorly focused but exposed trace where jumper will be soldered
Jumper in place to restore connectivity for D7 signal
Alas, testing this still didn't result in communication between the PC side and my interface board. Since I verified the connection of every external pin to its source on the FTDI chip, any connectivity problem must exist on my main interface board. That is, unless somehow a chip is blown. The PC sees the USB device and sets up the serial COM port for communication, making the daughterboard appear to be working.

Found another suspect solder joint on a different cable, which I cleaned up. Still no communications, but it seems I am getting closer and closer. As long as it isn't a bad chip I will eventually get this chatting with the PC. In the meantime, I worked with the other board that I completed, which does talk to the PC reliably it appears.

The card reader does not appear to be working properly - which may be an issue with my wiring or something that was already wrong in the reader itself since I hadn't done a full test of this device before. I can see the EOF signal go on and off, as well as reliably reflecting the front panel status conditions such as Hopper Check, Pick Check, and Read Check.

What isn't happening properly is reading. I see the program issue a Pick and the card moves through the machine, but the software is still waiting with the pick active. I need to put the scope on the reader to verify that it is delivering the response that the controller expects to the pick, which is BUSY signal going true. That signals that the leading edge of the card has reached the photocells.

Sometime after BUSY goes true, we should see 80 Index Marker (IM) pulses which tell the controller to sample the 12 data lines. The controller design by Brian Knittel ignores the BUSY line, thus the only way the controller chip could know that a card has been read is to see the IM pulses.

All of this suggests that I am missing the IM pulses, so that is first up on the diagnostic priority list.


Today we verified that the spurious Reader Check and Validity Check errors on the German 1401 system were indeed caused by the SMS card I identified last week. We ran the machine for quite a while without errors, after which I put the suspect card back in and began to see the same errors again. The good card was reinstalled and the machine run for quite a while with no errors.

The software archiving group brought a donated Mac IIci to me to restore, allowing them to archive a large batch of Mac related software. I helped them make a list of replacement electrolytic capacitors and CMOS battery, which they ordered from Mouser and handed to me this morning.

There were a few axial through-hole capacitors but most were surface mount cans. I used my vacuum desoldering gun and hot air gun to remove all the original capacitors. We cleaned the board, particularly the spots where leaking capacitor fluid were found.

I didn't think to bring solder paste, so I had to attempt to solder the SMT capacitors to the board using a regular soldering iron and careful technique. The through -hole were easy, of course. The machine sprang to life and works perfectly now.


  1. Mid-2010 13" MBPs are very sensitive to RAM speed and only work with the correct (1066?) speed RAM.

    1. MacSales sent me the proper OCW RAM, matching all the specs listed by Apple for this model, including speed. Well, the labels on the modules and the packaging listed the speed and other specs correctly.