gwiley
Experienced Member
Maybe you can scavenge the spring from a modern fuse cap so your fuse cap can look authentic/vintage
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
What did I do to my PDP-8 today.
- Thread starter DougIngraham
- Start date
DougIngraham
Veteran Member
Certainly I will find some solution that will look authentic.
The spring looks like copper but copper would make a terrible spring. It might be copper plated but whatever the original material it has lost its temper. Nothing looks like it got hot, certainly not hot enough to change the materials in this way. The spring was never designed to be the principal current carrier.
When working on these things you have to remind yourself that they are around 50 years old and there was never any expectation that they would still be operable, much less in use at that age.
jackrubin
Veteran Member
The gray fuseholder was actually an ECO to replace the original part, which was failing because of overloading. Someone a bit more obsessive can go back and dig out the actual part numbers and upgrade order.
DEC seemed to have an ongoing challenge making reliable power supplies. It seems your 8/E does have the above ECO since it has a gray +5V fuse. Does this 8/E have two Omnibuses? with core memory?
Are the MATE'N-LOK connectors showing any signs of discoloration on the +5V wires? Reworking with gold-plated pins and sockets to reduce the resistance or applying DeOxit D5 to those contacts can help.
vrs42
Veteran Member
Both Mouser and Digikey claim to have 03420025Z in stock:
Not cheap though. Might be easier to look for an appropriate spring.
Not cheap though. Might be easier to look for an appropriate spring.
DougIngraham
Veteran Member
Yes and no. The rear one might have been added later as it had the wrong connector on the power cable and someone broke off the retaining clip so it could be plugged in. I have been using it with just the front backplane because of this.
16k with 2 sets of 8k core. Plenty of slots free for the time being.
No signs of heating or high resistance in the contacts. I measured the voltage drop from supply cap to bus pin when I first brought it up and it was not excessive.
I see what you mean. $22 before adding in the shipping costs.
Since it is working now I will probably wait for it to drop out again and then see if I can pull the spring out without breaking anything. It may be that I can just tug on the spring to extend it back to its original working length. If I break it then maybe the $22 for a new cap would be worth it.
jackrubin
Veteran Member
Seems like DEC under-rated the fuse holder here - 5V output is rated at 20A but F200 in the power supply circuit is 25A. Even the replacement fuse holder is only rated at 20A, so no margin. You can also get a 30A fuse holder in the same series (but black, not gray). If you're spending the money, you might also consider a panel mount circuit breaker (for about one-quarter of the price).
Last edited:
SpaceHobo
Experienced Member
Not physical hardware yet, but I did get Usagi Electric's "HELLORLD!" meme running under Vince's branch of SIMH for the PDP-12.
Here's my code, along with a Makefile that will check out vrs42's tools and run them.
It was my first time diving over into the LINC side of the 12, and I was somewhat surprised to see that the DSC instruction I used pre-incremented the "register" I had pointed it to for indirect loading of the pixel-pattern words. I'm still reading the PDP-12 handbook and trying to work out where that's explained, as the section on the scope instructions assumes a bit more LINC experience by the time you get there.
I'm hoping to see this running on the UMD 12 some time this week, via video!
Here's my code, along with a Makefile that will check out vrs42's tools and run them.
It was my first time diving over into the LINC side of the 12, and I was somewhat surprised to see that the DSC instruction I used pre-incremented the "register" I had pointed it to for indirect loading of the pixel-pattern words. I'm still reading the PDP-12 handbook and trying to work out where that's explained, as the section on the scope instructions assumes a bit more LINC experience by the time you get there.
I'm hoping to see this running on the UMD 12 some time this week, via video!
DougIngraham
Veteran Member
The increment before use is the same with the auto increment registers and the three cycle data break operations on the 8. It is one of those things that is essentially free to do in the hardware because of the way core memory works. Core memory is destructive read. The bits get cleared in the case of DEC's implementation. Core memory operations are always read/possible modify/write. Writes need the clear bits part of the read because it isn't so much a write as an IOR with the existing contents. If you want to use a memory location as an auto incrementing index into memory without a holding register then you are
going to get a pre-increment.
I have not studied the LINC much either but it stands to reason that the auto increment would work the same way for the same reasons. Here is a pseudo code of the three phases of the auto increment memory operation. MB is the Memory Buffer register, MA is the Memory Address register.
- MB <- MEMORY[MA]; MEMORY[MA] <- 0
- MB <- MB+1
- MEMORY[MA] <- MEMORY[MA] | MB
Hope that clarifies the why.
vrs42
Veteran Member
Exciting! It took some time to get the LINC addressing modes figured out, and half-word indexing is a thing to behold.
Even more so as, while it did pass the CPU diagnostics at one point, the code isn't quite what I would call ready for prime time.
Thanks for trying it! Let me know if(when) you find bugs.
SpaceHobo
Experienced Member
So far the only bug I ran into is that the build system doesn't know to pull in the SDL library paths properly if you just make pdp12 by itself: I have to make pdp1 first so it sets up the build environment for the 1's scope, and then the 12 builds fine! Not something you hit if you just build all of simh at a go, but I didn't want to wait for VAXen or CDC machines to finish just to print a silly message...
Thanks again for putting so much work into this!
vrs42
Veteran Member
A quick note -- I checked out your code, and did 'make' then 'make test'. The make test hung in the PDP-12 build. I believe the pdp12.ini is keeping the SIMH register test from completing correctly.
I renamed pdp12.ini, finished the 'make test', then quit out of SIMH, renamed pdp12.ini back, and now 'make test' skips the SIMH build (as it is complete), and displays the "HELLORLD" text.
Very cool.
I renamed pdp12.ini, finished the 'make test', then quit out of SIMH, renamed pdp12.ini back, and now 'make test' skips the SIMH build (as it is complete), and displays the "HELLORLD" text.
Very cool.
SpaceHobo
Experienced Member
Ah, good point! It never tripped me up for some reason, but I should probably name it hellorld.ini or something, and specify it more explicitly on that command line in the Makefile.
Apologies for the strain this could put on your Subversion server: you've got about 400MB of PDFs in there you seemed to use for generating your tests, and everyone who does make test will download them!
SpaceHobo
Experienced Member
Ah yeah, this makes sense! I did finally find the bit explaining that the "I" in LINC instructions is "index" addressing through the "low sixteen" that works like the autoincrement 001X addresses on the 8 side. I had read it like the PDP-8's bare "indirect" mode!
It's only slightly confusing that the text uses an italic β in the proportional text, but a B in fixed-width text. Anyway, I'm going to have to read a lot more about LINC assembler, as I haven't found a good body of code to study like the Cookbook for the 8.
pbirkel@gmail.com
Veteran Member
I confess to not having heard of this "cookbook". So I looked for it, or at least one, online. For future reference, I found this:
SpaceHobo
Experienced Member
I also have this document, where I spent a while writing up a sort of hasty exegesis for the thing: https://zork.net/pdp8-cookbook/cookbook.html
Bonus: if you have your OS/browser set to "light mode" it's in PDP-8 livery, and if you have "dark mode" it's PDP-12 colours!
vrs42
Veteran Member
Very cool!
Two small quibbles so far...
1) The segment where instructions are presented to load values includes several model-specific instructions/values. These should perhaps be discouraged, or at least not included here.
2) Right after you mention 8tools in the sidebar (Thanks! The 8tools cross-assembler can also assemble PDP-12 LINC instructions.), you have a pointer to simh/simh. Should that be updated to point to open-simh/simh?
SpaceHobo
Experienced Member
Which section is this, and which instructions? I mentioned in the PDP-8 Instructions section that the text was from the PDP-12 documentation. I'm happy to add some sidebar notes with a warning about particular entries, and pointing readers to an overview of the differences if you have such a page available.
Oh, another good catch! I'll update that shortly.
vrs42
Veteran Member
"Quick Constant Instructions" includes some examples with IAC combined with RAL/RTL/RTR. Those will work with most models and the PDP-12, but not on the LINC-8 or the straight-8.
Also, the PDP-5 and the 8/S can't even CMA rotate. (I'll have to research whether they could CML rotate, but I suspect not.) It might be OK to ignore those two in a beginner's document, though. They aren't considered "family of 8", but the straight-8 is.
vrs42
Veteran Member
Just before where auto-indexing is explained:
Makes it sound like the DCA has something to do with why we know LINK is clear. That's not why LINK is clear, and actually I don't believe we care about LINK here. Perhaps
Code:
WE do the same thing for the output buffer, but since we recently did a DCA we know
we don’t need to CLL: the LINK is already 0.
Code:
WE do the same thing for the output buffer, but since we recently did a DCA we know
we don’t need to CLA: the AC is already 0.