What did I do to my PDP-8 today.

[thunter0512]

Thanks Vince and Paul.

Followup question - is there an equivalent to the SP384N (or SP384A) OR bus receiver?

It is used for example on the G111 Sense/Inhibit board.

Thanks
Tom

 

[ftcnet]

According to NSN, equivalent replacements are: DEC384A, DEC384, 1909486, 191039400, 19-10394-00, 1910394, 19-10394, 1909486, 19-09486, DEC5384, SP384N14, SP384N-14, SP384N, SP384A, 4200050, 420-005-0, 5962-00-407-4530, 00-407-4530, 5962004074530, 004074530
Part numbers starting with 19 are the DEC-assigned part numbers, but I don't recognize the ones in italics.
An eBay seller in Greece has some with corroded leads, but I suspect there aren't many other sources other than salvaging them from scrap PDP8 modules.

 

[thunter0512]

Today my recently acquired PDP-8/e developed a new fault.
Most control switches on the front panel no longer worked except for Halt, Step and SW.
All data switches appeared to work.
Armed with schematics, maintenance manual and oscilloscope I tracked it down to what looked like a faulty PNP transistor Q15 (DEC6534D).
I tried to rescue the transistor but DEC's annoying bent lead technique to hold them in place during soldering defeated my vacuum desoldering station so I cut the 3 leads and removed them one by one.
I had no DEC6534D but used instead a PN200 general purpose PNP transistor with similar enough characteristics.
The front panel works again perfectly after replacing Q15.

 

[Roland Huisman]

Good job! When I got my pdp8/f it worked after cleaning and a bit of the standard tlc. After that it failed four times again, every time something else. I ending up replacing 4 ttl chips. Now it works stable in the few years that I've got the machine. But Restoring an old machine now will not mean that it will work for ever... I have had tested and working spares, and when I needed it guess what... It broke down while sitting in an esd bag... So this old stuff will keep you busy

 

[thunter0512]

Good job! When I got my pdp8/f it worked after cleaning and a bit of the standard tlc. After that it failed four times again, every time something else. I ending up replacing 4 ttl chips. Now it works stable in the few years that I've got the machine. But Restoring an old machine now will not mean that it will work for ever... I have had tested and working spares, and when I needed it guess what... It broke down while sitting in an esd bag... So this old stuff will keep you busy

Thanks Roland.
A big part of the enjoyment I get out of the PDP-8/e and LAB-8/e is that I can fix them.
Sometimes parts availability can be challenging, but over the past two years I have learned where to find what I need.
BTW your M847 Universal Bootloader is an essential component for any PDP-8/e.
It is really really really helpful and I use it all the time even when the software is already in core.

 

[DougIngraham]

I fired up the Straight 8 to check the timing for the Console Serial Disk and it hasn't fixed it self. I toggled in the program. The load key likes to go into run mode every so often. Deposit likes to do double deposits and then the program produced questionable output once. Running it a second time either a jmp didn't or an ISZ skipped when it shouldn't have. I let it cool down and tried it again. Got a similar number out of the program but it still seems like the wrong answer. A second run failed just like the previous time. I guess once I get the CSD project out in beta I might have to work on it.

I have been using the 8/e several times every day for the last couple of weeks and it is a trooper. I have a large number of boards that I need to repair for it.

 

[djg]

Deposit likes to do double deposits

Common problem when switch contacts get dirty. Can get some other strange behavior also since the edge triggers the cycle but the level is fed to logic so if it goes away strange things can happen.

 

[DougIngraham]

Yesterday I was using the 8/e to develop and test the console serial disk project. Running OS/8 over the M8655 console port (it is the only peripheral in the machine) for several hours I got to a point where I needed to reboot. Only it wouldn't. I switched to the previous days code thinking I must have blown my system by accident and that didn't work either. It was getting stuck waiting for the server to send it the next byte of the boot record, a KSF; JMP .-1 loop. So either the M8655 is malfunctioning or the USB RS-232 dongle on the Rasp Pi has stopped sending. Probably a heat issue as it was pretty hot yesterday and the AC was not keeping up in that portion of the basement shop.

Getting that going again is the next thing to work on.

 

[DougIngraham]

Tried it a few minutes ago when everything is cool and it booted just fine. Almost certainly a heat related issue. Hopefully it is the M8655 and not something in the CPU as the top blocks in the CPU make it a little more difficult to look at signals.

 

[vrs42]

