MicroVAX 78032 | Hacker News Reader

MicroVAX 78032

en.wikipedia.org

56 pointsamacbride56 comments

This might have been the crucial point, where DEC missed the microcomputer boat. In early 1985, the only full 32-bit single-chip processor that was generally available was the Motorola 68020. The Intel 386 would come out later that year. DEC was focused on the high end though. Much of the R&D was going into high-end designs with rack-sized arrays of ECL logic for the processors in their VAX mainframes and vector supercomputers, which they never sold very many of. The later CMOS NVAX design, when process shrunk, ended up being faster than the $1 billion ECL VAX 9000 line not long after it was introduced.

"I just don't understand it, I don't see how this is possible, how this one chip can replace these racks of electronics, I just don't get it"

"There is no reason for any individual to have a computer in his home"

"Unix is snake oil"

—Ken Olsen (DEC Founder, president, and chairman)

Sorry, Unix IS snake oil when compared to VMS. Olsen got that one right.

The thing is that Unix(of the day)'s source wasn't full of 100s of pages of vax assembly code .... so it was portable - just a page or two of assembly.

Also prior to that OSs were proprietary - if you didn't work for a hardware manufacturer you mostly didn't get to play with them much. There was no incentive to make them portable - then along came Unix and it was dropped into the hands of a generation of college kids.

Sure VMS had a better VM story (I both ported Unix and was a VMS systems hack at the time) - but you couldn't pick it up and put on anything other than a vax, it was pretty useless as an OS unless you were DEC, Unix didn't have that yoke around its neck (it had others mostly because AT&T didn't understand what it had)

The VMS filesystem aboslutely shit all over any offering from Unix (and still does with the exception of ZFS). The Vax FORTRAN compiler smoked everything on Unix until IBM put a good FORTRAN compiler on AIX. VMS systems had actual security that we still don't have nowadays. VMS systems could be used for real-time tasks (Intel's fab line ran on VMS for a very long time).

I can go on and on ...

Unix "won" by becoming the darling of the people not willing to pay money while Windows swept the field of those willing to cough up cash.

However, don't mistake the virality of Unix for it being "better" than VMS.

Unix is/was a lot of things, it was developing at a much faster rate than VMS - was VMS better than V6/V7 certainly (I ported V6/V7 so that the kernel ran in VMS sup/user mode in place of DCL), better than V.2 (the VM subsystems were vaguely comparable) - file systems better than Linux's (there are so many, probably not in total, and that whole record based thing was just a straightjacket on so much).

The thing is you're comparing 1 VMS that didn't evolve much (it did get sort of cloned by MS) with effectively hundreds of Unix descendants.

As I said I've worked intimately with both, and I don't think VMS gets as much love as it's due, but in the long run I think it was a dead end largely because it was held close by a (great!) company that died

Dont forget the clustering/disaster recovery. VMS' clustering was incredible.

The lesson I take from tech of this era is that good enough (and cheap) beats superior over time. Unix over VMS, Ethernet over Token Ring, etc. I posit that Unix's simplicity of that era (you really could hold the entirety of the system in your head back then, and rereading the entire manual set every few months was something considered perfectly feasible and regularly recommended for power users) was the winning formula. It certainly helped that unix was all over academia. 20 years later, when Solaris was the incredibly powerful big dog and linux was the upstart, history repeated itself.

It may have been better from a sysadmins view, but user wise I loved Unix immediately. Whereas VMS? Meh.

I think this same system oriented view (as distinct from user) is what sunk DEC, HP and Sun.

"Free" is in fact one of the axes along which "better" can be measured.

Unix of the day was not "free" you could get free access at a Uni, but outside of there you had to pay AT&T, who frankly didn't really understand what they had (which is why we now have Linux)

Compared with proper commercial OSes that fee at the time was almost symbolic.

They were aware of what they had, hence why their first action after being allowed to commercially take advantage of UNIX was to sue BSD.

The thing is that Unix(of the day)'s source wasn't full of 100s of pages of vax assembly code ...

