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.

This was a poor connection to the power amplifier on, you guessed it, pin 5 on TB2.

Now we suspect that there is some corrosion on TB2 that is causing the intermittents.

Next time we will remove the wires on pins 1, 2, & 3 of TB2 and give them the same DEOXIT treatment that we gave pin 5.

Hopefully that will make the drive reliable again.

We also put a new ribbon on the second teletype, so both are completely functional.


The PDP-12 booted OS/8 from the RK05 on the first try.

Maybe the disk will stay fixed for a while.

We tried a TU56 control/data cable to replace the one in the system.

The TU56 drive reels vibrated when the drive was selected.

On closer inspection, the PDP-12 control cable and the TU56 control cable are different.

There are four contacts that are not wired on the PDP-12 control cable, A2, B2, U1, and V1.

So, it looks like we connected +5 from the processor to the TU56.

In any case, swapping the cable didn't make any improvement in the tape drive behavior.


The PDP-12 booted OS/8 from the RK05 on the first try.

We fiddled with binary image of FOCAL-12 that was taken from one of the UMN Duluth PDP-12 LAPS-DIAL tapes.

Unfortunately it depends on parts of LAPS-DIAL, so it would not run standalone.

The FOCAL overlays for all of the special PDP-12 hardware were on the same tape, including source.

We will see if we can add the overlays to FOCAL-69.

We started reading the paper tapes that were part of this week's donation.


The PDP-12 booted OS/8 from the RK05 on the first try.

We continued reading the paper tapes that were part of a recent donation, and saved them on an RK05 disk image using serial disk.

We printed the BUNNY.ASC tape to see what the file contained, but it wasn't the Easter bunny.


Warren Stearns, who provided a huge amount of technical and moral support for our restoration projects, died last Sunday.

We will really miss his help and friendship.

The PDP-12 booted OS/8 from the RK05 on the first try.

We continued reading the paper tapes that were part of a recent donation, and saved them on an RK05 disk image using serial disk.

On some the labels are not obvious, so we have to determine of they are source or binary paper tapes.


The PDP-12 booted OS/8 from the RK05 on the first try.

We found that running the tapes through the Teletype is the easiest way to determine if they are binary or text.

We continued reading the paper tapes that were part of a recent donation, and saved them on an RK05 disk image using serial disk.

We didn't get much accomplished because of interested visitors, but that is why we are here.


The PDP-12 booted OS/8 from the RK05 on the first try.

We finished reading the paper tapes that were part of a recent donation, and saved them on an RK05 disk image using serial disk.


We started reading FOCAL paper tapes for Charles Lasner, and ALGOL tapes for UMN.


I went to the Vintage Computer Festival in Elk Grove, so no PDP-12 time.


Back to reading paper tapes and saving them on an RK05 disk pack image.

We tried to demonstrate Spacewar, but the VR14 monitor is not working.

The VR14 and VR20 Troubleshooting Procedures manual says that the 2N4399 and 2N5302 transistors on the X and Y deflection boards can be damaged if the beam is deflected off the screen for an extended period of time.

We had the VR14 monitor on for many hours while we were running OS/8, so the beam might have been off the screen.


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

Yesterday Charles Lasner and John Wilson visited the RICM to give us moral support and technical help on the LINCtapes.

Earlier we replaced a bad right tape head, but were never convinced that we got the head alignment correct, and were unable to read LINCtapes.

Charles donated most of a TU56 DECtape drive to use for repair parts.

Both tape heads on Charles' drive had good coil resistance values, so they are probably OK,.

We swapped the front TU56 tape drive casting with the two tape heads from Charles' drive onto the drive on the PDP-12.

This procedure will retain the tape head alignment from Charles' drive.


We finished swapping the replacement LINCtape parts onto the TU56 tape drive and gave it a try.

For the first time in many months were were able to read a LINCtape on the PDP-12!

It still needs some tuning and adjustments, but this is major progress on this project.



ABSLDR.SV 5 09/20/74 CHESS .BN 21 10/25/74 EDU200.SV 31 11/02/74

CCL .SV 17 11/02/74 CHESS8.SV 17 10/25/74 CREF .SV 13 11/02/74

FOTP .SV 8 10/22/74 DIALPS.SV 21 10/25/74 DESCR .TM 2 11/02/74

