DEC PDP-12 Restoration Blog starting 1/1/17


It is possible that last week we adjusted the position of the tape head so that it was one bit time (33uS) from where it should have been.

Today we will remove the tape head shim that we installed last week.

Alex brought a bulk tape eraser, so we can completely erase a LINCtape before formatting it.

We will format a LINCtape, flip it over so the oxide side is up, and then measure the head skew.

We replaced the ceramic wear plates in the right side of the TU56 tape transport with steel ones.

The ceramic ones were known to cause problems, and DEC eventually replaced them.

We formatted just the Timing and Mark tracks on a tape, rewound the tape, put the tape in motion, and looked at the output of the G882 modules.

We could see the G882 modules oscillating when there was no tape head signal, and this is normal.

With the tape in motion we could see Mark track data, but no Timing track data.

We swapped the relay boards in the TU56, but there was no change.

We connected the same G888 setup that we used last week to see the raw tape head data.

We could not see any data on the timing track.

Oh well, we will debug this next week.


Warren suggested that we look at the signal strength of the timing track using only one Op-Amp, read a tape written by DEC, and align the head for the maximum signal.

This should get us close to the correct alignment.

We can then split the timing track coils and use the normal DEC procedure to measure the time difference between track-1 and track-10.

This should let us get the head alignment under 2 uS.

We measured the resistance of the head coils.

Fortunately the all read about 1.2 Ohms, so we can continue with debugging.

We adjusted the LINCtape head skew to about +/- 1uS by reading several LINCtapes that were written by DEC.

DEC must have had some very special equipment at the factory to adjust the head skew to 0.5uS.

Click on the image for a larger view.

The upper trace is Timing track #1, the lower track is timing track #10.

We tried to format a LINCtape, and it ran through pass 1, got half way through pass 2, recovered, got part way into pass 3 and did the "shoeshine" looking for something on the tape.

We saw the same behavior on two different LINCtapes.

We need to study the MARK12 software to see exactly what it is doing in each pass to determine what we need to fix.


We looked at the documentation for the MARK12 program that formats LINCtapes on the PDP-12 so we have a better idea of what it is doing when it fails.

We spent a few hours going through the Maintenance Manuals for the TU55 and TU56 tape drives, the TC12 LINCtape controller in the PDP-12, and any other documentation that we have on DECtapes. There are a lot of pieces of documentation available, but no single document that correlates the digital/analog/magnetic signals. We will make a document that describes the digital data from the TC12 tape controller, the analog data that goes to the tape head, and the resulting magnetic patterns on the LINCtape. We will also document the reverse process from the magnetic/analog/digital signals.

We ordered a small spray bottle of Magnetic Developer. The Magnetic Developer WWW page says "This elegantly simple formulation contains iron particles suspended in a fluid with a rapid evaporation rate. When the developer is placed onto a magnetic surface, the liquid evaporates and the magnetic particles orient themselves in accordance with the magnetic pattern on the surface of the material." This should let us see the data that is on a LINCtape.


The Magnetic Developer arrived.

Click on the image for a larger view.

The Timing Tracks are on the outside, the next tracks in are the Mark Track, then a gap, and then the three data tracks.

The bits on the LINCtape are about 2.7 thousandths of an inch for a 0-1-0-1 transition.

In places we can see the Mark track bits, but not the Timing or Data track bits.

Higher magnification might help, so we will try to find someone who will let us use a microscope with an attached camera.


Alex learned how to use the Arbitrary Waveform Generator, and made Timing and Mark track data.

We pulled the relay board from the TU56 to isolate the tape head and fed signals it into the TU56 to simulate tape head data.

Note that the track numbers in the TC12 LINCtape controller are different than the track numbers in the TU56 tape drive.

The ground pins for the shield for Data Track 3 are incorrect in the schematic, and the TC12 end was not grounded.

Click on the image for a larger view.

The sine wave is simulating Timing Track tape head data, and the square wave is the output of the G882 module in slot F05.

The output will lead the input at frequencies below 33kHz, and lag the input at frequencies above 33 kHz.

The TC12 tape controller was in Search mode at the time, so this shows that the tape head signal has no interference.

Click on the image for a larger view.

We reduced the analog input signal to about 10mV and saw no difference in the digital outputs from the G882.

At this low signal level there is a lot of noise on the signal, but the G882 was able to dig the signal out of the mud.

We also ran the LTspice simulation of the G882 module and verified that the simulation and the real module behaved the same.

Both the simulation and the 'scope images show a small glitch on the rising edge of the G882 output signal.


While everyone was watching the Pats win the Superbowl!, we did a little more debugging.

Later this afternoon we will go see the Hidden Figures movie about the African-American women working at NASA.

The oscilloscope and the cart of schematics in the movie were from the RICM collection.