VMS wasn't all vax assembly either. VMS and a lot of VAX system software was mostly written in BLISS [1], a high level language intended for systems programming that was created about the same time as C. It was all there for customers to read in a big stack of microfiche cards delivered with each machine. I remember being shown the code for the VMS scheduler or maybe the dispatcher which was 'a page or two of (VAX) assembly' - I recall it was pointed out that it was one of the (few) places in VMS that did use assembly.

I don't know how portable the BLISS code for VMS was, but there were BLISS compilers for several other machines besides the VAX.

1. https://en.wikipedia.org/wiki/BLISS

Most of the kernel was in VAX assembly (I've seen source code listings of VAX/VMS circa V4.x). They were able to port the kernel over to other architectures by creating a compiler that treated VAX assembly as a high level language. This approach came with its costs - even to this day, large parts of VMS remain 32-bit only because it was not possible to automatically make 32-bit assembly code into 64-bit object code for other platforms. Even in programs which use 64-bit addressing, VMS essentially requires you to use a mix of 32-bit and 64-bit pointers in the same program.[1]

A similar problem (AFAIK) befell BLISS - BLISS code for the VAX treats all values as 32-bit. There is a separate BLISS-64 compiler for the 64-bit platforms VMS was ported to, but I don't think all the BLISS-32 code was converted over to BLISS-64.[2]

[1] http://www0.mi.infn.it/~calcolo/OpenVMS/ssb71/6467/6467p005.... [2] https://www.cs.tufts.edu/~nr/cs257/archive/ronald-brender/bl...

Oh I completely agree - but I also remember putting a graphical header on the first page of the output from the print symbiont (aka daemon, essentially CUPS), I had to type in pages of assembler from microfiche

And it had bounds checking like most sane system programming languages since late 1950's.

The reality is that lots and lots of early sun costumers were running Unix on their VAX and then the bought a sun and simply continued to use Unix just on a much cheaper machine.

So the question is why were all these university people running Unix instead of VMS. Were they just dumb?

> So the question is why were all these university people running Unix instead of VMS. Were they just dumb?

The "university" people were still running VMS certainly up through 1990 or so. Very few people ran Ultrix on their VAX hardware. And workstations were never widespread in universities as workstations basically cost as much as a car. A lab with 8 workstations was still a big deal in 1990.

Unix didn't sweep away VMS, PCs did. Just like PCs swept away workstations.

Unix didn't "win" until it latched onto PCs as a host. And people also forget that Unix didn't "win"--it lost terribly to both Microsoft and Apple.

I was thinking the same as implied here, and yes he said that in 1977 but it was taken out of context; he was referring to home automation and not personal computing. [2]

It seems, no, DEC did not miss the PC boat due to one person's nearsighted view.

Microvax was 1985 and yes it would have been interesting if they had a low-end personal product based on VAX at that time. They did have the Professional [0] around 1982 based on PDP-11 which I used at school to learn Macro-11 assembly, C and Pascal. It was blazing fast and ran RSX/11 which was years ahead of DOS. They also had the Rainbow [1] around 1982 (maybe marketed to officework) with a z80 and 8088. And then there was the VAXMate in 86 which we don't talk about :). So it seems these were all aiming at the new "PC" market in a scattergun manner but nobody really knew what that was at the time.

0. https://en.wikipedia.org/wiki/DEC_Professional_(computer)

1. https://en.wikipedia.org/wiki/Rainbow_100

2. https://www.snopes.com/fact-check/ken-olsen/

The had to many attempts at building a PC, not to few. It kind of crazy, they basically launched 3 PC type computers at the same time.

Between non of them being a actual PC clone, not running the same software and not really able to compete in the race to the bottom price fight they simply failed to get traction.

It seems like the repeating cycle of the industry is the low end "toy" computers eating the high end "real work" computers, first in volume, eventually also in performance, from mainfraim (IBM) -> mini (DEC) -> workstation (SUN) -> PC (Intel) -> phone (Apple/ARM). With the incumbents never learning from history.

They learn, they just can't usually do anything different. See Clayton Christensen's The Innovator's Dilemma. [0]

[0] https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma

I wonder if these classic patterns still hold now that everyone competent has read these 1990s era books.

I could be strongly biasing myself without realizing it but I think they've become less common except on really grand scales where no single industry player is big enough to really control things

Here's a few I see:

podcasts and YouTube are successfully attacking conventional television and radio

Home recording studio equipment improvements have seriously been eating into studio time.

Home audio improvements have made the high end less relevant

Display technology improvements have made affordable displays eat into the high end market.

I think transportation and energy are the next big ones; solar panels will be so cheap that they'll start to be integrated just about everywhere and smaller electric cars (under 1500lbs or so) will become so affordable that those who drive for pure function will start adopting them en masse

The Innovator Dilemma doesn't mean you can't do anything about it. Its just harder to do and you need to make the necessary investments (usually doesn't even require that much money) and need to have the right strategy to do it.

SGI -> Nvidia

Maybe relevant to this discussion, "A Historical Look at the VAX":

https://news.ycombinator.com/item?id=27527140

And also "The VAX":

https://yarchive.net/comp/vax.html

I don't really understand all of this, but the high level gist is that the VAX ISA was almost out of runway; it wasn't entirely that DEC made bad choices but also that they couldn't take VAX where it would need to go to remain competitive anyway.

I don't know, if you have an Alpha and you simply write a fast hardware virtualization layer I don't see why you couldn't sell those machines to the exact same costumers you did before.

Now Alpha was a bit late but the same strategy could have been adopted earlier.

IBM has the same costumers and has virtual layer onto of virtual layer to support technology from the 60s.

You then also port the OS to some RISC system and x86 and attempt to get new costumers using VMS on those system architectures.

That's what DEC did, they ported VMS to Alpha. No virtualization necessary.

OpenVMS is still out there and used by people, but VAX is dead. As is DEC :/.

“No one will survive the attack of the killer micros!” -- Eugene Brooks, circa 1990

yeah, thats true. the 9000 was a really lovely workhorse though.

While collecting VAXen is usually reserved for those with gratuitous amounts of free space and lots of cheap power, I'm happy to have the 78032's successor, the CVAX SOC, running in my datacenter (it's slow - be patient):

http://vlc.zia.io/

It includes the 78034, the floating point unit, and up to 8K of L1 cache in a single CPU package. The "up to 8K" was because they'd keep CPUs if 5K or more of L1 worked.

It's my little piece of this interesting history.

Very cool! What's the software stack?

Thanks! It runs NetBSD 9 and is being used to test a number of toolchain patches, and soon it'll be used to test NetBSD 10. The web server is NetBSD's bozohttpd.

After the eastern bloc copied this chip, DEC engineers had a special message for the Russians:

https://micro.magnet.fsu.edu/creatures/pages/russians.html

I cannot find any reference to this online, but your post reminded me of a similar message to the Russians from the same era. The roof of the Northrop plant in Hawthorne, CA (now SpaceX) had "Yeb Vas" written in some fashion so as to be visible only from the ISR satellites of the day.

https://mymemory.translated.net/en/Russian/English/yeb-vas

It's also mentioned by one of the designers here:

http://simh.trailing-edge.com/semi/cvax.html

This is a meaningless phrase and it does not translate to anything meaningful in Russian. They should have done proper research before wasting time on this nonsense.

I did some development on uVAX in 1989. Wrote a DECWindows app that did monitor & control of a distributed realtime system. DECWindows was slow, so it would get updated every 250ms, while the realtime stuff communicated to a proxy (via 10Mbps DECNet with a custom driver) every 20ms. All of the code was in 'C', but everything aside from the DECWindows stuff was running from ROM on embedded VAXELN.

https://en.wikipedia.org/wiki/DECnet

https://en.wikipedia.org/wiki/VAXELN

Interesting that it had roughly the same number of transistors as the 286 but appeared three years later but on a larger node size (so bigger die).

The VAX was a 32-bit CPU with an mmu, the 286 was not. UNIX variants on the 286 had severe limitations (64k max program size). VMS was built for a much bigger machine than a 286.

The fab was also in-house.

"It is DEC's first single-chip microprocessor implementation of the VAX ISA and DEC's first self-fabricated microprocessor...

"The MicroVAX 78032 contains 125,000 transistors on an 8.7 by 8.6 mm (74.82 mm2) die that was fabricated in DEC's ZMOS process, a 3.0 µm NMOS logic process with two layers of aluminum interconnect."

Yes my first reaction was that the VAX would have been a much better architecture but Intel's manufacturing lead meant that it could churn out 286s (and of course 386s in 1985) at much lower cost.

Interesting to compare them both with the ARM1 which was 32 bit (no MMU) but only used 25k transistors on a 3 µm process - and which was more powerful than VAX 11/780. So both powerful and cheap to make.

I really don't understand why Acorn wasn't purchased outright as soon as the samples were back from the fab.

I think DEC was the first third-party implementation with StrongARM.

https://en.m.wikipedia.org/wiki/StrongARM

Yes I think you're right on StrongARM which was the most powerful ARM CPU for a long time. Eventually made its way to Intel I think.

I think everyone eventually had their own RISC - IBM, HP, AMD, Intel (i960) plus MIPs and SPARC of course and a few others.

Arm eventually got traction because of the business model and because they intentionally didn't go head to head with the Intel x86 juggernaut. It wasn't obvious for a long time that their model would work though.

Your comment reminded me of Paul DeMone's signature line on USENET's comp.arch back in the day!

The 801 experiment SPARCed an ARMs race of EPIC proportions to put more PRECISION and POWER into architectures with MIPSed results but ALPHA's well that ends well.

Very good! Just need to get RISC-V in there now too.

"Something, something, RISC-V business"?

> StrongARM which was the most powerful ARM CPU for a long time. Eventually made its way to Intel I think.

DEC sued Intel for patent violations and won. Digital was dying, and part of the settlement was that Intel purchase the billion dollar chip fab in Hudson, Massachusetts that was just built to produce the chips, and later demolished it in 2015.

Interesting thanks.

IIRC, StrongARM was the basis for XScale, which Intel foolishly spun off. They could have had a good chunk of the smartphone market, or at least a viable path into it.

But they couldn't have because if they kept XScale they wouldn't have invested in it.

Indeed, sold c2006 I think just before the iPhone launched!

The 286 was a curious little beast. It did have a sort of an MMU, and, according to Wikipedia, The CPU was designed for multi-user systems with multitasking applications…

286 and for that matter even 386 has the segment-based memory protection mechanism that is somewhat reminiscent of Burroughs mainframes, GECOS and maybe AS/400. There are two giant issues with the idea: it does not work that well on 16b word system and it is totally incompatible with what most of existing code written in C expects. So with 386 Intel had combined that mechanism with traditional MMU and somewhat hack-ish method to turn all that of (reportedly because Microsoft wanted that for Windows/386)

A few operating systems, mostly UNIX clones, did exist that specifically took advantage of 286 protected mode. The 286 has user and supervisor modes, and could address up to 16 MB of physical memory. In protected mode it still used 8086 style segmented addressing, but the segments were virtual.

The bittersweet fact is that when the 80386 came out, OS designers dispensed with segmentation altogether, because it was conceptually so much easier to just flatten out a single vast address space.

So despite the fact that i386 was now capable of really useful and intricate segmented memory architecture, it was the unsegmented, flat virtual address space that won the race.

Sydney University (Basser CS) had a few 11/780s. It may have run AUSAM, a modified 6th edition.[0]

It was a rush to go from sharing one with 40 other students to my first job where I had a microvax all to myself!

[0] https://www.tuhs.org/cgi-bin/utree.pl?file=AUSAM

Yeah, that brings back memories. My college ended up getting a MicroVax while I was there... to replace the PDP-11/70. The 11 is one of my favorite machines due to the ISA. The MicroVax was just not the same. I'll grant that this is mostly due to nostalgia than technical merit, but, still... not the same.

Reply on news.ycombinator.com