• Please review our updated Terms and Rules here

Reviving the PDP-12 at the RICM

Of course it also depends on the make up of epoxy used which might be a whole lot different to that used in the navy aeroplanes. I once worked for a company (Elliots) who made a range of encapsulated discrete RTL/DTL/TTL modules (precursors to ICs) in epoxy-filled plastic cases. The epoxy didn't degrade in the way this navy report mentions. For failure analysis we needed to use a nitric acid mixture and some mechanical gouging to get at the components. YMMV of course ;) .
 
jackrubin said:
Here's a Navy report on depotting F-4 components from roughly the same time period. They describe a solvent that seems pretty effective, though I wonder if any of the solvents are still available under today's HazMat regulations -
http://www.dtic.mil/dtic/tr/fulltext/u2/725493.pdf

Jack
Click to expand...

Anyone who has spent any time in a #1ESS or #1AESS environment is familiar with the Western Electric 313A relay and something referred to as "green goo". They're the square looking cans just above the middle of the second bay in this picture of a typical lineup.

https://en.wikipedia.org/wiki/Number_One_Electronic_Switching_System#/media/File:1A_Frames.JPG

These relays had mercury wetted contacts inside a glass capsule that was stabilized by some sort of resin potting compound inside a metal outer can. These relays were used, literally by the hundreds, in the older style Signal Distributor frames and in lesser quantities throughout the switch. The earliest ones, made in the late 1960's - 1972 could be identified by the aluminum outer can. They never gave us any trouble. Later production was in a gold looking plated steel can with apparently a different potting compound. At some point in the 1990's or so the potting compound in the later relays began to re-liquify, ooze out of the cans, and contaminate anything that was below it. We, as in what was left of the Bell operating companies and Tellcordia, were unable to identify any solvent that was more than marginally useful at loosening and removing the goo once it touched anything. Try to imagine the problems you would face if one of those relays in the picture leaked a viscous goo down into the relays further down in the lower half of the bay.

So your success will depend largely on finding something that will work on the potting compound you have. You may find that there are heads out there in the wild made at different times that will have different potting compounds. In the end, you may be reduced to Marty's suggestion. Cut all the old &^%$ off of the head assembly and rewind the coils.
 
The right LINCtape drive is mostly working so I spent some time looking at the contents of the tapes that came with the PDP-12. I found some games on one tape, including the source and binary for MOON. It displays a line on the VR14 representing the surface of the moon, some text numbers where one is likely the fuel or time remaining. A small rocket is displayed at the top middle with an engine fire. The rocket rotates slowly above the moon surface until the fuel runs out. Then the fire goes out, the rocket drifts to the surface of the moon and explodes. The display starts again at the beginning. I tried typing on the console, changing the console left, right, and sense switches. and the analog input knobs and nothing has an effect. Maybe it needs a light pen like the LAB-8/e version? Any ideas how this works?

Charles Lasner wrote an OS/8 program that can be linked to a standalone LINC *.BN program and then saved as a *.SV file. The program has the normal 0200 starting address, then sets up the fields to match what the LINC expects, and then jumps to the LINC program. This lets me just do R KALEID and run the LINC demo program.

I also found that Kyle/Bob's serialdisk works OK if the PDP-12 is booted from the RX01 instead of the RK05. I can't explain that, but serialdisk is quite useful now.
 
We figured out how to drive the TANKs and control the lunar lander. We are starting to get some programs running that our young visitors will actually like.
 
m_thompson

I've been following this thread closely this past 12-18 months. I certainly have enjoyed reading about the various problems and the solutions that the team at RICM have applied in getting these machines running.

I am a little disappointed that after a couple of weeks you haven't posted high scores for these two games. :D Surely, someone there has at least trained and become proficient on these two games, especially if they're going to be available to the public. These two games, and screen shots provided, do bring back a lot of memories. Thanks for posting them.

I don't get up to New England very often, but this blog has certainly made me think about flying into Providence, and staying over for a visit to RICM.
 
MichaelM

We still have problems with the LINCtapes and the second serial port. Until those are fixed I am spending time on the repairs instead of getting proficient at the games. Personally, I would rather fix the systems and write demonstration software than actually run the systems. Once the PDP-12 is fully functional I will probably start working on a PDP-11/05, and looking for a new set of demonstration programs. I already have Adventure for RT-11.

If you visit, we have two locations. The Lab space where we teach STEM classes, have a selection of smaller systems on display, and have the PDP-8/I and the PDP-12. The warehouse is a few miles away and holds the majority of the collection.
 
