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

08/24/19

Something strange is going on.

Sometimes OS/8 hangs, looping with a 6041 instruction waiting for characters to be sent out the serial console.

None of the usual programs like SPCWAR, TANK, and HANGMAN will run, the all loop with the 6041 instruction.

A toggle-in test for console output that uses the 6041 instruction works OK.

We swapped the M707 Teletype Transmitter module, but there was no change in the behavior.

Instruction test 1 works OK, including ringing the bell on the serial console.

Instruction test 2 works for a little bit, and then hangs in a loop at 0001 executing a JMP 0001.

Executing an interrupt when it should not?

Not executing an interrupt correctly?

Next week we will start at the beginning with all of the simple diagnostic programs to make sure that the processor is working OK.

08/24/19

It 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 do not happen after a range of instructions, so this looks like the problem

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

We 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

9/2/19

Starting MAINDEC-8I-D02B Instruction Test 2 at 201

Hangs in a loop of JMP 0001 @ 0001

Core 0000 contains 3013

Core 0001 contains 5001

Core 0002 contains 3016

The interrupt happened and the instruction @3012 was the last one executed before the interrupt happened

The target address for the JMP i is 3016, which is correct

The JMP 0001@0001 should be a JMP I, 0002

The subroutine that changes the contents of 0001 didn't work

We checked the core contents against the diag listing and found that core locations 2000-2777 were all 0000

We ran MAINDEC-08-D1B2 Memory Address Test and found that Core from 2000-2777 was reporting errors

The G221 flipchips decode the memory address and send current through the core stack

It either had to be the G221 in slot C08 or C07 that was not decoding the 2xxx addresses

We tried the G221 in slot C08 first, but it didn't make a difference

Replacing the G221 in slot C07 fixed the memory

We will repair the G221 and put it back in the spares inventory

OS/8 and Spacewar are running again!

6/21/20

Ran Spacewar! just to make sure everything is working OK.

10/17/20

Ran Spacewar! just to make sure everything is working OK.

The serial console looks it is receiving characters, but the menu option from Spacewar! is not displaying.

7/2/21

The system has been running Spacewar! demonstrations just fine for about nine months. We needed to image some 8" diskettes, so we booted OS/8 from the RK05 and then used it to load the RIM and BIN bootloaders. We then used the BIN loader to load the RX01 dumprest program through the serial console, connected my laptop to the serial console, and tried to read the diskette. We got some strange error messages about the diskette being quad-density. After several tries we reloaded Spacewar!, but it would not run. Time for some diags to see what is broken.

7/3/21

We ran MAINDEC-8I-D01B Instruction Test 1, so most of the CPU and the core memory is working OK. We tried loading MAINDEC-8I-D02B Instruction Test 2, halted at 226 doing a DCA test. That section of the program did not have the correct contents even though the BIN loader said that it was received correctly. Sounds like a core memory problem. We loaded Warren's Tune core memory test, and the first run seems to work OK. We need to fiddle with the switch settings to do a more severe core memory test.

7/7/21

We started running the MAINDEC diagnostics that are listed on the summary WWW page for the PDP-12. All are working OK so far.

MAINDEC-8I-D0BA EXT ARITH TST PART 3B halted, but MAINDEC-08-D0BA Instruction Test 3B runs OK. We are not sure what the difference is in the PDP-8/I version.

7/10/21

We noticed that the bit-11 bulb in the MQ is not working. The bulb is OK, so there is a problem elsewhere.

We had lots of visitors today, so we only had time to rerun MAINDEC-12-D6BC VR12 Display, Tests display system using DIS and DSC instructions. It worked OK.

7/13/21

We ran MAINDEC-12-D8CD-D KW12A Clock Test, and after about 30 seconds it failed with a TST70 CHAN 3 INPUT LINE FREQ FAILED 0000. We reran the test and saw the same error. The source code says that the SOURCE knobs on the KW12 Clock Control panel need to be in the LINE FREQ position. We set all three knobs and now it fails with the message TST74 O'FLO WON'T FAST SAM 0776 0775. We reread the instructions, especially the part about setting the KW12 switches and knobs and the Analog Channel 0 & 1 knobs to specific positions. The KW12 test now runs OK.

We ran MAINDEC-12-D8AB Relay Register Test. It ran OK and even lit the Christmas lights that we have connected to relay 0.