I've been trying to set up an HP1630G to look at the Omnibus. There's a fancy new memory/boot loader under there with a serial port implementation (the Atmel programmer's ribbon cable goes there). Boot and memory work fine, but not so much the serial port.

Alas, I'm out of pods on the analyzer, so I'll have to remap the pins to use every single available input. I also need to add a proper clock, so that the analyzer will actually take the samples at reasonable intervals. (Probably means a chip needs to be added to the protoype board to OR the TPn signals.)

Vince

 

[thunter0512]

You probably don't need all of the Omnibus signals to debug a particular event but get away with a small subset because you know what is happening on the remaining bus signals when running a small program to exercise the serial implementation.

 

[vrs42]

You probably don't need all of the Omnibus signals to debug a particular event but get away with a small subset because you know what is happening on the remaining bus signals when running a small program to exercise the serial implementation.

There are three designs I need to debug, which all use the same board and CPLD pin-out. The serial is fairly simple, but the extended memory control uses all 64 of the CPLD pins. I'd like to get to a single setup with the cabling and the logic alanyzer programming the same for all three, since it seems likely that I'll be debugging for a while.

Also, the serial interface is interfering somehow with the Serialdisk boot (though echo tests, and such seem to work), so I've not yet been able to identify a small test case.

Vince

 

[thunter0512]

There are three designs I need to debug, which all use the same board and CPLD pin-out. The serial is fairly simple, but the extended memory control uses all 64 of the CPLD pins. I'd like to get to a single setup with the cabling and the logic alanyzer programming the same for all three, since it seems likely that I'll be debugging for a while.

Also, the serial interface is interfering somehow with the Serialdisk boot (though echo tests, and such seem to work), so I've not yet been able to identify a small test case.

Vince

Can't you fully simulate your design using ModelSim (or similar) to avoid (or at least limit) the debugging on the bench with a logic analyser?

 

[vrs42]

Can't you fully simulate your design using ModelSim (or similar) to avoid (or at least limit) the debugging on the bench with a logic analyser?

Possibly. However, doing that implies a learning curve for ModelSim, and presumes that I also fully understand how to model the Omnibus. My previous experience with ModelSim was that it was easy for me to get models to simulate, but hard to get models that actually ran on the hardware. I can only assume meant I somehow understood the hardware imperfectly.

The hardware seems to work in the simplified cases I've tried, which are similar to what I'd have done in a simulation. But doesn't work in the real system boot, so I'm setting up the logic analyzer. I hope to be able to reconfigure, collect some data, and maybe even gain an insight this weekend.

Vince

 

[thunter0512]

Possibly. However, doing that implies a learning curve for ModelSim, and presumes that I also fully understand how to model the Omnibus. My previous experience with ModelSim was that it was easy for me to get models to simulate, but hard to get models that actually ran on the hardware. I can only assume meant I somehow understood the hardware imperfectly.

The hardware seems to work in the simplified cases I've tried, which are similar to what I'd have done in a simulation. But doesn't work in the real system boot, so I'm setting up the logic analyzer. I hope to be able to reconfigure, collect some data, and maybe even gain an insight this weekend.

Vince

If you have implemented your design in VHDL, then I would be interested in seeing the code.

 

[vrs42]

If you have implemented your design in VHDL, then I would be interested in seeing the code.

It's Verilog, as extracted from a TTL schematic. I can send it to you if you're still interested.

Vince

 

[thunter0512]

It's Verilog, as extracted from a TTL schematic. I can send it to you if you're still interested.

Vince

I have used VHDL for reasonably complex stuff before but ignored Verilog as it was more limited back when I started with FPGAs. Clearly Verilog has improved a lot since but as VHDL works well for me so I felt there is no point in learning yet another language doing the same.

You wrote that you have implemented the TTL schematic verbatim. While this should guarantee identical behaviour, it probably doesn't because CPLDs and FPGAs have different timings and the synthesis tools optimise the logic so your timing may not be what you are hoping for. I had very good success expressing logic at a high level of abstraction including various nice IEEE packages and letting the synthesis tool do its magic aided by specifying proper timing constraints.

Nevertheless, could you please email me your Verilog implementation.

 

[thunter0512]

Today I received a package from JLCPCB with some nice 3D printed parts. Here is a photo with a sample:



These parts have been printed by JLCPCB using a process called MJF using PA12-HP Nylon. The two PDP-8/e switch levers are natural grey and Vince's nice DEC panel bracket is dyed black.
The front switch lever is Vince's design with integral pivot pins (switch-vrs.stl) and the rear switch lever is Doug's design with through-hole instead of pivot pins (Doug_paddle_25_86.stl).
These Nylon parts are beautiful and are very strong. The most fragile part would be the pivot pins, but I couldn't break it when I tried.

I previously printed the bracket in ABS on my Creality Ender 5. The part looked fine after some Acetone smoothing, but the two pins broke off after short period of use. I didn't bother trying the switch levers because I didn't expect it to be strong enough.

After seeing the quality and the strength of the JLCPCB printed parts I am thinking of selling my Creality Ender 5. It is just an expensive toy and only suitable for printing toys which don't require much strength. The Ender 5 was a waste of money. Given the low volumes I occasionally need it makes much more sense to get parts printed professionally than trying to do it myself - even if I could approximate the quality and strength - which I cannot.

 

[gwiley]

These parts have been printed by JLCPCB using a process called MJF using PA12-HP Nylon. The two PDP-8/e switch levers are natural grey...

Our minds are on the same track. I also ordered switch handles fabricated in the same PA12-HP Nylon. The first batch was grey because it seemed it would contrast better with the black plexi panel. I learned that the "natural grey" seemed to absorb a slight amount of grease from my fingers. Perhaps I shouldn't eat lunch while operating my 8/E, haha. In that first order of switches, JLC by mistake made one of the switches black, which was kind of interesting for me. The second batch, which I just received recently, are all in black PA12-HP Nylon.

Notice the Load Addr switch which gets a lot of use is starting to change color a little.

The front switch lever is Vince's design with integral pivot pins (switch-vrs.stl) and the rear switch lever is Doug's design with through-hole instead of pivot pins (Doug_paddle_25_86.stl).
These Nylon parts are beautiful and are very strong. The most fragile part would be the pivot pins, but I couldn't break it when I tried.

I agree, the Nylon is very strong. Both the grey and black handles that I had built are Vince's design with the nylon pins. The switches have gotten a lot of use because I don't yet have a bootloader board.

Given the low volumes I occasionally need it makes much more sense to get parts printed professionally than trying to do it myself - even if I could approximate the quality and strength - which I cannot.

I agree completely. My goal is to have the printed part rather than tinkering with the 3D printing process, so it's nice to have someone else be concerned with process control and quality.

 

[jackrubin]

Thanks for being pioneers on this trail - what did the parts cost?