PIP .SV 11 11/02/74 CUBIC .SV 8 10/25/74 TC12F .SV 11 11/26/74

DIRECT.SV 7 11/02/74 KALEID.SV 2 10/25/74 SSINST.WU 6 12/10/74

RESORC.SV 10 09/20/74 EDIT .SV 10 01/18/74 SOS .PA 14 12/10/74

BOOT .SV 5 09/20/74 MARK12.SV 7 MAGSPY.SV 27 05/19/72

BUILD .SV 33 11/02/74 SOS .BN 2 12/10/74 TEMP .TM 73 11/07/71

HANGMN.SV 8 10/25/74 SOSDEF.PA 2 12/10/74 FENWEL.FT 2

SNOOPY.SV 15 10/25/74 BLINK .PA 1 11/26/74 BTEMP .FT 1 03/31/75

MOON .SV 14 10/25/74 BLINK .BN 1 11/26/74 ATEMP .FT 1 03/31/75

HANGMN.BN 5 10/25/74 EPIC .SV 14 11/02/74 BETA .FT 2 04/01/75

PING .SV 8 10/25/74 BASIC .SV 73 11/02/74 FENWAL.FT 3 04/01/75

HANGMN.WD 2 10/25/74 TECO .SV 12 11/02/74 LINES .FT 3 04/02/75

CHESOV.PA 17 10/25/74 PAL8 .SV 16 11/02/74 TEMP .FT 1 04/02/75


We took a look at the broken VR14 monitor.

The 2N5302 Q2 is shorted, so we will order some replacements from Digikey.

We also noticed that Q2 had been replaced before.

We had some 2N5303 transistors in stock, so we replacd Q2 with one.

These are the same as a 2N5302 but are 80V rated instead of the 60V for the original transistors.

The VR14 is working OK now, but we need to adjust the X and Y gain and centering.


We corrected the X & Y gain issue, but haven't done a complete recalibration of the display.

It works quite nicely now.


We readjusted the X & Y gain and position trimpots to center the display.

We still need to check all of the voltages.


We checked the +/-22V supplies.

The 22 +/- 1.0 reads +21.8, and the -22 reads -22.2 so no correction is required.

It looks like they are not adjustable, so they will stay as they are.


We ran MAINDEC-12-D6BC to exercise the VR14 display and the VC12 controller.

We checked the X and Y deflection output voltage that comes from the VC12 controller in the PDP-12.

One of the manuals says that the deflection voltages should be about +/-6V.

We observed +/-4V, and adjusted the X and Y gain in the VR12 monitor to make the test patterns fill the whole screen.

We locked the diagnostic on pattern 2 to display an X on the screen.

The upper trace is the X deflection, the lower trace is the Z or Intensify signal.

A negative voltage on the X deflection signal moves the beam to the left, and positive to the right.

A negative edge on the Intensify signal causes the VR14 CRT to draw a dot on the screen.

The upper trace is the X deflection, the lower trace is the Y deflection signal.

A negative voltage on the X deflection signal moves the beam to the left, and positive to the right.

A negative voltage on the Y deflection signal moves the beam to the bottom, and positive to the top.

In this case we see the X position of the beam traversing from left to right, and the Y position hopping from bottom to top and back to the bottom to drawn an X on the screen.


We ran MAINDEC-12-D6BC to exercise the VR14 display and the VC12 controller so we could look at the X & Y deflection signals and the Intensify signal.

This is the description from the PDP-12 manual for how the VC12 draws characters on the VT14 display.

The upper trace is the Y deflection, the lower trace is the X deflection signal.

In the left half of the screen you can see the Y beam position moving incrementally to the right while the X position moves right and left.

The diagnostic is displaying small and large text on the screen using the LINC DIS instruction.

The first DIS instruction will complete in 4.8 to 6.4 uS but the VC12/VR14 display will take longer to write the dots.

The next DIS instruction can take up to 56uS to complete the work from the previous DIS instruction, and the new DIS instruction.

This lets the processor do some work while the VC12 display controller takes care of writing the character.


We ran Spacewar for a visitor,

The system is running OK.


We spent some time on the LINCtape problem.

We see large signals from the tape heads, even when the system is powered off.

We connected just a TU56 tape head to the 'scope and spent some time searching the lab space for the interference.

It doesn't seem to be coming from a source in our space, so maybe it is coming from a neighbor.