• Please review our updated Terms and Rules here

PDP-12 at the RICM

m_thompson

Veteran Member
Joined
Jul 8, 2014
Messages
1,985
Location
Rhode Island, USA
The PDP-12 at the RICM broke a few weeks ago, and I finally had a chance to look at it. When first powered up it will boot and run OS/8 from the RK05. It will not run SPACEWAR or TANK or any of the other demonstrations we normally use. It will run KALEIDESCOPE. That means that large parts of the machine are working OK including most of the CPU, Core, and even the EAE.

Sometimes OS/8 will hang in a loop where it is executing the IOT 6041 and a JMP -1. It is waiting for a character to be sent out the console serial port before it can send the next character. At this point I can toggle in a little program that sends the contents of the AC out the console serial port, waits for the character to be sent (IOT 6041), increments the AC, and loops. This works OK. If I now run OS/8 it hangs in the IOT 6041 and a JMP -1 loop again. We swapped the M707 Teletype Transmitter flipchip, but it didn't make any difference.

SPACEWAR loops in a JMP 0001 loop. This looks like it got an interrupt when it should not have.

It ran Instruction Test 2 successfully. We will run all of the processor diagnostics, and maybe one will find something misbehaving.

Ideas are welcome.
 
The PDP-12 passes MAINDEC-8I-D01C Instruction Test 1, but fails fails MAINDEC-8I-D02B Instruction Test 2. It gets stuck in an loop at 0001 executing a JMP 0001. Instruction Test 2 tests that interrupts happen when they should, and do not happen when they should, and tries this for a range of instructions. Either we have a peripheral that is generating an interrupt when it should not, or the CPU is processing an interrupt when they are inhibited.

Looks like interrupt test #4 is not working. We swapped the M607 Teletype Receiver, but it did not make a difference. Running the CPU in single-step mode works OK if the Auto Repeat is on and set to a slow speed. So we don't have a solid failure, we probably have a chip with low drive capability.

I looked through the diag code. The base code has a JMP 0001 in location 1. The first interrupt test does a JSR to a routine that writes a JMP I, 0002 into 0001 and clears locations 0002 and 0003. Each interrupt test writes a return address into 0002. It looks like the JMP I, 0002 was never written into 0001.

Time for some single step debugging to see what is not working.
 
Ah, its a core memory problem. The Core from 2000 to 2777 is always 0000. The JMS instruction @2675 to the routine that fixes the JMP instruction @ 0001 never executed. As long as the Core stack is OK this should not be difficult to fix.
 
Memory problems...

But you have fiddled with the serial card right? The M707. Test receive and transmit separately, which of them does not work?
 
Memory problems...

But you have fiddled with the serial card right? The M707. Test receive and transmit separately, which of them does not work?

Anders,

I did not diagnose the problem correctly. The Core between 2000-2777 did not work. OS/8 would load correctly and run, but would not respond to any console commands. Instruction Test 2 uses the serial port to generate interrupts, and to make sure that interrupts don't happen when the transmit flag is off, and do happen when the transmit flag is on. I misinterpreted this as a serial port problem. We have spare M706 and M707 modules, so I swapped them and that did improve the behavior. It looks like one of our spare modules is broken because the serial port worked OK when I put the original M706 and M707 modules back in.

With the missing core memory it looks like parts of OS/8 did not execute therefore no CLI. Part of Instruction Test 2 did not get loaded, especially the part that setup the JMP I, 0002 for the interrupt tests.

This was a good lesson in debugging because I was convinced that the serial port problems were caused by hardware, and it technically was a software problem. The memory problem that caused the software problem was really a hardware problem.
 
The serial console in the RICM's PDP-12 stopped working. I tested other devices and found that the RK05 disks, paper tape reader, and serial console were all broken. The paper tape punch worked OK. I am guessing that the problem is with the MB signals that hold the I/O address or one of the IOP signals. I connected a 'scope to signals on the M707 for the console and could see what looked like reasonable activity. While I was debugging the console started working. I shut it off for 30 minutes and tried again. After several seconds of running the console started working again. A thermal problem with a chip? Bad solder joint? Bad connection on the FlipChip fingers? This should be a fun fault to track down.
 
It booted OS/8 from the RK05 disk and ran SPACEWAR! so everything looks OK for now. I wiggled all of the serial port related boards, so maybe it will stay working for a while.
 