We pulled the relay board from the TU56 to isolate the tape head from the G882 modules in the TC12 LINCtape controller.

We fed the signal from the waveform generator to all of the *(1) signals on the TU56 that are connected to the "E" inputs on the G882 modules, and grounded the *(0) signals.

We also ground the *(1) signals and feed the waveform generator into the *(0) signals.

This let us test both sides of the COAX between the TU56 and the TC12, and both inputs on the G882 modules.

We fed the D and then the E input with a sine wave of 200mV and the digital output of the G882 cards all looked OK.


We used both channels of the waveform generator with one inverted to simulate both sides of the head signal, and fed all 5 signals from the TU56.

Even with the signal level down to 20mV, and lots of noise on the "head" signals, the output of the G882 modules was rock solid.

Wiggle the cables showed no glitches on any of the signals.

There is a 200mV spike with a 60kHz repetition rate on the signals that go from the TU56 tape head to the TC12 controller.

When the "head" signal is reduced to about 5mV, and the 200mV spike lines up with the zero-crossing of the head signal, the G882 shows a glitch on the digital output signal.

The signal is present with the PDP-12 turned off, so the source is external.

We are now thinking that the problem with the LINCtapes may be the office environment that it is running.

None of the WiFi, Bluetooth, or cell phone signals were in use when the PDP-12 was designed, so it is not very well shielded.

We will hunt for the source of the signal that is causing the problem on the G882 modules.


Click on the image for a larger view.

We still see the the 200mV signals every 4uS on the cable that goes between the TU56 and the TC12.

Even with the signal shorted to the shield on the end of the Triax, we still see the noise, although diminished.

Click on the image for a larger view.

We still see the the 200mV signals every 4uS on the cable that goes between the TU56 and the TC12.

We are digging into the Triax cable and shielding to determine how we can reduce the interference.

We found a mistake on sheet TC12-0-LTR in the PDP-12 schematics.

The pins on the cable between the TU56 and the TC12 labeled BT2 and FT2 are really BL2 and FL2.

DEC wired the TC12 backplane per the incorrect schematic and grounded pin F06T2 instead of F06L2.

This leaves the TC12 end of the Triax cable shield for data track 3 ungrounded.

Data track 3 is the one on which we are having a noise problem, so this is a promising discovery.

Since this system was always run in an electrically quiet environment, the missing ground may not have caused any problems.

It is possible that all PDP-12s were built with the missing ground wire.

We added a ground wire on pin F06L2, but it didn't improve the boot behavior.

Next week we will try to format a LINCtape, and run the tape drive diagnostics.

It is possible that our fiddling with the tape head alignment has it 33uS out of alignment, so it won't read tapes written on another machine.


We replaced the bulb for MA(4).

Fixing the ground does not seem to have improved the LINCtape behavior.

We were unsuccessful when trying to format a LINCtape, so mode debugging is necessary.

We reran the LINCtape TC12 controller diagnostics to make sure that everything other than the tape transport is OK.

MAINDEC-12-D0GA Tape Quickie

MAINDEC-12-D3AE Tape Control Test Part 1 of 2

MAINDEC-12-D3GA Tape Control Test Part 2 of 2

MAINDEC-12-D3DB TAPE DATA EXERCISER (Ran for a long time before it halted)

They all ran OK, so we have high confidence that the TC12 controller is still working OK.

We didn't see any Timing Track or Mark Track data at the TC12 LINCtape controller.

Warren wasn't here to provide adult supervision so I put the G851 relay board in the TU56 drive upside-down.

Putting the G851 board in the right way allowed the data to get to the TC12 controller, but the behavior is still not improved.

Maybe it is time to connect the Logic Analyzer and see what all of the tape tracks look when reading a tape?


We spent some time on my broken Tektronix THS730A 'scope.

Alex cleaned up a spare TC01 to TU56 cable.

We will substitute the cable for the one in the PDP-12 and see if the LINCtapes behave better.

We booted OS/8 from the RK05, and played Space War for a while.

Spacewar is a really good test of the PDP-12 processor, and uses just about every part of the system.


Our younger visitors are fascinated by the Teletypes, and the idea of storing their name on paper tape.

The ASR-33 that came with the PDP-12 is actually a model 33TU, 8-Level, Standard Duty, 60 Hz, Answer Back, Private Line, Friction Feed, has a 0 for the zero, and includes the DEC modification to for remote control of the paper tape reader.

We installed the same DEC 8-pin AMP connectors for the serial console connection on everything so the Teletype can plug into the PDP-12, PDP-8/I, PDP-8/L, PDP-8/S, and PDP-9.

Teletypes require maintenance and adjustments to keep them running properly.

This one has a problem where the keys get stuck, but sometimes pressing the HERE IS key will get it working again.