Hi All;

M-Thompson, this may be a dumb question, ""The Lab space where we teach STEM classes"" , but What are STEM Classes ?? I've heard of Stem Cells, but not Stem classes..

THANK YOU Marty
 
Another day spend debugging the TC12 LINCtape controller, and no real progress. Next week I will take a break from the TC12 and work on making the second serial port more reliable so we can use Kyle's serialdisk emulator.
 
m_thompson said:
Until those are fixed I am spending time on the repairs instead of getting proficient at the games. Personally, I would rather fix the systems and write demonstration software than actually run the systems.
Click to expand...
From your descriptions of the problems and repairs being made to these systems, I figured that you probably leaned toward the repair instead of game playing. I really look forward to your updates on the team's work on these systems. I've been too busy to get my own PDP11 systems up and running, and I certainly like to follow the work you and others on this site do in getting your systems up and running.

Having never been around a PDP8/PDP12/LINC, your blog posts have certainly been very educational. I had intended to drive over to Atlanta for VCF Southeast and take a look at Kyle Owens' PDP8, but life/work got in the way; maybe next year. Alternatively, since I am regularly in Auburn (AL), I may be able to get with him one weekend over the next year.

I will certainly keep in mind the two RICM locations, and plan on having some extra time next time work takes me to MA.
 
MichaelM,

You are right, I like the challenge of the debug and repair much more than playing games. We still need to have programs that will run in the systems so visitors can see them run and do something other than blink lights. Since the PDP-12 has graphics capability we are using that as the showcase. I have been reading the manuals and looking at existing code to see how to display controller works. It is a little painful to flip from PDP-8 mode to LINC mode to get to the analog and digital I/O and the graphics. The editors in OS/8 are horrible by current standards, and the assembler support for mixed mode programs is not very good. This is all part of the challenge that makes the work interesting.

Let us know when you are in the area so we can show you our toys.
 
OK, getting graphical games running on the PDP-12 is fun too. I assembled SPCWR3 from source from here: http://www.chdickman.com/pdp8/VC8/

I had to put a NOP instruction at 05503 to fix a hang, and now the game runs. You can see the gravitational attraction on the rockets from the sun.

The action is way too fast to be able to control the space ships. The code that I disabled was probably slowing it down to a reasonable speed. It is interesting to say that the PDP-12 is running too fast...

PDP-12_SPACEWAR.jpg
 
Last edited:
It's possible to slow the game down. You can play with the timer reload value, by doing that you should be able to get the interrupts less frequently. Now the timer is set up to give an interrupt 30 times/second. If the interrupts are coming less frequently the game should slow down a bit. The problem is that the screen is updated less frequently and it will start to flicker more.

Look in the code where the timer is set up.
Code: 
/SUBROUTINE TO START UP CLOCK
/MAY BE HARDWARE DEPENDENT
/THIS IS FOR KW12A CLOCK - PDP12
/OR PROGRAMABLE PDP8E CLOCK DK8EP
	CLSK=6131	/SKIP IF CLOCK
	CLLR=6132	/LOAD CONTROL
	CLAB=6133	/AC TO BUFFER PRESET
	CLEN=6134	/LOAD ENABLE
	CLSA=6135	/BIT RESET FLAGS

STCLK,	0
	CLA CLL		/JUST IN CASE
