Correction -- it's a 2:3 scale model of a PDP-10 front panel, concealing a Raspberry Pi running an emulator. In the original equipment, the panel would have been attached to one of several racks containing the CPU and main memory, cabled up to peripherals (tape drives like in '60s movies, disk drives the size of washing machines) through wires under the false floor of a dedicated computer room...
The PiDP-10 accurately models the console, but it doesn't depict the rest of this at all.
The KA-10 had core memory (except for the instruction counter and locations 0-15 which were general purpose registers which were implemented in DTL). So when the power went out you could just restart, except for the running process.
An interesting thing about the KA-10 is that those DTL registers were optional. Architecturally the registers are simply the first 16 words of core memory. If you bought the fast register option with your KA-10 they installed the DTL registers which overlaid the first 16 words of core.
A consequence of that was that anything that took a memory address could access the registers as memory. Just give it an address in [0,15].
That included the program counter. Load code in 0-15 and jump to it and it would run quite a bit faster than if it were in core if your KA-10 had the fast register option.
I've got one of these and its glorious if you fondly remember the PDP-10 as I do.
Yes, its just being emulated on a Raspberry Pi, but seriously running a "real" one generates several kW of heat and required even more kW of power. Not to mention space.
I do have a couple of "real" PDP-8s (an 8/e, 8/f, 8/m and most of an 8/a) but I rarely run them because they take a lot of power and they are noisy. I've got a PiDP-11/70 which is running RSX-11M and Pi-hole and DHCP and logs the iOT temperature widgets I built. So it looks good, and does helpful things. Not to mention you can SSH to it and get your RSX-11M console right there :-).
So while you don't get the visceral response of a "real" one, 90% of the time you were never in the same room as one in the first place, it ran in the machine room and you were in a room next door typing on a VT100 (or VT-52 ewwww!)
> but seriously running a "real" one generates several kW of heat and required even more kW of power.
No, both are the same :) It converts the power into exactly the same amount of heat, save for a tiny fraction in light from the bulbs which eventually ends up as heat as well.
Totally agree you wouldn't run these at home though. We had a PDP-11 at college and even there they didn't like to switch it on. Never saw a PDP-10 though.
I have the PiDP-8 and -11 replicas but I won't be getting this one, it's pretty big and expensive (especially now that it ships from the US, I'm in Europe) and it lacks the nostalgia factor for me due to not having known it in real life.
It is however a real piece of retro art, just like the others (and it looks like it's been done even better).
Depending on whether or not you consider a KS a "real" PDP-10, my KS actually uses less power than my modern PC does under load. The KS sits just under a kilowatt running UETP, but my PC spikes north of 1.2 when running benchmarks. And that's with a now obsolete graphics card in the PC, the newer ones are even more power-hungry.
I feel I should point this out because it seems to be a point of confusion: "PDP" is not a single unified product line. The numbers do not indicate linear progress. There is no architectural relationship between a PDP-8, a PDP-10, and a PDP-11. "PDP" is just the TLA for "Programmed Data Processor", the term DEC used instead of "Computer" to avoid the business/political connotations that the word "computer" had at the time.
Allegedly the term was used so DEC equipment was classified as lab equipment and went through a different procurement process so it didn't end up in the typical computer center glassed off by IT gatekeepers and bureaucracy.
>DEC Number #2 in computing during the 80's, bought by Compaq, bought by HP and now almost unknown. How the mighty fall.
Ken Olsen had a flair for being a bit over the top -- which makes the following quite amusing given how things worked out:
One of the questions that comes up all the time is: How enthusiastic is our
support for UNIX?
Unix was written on our machines and for our machines many years ago. Today,
much of UNIX being done is done on our machines.
Ten percent of our VAXs are going for UNIX use. UNIX is a simple language,
easy to understand, easy to get started with. It's great for students, great
for somewhat casual users, and it's great for interchanging programs between
different machines. And so, because of its popularity in these markets, we
support it. We have good UNIX on VAX and good UNIX on PDP-11s.
It is our belief, however, that serious professional users will run out of
things they can do with UNIX. They'll want a real system and will end up
doing VMS when they get to be serious about programming.
With UNIX, if you're looking for something, you can easily and quickly check
that small manual and find out that it's not there. With VMS, no matter what
you look for -- it's literally a five-foot shelf of documentation -- if you
look long enough it's there.
That's the difference -- the beauty of UNIX is it's simple; and the beauty of
VMS is that it's all there.
-- Ken Olsen, President of DEC, 1984
Does anyone know what the name of this old VMS documentation is? I'd like to have a search for it so I could see if I can find a copy. Specially if it's 5 feet of old technical docs, I collect this type of thing.
Generally speaking, "ProductNameVersion documentation set", where ProductName is one of "VAX/VMS", "VMS", or "OpenVMS", broken up into a variety of sets, subsets, and volumes.
Taking VMS V5.5 as an example, for the complete set, you want the "Extended Set (with Base Set)", order number QA-001AA-GZ.5.5[1].
If I'm counting correctly, this set consists of 143 titles, which is probably closer to 25 feet than 5.
Even if you go back as far as V1.5, the complete set still included around 50 titles[2] — I can't find a list for V1.0 — and unlike the V5.5 set, this one wasn't available on CD-ROM.
When you get so big that you think you can start telling your customers what they want instead of listening to them, this is what happens. Novell did the same thing with small/medium business LANs. In DEC's case, they thought they could become IBM by hiring people that IBM either fired or didn't hire. This in turn led to telling the customer what they wanted since that's how they thought IBM's sales process worked. We all know where that ended up. The story is old as the hills and the result is always the same. Boeing is going through it right now; They absorbed the McDonnell Douglas corporate culture and forced out everyone who didn't agree, and now the same chickens that sank McDonnell Douglas are coming home to roost at Boeing.
The problem is that the PDP-10 is really unsuited to running C. It doesn't use 8-bit bytes and doesn't have a native "byte" datatype, just words and halfwords. There are byte instructions, but you have to construct a "byte pointer" to use them, which is a control word describing bytes of arbitrary size. The PDP-10 also has no single dedicated stack pointer, any AC except for the program counter can be used as a stack pointer, to its own independent stack if you want.
Isn't stack direction an ABI convention rather than language or processor limit? I mean if you are trying to run existing PDP-10 binaries (I don't know of any that are publicly available), sure. But just to get to the point that you are running bash and serving and HTML Hello World from Apache, it shouldn't be an issue.
> 8-bit bytes
Doesn't the C standard just specify the minimum range of datatypes, and the max? Don't know if you can tell the size of actual bit without triggering UBI. (obviously not a C programmer)
The standard specifies that you must have an independently addressable unit of storage that corresponds to the basic character set. The PDP-10 does not have this.
Oh, there is/was a C compiler for the -10 (KCC), but it wouldn't support the modern dialects that the *BSD kernels are written in. Just having the language isn't enough, you have to be able to support the build chain of a modern kernel.
I haven’t checked, but I’m fairly certain it’s too big for Tiny Tapeout, so ASIC is out of the question unless you want to crowd source an older geometry.
That page does tell you Len Bosack founded XKL but IIRC (that was long ago!) it was Cisco’s original plan to make a PDP-10 clone, and they sold SUNET routers to fund the work. It was a rather successful pivot to make the routers the main business.
Another company that used that same hardware to get going was Sun Microsystems, though their initial plan didn’t change.
The PiDP-10 accurately models the console, but it doesn't depict the rest of this at all.
reply