• Please review our updated Terms and Rules here

PDP-12 #435 at the University of Minnesota Duluth

pahp

Experienced Member
Joined
Dec 14, 2021
Messages
63
Location
Duluth, MN
Testing the registers. Our sheet says M222, but our machine has M221s... Anyone know why?

Also, it passes M221_REG.TST, but two M221s in a row fail 1142 steps of M221.new, and tests M221.NEW.1 and M221.NEW.2 will not load in the tester.

1000002327.jpg
 

pahp

Experienced Member
Joined
Dec 14, 2021
Messages
63
Location
Duluth, MN
Last register passed M221_REG.TST. Now to double-check our card sheet to make sure everything is still in place.
 

pahp

Experienced Member
Joined
Dec 14, 2021
Messages
63
Location
Duluth, MN
Testing the registers. Our sheet says M222, but our machine has M221s... Anyone know why?
I'm a dummy, I didn't realize there are 222s in the top and 221s in the bottom. How did I never notice that! 🤦
 

pahp

Experienced Member
Joined
Dec 14, 2021
Messages
63
Location
Duluth, MN
Ok, everything has been tested within a year, mostly within the last week or so. Just two failures -- two M216s. I hope to repair them today or Monday.
 

pahp

Experienced Member
Joined
Dec 14, 2021
Messages
63
Location
Duluth, MN
The M216s that had failures retested successfully. The machine is still behaving strangely, though, so we are a bit back where we started.
 

DougIngraham

Experienced Member
Joined
Oct 2, 2019
Messages
497
Location
Rapid City, SD USA
Warren's tester can not tell you that a card is good, only that it is bad. Weak or slow outputs are things it cannot test. It is still a useful tool for getting you most of the way to a working machine.

One thing you can do with the tester is to run some passes with the power supply a little high and a little low to help find marginal parts. Maybe as high as 5.5 volts and as low as 4.5 volts. But without putting real loads on the outputs this probably won't find much over the regular 5 volt run.

The next step is to run the diagnostics which will hopefully find problems you can correct. I've never looked for the PDP-12 specific diagnostics, but the 8/i diags are readily available and will test the stuff you are most interested in. The maint manual probably has a list of diags to run and the order to run them. Once you find and fix something, start over as your fix could have broken something that got tested in an earlier test.

My view is that the 8/i. 8/l, and PDP-12 are the best machines to own from a maintenance standpoint. The 8/e, f, and m are a close second. The TTL logic in these machines is still mostly available and the use of simple double sided boards makes the parts easy to replace. The 8/a boards are multi layer making them more difficult to work on and they started using ROM's and some custom logic that is no longer available.

One of the projects Warren was working on at the time of his death was an advanced tester that would have been able to load outputs and measure slew rates. He was very interested in being able to test the R and S cards found in the Straight 8, 8/s and LINC 8 machines. These cards have negative voltage logic levels.
 

vrs42

Veteran Member
Joined
Nov 24, 2009
Messages
727
Location
Beaverton, Oregon
@vrs42 not sure if these differences are useful for you -- M216B vs L206B with an M216 handle.
Those phots are interesting. I have no information about any Lxxx series modules.

The module itself is interesting. It is exactly an M206B, except that someone has made it into an M216 by removing the jumper configuration stuff. The actual M216B, on the other hand, is rather different.

Vince
 

pahp

Experienced Member
Joined
Dec 14, 2021
Messages
63
Location
Duluth, MN
Those phots are interesting. I have no information about any Lxxx series modules.

The module itself is interesting. It is exactly an M206B, except that someone has made it into an M216 by removing the jumper configuration stuff. The actual M216B, on the other hand, is rather different.

Vince
I think that our weirder modules may have been due to a field repair or maybe a feature addition? A number of them were marked by masking tape when the machine was in service.
 

pahp

Experienced Member
Joined
Dec 14, 2021
Messages
63
Location
Duluth, MN
I think that our weirder modules may have been due to a field repair or maybe a feature addition? A number of them were marked by masking tape when the machine was in service.
This module was also fixed by Dawson when Warren was there -- that's the replacement solder work (hence the tag).
 

pahp

Experienced Member
Joined
Dec 14, 2021
Messages
63
Location
Duluth, MN
Thanks for the wisdom and advice.

Rerunning the diagnostics is our next step, after retesting the few modules last tested in March before our old tester died.

The behavior we are seeing is as follows. We can punch in the RIM loader and run it. Then we can send bootloader.rim via the serial port (using minicom or MTTTY), and that seems to work.We start os8diskserver on the other serial port and attempt boot
With START 20.

