• Please review our updated Terms and Rules here

Building a PDP-11 from scratch

maguro said:
I was wondering, would it be remotely possible to construct PDP-11 boards from scratch? iiuc, they didn't start using custom VLSI until the VAX line, though I could definitely be totally wrong.
I'm an AMD2901 fan boy and would LOVE to start an Open Source Hardware project to reconstruct a PDP-11/44.
Click to expand...
Everything built by humans can be built by humans again... There are a few questions to be answered. How much time do you want to invest, and are you aware of the fact that such a project can get more expensive than buying a real PDP11? If such a project is just for fun and learning or a personal goal, just do it. If you want to have a cheap PDP11, think again... And where does it end? A CPU, or a 22bit bus with full blown memory and harddisk / floppy / Tape controller?

You could consider building only a CPU and use a Unibone of Qbone to emulate memory and peripherals...

Regards, Roland
 
There was some interest in the HSC50 in the distant past because it was the only MSCP device that worked with the DEC20 CI
but I don't think anyone ever found the code to make that work (and the problem of finding a the CI-20
 
saipan59 said:
Hi Paul, All of those that I mentioned have the dual-sequencer architecture. And add to the list the RC25 controller [I knew a LOT about that module 41 years ago, because I designed the Manufacturing Functional Tester for it. Most of those brain cells are gone now...]
Click to expand...
I have this vague recollection that there was some AMD literature mentioning this two-phase design approach but I can't recall where. Regardless, the dual-sequencer approach is pretty interesting.
saipan59 said:
Correction: The micro-word is 48 bits, not 64.

In the KDB50 image you reference, the six 2911 sequencers are near the lower-center.
Click to expand...
Ah, second photo (T1002 Processor); see them now :->. Forgot that they were 0.3" parts rather than 0.6".
saipan59 said:
Looking at a picture, I see that the UDA has 12 PROMs instead of 6 -- I think that's just because the necessary density wasn't readily available at the time (circa 1980). If true, it would be easy to mod the board to use 6 chips.
Click to expand...
I'm seeing just 6x 27HC641 8kx8 45nS PROMs on the T1002 module, which does indeed correspond to a 48-bit uWord :->.

I think you're thinking of the HSC50 L0107 which has 12 prominent PROMS (apparently AMD but I can't find a photo with enough resolution to make out the PN).
saipan59 said:
The HSC's K.SDI board has the 2901 architecture, but does not have a Unibus or Q-bus, and the board is physically larger than any of the others.
Click to expand...
Don't you mean the K.pli (L0107) here? I've attached a photo of what I believe to be the K.sdi (L0108) module; also a (dark!) photo of a K.sdi (L0107) that I found online.
saipan59 said:
2901-related story: Richie Lary [see https://www.computerhistory.org/collections/catalog/102737954 ] was the lead designer of the dual-sequencer controllers that started with the UDA.
Click to expand...
I didn't know that; always tied Rich to the 11/60 microcoded implementation of a PDP-8.
 

Attachments

  • L0108 - Front #2.jpg
    L0108 - Front #2.jpg
    512.7 KB · Views: 10
  • L0107 - Front #2.jpg
    L0107 - Front #2.jpg
    156.9 KB · Views: 10
pbirkel@gmail.com said:
I'm seeing just 6x 27HC641 8kx8 45nS PROMs on the T1002 module, which does indeed correspond to a 48-bit uWord :->.
I think you're thinking of the HSC50 L0107 which has 12 prominent PROMS (apparently AMD but I can't find a photo with enough resolution to make out the PN).
Click to expand...
Hi again. As for the number of PROMs, I was talking about the UDA50 controller, which has 6X2, the same as the L0107 in the HSC50. Both were developed early on (about 1980-ish). All the later products (starting with RC25, then KDA50, then KDB50) had just 6 chips. The next controller, the KDM70, didn't use the 2901 architecture at all - I don't remember much else about it, except that it was mostly surface-mount chips, which was a new-ish thing for us.
pbirkel@gmail.com said:
Don't you mean the K.pli (L0107) here? I've attached a photo of what I believe to be the K.sdi (L0108) module; also a (dark!) photo of a K.sdi (L0107) that I found online.
Click to expand...
Yes, you're right! The "K.SDI" name should have been a hint (SDI is the storage interface, not the processor).