We ran MAINDEC-12-D6CC A To D Test.  Channels 0-17 all look OK, but channel 16 needs a slight adjustment. Channels 20-37 all need to be adjusted.

We ran MAINDEC-12-D6BC VR14 VR20 Display Test.  When it is displaying pattern 2 the text wiggles a little. Maybe we should check the power supplies in the VR14 to see if there is some ripple when displaying pattern 2. The other patterns are solid with no jitter.

We ran MAINDEC-12-D0SA Automatic Priority Interrupt Test. it runs and does not halt, but doesn't ring the TTY bell after 1 minute so it may not be working. We don't use this part of the PDP-12, so we can ignore this for now.

We loaded SpaceWar! and it works OK. The TTY console options list is working too. We even got a ship to orbit around Polaris.

We booted OS/8 from the RK05 and tried to run LUNAR.SV. It hung at a TSF instruction waiting for the console printer to be ready for another character. Maybe a serial port problem?

TANK.SV halted at 7702.  That is beyond the end of the program.

KALEID.SV runs OK.

MOON.SV runs OK.

SNOOPY.SV runs OK.

We tried LIFE.SV. It is executing a 7141 IOT instruction. We have no idea what peripheral responds to that IOT.

ORGAN.SV runs OK. You use the TTY console keys to control the notes.

CUBIC.SV is a 3D TIC-TAC-TOE program. It runs OK.

HANGMN.SV runs OK. 

6/25/22

We tried to demonstrate the system by running SpaceWar!, but it would not run. We need to try the toggle-in tests to see if anything is broken, and then try the Maindec diagnostics.

6/29/22

We tried the PDP-8 Toggle-In Programs to see if the Processor instructions work OK.

Group 1, Group 2, Operate and ISZ instructions work OK.

Other instruction tests work OK.

It booted OS/8 from the RK05 disk, so at least the PDP-8 processor is OK.

It runs KALEID, ORGAN and MOON so the LINC processor is OK.

We reloaded SPCWR3 from my laptop, and it runs OK.

We really need to load SPCWR3 source onto the RK05 disk so we can run it under OS/8.

2/18/23

A few weeks ago we tried to run SPACEWAR!, but it would not run. It would not boot OS/8 from the RK05 disk either.

Today we toggled in some simple instruction tests to see if the processor and core memory work OK. Simple register manipulation instructions work OK. A simple loop that displays characters on the console. It is getting stuck on the TSF instruction where it waits for the character to be sent to the terminal. Without a console nothing is going to work. We tried a console echo program and found that it gets stuck on the KSF instruction where it detects a character has been sent from the console. There is an M452 module in slot N08 that generates the clock pulses for both the console transmit and receive logic. If this failed it would explain the symptoms that we see. It will not read paper tape, but it will punch paper tape. Maybe the processor is having a problem sending the device address to the devices?

We decided to look at the M707 FlipChip in slots N07 & M07 that contains all of the console serial output logic except for the baud rate clock. Pin MR1 should go low when the I/O address is correct and the IOP4 signal on pin MS1 goes high. The instruction that clears the output buffer loads the contents of the AC into the output buffer is TLS 6046. The 6 is the I/O instruction, the 04 is the device address, and the 6 will enable IOT pulses 4 & 2. To get I/O address 04 we need MB[3..8] to be 000100.

We triggered the 'scope in the IOC IOP4 H signal going high and ran a program that incremented the AC and loaded it into the console output buffer. On the 'scope we see a 900 ns positive going pulse at a 111 kHz rate. We added the TTO SELECT H .NAND. IOC IOP 4 to the 'scope and see a 900 ns negative going pulse coincident with the IOC IOP 4 pulse. We added the TTO MAGNET DRIVE H signal to the 'scope and ran the original program that outputs all possible characters to the serial console. While we were fiddling with the 'scope the console started working.

Maybe we just need to wiggle all of the flipchips in the system to establish better electrical connections? We powered the system off for 30 minutes. When we powered it back on and ran the test program there was a several second delay before the console started working. This is going to be a challenge to track down.

OS/8 booted from the RK05 disk, so much of the system is working OK.

3/1/23

We thought that Kermit was on the RK05 disk pack, but it was not. We will need to put it on an RX01 floppy diskette and copy it to the RK05 disk. We will make the diskette on my PDP-8/e at home. We experimented with sending the source code through the serial console port using a terminal emulator, and receiving the file using PIP on OS/8. That didn't work well, and is probably why Kermit exists. We can also put the source and binary of the newest version of Spacewar! on the diskette too.