It could be a bad capacitor, especially if the machine has been idle for a while. Low electrolyte allows the plates depolarize. Applying power will reverse the process temporarily and after a while they get close enough to the specifications to function.

My 861 power controller, with just 1 capacitor, behaves like this.
 
The PDP-12 worked fine for a few hours, and then died while I was copying files from a SerialDisk RK05 image to the real RK05. After that it would not boot from the RK05, or run Spacewar! loaded through the serial console port using the BIN loader. We tried some of the toggle-in diags and the processor looks like it is working OK.

We loaded MAINDEC-08-D02B-d PDP-8 Instruction Test Part 2B through the serial console port using the BIN loader. It ran for a few seconds and then died. We looked at what it was doing before it halted and the code in memory did not match the diag listing. Since we previously had problems with the serial console we decided to use the paper tape reader instead. We had a tape of MAINDEC-8I-D01C Instruction Test 1, so we tried that. It also quickly halted and we found that most of the constants stored in memory were incorrect. Maybe a problem with one of the instructions used in the BIN loader?

We loaded MAINDEC-08-D1B0-D Memory Address Test in RIM format through the serial console port. When we ran it, it reported errors in memory from 0000 to 3777. These memory addresses work OK when set from the console, but not at full processor speed. We looked at the contents of the first 4k of memory and found that many did not have the correct address stored. The memory range 3000-3777 doesn't work at all.

I am guessing that one of the G221 Address Decoder flipchips is broken. It should be relatively easy to determine which one if the eight in the first 4k died and swap it or fix it.
 
I fiddled with different memory addresses and found that the first 2k of memory was misbehaving and the upper 2k if the first field was OK. The second 4k field also was OK. The G221 boards decode the memory address to drive core memory signals. I swapped the G221 in slot C07 with a repaired spare. The first 2k of memory now worked, but I couldn't set address bit 0. I swapped the G221 for another repaired spare and now all 8k of core memory is working OK. OS/8 booted and is running OK.

The whole point of this exercise was to copy the RICM modified source to Spacewar! for the PDP-12 using SerialDisk and assemble it on the PDP-12 using PAL. The Spacewar! source was on the RK05 disk from last week's work, so now I need to learn how to use PAL.
 
Unfortunately the Spacewar! source code that we moved onto the physical RK05 was mangled in the process. This time we used Kyle's Serial Disk and Vincent's OS/8 image manipulation tools to move the Spacewar! source code to the physical RK05 on the PDP-12. The modified Spacewar! has LINC code for the PDP-1 like game controllers that one of our volunteers made. We were able to assemble and run the modified Spacewar! on the PDP-12. Now we need to modify TANK and Lunar Lander to use the game controllers.
 
We moved the PDP-12 to RICM's new larger display space a week ago. We had to remove the console panel to get it out the door. In the process of moving we managed to cut three traces on the switch PCB on the bottom of the console. Not a difficult repair, but awkward with the console flexprint cables still connected. The processor looks like it is working OK. We unlocked the heads and tried to spin up the RK05 disk pack. It smells like something is burning and doesn't go ready. That will be the project for Saturday.
 
The RK05 worked OK with the cover off. No smells and OS/8 booted OK. Spacewar! will run for a few minutes and then the processor hangs.

LINC MODE is on, IR=0705, PC=1626, MA=1625, MQ=1356, AC=0000, MB=1005. RUN, ION, INT PAUSE, and LINC MODE are all on.

Looks like it is time to run the instruction diagnostics.
 
I wrote a PDP-12 emulator and I'm currently testing it with LAP6, which is a OS basically written for the LINC. I would like to get a copy of LAP6-DIAL in binary, listing, or better yet, the sources.
Do you perhaps have this software available in the RICM?
 
What did you write the 12 emulator in? Vince has been adding support to SimH for it. I'm still interested in constructing a hardware model of it in Verilog one of these days...
 
I wrote a PDP-12 emulator and I'm currently testing it with LAP6, which is a OS basically written for the LINC. I would like to get a copy of LAP6-DIAL in binary, listing, or better yet, the sources.
Their are various DECtape and other media images for at least LINC-8 and PDP-12 here. I don't have any working hardware that can run it currently so can't say which actually work.

http://www.pdp8online.com/images/index.shtml
 
Back
Top