Trivia regarding the L0108 (similar for the UDA50's SDI module): IIRC, the 3 bigger chips near the middle are what we called "SERDES" (serializer/deserializer, a fast UART-type device). The guys to the right with the black heat sinks are "ENDEC" (encoder/decoder, converted the serial bit stream to the encoding used by SDI, sorta like the 8/10b code used in FibreChannel). The hybrids in the upper-right are the electrical interface to SDI.

Meanwhile, attached is a pic of the KDA50 and KDB50 controllers. I built the Manufacturing Functional Tester for those also.
The earlier testers included a WCS (writeable control-store) which "replaced" the PROMs via the bed-of-nails vacuum fixture, allowing me to run my custom diagnostic code during the test without physically removing the PROMs.
Also attached is an 'official' pic of the KDB50 tester. Unlike the earlier testers, it was no longer practical to use a bed-of-nails fixture (mostly because of the BI bus, IIRC), so I used a BI backplane, a known-good SDI module, and a complete HSC50 cab. So very little custom HW in the tester; mostly just some SW.

Pete
 

Attachments

  • s-l1600.jpg
    s-l1600.jpg
    312.1 KB · Views: 18
  • s-l1600 (1).jpg
    s-l1600 (1).jpg
    595 KB · Views: 17
  • KDB50_tester.jpg
    KDB50_tester.jpg
    200.1 KB · Views: 17
do you have any HSC engineering drawings?
the ones for the HSC50 were essentially impossible to find
I remember the only source in the late 90s was some place in the UK that wanted over a grand for them

when CHM got the DEC engineering archives, I was disappointed to discover almost nothing was
there from Colorado Springs (or DECWRL, DECWEST, et. al.)

Richie was still in the storage business in the 00's, working for a company that was bought by Seagate
 
While on this topic, does anyone here have schematics for the KDA50 controller (M7164)?
The print set would be MP-01423.

I know I had a hard-copy years ago, but I must have disposed of it...

I still have an M7164 module, so it makes me think of project ideas... [Danger, Will Robinson!]

Thanks,
Pete
 
> I still have an M7164 module

Wouldn't it be possible in theory to put all the ICs in Kicad's schematic editor and guess the interconnections?
 
jplr said:
> I still have an M7164 module

Wouldn't it be possible in theory to put all the ICs in Kicad's schematic editor and guess the interconnections?
Click to expand...
Sure. Guessing *correctly* is a bit harder. Quite a bit ... and guessing the content of the ROMs/PLAs requires a roomful of monkeys and suitable input devices ... plus lots of time and a mechanism to determine when they've (and you've) guessed *correctly*. You can see the difficulty. P=NP? So "in theory" isn't a very helpful postulate ... in practice :->.

Even having a board-in-hand is pretty much a necessary precondition for reverse engineering, but far from sufficient. Photos even less so.
 
> So "in theory" isn't a very helpful postulate ... in practice :->.

I don't intend to start that myself, but I was making a suggestion to someone who designed a board tester and perhaps the board itself, and I thought they might still have some intimate knowledge of the board's internal working.

> guessing the content of the ROMs/PLAs
The question to which I answered was " does anyone here have schematics for the KDA50 controller (M7164)?"
 
pbirkel@gmail.com said:
Even having a board-in-hand is pretty much a necessary precondition for reverse engineering, but far from sufficient. Photos even less so.
Click to expand...
My first thought for a "project" was to try and decode the microword fields. Then hand-assemble a few words of code, burn EPROMs, and make the diagnostic LEDs blink. I (myself) wouldn't attempt it without schematics - any significant 'guessing' would take the fun out of it.

jplr: Thanks for you input. I know the guy (Randy) who owned the M7164 design, and Joe who owned the M7165 (SDI) board. But they didn't keep schematics or other good stuff from way back then. Compared to me, they are less inclined to do tedious hobby projects based on obsolete hardware (I "live" for those types of projects!).

Another hassle of making an 'interesting' device out of a KDA (or UDA) board is that there may not be any sort of "register file" on the controller board (other than the 4-word stack in the 2911). I suppose there may be some registers implemented in one of the PALs. The RAM was on the SDI board.

Pete
 
saipan59 said:
...
Another hassle of making an 'interesting' device out of a KDA (or UDA) board is that there may not be any sort of "register file" on the controller board (other than the 4-word stack in the 2911). I suppose there may be some registers implemented in one of the PALs. The RAM was on the SDI board.

Pete
Click to expand...

The UDA50 (and I am guessing the KDA50) used a 16b Am2901 datapath which inherently has a 16 location register file.
The same size as pretty much every microcoded discrete PDP-11 CPU used using for example 74181 4b ALU slices and separate 16x4 4b ram register files.
But really the main datapath is the least of your worries in microcoding a PDP-11. Dissecting and parsing of the instruction word fields reasonably efficiently is going to be problematic.
PDP-11 designers put a lot of thought into this process so all the instructions and address mode processing could be efficiently done.
 
AK6DN said:
The UDA50 (and I am guessing the KDA50) used a 16b Am2901 datapath which inherently has a 16 location register file.
Click to expand...
Ah, good point! I had forgotten about that.