IFNZRO PDP12 <CLLR	/STOP CLOCK
	CLEN		/CLEAR INTERRUPTS
	>
	TAD (-40	/ABOUT 30CPS
	CLAB		/LOAD PRSET
	CLA CLL
	IFNZRO PDP12 <
	TAD (0100	/1KC - PRESET TIME
	CLLR		/LOAD CONTROL
	CLSA		/CLEAR STATUS AND POSSIBLE OVERFLOW
	CLA CLL
	TAD (300	/INTERRUPT ON OVERFLOW
	CLEN
	CLA CLL
	TAD (4100	/AND START UP CLOCK
	>
	IFNZRO DK8EP <
	TAD (5300	/INTR ON CLOCK - 1KC
	>
	CLLR
	CLA CLL
	JMP I STCLK>
 
Right now the problem is the WAIT flag is never set, so the game does not run. I put a NOP after the skip instruction so it would not wait for the KW12 timer tick.

We need to rerun the KW12 diagnostics to see if the clock is still working OK. I will connect a 'scope to the timer event flip-flop to see if can drive the interrupt and skip lines on the backplane. If that is all OK then we need to debug the timer interrupt handler and restart code.

I have never worked with a DEC clock so this will be a learning experience.
 
We ran the MAINDEC-12-D8CD KW12A Clock Test to make sure that the KW12A clock is working OK.
With error halt disabled we found these faults:
TST34 O'FLO FAILED TO SET O'FLO FLOP
TST41 O'FLO FLAG WON'T CLEAR
TST42 CLOCK INTR WON'T CLEAR
TST55 RATE 400KC FAILS
TST56 RATE 100KC FAILS
TST57 RATE 10KC FAILS
TST58 RATE 1KC FAILS
TST58 RATE 100CPS FAILS
TST60 CHAN 1 INPUT LOCKED OUT
TST72 CHAN 1 INPUT LINE FREQ FAILED
TST86 FAST SAM NOT CLEARED
TST87 CHAN 1 WON'T TRANS CNT TO BUF
TST90 CHAN 1 WON'T TRANS CNT TO BUF
So it looks like the KW12A clock is broken.

I replaced the M216 flip-chip in slot F19 that contains the Overflow flip-flop.
This was a previously repaired module where we only replaced one of the three SN7474 ICs.
Next time we will replace all three SN7474 ICs because we see so many failures of this part.

The KW12-A is working OK now.

Space War is now running OK.
 
Last edited:
Very cool Mr. Thompson.

One of the features of the PDP8 that I find so interesting is its low level implementation. Imagine the difficulty that one would encounter in repairing a more modern computer with its greater level of integration. The process would likely focus on subsystems and replacing them when faults are located. The PDP8's level of integration allows repair at a very low level that many young engineers and technicians cannot imagine today.
 
MichaelM said:
Very cool Mr. Thompson.

One of the features of the PDP8 that I find so interesting is its low level implementation. Imagine the difficulty that one would encounter in repairing a more modern computer with its greater level of integration. The process would likely focus on subsystems and replacing them when faults are located. The PDP8's level of integration allows repair at a very low level that many young engineers and technicians cannot imagine today.
Click to expand...

Most of the ICs in the PDP-12 are standard TTL parts and are still available. Some of the ICs were Signetics Utilogic, and are difficult to find. Through eBay and some generous donors we have a few spares. Some TTL ICs like the 7453 and 7460 had a very short lifespan. If we get desperate and can't find replacement parts, it would be possible to make a generic replacement flip-chip that contained a single CPLD, and program it to behave like the broken board. We haven't gotten to this point yet.

Other parts, like TU56 tape heads, are failing and we can't fix them. That will eventually be a problem, and may require a very expensive fix. Core memory is another problem. The way that DEC's vendors made the core stacks makes them susceptible to solder joint failures. It is repairable, but a very tricky and involved process.

The PDP-9 in our collection doesn't have any ICs. One of the transistors that is common in the PDP-9 was made by Fairchild in the 1960. We found 20,000+ in stock at Digikey at a very low price. That machine is even more repairable than the PDP-12.

Experiencing one of theses machines running, and interacting with it, is completely different than running a simulator. It really is interesting seeing a young enthusiast's reaction to working with one of these systems.
 
We have been testing Charles Lasner's modifications to Kyle Owen's non-system serialdisk OS/8 handler. Charles found another bug where the code depended on the PDP-8/e IOT behavior for serial ports. He modified the code for both the PDP-8/I/L and PDP-12 IOT serial port behavior and now serialdisk works on the PDP-12!

Charles is now working on the serialdisk system handler. After we get that debugged we will release the updated handler and server code. This updated version should work on a Classic PDP-8, PDP-8/I, PDP-8/l, and PDP-12. I imagine that it would also work on a LINC-8.
 
The serialdisk system handler works OK on the PDP-12 with an RK05 image that was built using my PDP-8/e. If you run BUILD on the PDP-12 and modify the RK05 image, it makes the RK05 image unbootable. It I then run BUILD on my 8/e the damaged RK05 image will boot on the PDP-12 again.

We are working on the LINCtapes again. Alex made a LTSPICE model of the G882 Manchester Reader/Writer. It looks like the reader is almost immune to common-mode noise, and will work with a head signal of a few microvolts up to the expected tens of millivolts. That should make it work really when the head signal is cut in half when there is a complete track dropout. After we improve the model some more we will post it on the RICM WWW page along with a summary of how the circuits work.
 
You must log in or register to reply here.
Back
Top