The system seems to be running fine today.

3/4/23

We didn't make a diskette that contained Kermit and the updated source for Spacewar! Today we will attempt to boot from a Serial Disk image served by my laptop through the PDP-12's second serial port. It would have been easier if the OS/8 kernel on the RK05 disk drive included support for Serial Disk, but it looks like we neglected to do that. 

Its been quite a while since We used SerialDisk so it took a while to get the cabling, USB-Serial cables, and configuration files setup. We toggled in the SerialDisk bootloader and it booted OS/8 from a virtual disk. We copied Kermit12 from a virtual disk to the physical RK05, and also copied the OS/8 SerialDisk drivers. The updated OS/8 boot command source code that includes booting from serial disk was already on the B side of the physical RK05.

For future reference, the OS/8 kernel on the PDP-12 RK05 disk pack supports SerialDisk on the second serial port, even though it is hard to see using the RESOURCE/E command.

.RESOURCE/E

113 FILES IN 1359 BLOCKS USING 3 SEGMENTS

1833 FREE BLOCKS (10 EMPTIES)


#  NAME TYPE MODE SIZ BLK KIND U V ENT USER

01 SYS  RK8E RWF 3248 SYS      0 C  07

02 DSK  RK8E RWF 3248 SYS      0 C  07

03 TTY  TTY  RW       16+ KL8E   E 176

04 PTR  PTR  R        17  PT8E   A 112

05 RXA0 RX8E RWF  494 20         E  30

06 RXA1 RX8E RWF  494 20         E  34

07 LTA0 LINC RWF  737 21       0 A  10

10 LTA1 LINC RWF  737 21       1 A  11

11 TV   VR12 W        22+        A  13

12 RKA0 RK8E RWF 3248 23  RK05 0 A  20

13 RKB0 RK8E RWF 3248 23  RK05 0 A  21

14 T4    64  RWF      24         G  53

15 TDA0  64  RWF      24         G  52

16 T5    64  RWF      24         G  51

17 TDA1  64  RWF      24         G  50


FREE DEVICE SLOTS: NONE,  FREE BLOCK SLOTS: 01

OS/8 V3Q

Using Kermit12 we should be able to transfer binary and source files from a laptop to the PDP-12.  We need to put the current source code, the version that supports the switch boxes connected to the SENSE signals, for Spacewar! on the disk drive, assemble it, and run it from disk. We should also try the other video games that are on the disk like TANK and Lunar Lander.

3/8/23

