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/24

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.

11/13/24

We replaced the defective Memory Address bit-8 lamp with a recently donated real Oshino OL-1 lamp. We even used a DEC lamp installation tool for the job. It is working again.

We loaded OS/2 from the RK05. We entered the DIR command and it halted at Memory Address 17726 that contained 7602. The instruction is a CLA & HLT which explains why it halted. We think that the instruction should be just a CLA (7700). We either picked up a bit in memory or the disk image is corrupted. We examined location 17726 and it does contain the 7602 instruction. We replaced the 7602 instruction with 7600 and now OS/8 doesn't halt when you enter a command.

We tried to load various versions of Spacewar!. The original version would run, but not the latest. SNOOPY ran OK, and returned to OS/8 with a ^C. We tried to assemble SPCWR3.PA, but the assembler halted without creating files.

MAINDEC-12-D8CD KW12A Clock Test halted a 5034 and printed the messages "TST74 O'FLO WON'T FAST SAM, 7060 7057. We forgot to set Analog knobs 0 & 1 to the correct positions. After a restart it ran OK.

We loaded and ran:

11/16/24

It looks like the RK05 drive/pack is failing. We need to determine if it is a hardware, read/write head/ or pack problem. The pack looks clean and there is no aluminum showing. That is a good thing because replacement RK05 read/write heads are difficult to find.

We had an RX01 with a bootable OS/8 image built for a PDP-12 including serialdisk support. We booted from the RK05 and used the OS/8 BOOT command to boot from the RX01. We then created a new diskette and copied the binary and source to the modified SPCWR3 program to the diskette from the RK05 image using serialdisk. Then we use the OS/8 command R ABSLDR SPCWR3.BN/G to load and run Spacewar!. We are now all set for when the Providence Geeks visit on Wednesday.

We need to put a scratch pack in the RK05 and run diagnostics to see if the controller, drive, and pack are all OK.

2/19/25

We demonstated Spacewar! to visitors. It ran for a few minutes and then halted. Pressing the CONT button would execute just one instruction. We are guessing that the RUN flip-flop is getting set, and then immediately getting cleared.

We looked through the schematic and decided that the M216 in slot L07 was the first FlipChip to test. Unfortunately the FlipChip tester would not work. The MCP23S17 IC1 had failed. We swapped it for IC5 that is not used with single wide FlipChips. The M216 tested OK using Warren's FlipChip tester. We tried the M160 FlipChip in slot K08 that feeds signals that halt the processor. That one tested OK. We tested the M117 FlipChip in slot K05. That one worked OK. We tested the M112 from slot L10. We cleaned the gold fingers when we tested the FlipChips. We tried to run Spacewar! and it ran for a few minutes and then halted. It is again stuck in the single-step mode.

We will continue debugging on Saturday.

2/22/25

Doug suggested heating the FlipChips while they were being tested. We have plenty of spare FlipChips so we will replace the suspect FlipChips with spares, one at a time, to see if we can find the broken one. We can then heat the broken FlipChip while testing to find the bad chip.

We swapped the M216 in slot L07 with a spare.

2/26/25

The M160 FlipChip in slot K08 collects many signals that can stop the processor and sends them to the RUN flip-flop. This is a likely source of failure. We swapped the M160 FlipChip in slot K08 with a repaired and tested spare. The Spacewar! program got corrupted so we toggled in a IAC, JMP .-1 loop and ran it. That worked fine and it stayed running for several minutes. We booted OS/8, loaded and ran Spacewar! We let Spacewar! run for a few minutes, and then it halted with the same broken behavior as before.

We noticed that the Auto Restart function is not working. This signal goes through the M160 in slot K08, so maybe the replacement FlipChip has failed.

We put the original failed M160 Flipchip from slot K08 in the FlipChip tester. It ran OK for several minutes, so we heated it with a hot air gun. That didn't change its behavior and it continued to test OK.

We replaced the M160 FlipChip in slot K08 with repaired and tested spare. SpaceWar! ran OK for about eight minutes and then failed in the original way.

We replaced the M160 FlipChip in slot K08 with yet another repaired and tested spare. Spacewar! has been running for about an hour so we will declare victory.

We need to determine why two different M160 FlipChips test OK, but will not run Spacewar! 

3/1/25

We ran Spacewar! to make sure that the processor was still running OK. It ran for about two minutes and then halted. Pressing CONT would execute just one instruction. We powered the system off for a few minutes and then started Spacewar! again. It ran for about 40 seconds and then halted.

We also heard the RX02 drives recalibrate a few times after it halted. We are speculating that something is intermittently resetting the machine when it shouldn't.