Now the Teletype will only let you press one key after pressing HERE IS, so it is time to do some exploring.

Fortunately there is a group of experts at GreenKeys that can help us.

We found a sticky Code Bar in the keyboard, that took several seconds to return after a key was pressed.

A little WD-40 dissolved the congealed lubricant and freed up the bar in the keyboard. (I will find out the proper name.)

After some testing we found that some of the characters on the print head is worn out from using the Teletype with a dried out and damaged print hammer.

The steel under the rubber print hammer chewed the characters on the aluminum print head.


Charles Lasner dropped off a partially damaged TU56 that is missing lots of parts, but it has two good looking heads.

We will check the resistance of the head coils, and if they are OK we will use them in the PDP-12.

The plan is to remove the whole front casting, including the tape heads, from the parts TU56, and replace the assembly on the PDP-12.

This way we will not disturb the existing tape head alignment.

Cross your fingers that this will get the LINCtapes working.


We borrowed a print head from another Teletype in the warehouse.

The Teletype that we borrowed the print head from was a DEC modified Teletype, but it has a different print head without the slashed zero.

The borrowed print head works much better and you can actually read what is printed.

Quite a while ago when we first worked on the Teletype the platen would not turn.

We fixed the frozen platen, and also found that a rubber bumper that cushions the line feed linkage was missing

We put some shrink tubing around the steel to protect it until we could do a more permanent repair.

After fiddling with the line feed linkage I remembered a caution from one of the Greenkeys members.

If I pushed the line feed linkage down about 0.050" it worked OK.

So, our temporary repair with the shrink tubing didn't hold the line feed linkage in the right resting location.

I added about 5 more layers of shrink tubing, and now the line feed works OK.

I connected the Teletype up to the PDP-8/I and it works just fine!


A generous person is donating a replacement print head for the KSR33 Teletype.

Should have it in a week.

Last week we found that the RK05 would not go ready.

We thought that it was the same problem with the grey wire that carries the analog signal to the amplifier.

We wiggled and cleaned the grey wire connection, but it did not fix the problem.

More debugging to do.

Victor and Charles donated the rusty remains of a TU56 tape drive.

Both tape heads have the correct resistance, so they are likely OK.

One head is from Western Magnetics, and one head is from Applied Magnetics.

The blue connectors are different, but they look interchangeable.

We will swap the whole die cast face of the TU56 drive with the heads in place so we don't disturb the head alignment,

We need to do some cleanup and cosmetic repair to the front of the TU56 before we swap it.


Wayne Durkee donated a replacement printwheel for the ASR-33 Teletype console.

I removed the sheet metal cover on the RK05 this morning, and gave it a try.

Of course it worked fine.

I closed it up and pushed it back on the rack and it would not go ready.

Opened and it worked again.

Ran MAINDEC-12-D3AE Tape Control Test Part 1 of 2, and MAINDEC-12-D3GA Tape Control Test Part 2 of 2.

Both worked OK.

Ran MAINDEC-12-D3FB Tape Data Test.

That ran fine too.

It can't find blocks on a tape, so the next test is substituting the data/control cable with one from the warehouse.

Then replacing the face of the TU56 including the heads that are mounted on it.


More time away from the -12 while I was in Germany again.

The RK05 will not go ready, so it is time for some serious debugging.

We bought new ribbons for the Teletypes from Ribbons Unlimited for $11.95 each.

If you ask for model 33 Teletype ribbon they will add the reversing rivets to a standard ribbon.

They seem to work nicely, and we can actually read the printing now.


We tool a look at the intermittent RK05 today.

Since the heads were not loading we looked at the LOAD HEADS H signal on pin AP1 on the m7701 Control + Interlock module.

The signal was always low, so that explains why the drive would not go ready.

We put the M7701 on an extender board and looked at the SPINDLE SPEED OK H signal on pin 4 of E3, and it was always low.

We looked at the INDEX PULSE L signal on pin 11 of E8, and it was always high.

The index pulse comes from a sector transducer under the disk pack.

In the transducer, the light from an LED is interrupted by a ring on the bottom of the disk pack.

The voltage between pins 1 & 3 of TB2 showed enough voltage to light the LED.

The voltage between pins 1 & 2 of TB2 was about 5V until we put a piece of paper between the LED and the photodiode.

We put the disk pack back in, manually rotated the disk pack, and could see the voltage from the photodiode change.

It is just wiring from the sector transducer to the M7701 module, so it shouldn't be difficult to debut this issue.

We measured the voltage between pins B06 L1 and B06 T1, and we could see the voltage change when we rotated the disk pack.

We looked at the INDEX PULSE L signal on A04 J1, spun up the disk, and could see sector pulses.

Of course the disk went ready, so that was the end of debugging.

The previous intermittent on this drive prevented the heads from moving out to cylinder 0.</