Hacker News new | ask | show | jobs
by herio 1810 days ago
Really cool, but just to nitpick a bit not entirely correct in some ways.

Logical systems still sell their NuVAX machines, see https://logical-co.com/product/nuvax-4400-system/

They also do PDP/11 systems and hardware.

I think they might be built using an emulator on PC hardware with some interfacing hardware, but still I would call it a "new" VAX for most purposes.

7 comments

NuVAX is based around software reimplementation of VAX cpu with special-purpose I/O system to reuse existing interfaces (important when you need to deal with custom interface cards, for example).

Funnily enough, it appears that real vaxen ended up being produced for shorter time than PDP-10, despite efforts going as far as encasing last high-end PDP-10 prototype in concrete and dumping it in mill pond (or so the story goes), as known single-chip PDP-10 were produced at least as late as 2004, after last VAX rolled off production line.

"If you're not playing with 36 bits, you're not playing with a full DEC!" -DIGEX (Doug Humphrey)
I didn't realize anybody still remembered Digex.
DIGEX was Doug Humphrey's nickname long before he started an ISP using that name.

Doug had a KA10 in the living room of his apartment in a high rise tower in Maryland, near where I used to live.

He had to take it up the elevator in two pieces, and the elevator had a hard time aligning with the floor because of the weight, so he had to lift it up a foot to get it out the door.

The apartment didn't have the right two phase 220 volt power outlet, but it was possible for two people to simultaneously plug it into two different 110 volt outlets at opposite ends of the apartment that were on different phases to get it to work.

It didn't have any memory except for the registers, but you could load a loop of code into the registers and run it really fast (since they were mapped to low memory), to keep the apartment nice and cozy warm.

Good thing electricity was included in the rent!

I barely remember them. I worked for an ISP that had a dual T1 to Digex. We also had a couple to UUNet and another to MCI. Digex was cheap compared to the other two.
"Radix-50 Rulz!!!"
So you are a DEC fan but don't remember Radix-50 encoding?
> as known single-chip PDP-10 were produced at least as late as 2004

Who was producing a PDP-10 in 2004? I'd love to know more about this.

XKL's TOAD-2 is/was based on a single chip PDP-10.

The hardware is used as a router, but supposedly if you ask it very nicely you can get it to run TOPS-20.

Living Computer Museum had two XKL-2 running TOPS-20.
Yup, the XKL TOAD ("Ten On A Desk") and TOAD-2.

https://en.wikipedia.org/wiki/XKL#TOAD-1