We got mobbed with visitors, so no more debugging. We will get back to working in it Wednesday.

3/5/25

We decided to look at the 4x input signals to the RUN flip-flop on the M216 FlipChip in slot L07. The CPR SET RUN L signal is on pin U2, the CST IO PRESET L signal is on pin K2, the CPR ENABLE RUN H signal is on pin T2, and the CPTP TP5 H signal is on pin S2.

We saw a string of pulses on CST IO PRESET L an on CPTP TP5 H for a while, but can't reproduce it. We are not seeing a pulse on on CPTP TP5 H when we press LS, so that would explain why it only executes one instruction.

We went looking for the CPTP TP* signals to see if the processor is going through all of the instruction states. We started with CPTP TP1 L and CPTP TP1 H. The TP1 signals look OK. The TP2 through TP5 signals all look OK.

We triggered on the state of the RUN flip-flop and looked at the TP5 H and ENABLE RUN H signals. When the processor halted the TP5 H signal strobed and ENABLE RUN H signal was low at the time which disabled the RUN flip-flop. This is the way the circuitry is supposed to work. Now we need to find which one of the 15 input signals to the flip-flop is doing the wrong thing.

3/8/25

We started looking at the input signals to the M360 in slot K08. The signals on pins C1, E1/F1, L1, and M1 were all high when the processor stopped. The signals on pins C1, L1, and M1 are inputs to and gates where the other signals were low, so the only signal that would cause problems is the signals on E1/F1. 

We looked at the inputs to the M117 in slot K05 on pins D2, E2, F, and H2 that drives E1/F1 on the M360 in slot K08.  The signals on pins D2 & E2 were low when the processor halted. We need to look at the source of the CST FILL STEP  (1) L, and CSI KEY SS L signals. We saw the CST FILL STEP  (1) L on pin D2 low when the processor halted.

The CST FILL STEP  (1) L signal comes from the M216 in slot M39. We looked a pins K1, L1, and M1. When the processor halted the pins were Low, High, Low. That means that the output of the M115 in slot K13 was low and set the CST FILL STEP flip-flop. 

We looked at pins N2, P2, and R2 on the M115 in slot K13. These signals all need to be high to make the output on pin S2 go low and set the flip-flop. When the processor halted the pins were Low, High, Low so the output on pin S2 should be high. We looked at S2 and it was high, so that gate looks OK.

We replaced the M216 in slot M39 with at repaired and tested spare. That didn't fix it.

We replaced the M115 in slot K13 with a repaired and tested spare. That didn't fix it.

3/15/25

We spent a lot of time chasing the signals from the console switches. We found the MCT PWD CLR L signal was erratically activating and resetting the processor. This signal comes from pin D2 on the G916 Power Detector FlipChip that monitors the +5V and -15V power supplies. We pulled the G916 FlipChip, connected to a bench power supply, varied the voltages, and evaluated the operation. It looks like this FlipChip works OK. After replacing the G916 FlipChip the problem with spurious I/O Resets stopped.

Back to why the processor will only run for a few minutes.

3/22/25

We spent a few hours chasing why we get repeated IO PRESET signals that cause the RX02 diskette drives to recalibrate. We chased the errant signal back to the MTC POWER CLEAR H signal on pin ES2 G826 REGULATOR CONTROL FlipChip in slot EF2 in the memory chassis. The G826 measures the core stack temperature and regulates the current going through the core stack by adjusting the core memory voltage.

The manual has an adjustment procedure for the POWER OK H signal. If this is misadjusted it would cause the symptoms that we are seeing, This will be the project for Wednesday.

3/26/25

We adjusted the trimpot (R2) in the middle of the G826 Power Detector FlipChip one turn clockwise to make the voltage detection less sensitive. We toggled in and ran a little program to blink the console lights. It ran fine for 10 minutes, so we loaded OS/8 and then SpaceWar!. It ran OK for 30 minutes, so we adjusted the trimpot counter-clockwise expecting the processor to halt. We got the trimpot back to the original position and the SpaceWar! is still running OK. We now think that the trimpot has a dirty spot where the adjustment is set and the resistance setting was not correct. The system should get a workout at the Providence Geeks meeting tonight.

3/29/25

SpaceWar! would only run for about a minute, and then the processor would halt. We adjusted the trimpot (R2) in the middle of the G826 Power Detector FlipChip one turn clockwise and left it there. SpaceWar! is running OK now.

4/6/25

SpaceWar! will not run. We see processor activity, but no activity on the MQ register. After some investigation it turned out to be an operator error when we loaded Spacewar! from OS/8. We fixed the instructions so it will not happen again.

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.