• Please review our updated Terms and Rules here

What did I do to my PDP-8 today.

I have taken some very simple parts to close the lid of a pdp8/e. I've the TU-56 in the rack above the 8/e and there is very less room between. So the lid must be closed very exact to get the 8/e into the rack.

IMG_7413.JPG

IMG_7414.JPG

AMAZON Germany
 
That is a clever repair! What does the attachment to the power supply look like under then handle? They don't show that detail on the Amazon page.

I am still planning on trying to 3D model something that looks like the original now that I know what the original looks like.

Did you replace the foam on the inside top of the cover? If so what did you use?
 
here one foto from both sides. I had to drill a hole very near to the edge, even more near.... Und for the front 2 washers to bring it in the right position. Also I had to shorten the plastic part at the lid for about half or one mm, so that it is slightly less high.

IMG_7423.jpg

There may be better parts for this, it was my first attempt to fit this.

Have fun,
Volker
 
Gee.... that is pretty nice. My PDP8E has one latch that once in a while will work and the other is completely useless. I think that I'll start to look around for some clips that might work. Thanks for the idea, Mike
 
These latches are rather simple. I suspect that anyone that is proficient with 3D printing probably could make a bunch of them. Seems that the movable part, where it hinges is where mine has broken. Most likely from being latched and unlatched so much. Mike
 

Attachments

  • CaseLatchS1.JPG
    CaseLatchS1.JPG
    113.4 KB · Views: 12
  • CaseLatchS2.JPG
    CaseLatchS2.JPG
    123.4 KB · Views: 13
My son 3D prints in kevlar and carbon fibre! The machines are somewhat expensive though...

3D metal printing is also possible - but not for the amateur.

Dave
 
Most 3D printers with special (read harder material) extruder nozzles can print filament infused with carbon fiber. I have seen PLA, PETG, ABS and ASA filament with carbon fiber in it.

Many companies sell hardened or ruby nozzles.

That might be as strong as pure carbon fiber but I don't think that is needed for for this application. Regular ABS or even PETG should suffice.
 
JLCPCB has a pretty good assortment of materials for printing parts. There are some metallic options, too.

Could print prototypes in plastic at home, and when the design is confirmed, send it out to be printed (or machined) in a durable material.
 
As Paul alluded to, polypropylene is the plastic commonly used for living hinges, they don't like being stressed sideways as they tear along the hinge. Plastic lunchboxes are a prime example of this.
I think Mike's broken over-centre latch might be repairable with some polypropylene sheet and kevlar binding, but am wondering are these latches no longer made?
 
I have been keying up the assembly for maindec-8e-d0ab from the documentation that has been scanned in. This is instruction test 1 for the 8/e processor. I have been taking notes for the handful of spots where I have found bugs in the program. I've also been keeping track of comments that don't exactly match the piece of code they are documenting. This is a pretty clever bit of code that tests aspects of the processor and then uses what works to test more things.

I want to add this to the Console Serial Disk project but I need a version that does not have any HLT instructions. The instruction test 1 program is a linear sequence of instructions where conditional skips are the only branch instructions. The skips when taken skip over HLT instructions. When you run the test, if it halts, you look at the address and then look at the listing to see what exactly failed. I will probably change this behavior such that all the HLT instructions become JMS to a subroutine that prints the calling address on the console and then returns to OS/8. It seems like you could also print a message describing the error but the program uses most of field 0 and there is no space left to do this adequately.

I need a way to verify that the binary I am producing with my assembly matches the DEC produced binary so I wrote a C program to convert a binary to a list of octal address/values which I can use diff to compare and then go fix my code when there is an error. It currently doesn't handle field changes but I don't need that for this project.

There is also a long term goal to compare this program to maindec-8e-d0aa and generate the source for that since it appears to have been lost to time. And I can fix the bugs that I have identified and generate a new version maindec-8e-d0ac-pb some 51 years after the last official DEC version.
 
...
I need a way to verify that the binary I am producing with my assembly matches the DEC produced binary so I wrote a C program to convert a binary to a list of octal address/values which I can use diff to compare and then go fix my code when there is an error. It currently doesn't handle field changes but I don't need that for this project.
...
Try BeyondCompare from Scooter Software as it does a great job of diff-ing anything including binaries. It has a free 30 day trial and if you like it there is a one-time license fee of $35 for the license keys. It runs on Windows, macOS, and Linux. I have been using it for many years.
 