The first disk block is sent, but then the machine hangs in a loop of some kind; the loop differs in behavior based on the visible lights. Sometimes it screeches due to speaker clicking. If it does anything beyond sending the first block, we see messages like this (an example, it's not consistent).

1000002338.jpg

As I said, we intend to rerun diags but I'm providing this info here in case this happens to be a common issue.
 

SpaceHobo

Member
Joined
Dec 10, 2021
Messages
32
Location
London, UK
Warren's tester can not tell you that a card is good, only that it is bad. Weak or slow outputs are things it cannot test. It is still a useful tool for getting you most of the way to a working machine.

One thing you can do with the tester is to run some passes with the power supply a little high and a little low to help find marginal parts. Maybe as high as 5.5 volts and as low as 4.5 volts. But without putting real loads on the outputs this probably won't find much over the regular 5 volt run.

This reminds me of how they tested vacuum tubes in 1940s/50s computers: they'd supply marginal voltages and run around tapping the things with the eraser end of a pencil. If it failed from that, it was worth replacing anyway!
 

vrs42

Veteran Member
Joined
Nov 24, 2009
Messages
727
Location
Beaverton, Oregon
One thing you can do with the tester is to run some passes with the power supply a little high and a little low to help find marginal parts.
One of the things I'd try, to shake out weak outputs, is to load the suspect TTL outputs with the provided LED loads. Those should add about 300 ohms of load pulling toward GND. LOADH1 and LOADH3 are also 2K and 5.6K loads to GND, but they don't provide as much load (nor do they shine properly).

LOADL1, and LOADL3 are 280 and 90 ohms toward VCC, respectively. That may not be as useful, unless the transistor closure to ground has somehow gone to some intermediate impedance.

The tester doesn't do much to measure propogation delay or slew rates, though.

Vince
 

pahp

Experienced Member
Joined
Dec 14, 2021
Messages
63
Location
Duluth, MN
So, yesterday and today Kyle R. and I did a deep dive on debugging our problem with the machine.

I punched in a bunch of the low level diagnostics (not the official DEC ones). Everything that I tried, worked, modulo working around the BSW instructions that the PDP-12 doesn't have. Every punch-in program that we try at the console works (once we grasp the addressing modes :ROFLMAO: ). We're yet to see a basic operation that doesn't work as it's supposed to.

When we send files from minicom, the machine runs the RIM loader and acts like it is reading data correctly. (For example, the speaker clicks as the data is read in, and we can slow down using AUTO and see that it is receiving data and working.)

We tried loading the OS8 bootloader.rim, decoding it, and double-checking the data in core, which seemed to show that it was loaded correctly. Then we tried loading the BIN loader, but it was not properly loaded. Some addresses were right, and others were not. There didn't seem to be a pattern.

So, we wrote a punch-in program to wipe the first 4K of core (actually, set it to 7777). Then, we re-loaded the BIN loader and... there was no data loaded -- 7777 had 7777 (from our wipe) not 5301 as it's supposed to. The lower addresses in the BIN loader were also still 7777. Then we tried loading the OS8 bootloader.rim, and the same thing was true -- words in core were not being changed, even though the machine definitely seemed to be RXing data from the terminal.

One time, we loaded a file and slowed down the RIM loader using AUTO, and that one time it seemed like the very first address was changed, but iirc it was not correct.

So, our next plan is to single-step through the RIM loader and trace loading the first word of something into memory to see what's happening. If this triggers any memories or hot ideas, please let me know! Thanks!
 

vrs42

Veteran Member
Joined
Nov 24, 2009
Messages
727
Location
Beaverton, Oregon
The RIM loader would do something like this if the 0100 bit was failing to read correctly. If you can run the echo test, and echo alphabetical characters correctly, that's not it, though.

I assume you're loading from minicom, not a TTY? Otherwise it's also possible one of the reader pins is stuck or slow.

Vince
 

DougIngraham

Experienced Member
Joined
Oct 2, 2019
Messages
497
Location
Rapid City, SD USA
So many things could be wrong. You need to find something that doesn't work that you can reproduce at will.

You could have bits stuck in the MA or MB registers. I am not sure of the best way to see these on an I or 12. On the Straight 8 you can see those registers so it is obvious when a bit doesn't get set or cleared in the MA when you do a Load Address. I think this is also true of the 8/i and PDP-12. Similarly when you do a deposit the switch register gets transferred to the MB so depositing a 0 should clear all bits in the MB and depositing a 7777 will set all bits in the MB. I like to walk a single bit through those registers as my initial tests. If you have adjacent bits stuck or talking this tends to find them.

You might have an addressing problem. Try storing the address at the address. I generally do a single bit walk
on the address lines with just the switches.

address 0000 store a 0000
address 0001 store a 0001
address 0002 store a 0002
address 0004 store a 0004
...
address 4000 store a 4000
address 7777 store a 7777

Examine all of these to make sure they are correct.

Then repeat this with the one's complement of the address at the address.

If that all seems to work then try running a program to store the address at the address.
Code:
0000 1005 TAD 0006
0001 7000 NOP           /OR 7040 CMA TO STORE THE COMPLEMENT
0002 3405 DCA I 0006
0003 2005 ISZ 0006
0004 5000 JMP 0000
0005 7402 HLT
0006 0007               /STARTING ADDRESS TO SET

Hope that helps. I would come out for a PDP play date but this is not a great time of the year to visit Duluth and its around 800 miles.
 

pahp

Experienced Member
Joined
Dec 14, 2021
Messages
63
Location
Duluth, MN
Thanks, @DougIngraham and @vrs42 . We will try those things, probably starting with the echo test.

@DougIngraham , this is what's visible on the console.

1000002505.jpg

Is MA "memory address" and MB is "memory buffer"? If so, then we can see them. Here, I have just deposited 6032 into 7765 (a typo, the RIM loader should start at 7756, but that's just for demonstration of the lights). Thanks again!
 
Top