At the time of TOAD-1, there were also still machines built based on SC design, for effectively singular consumer - Compuserve.
Fascinating... in the phrase "replaces the VAX chassis, CPU, memory, KWV11-C clock and mass storage", the clock being mentioned separately intrigued me, so i googled it. Turns out that only the clock was a whole board full of good old TI 74x TTL chips - and a "used but working" board goes for 345$ on eBay (https://www.ebay.de/itm/M4002-KWV11-C-MODULE-USED-AND-WORKIN...)...
The first-gen PDP-11's CPU was just a couple of boards full of good old TTL chips.
Yes, the pdp-11/20, released in 1969. Core memory only. In my opinion, it took the pdp-11/45 to firmly establish an impressive new line of machines, separate and more powerful than the pdp-8 line. But, in DEC's way of thinking, it's instructive to note that a pdp-11/40 was used as the console of the DECsystem-20. Separately, it's a shame we no longer have 36-bit machines; 36-bit ints would hold time_t just fine, and 72-bit doubles will work great for science. Oh well. What we're stuck with now bytes.
I remember reading an old paper on some funky experimentat user-interface that used a pair of PDP-11s (possibly, might have been event older) essentially wired together at the busses, with extra instructions added with new logic in TTL silicon, I think it was for doing the maths for the vector graphics. It was amazing the amount of hardware hackery that was necessary to build these experimental systems.
Compared to x nm VLSI, TTL and ECL are ridiculously low density. And soooo sloooow.

DEC were very pleased with themselves when they got to ~40VUPs in the later ECL models, but a full modern VLSI - not FPGA - implementation wouldn't break a sweat at 1000VUPs.

What seems particularly interesting is that the board seems to really be just an RTC, yet does not have any obvious place for backup battery and has 10MHz oscillator on it.
GE Canada has VAXen running their atomic plants and they are under contract to keep 'em running for a long time, 2035 or 2045. (Might be called BWXT today.)
Melbourne (Australia)'s train signals used to be controlled by PDP-11s running Ericsson JZA715 train control software. They were replaced by Ospreys. An Osprey is actually a hardware PDP-11 CPU on an expansion card which plugs into an x86 PC bus. It uses an actual CPU not emulation because realtime applications like train control need to be 100% cycle accurate. (Originally they used actual PDP-11 CPU chips manufactured by DEC, later they switched to using FPGAs). It also has Unibus cards to do Unibus-ISA/EISA/PCI translation so it can integrate with the original peripherals.

http://web.archive.org/web/20210126085900/https://www.equico...

http://www.strobedata.com/home/ospreyguide.html

Why does train control need to be 100% cycle accurate?

PDP-11s ran at what, 1.25Mhz? I'd think that a modern CPU software emulating a PDP-11 CPU could get to below those cycle times.

> Why does train control need to be 100% cycle accurate?

It's not uncommon for IO interfaces to be cycle-sensitive. I can only speculate, but perhaps they do not use a timer and it is cycle-exact code for certain timing operations. They could be bit-banging a serial protocol, as that was done then as now. Or they could be controlling very sensitive things where even a few microseconds of jitter is unacceptable. Tying it so closely to the CPU like that was a dirty but common practice in the 70s and 80s. And sometimes simply obligatory! There is no high precision timer on the low-end PDP-11s by default, I believe.

A few cache misses in a row, and some branches mispredicted and your modern CPU is slower than 1.25mhz. This almost never happens (CPUs are very good at this) but when it does things can get bad.
You could keep all of the PDP-11's RAM and probably most of its "external storage" in the L2 cache of most modern CPUs.
https://en.wikichip.org/wiki/amd/microarchitectures/zen_3

> 512 KiB per core, 8-way set associative

So the 64 core 7763 / 7713 you are looking at 32 megabytes of L2.

The 11/70 in 1975 already had 22 bit address space and like 10MB disks. So -- yes, it's not unlikely with a bit of hand crafting you could keep the whole shebang in L2 but you need a top end CPU.

Lets say the modern CPU gets itself really tied up in knots and is out of action for a staggering 10ms. During that time a speeding train doing 350kph travels not quite a meter. Do trains run such tight scheduling that this isn't sufficient time to cause delay on actuating a switching element and cause an accident?
You have a legacy safety-critical system, which incorporates legacy hardware peripherals. How sensitive is it to changes in timing? You may not actually know. Do you want to do the engineering analysis necessary to prove that replacing one part of that system with potentially different timing is not going to cause problems? Or do you just seek out a replacement whose timing is as close as possible to the original?

The big issue may not be with the trains themselves but the communications protocols used to talk to signalling equipment and other peripherals. Changing the timing in the communication with them may lead to problems.

And what if the original software has race condition bugs which have never been surfaced, and the occasional inaccuracy in timing starts to surface them? Good luck fixing bugs in some obscure piece of PDP-11 software that was written in the 1970s.

I have no idea. If this is real time control that could mean you keep running the motors in the switch long enough to damage something. Or maybe you go past the end of travel switch signal without reading it, the switch turns off and you never stop... There are a lot of ways real time systems can fail.

You are correct that 10ms is well within the margin of error for safety stopping a train, but it may be out of the margin for some subsystem in the control.

With bipolar memory option, the pdp-11/45 had a 300 ns memory cycle time.
I would love to have some one write an article about how they even manages to do that.

Are they real VAX servers or have they've been virtualized/emulated somewhere down the line.

More than you would imagine.
Definitely at least some software emulation on x86. The manual for that system shows a board name "PEAK876VL2" in a picture - that's an x86 board - but LGA1156, so old!
I suppose that means the author of the blog post potentially has a market for his FPGA implementation.
I think getting VAX software to run on an FPGA board is the lesser problem - getting it to be 100% compatible so it can serve as a "slot-in" replacement for an existing VAX is probably a lot more difficult.
Thanks, didn't know about NuVAX. How old is that product? It seems like you could do much better than 70 VUPs today. Or 5 years ago, for that matter. I guess it is because everything is done in sw emulation?
Are there really PDP-11s out there still doing stuff? That is wild