I (myself) would never attempt to do a PDP instruction set. But if the microword were decoded, perhaps it be possible to do something simple (like blink an LED) with just a couple of the EPROMs installed. A 'baby steps' way to avoid the tedium of dealing with six EPROMs right away.
And it would be interesting to learn just what functionality is possible *without* knowing how to use the PALs.

Meanwhile, I just discovered that bitsavers has the print sets for UDA50 and RC25! Not sure why I didn't find it before...
In the UDA folder, there's even a patent (by Richie and others) related to the dual-sequencer feature.

With a UDA schematic now, figuring out the KDA should be much easier. I *think* the KDA was just a UDA re-do, changing from Unibus to Q-bus, and shrinking it to fit on quad boards. The microword may even be identical... The PALs on the KDA may correlate closely with stuff on the UDA schematic. I'll shoot a question off to Randy (the designer) and see what he remembers.

Meanwhile, I note that the OP ("Maguro") has been silent since the first day. Did we scare him off? :)

Pete
 
Everyone wants to replicate PDP-11, but it's a different model. I'm trying PDP-11/70, but there are too many circuit boards and it's not easy. Fortunately, the engineering drawings come with microcode, so I hope I can persevere.
 
MattisLind said:
Actually not entirely sci-fi :

https://github.com/pepijndevos/74xx-liberty

https://abopen.com/news/pepijn-de-vos-74-series-project-goes-straight-from-vhdl-to-pcb/
Click to expand...
Very interesting. https://devbisme.github.io/skidl/

I've been learning my way around KiCAD v7, which takes another baby-step towards being usable/useful for reverse-engineering a PCB. It's annoying that it's >this< close to fully supporting that functionality, but no one has implemented it. The missing step is being able to get a netlist out of the PCB Editor that can be fed into the Schematic Editor; information flow is only supported in the opposite direction. Poking around in various tools/editors seems to indicate that the critical netlist information is present from simply following tracks on a PCB once you've established a component-set and their positioning; it's just that no one has implemented the connection. Perhaps one could get a raw netlist for a PCB and then manually augment it to SKIDL expectations.

It would be great to be able to verify the derived schema against the existing PCB; unfortunately leaving it to autorouting to lay down necessary traces is pretty unlikely to result in anything that matches the original PCB to the degree that it can be visually verified. I don't see how to avoid the awkward step of manually routing traces in order to confirm that the original interpretation of the PCB is consistent with the derived schematic. While I firmly believe in using round-tripping in any data-transformation as a verification tool, in this situation the cost to doing so seems out of proportion to the value received. Just don't make any mistakes in the original netlist "extraction" ...

The thorny problem at the moment is dealing with a populated PCB (I'm only considering two-layer cases and thru-hole components) with traces hidden by components. Inferring trace presence & connectivity depends on observable geometry (traces disappearing along component boundaries), non-observable geometry (hidden traces potentially ending on component pins or under-component vias, rather than exiting at another component boundary), and functional connectivity requirements based on a complete(d) schematic.

My target complexity is a 15x15" PCB with ~100 ICs (somewhere between DG Nova 3 & 4 density); I've manually worked a PCB of about 1/3rd that size to generate a few lessons-learned regarding KiCAD use and a workable iterative process. I've been stumped regarding how to scale that experience up to the target size/complexity without getting lost in the excruciating details. You need the patience of a medieval manuscript illuminator!

I'm unenthusiastic about stripping a PCB of components in order to get a clear view of the top side traces.

Anyway, thanks for pointing out this work. Maybe SKIDL has a use in my workflow.
 
I have tried some similar explorations, but there is currently no perfect path. I started thinking of using Verilog to describe each circuit board and then generating a netlist of OrCAD in Python, so that I don't have to redraw the schematic. I used M8130 as an example, and when I saw the netlist, I found that the format was too complex and didn't work. But I found that the opposite is feasible, as verilog codes can be generated from the schematic. Currently, I plan to do so
 
I did a similar thing when I converted the MIT AGC schematics into VHDL.

I captured the schematics (well, captured them by hand into Excel as the schematics utilise 3-input NOR gates only) and wrote a little converter to spit out VHDL code.

I ran into a couple of issue with this approach - and had to add an extra field into the Excel spreadsheet to determine whether the spat out code for a gate was a 3-input NOR gate, a 3-input NOR gate expander, or it contained a D-type latch to correctly implement logic delays. I found that the logic relied (in some cases) on specific signals from different parts of the logic arriving at the same time. The logic contained (for example) series-connected inverters to delay the signal. Of course, without the D-type latches, the synthesiser optimised out the chain of inverters. Also, the timing was all messed up due the speed difference between the silicon at the time and the super-fast FPGA speeds.

Dave
 
You must log in or register to reply here.
Back
Top