We tried unsuccessfully to use Kermit to move files from my laptop to the PDP-12 when running OS/8. It is a lot more complicated than it looks. We need to get some help with this.`

We tried to use John Wilson's PUTR program to move the SPCWR3 source code onto an RK05 disk image. My 64-bit Windows 10 would not run the 16-bit DOS program. We installed DOSBox, ran PUTR within DOSBox, and then used PUTR to copy the files to an RK05 image. That was also complicated to get setup, but we got it working. We ran the SerialDisk server and mounted the RK05 disk image. We then booted OS/8 from the RK05 disk, and used the COPY command to move the SPCWR3 files from the SerialDisk RK05 image to the physical RK05. It moved the binary file and the source file, but died when it was moving the listing file.

OS/8 will not boot from the RK05. We think that the PDP-12 processor is broken again. We toggled in the RIM loader, ran that and loaded the BIN loader. We used the BIN loader to load Spacewar!. It looked like it loaded OK, but it would not run.

We tried to use the BIN loader to load the first PDP-8/I instruction diagnostic, but it immediately halts. We used the RIM loader to reload the BIN loader, and now it loaded MAINDEC-8I-D01C Instruction Test 1. The diag failed immediately. We compared the instructions in core memory with the diagnostic listing, and many instruction bits were dropped.

We tried the basic toggle-in tests to see what instructions worked OK. The Group 1 and 2 Microinstructions work OK. ISZ instructions work OK. The console print test works OK. The console echo test works OK. It looks like the basic set of instructions are working OK.

We reloaded the BIN loader and then loaded MAINDEC-08-D02B-d PDP-8 Instruction Test Part 2B. This ran for a few seconds and then printed "GLLD" and is stuck in a loop. We reloaded the program and it looks like it is stuck in a loop again.

3/11/23

We have paper tapes of the PDP-8 and PDP-12 diagnostics. We suspect that there might be a problem with the receive side of the console serial port, so loading them through the paper tape reader might work better, and will be much faster.

We loaded MAINDEC-8I-D01C Instruction Test 1 from paper tape. The BIN loader can load from either the serial console or the paper tape reader. If you set the console switch 0 on it will load from the serial console. If you set switch 0 to off it will load from the paper tape reader. If we haven't use the bin loader for a while this configuration switch is easy to forget, and then it won't load diags from the serial console as expected. There are two different RIM loaders, the low speed that loads from the serial console, and the high speed that loads from the paper tape reader.

We ran MAINDEC-8I-D01C Instruction Test 1. It halted at 0146 with the AC=0000 as expected. We pressed CONT and it halted at 0215 which indicates that it was performing SZA test #5 and and the AC did not contain 0400. It actually contains 7740.

The contents of core memory is not as expected.

Address Cont. Should Be

0001 5001 5000

0006 7400 7402

0021 0000 0001

0022 0000 0002

0023 0000 0004

0024 0000 0010

0026 0000 0040

0027 0000 0100

We reloaded the diagnostic and the contents of memory have the same incorrect values. We can load the correct contents into memory from the console.

We toggled in a little memory checkerboard program that fills memory with alternating 0000 and 1111. That program worked correctly.

Maybe one of the instructions used for the BIN loader is not working correctly so it is not loading the diagnostic correctly?

We loaded MAINDEC-08-D1B0-D Memory Address Test in RIM format to avoid the issues we had loading BIN formatted files. When we ran the diag we found problems addressing memory starting at 1000. The number following the A is the problem address and the number following the C is the contents. The contents and the address should match.

A1000 C0000

A1001 C0000

A1002 C0000

A1003 C0000

A1004 C0004

A1005 C0004

A1006 C0000

A1007 C0004

A1010 C0000

We did some manual checking and found that the addresses in the range of 0000-3777 are unreliable when written at full speed. Using the system console we can successfully read and write to some of these addresses. The address range 3xxx is completely broken. On Wednesday we will look at the G221 core memory Address Selector FlipChips to see which one is broken.

3/15/23

We decided to look at each 512 chunk of memory and see what works. From the console 0000-0777 works, 1000 works but 1001 and addresses up to 1777 don't, 2000-2777 works, 3000-3777 is broken, 4000-7777 works. Using the AUTO function, FILL STEP, and then STEP EXAM addresses 0000-3777 are broken and addresses 4000-4777 are OK. The addresses 0000-2777 drop some bits and addresses 3000-3777 are completely broken. All addresses in the second 4k core memory field work OK. Debugging the address range 3000-3777 should be easiest because it is completely broken.

We swapped the G221 in slot C07 with a repaired spare. The bottom 2k of core memory is working OK now, but we can't set address bit 0 to access the upper 2k of the first core memory field. We replaced the G221 in slot C07 with another repaired spare and all of the first 4k of memory is now working. Even though the INST FIELD or DATA FIELD lamp does not go on when bit 2 of the INST FIELD switch is set, we can still access the second 4k field of core memory. 

OS/8 booted from the RK05 disk and is working OK. The source code for the RICM version of Spacewar! for the PDP-12 was copied from the SerialDisk to the RK05 last week, and the file looks OK. We tried to assemble it using PAL. It printed some messages that we didn't understand. We need to study the OS/8 manual to find out how to use the software development tools.


.R PAL8

*RKB0:SPCWR3.BN,RKB0:SPCWR3.LS,RKB0:SPCWR3.TM<RKB0:SPCWR3.PA/C

IC  0200

IC  0200

IC  0201

IC  0201

IC  0202

IC  0202

IC  0203

IC  0203

IC  0204

IC  0204

IC  0200

IC  0200

IC  0201

IC  0201

IC  0202

IC  0202

IC  0203

IC  0203

IC  0204

IC  0204

.

It looks like the source code did not make it to the RK05 disk intact. We used John Wilson's PUTR program to transfer the source code from Windows to an RK05 disk image, and then SerialDisk to transfer it to the physical RK05 disk on the PDP-12. Looks like something broke in the process.

3/18/23

We used tools created by Vince Slyngstad and Kyle Owen to transfer the source code for Spacewar! that was modified to use the RICM game controls from a virtual RK05 disk drive on the laptop to the physical RK05 disk drive on the PDP-12. Assembling the source code on the PDP-12 was a lot slower than cross-assembling on the laptop using PALBART. Yes, PALBART was developed by the Bay Area Rapid Transit to build software for the DEC PDP-8/e systems that controlled the digital signs for 30 years. Now we can run Spacewar!, Tank, Lunar Lander, etc. from OS/8.

6/13/23

We ran Spacewar! for visitors. Everything worked OK.

6/17/23

We moved the PDP-12 to the new RICM Lab space. I even remembered to lock the heads in the RK05 disk drive. It will be interesting to see how much work it takes to get it running again.

7/1/23

Well, the PDP-12 didn't survive the move. It doesn't look like there is any power on the VR14 because the red indicator light doesn't go on. That I can Examine and Deposit core memory, so a lot of the machine is OK. Pressing the LS button does not start the processor running.

Pressing the EXAMINE or DEPOSIT keys causes the RUN flip-flop to go on for 1.5 uS, and the core memory works OK.  Pressing START/20 or START/LS does nothing. Pressing START/400 sometimes will cause the system to run, but the Program Counter starts at 5000, not 0400. I put a JMP 0000 at 5000, a JMP 0001 at 0000, and a JMP 0000 at 0001. Pressing START/400 with STOP on causes the processor to go to 5000, then 0000, then 0000. That looks good, and means that the processor is capable of decoding and executing instructions.

We traced the signals back to the console. We found that the PC traces for the START/20, START/LS, and LINC/* MODE on the bottom of the console switch board were cut. We had to remove the console to get the system through the door when it was moved, so the damage must have happened then. I soldered a wire-wrap jumper wire across the cut in the traces, and the switches kind of work again. The START/400 doesn't start at 0400, and the START/LS doesn't start at all possible combinations of switch settings. All of the left switches work for setting the EXAMINE/DEPOSIT address, so the starting address issue must be in the processor logic somewhere.

We toggled in an ISZ loop at 0200, set the left switches to 0200, and pressed START/LS. The ISZ loop started, so the console is working again.

Wednesday we will unlock the RK05 heads and try to boot OS/8. If that works we can connect the game controllers and load Spacewar!

7/8/23

We took the cover off the RK05 so we could watch what happened when it was powered on and spun up. This time it worked OK and went ready with no drama. OS/8 booted on the first try and we were able to use the ABSLDR to load SPCWR3.BN into memory and run it. It ran Spacewar! OK

7/12/23

It ran Spacewar! OK

11/11/23

It ran Spacewar! OK

We received an RK05 disk drive emulator to try. It plugs onto the cable from the disk controller or RK05 disk. It is made from a combination of a Raspberry Pi Pico and an FPGA.  The workmanship is really impressive, but OS/8 didn't see the drive. It works fine on my PDP-8e, so we have some more debugging to do.

1/31/24

We tried to run Spacewar!. It didn't display any graphics, and the light pattern on the console looked unusual. We booted OS/8 from the RK05, but didn't see anything on the VT220 console. We toggled in a short program to display all characters on the console. It got stuck waiting for the first character to be transmitted. We toggled in a short program to echo characters from the VT220 keyboard back to the display. It got stuck waiting for a character to be typed.

Since both the receive and transmit serial console functions are broken, the only common part is the baud rate generator. We will look at that on Saturday.

2/24/24

The modern replacement M452 that Vince gave us failed. We put the original M452 back in and the serial console and Spacewar! runs again. The only downside is the console is back to 110 baud instead of 1200 baud. We will fix the modern M452 and put it back. 

3/2/23

We plugged Vince's M452 into the FlipChip tester and looked at the clock signals with a 'scope. We found that 1/2 of  a 74LS193 chip failed so the slowest four of the selectable baud rates will not work. We selected a faster baud rate, and will get a replacement for the chip.

To Do:

Fix the issue where pressing the LS button does not copy all of the bits from the left switches to the PC.

Test the TC12 & TU56 to see if the RF interference that we observed in the other building is not present and LAPS-DIAL will boot

Move the modified Spacewar! that supports the game controllers onto the RK05 disk pack. (Done 3/18/23)

Find a copy of Pong (PING) and copy it to the RK05 disk pack

Modify Pong to use the game controllers instead of the analog knobs

Fix the bit-11 indicator for the MQ register. The bulb is OK.