Try BeyondCompare from Scooter Software as it does a great job of diff-ing anything including binaries. It has a free 30 day trial and if you like it there is a one-time license fee of $35 for the license keys. It runs on Windows, macOS, and Linux. I have been using it for many years.
The problem is not in finding a difference in the binaries, it was knowing where in the source I made a mistake. For that having human readable address/value pairs is important. Once I had readable files to compare, Unix diff works perfectly.
 
The problem is not in finding a difference in the binaries, it was knowing where in the source I made a mistake. For that having human readable address/value pairs is important. Once I had readable files to compare, Unix diff works perfectly.

Here's something I generated a while back for testing my verilog PDP-8 design. Reads a PDP-8 binary and generates a location/value assignment and a disassembly.
Example:
Code:
    // File: ../../../../MAINDEC_software/KK8-E_pdp8e_cpu/MAINDEC-8E-D0AB-PB.bin; Status: CHKSUM: Computed: 1504, input: 1504 -- PASS
    //
    memory[15'o00000] = 12'o0000;    // AND 0        ea=00000
    memory[15'o00001] = 12'o5001;    // JMP 1        ea=00001
    memory[15'o00002] = 12'o0002;    // AND 2        ea=00002
    memory[15'o00003] = 12'o0003;    // AND 3        ea=00003
    memory[15'o00004] = 12'o0000;    // AND 0        ea=00000
    memory[15'o00005] = 12'o0000;    // AND 0        ea=00000
    memory[15'o00006] = 12'o7402;    // HLT
    memory[15'o00007] = 12'o7000;    // NOP
    memory[15'o00010] = 12'o0000;    // AND 0        ea=00000
    memory[15'o00020] = 12'o0000;    // AND 0        ea=00000
    memory[15'o00021] = 12'o0001;    // AND 1        ea=00001
    memory[15'o00022] = 12'o0002;    // AND 2        ea=00002
    memory[15'o00023] = 12'o0003;    // AND 3        ea=00003
    memory[15'o00024] = 12'o0004;    // AND 4        ea=00004
    memory[15'o00025] = 12'o0006;    // AND 6        ea=00006
    memory[15'o00026] = 12'o0010;    // AND 10       ea=00010
    memory[15'o00027] = 12'o0014;    // AND 14
    memory[15'o00030] = 12'o0020;    // AND 20       ea=00020
    memory[15'o00031] = 12'o0030;    // AND 30       ea=00030
    memory[15'o00032] = 12'o0040;    // AND 40       ea=00040
    memory[15'o00033] = 12'o0060;    // AND 60       ea=00060
    memory[15'o00034] = 12'o0100;    // AND 100      ea=00100
    memory[15'o00035] = 12'o0140;    // AND 140
    memory[15'o00036] = 12'o0200;    // AND 0        ea=00000
    memory[15'o00037] = 12'o0300;    // AND 100      ea=00100
    memory[15'o00040] = 12'o0400;    // AND I 0      ea=00000
    memory[15'o00041] = 12'o0600;    // AND I 0      ea=00000
    memory[15'o00042] = 12'o1000;    // TAD 0        ea=00000
    memory[15'o00043] = 12'o1234;    // TAD 34       ea=00034
    memory[15'o00044] = 12'o1400;    // TAD I 0      ea=00000
    memory[15'o00045] = 12'o2000;    // ISZ 0        ea=00000
    memory[15'o00046] = 12'o3000;    // DCA 0        ea=00000
    memory[15'o00047] = 12'o3312;    // DCA 112      ea=00112
    memory[15'o00050] = 12'o4000;    // JMS 0        ea=00000
    memory[15'o00051] = 12'o7717;    // 7717
    memory[15'o00052] = 12'o7776;    // SPA SNA SZL CLA OSR HLT
    memory[15'o00053] = 12'o7775;    // 7775
    memory[15'o00054] = 12'o7773;    // 7773
    memory[15'o00055] = 12'o7767;    // 7767
    memory[15'o00056] = 12'o7757;    // 7757
    memory[15'o00057] = 12'o7737;    // 7737
    memory[15'o00060] = 12'o7177;    // CLL CMA CML IAC
    memory[15'o00061] = 12'o7677;    // 7677
    memory[15'o00062] = 12'o7577;    // 7577
    memory[15'o00063] = 12'o7377;    // CLA CLL CMA CML IAC
    memory[15'o00064] = 12'o6777;    // IOT 77,7
    memory[15'o00065] = 12'o5777;    // JMP I 177    ea=07410
    memory[15'o00066] = 12'o3777;    // DCA I 177    ea=07410
    memory[15'o00067] = 12'o7777;    // 7777
    memory[15'o00070] = 12'o5252;    // JMP 52       ea=00052
    memory[15'o00071] = 12'o2525;    // ISZ I 125
    memory[15'o00072] = 12'o6000;    // IOT 00,0
    memory[15'o00073] = 12'o7000;    // NOP
    memory[15'o00074] = 12'o7400;    // 7400
    memory[15'o00075] = 12'o7600;    // CLA
    memory[15'o00076] = 12'o7740;    // SMA SZA CLA
    memory[15'o00077] = 12'o7760;    // SMA SZA SNL CLA
    memory[15'o00100] = 12'o7770;    // SPA SNA SZL CLA
    memory[15'o00101] = 12'o7774;    // SPA SNA SZL CLA OSR
    memory[15'o00102] = 12'o0007;    // AND 7        ea=00007
    memory[15'o00103] = 12'o0067;    // AND 67       ea=00067
    memory[15'o00104] = 12'o0017;    // AND 17
    memory[15'o00105] = 12'o0037;    // AND 37       ea=00037
    memory[15'o00106] = 12'o0077;    // AND 77       ea=00077
    memory[15'o00107] = 12'o0177;    // AND 177      ea=00177
    memory[15'o00110] = 12'o0377;    // AND 177      ea=00177
    memory[15'o00111] = 12'o0777;    // AND I 177    ea=07410
    memory[15'o00112] = 12'o1777;    // TAD I 177    ea=07410
    memory[15'o00113] = 12'o7700;    // SMA CLA
    memory[15'o00114] = 12'o5225;    // JMP 25       ea=00025
    memory[15'o00115] = 12'o2552;    // ISZ I 152    ea=07440
    memory[15'o00116] = 12'o0770;    // AND I 170    ea=07440
    memory[15'o00117] = 12'o7007;    // IAC RTL
    memory[15'o00120] = 12'o0207;    // AND 7        ea=00007
    memory[15'o00121] = 12'o5140;    // JMP 140
    memory[15'o00122] = 12'o5140;    // JMP 140
    memory[15'o00144] = 12'o1067;    // TAD 67       ea=00067
    memory[15'o00145] = 12'o7200;    // CLA
    memory[15'o00146] = 12'o7402;    // HLT
    memory[15'o00147] = 12'o7410;    // SKP
    memory[15'o00150] = 12'o7402;    // HLT
    memory[15'o00151] = 12'o7200;    // CLA
    memory[15'o00152] = 12'o7440;    // SZA
    memory[15'o00153] = 12'o7402;    // HLT
    memory[15'o00154] = 12'o7450;    // SNA
    memory[15'o00155] = 12'o7410;    // SKP
    memory[15'o00156] = 12'o7402;    // HLT
    memory[15'o00157] = 12'o7200;    // CLA
    memory[15'o00160] = 12'o1050;    // TAD 50       ea=00050
    memory[15'o00161] = 12'o7440;    // SZA
    memory[15'o00162] = 12'o7410;    // SKP
    memory[15'o00163] = 12'o7402;    // HLT
    memory[15'o00164] = 12'o7450;    // SNA
    memory[15'o00165] = 12'o7402;    // HLT
    memory[15'o00166] = 12'o7200;    // CLA
    memory[15'o00167] = 12'o1045;    // TAD 45       ea=00045
    memory[15'o00170] = 12'o7440;    // SZA
    memory[15'o00171] = 12'o7410;    // SKP
    memory[15'o00172] = 12'o7402;    // HLT
    memory[15'o00173] = 12'o7450;    // SNA
    memory[15'o00174] = 12'o7402;    // HLT
    memory[15'o00175] = 12'o7000;    // NOP
    memory[15'o00176] = 12'o7000;    // NOP
    memory[15'o00177] = 12'o7410;    // SKP
    memory[15'o00200] = 12'o5144;    // JMP 144      ea=00144
    memory[15'o00201] = 12'o7200;    // CLA
    memory[15'o00202] = 12'o1042;    // TAD 42       ea=00042
    memory[15'o00203] = 12'o7440;    // SZA
    etc

Attached is the entire diagnostic dump/disassemlby zip'ed.
 

Attachments

  • meminit_d0ab.zip
    11.8 KB · Views: 0
I need a way to verify that the binary I am producing with my assembly matches the DEC produced binary so I wrote a C program to convert a binary to a list of octal address/values which I can use diff to compare and then go fix my code when there is an error. It currently doesn't handle field changes but I don't need that for this project.
I frequently use Makefile rules like this one:
Code:
%.bin:  %.pal
        pal -d $<
        bincmp $@ $(<:.pal=.ok) || rm -f $@
which cross assembles a .pal file, then compares the .bin to the .ok, so that I can tell if errors persist (or have been introduced), The output of bincmp are lines of the form:
aaaaa: xxxx != yyyy
where aaaaa is an address, xxxx is the value from the first file, and yyyy is the value from the second. If only one file had a value at that address, "XXXX" is displayed instead of xxxx or yyyy.
 
Last edited:
Been a while since last writeup so a little long.

Been supporting the local museums. The VCF straight 8 was acting up again. Found it didn't want to jump. Poking around the load MA to PC 5-11 signal wasn't getting to the PC card. R603 pulse amp in PD20 was the cause. Seemed to be bad transistor this time. Swapped in a spare I brought. Will fix card later.

Left over problem from initial restoration was the machine would go into run on power on sometimes. Found power good was getting set when voltages were only 65% of proper level. Two cards in the power supply generate the ok with wired or. The G809 for the -15 wasn't operating properly. Traced it to one of the transistors in a differential pair used as comparator. It was a DEC2894-3B. Their are at least 6 different dash numbers of 2894. Replaced it with a 2B but then always said power not good. Apparently the dash numbers are important in some cases. Fudged it for now by paralleling a resistor with one of the divider resistors to shift the threshold. I will need to match two 2894's and replace both at some time.
Power up run fixed and seemed to survive some power cycles without corrupting running program.

I was reminded near the end that they had crashes if backplanes moved. Verified it occurs but too late to mess with so it will wait till another time. Likely backplane contacts need cleaning again. Its been 8 years since initial restoration. Computer was stored in damp environment so I had problems with contacts during restoration. Other remaining problem is front panel flaky from switch bounce. Have cleaned best can with spray cleaner a couple times. Fixes for a while but comes back. Mine same though not a bad. Since the switches are custom for the rocker handles don't know where to get replacement. Will look into making inline debouncer for the cable.

After a previous workshop at System Source Museum I had taken home the high speed reader card to fix. I had fixed it. Went to make some tapes on my 8/I for them to use and found my punch wasn't punching one of the bits. Traced it to a transistor on the M040. Failure was the transistor lead was broken. Another broke when removing transistor. Strange thing was it wasn't at the bend but in the middle of the straight portion. It wasn't corrosion. Hadn't see that before. Made Focal 69 with some games and music tape.

Was able to load some short tapes on System Source 8/I but reader wasn't working well. Since visit was for working on LINC we didn't try to adjust the reader this time.

I'll make BASIC tape also. Anybody have idea of non game programs that general public would understand and can be demoed in reasonable time? Right now its 8k 8/I with high speed paper tape and teletype. DECtapes not yet restored.

Real purpose of the trip was to work on the LINC (no 8 in this one but still 12 bits). Power supply had failed a while ago while I was trying to adjust the LINCtapes. Cause was AC capacitor shorted on transformer. When they opened it up to fix other capacitors were leaking. They replaced all suspect parts but supply still not working. The regulated voltages weren't working. Found that parts list was wrong and when they replaced two transistors wrong part was used. NPN instead of PNP. Put proper transistor in -15 but still didn't work. Appeared power sequence card was turning it off. Card didn't match layout in prints. Traced signals and found bad transistor. Possibly killed by wrong transisor. -15 now worked but couldn't trim to -15V. Replacing wrong transistor on +10 card got it working. -3V is shunt regulator with voltage externally supplied. Hooked up a supply with pass resistor but it didn't regulate properly. Out of time. Will be going back for the workshop they are having this weekend to finish this repair and 8/I. At home marked up photo of power sequence card with reference designators to make troubleshooting easier. It regulates the -3V also. Also created spice models of the regulators with problems to hopefully have reference on what expected voltages are at the various nodes. I'm slow doing that by hand. That did verify that there was an error in one of the schematics.
 
Here's something I generated a while back for testing my verilog PDP-8 design. Reads a PDP-8 binary and generates a location/value assignment and a disassembly.
Nice. I didn't think about doing the disassembly although it would have been easy as I have a subroutine in my emulator that does it for trace dumps. The emulator can load binaries but it does so by running the real bin loader code.
 
I frequently use Makefile rules like this one:
I suppose I could make a Makefile but so far I have just been doing it with up arrow to get past shell commands.
Code:
$ vi maindec-8e-d0ab.pal
$ pal maindec-8e-d0ab.pal
$ decodebin maindec-8e-d0ab.bin >temp.decode
$ diff maindec-8e-d0ab-pb.decode temp.decode | less
I do that about once every half hour when I take a break from studying/understanding/typing what they were trying to do with this diagnostic.
 
Back
Top