Museum digs up Digital Equipment Corporation's dusty digital equipment Reading Museum is hosting an exhibition marking more than 60 years since Digital Equipment Corporation (DEC) opened its first UK office. The office was opened in 1964 and rapidly grew until DEC employed more than 2,000 people in the Berkshire town west of London. This writer is a fan of dusty beige boxes so jumped at the …
> Software was loaded from an RK05 removable disk drive
With a "whopping" 2.5 megabytes (yes, mega) of storage. And it still booted up faster than my PC does today.
Though with a Raspberry Pi being faster than a Cray, we frequently forget just how much things have improved. Except software, whose main function seems to be to slow all that incredible hardware down to a manageable speed.
> With a "whopping" 2.5 megabytes
Isn't this why UNIX had the split /usr directory structure? IIRC, there wasn't enough disk for the whole OS, and you had to split things up to put what it needed to boot on one disk, before you could mount /usr.
Now a lot of the Linux distros are doing "usrmerge" to undo this, including Debian.
"Isn't this why UNIX had the split /usr directory structure?"
I suspect probably a few reasons.
When file systems weren't particularly reliable especially after power loss or kernel crashes having a small fairly static root file system/partition probably meant a better chance of fsck fixing the file system on boot instead of a rescue/restore.
When Sun et al. put workstations on networks which could then share file systems (NFS, RFS) and understanding SCSI and IPI disks were small (MB) and expensive that it was fairly common to configure diskfull workstations with a local root file system, swap, possibly /var and /home with the /usr NFS mounted read only from a server.
For diskless workstations each NFS mounted an individual root, etc but shared a single NFS mounted /usr.
With sharing between different Sparc hardware you had the added complexity of /usr/kvm.
Grand days lad, I'm thinking we'll never see their like again. (Lad thinking: We must be thankful for small mercies. ;)
I think originally /bin &/sbin were the commands required to run the system itself while /usr was the stuff users directly invoked, what we would now call apps. The /home tree is much, much later. Even /var wasn't there for ages. /opt was invented (by Sun? or IBM?) as the place to install commercial packages.
The different filesystem thing was at least partly to reduce the risk of a filesystem error... Back then it was not at all uncommon for the bootup fsck (you never skipped them if you were sensible) to find errors even without a power failure or similar. Smaller FS == quicker fsck time and fewer files to restore from backup. The disk full thing was also true as early Unix was not nice to fix if you had 0 blocks free.
As an aside, I still occasionally try to "cat" a directory rather than "ls" it because originally that worked just fine.
I'd bee surprised if you found many Sun systems running RFS (unless you were working at AT&T). It was an AT&T STREAMS based remote filesystem that came as an add-on for SVR3.2 (although I had it running on R&D Unix 5.2.6 on an Amdahl mainframe, but that was nearly SVR3 anyway).
At the same site, we had also started using SunOS 4.0.3, which was nominally SVR4, but even then we had to put the R&D extensions over the top in order to get it to play with the RFS, Although it had STREAMS, the RFS components still had to be added to SunOS, and I don't think Sun provided it, as they wanted everyone to use NFS.
"Isn't this why UNIX had the split /usr directory structure? IIRC, there wasn't enough disk for the whole OS, and you had to split things up to put what it needed to boot on one disk, before you could mount /usr."
Nope. For the earliest versions of UNIX, the *whole* OS, including source code, could easily fit on a ~2.5MB RK05 disk*. And often did. /usr might have been on a different partition that got mounted during the boot process. But it would almost certainly have been on the same physical disk. IIRC / and /usr were separated to limit the damage on the other if one of those filesystems got filled. If / and /usr were on different disks, it would have made life somewhat difficult when your PDP11 only had one disk drive. As most of us did back then.
* The V6 kernel was < 10K lines of code.
We had a VAX 8250, which was around the size of an SUV in its own air conditioned chilled room. Several huge disk platters including a removable one plus the obligatory tape deck. Eventually it was replaced with a micro VAX which was around the size of a desktop computer and had a micro cassette for backups. It looked completely lost in the huge room, just perched on a desk. I've probably got more processing power on my phone nowadays.
The first mainframe I used was an IBM System 370/145 which had about 25% of the CPU performance of the VAX 8250 and not only had its own machine room, but an outdoor fishpond to help dissipate the heat!
DEC was not unique amongst the US computer companies in developing both hardware and software in the UK, nor even in its collegiate/campus atmosphere, but it was held in remarkably high regard by the people who worked there. Perhaps in the end it was just too good a place to work.
Interesting to see it finally being acknowledged by Reading. It was in many way a place apart and the influx of staff adding to traffic and house prices was not always locally popular. But also alarming to see my past already considered museum material.
I was the project Engineer on the Compact Vax 11/730 system while at Dec in Reading. This took a standard Vax 11/730, removed the top Disk Drive and replaced it with a TSU05 tape drive.
I still have one copy of the Flyer for it on the wall in my office. That was around 40 years ago. Sigh. How time flies.
"We had a VAX 8250, which was around the size of an SUV in its own air conditioned chilled room. "
There was a reason MicroVAXes were called MicroVAX, related to the reason MicroPDP11 were called MicroPDP11. Size isn't everything but sometimes its important. Speed can be important too, (helo Richard).
Waaay back in the 1980s size and speed of various IT things were one of the reasons why trustworthy email (amongs others) never caught on, what generally caught on was "cheap" rather than what was cost-effective by virtue of being based on interoperable vendor-independent standards-based hardware and software.
I worked for 2 summers at a DEC plant, testing RK06 (6.7 megabytes) drives as they came off the production line. It was a very educational experience for a grad student. Gave me a real insight into how my future designs would be produced, and great respect for the people who would build and test them.
2 platters in a removable pack, very rare now, as they were almost immediately superseded by the RK07 (14 megabytes) in the same form factor.
"I remember a small office with wall to wall,floor to ceiling folders. They explained everything! Hugely better than windows and Linux. Sorry fedora but Dec were better at documentation."
Yes, I remember well the "Orange Wall" (VMS 4.x manuals) and the "Gray Wall" (VMS 5.x manuals).
"And they would update the manuals too."
Yes, I spent at least one occasion sitting with the (ring-bound) manuals and a stack of updates (shipped with the updated pages shrinkwrapped onto cardboard) swopping the pages over.
Yup, TOPS-10 and TOPS-20 both had massive sets of documentation covering fairly much all the producsts Digital offered - even if you hadn't purchased them. Were the TOPS-10 Software Notebooks in blue covers and the TOPS-20 ones in a orangey-red to match the cabinet colours?
And the (seemingly) endless endless physically mailed out copies of the SPR (Software Performance Report) books with printed patches (you had to type them in and use DDT/FILDDT to update the executable, or edit the sources and rebuild) - and even newly submitted and unanswered SPRs. (Talking from the LCG - TOPS-10/20 - but I might remember RSX-family and RSTS/E too, but somebody else within my team was resposible for them) perspective here. Was it quarterly, monthly or every two weeks?
I spent several weeks of my life attending courses at both the Reading town centre offices and later at the newer buildings out towards the southern bypass. The town centre was great if you could stay in town and you didn't need a car - but it was essential when training moved to the new building.
While Reading may have been the UK HQ our focus was more frequenetly on the telephone support centre and centre of excellence for the LCG product lines based in Basingstoke.
> RSTS/E
Good grief, I'd entirely forgotten RSTS! The Engineering department were running RSTS, whilst the Stats dept had Unix, CompSci had something entirely different and the Pr1me lurked elsewhere. In my day you had to look at your schedule and carry around the correct cheat sheets for that day! You try telling the youngsters that.
Trying to remember what the big machine in the Maths dept was...dang, all I can recall is that it filled the machine room one year, then it transmogrified into a couple of cabinets looking rather lost in the middle of all that space.
Did get locked away with in an office with a half-height Vax (nope, can't recall the model, rats) for a while in one job, running VMS: I do miss file version numbers.
Back in the late 80s/early 90s I was regularly using several different versions of Unix on different CPUs, all with the same nfs mounted home, so my own scripts and binaries added the right ~/bin/bin.{arch} and ~/bin/bin.{os} tree to path.
I think the most at one time was 5 different CPU arch's and 5 different OSs: HP-UX/68k, HP-UX/HP-PA, SunOS/68k, SunOS&Solaris/SPARC, IRIX/MIPS, AIX/Power. We did also have a DEC Alpha/OSF1(?) but it wasn't something I was using.
When I managed to lock myself out of my engineering department VAX by using a password with a space in it (accepted to set but not for login) the system manager was able to read though the OS source, in SNOBOL, I think,find and fix the problem. RMS eat your heart out.
> original IBM PC (and AT) reference manuals
With the ring-binder BIOS listing - including the serial port code that "wasn't broken" yet somehow only worked after you'd copied it into your program and then swapped two config values around (eek, was it two adjacent bytes or two nybbles in one byte? Nybbles, IIRC). So if you had a working serial port, chances were you'd just pirated part of their (very) copyrighted BIOS...
yes manuals were very good even for the tandy built pc clone they put their name on. Figured out why adaptec scsi cards were causing memory errors. knew a lot of people who worked their just up the street in maynard. played space war on a dec in grade school at mit. had a handbuilt joystick controller. first computer game i ever saw/played.
The 2003 Cray Asci-Q had 4,096 Alpha 21264 processors at 1.25 GHz and reached 7.7 TFlops, and was #2 on the Top 100 in 2003. (About 1.9 GFlop per die).
My 2013 salvage e5-2697v2 runs at up to 2.7GHz delivering 28.5 GFlops (two each in my salvage servers).
A 2020 PlayStation 5 GPU runs at up to 2.2 GHz and delivers up to 10.2 TFlops at FP32 (or 643 GFlops at FP64).
Of these the PS5 sees the most use, why? Because it has the most interesting use case: Wreckfest 2!
Seen this myself :)
https://www.quora.com/Are-Chinas-largest-supercomputers-using-Sunway-CPUs-actually-based-on-reverse-engineered-American-DEC-Alpha-CPUs-from-the-1990s
As for the cost of Alpha, I rather suspect that DEC's decision not to sell the things to Apple in the early 1990s for what became the PowerMac series was probably what finally brought DEC down; if we could have had 64 bit processors and programs on the desktop in 1995, the world would be a better place now and DEC might still exist :(
I worked for a while at Macro Marketing back in the 80's and they ran the entire sales floor on a PDP11/70. 100 dumb terminals. I had my own VAX with just one graphic terminal on it for custom silicon design which probably spent more time running rogue than design software.
The PDP11/70 was eventually replaced by a pair of Amhdal towers (I think), but the software was never as good as the original suite.
The recent outage at Heathrow brought back an interesting incident where the emergency generator was religiously tested each week and fell over and back without batting an eyelid, until that is a real event occurred. The generator kicked in ran for a few minutes and then spluttered to a halt ... you need the fuel feed switched to 'main' and not 'reserve' ...
"The 1990s were not kind to DEC, and the once-mighty tech giant faded from relevance due to a series of business decisions that, in hindsight, proved detrimental."
The 1990s were indeed unkind to DEC. But it wasn't management that killed them and competitors like SEL. What did the Minicomputer vendors in was that they occupied a market position that was devoured by substantially less expensive "desktop computers" The release of the IBM 5150 PC in 1981 signaled the start of a two decades squeeze on the minis. They couldn't move up very easily because IBM and its cousins had the mainframe market nailed down. They were slowly devoured from below as PCs became ever more powerful. Nothing much management could do about that. They were managers, not magicians.
But the server market they occupied is still there, it's powered by the technology descended from what powered the PCs. I don't think it's as simple as the PCs devoured them from below. It was largely, I think, Unix mid-range servers that delivered the knockout before Windows servers came along.
A failure to push Unix, because of a fear of cannibalizing VMS? The UNIX wars? The attempt to use more expensive micro/mini hybrids like the Professional, DECmate, and Rainbow?
We might forget that Microsoft had a license to sell and distribute Xenix because they didn't have anything until Windows NT? I had a conversation with a NetWare consultant when NT came out - I used and wrote software for it. I predicted that MS would dominate that arena - He said it wouldn't, I said that, yes, it was better; but people were using MS software throughout their businesses and that would soon include networking.
I was trying to connect and network PDP/VAX/DG/Unix/CPM/Apple and then IBM PCs in the 1980s; and quickly realized it was cheaper and much easier to connect and utilize PCs on a LAN than the other "superior" systems.
I had a similar conversation with an uncle who was a consultant, he was insistent that OS/2 would be the future and was most dismissive of his 19yr old nephew who was installing 50 copies of WfW 3.11 for every one copy of OS/2.
Sadly and in spite of all the reasons it should have been, it wasn't.
I'm fuzzy about the timeline because my DEC days came a few years after they were big but I did work on PDP, VAX and even Alpha server with VMS and Tru64, they were great machines (still are I guess, I've not seen one for a decade because of changing job roles)
Er, it was.
DEC's management thought VAX clusters could win in the mainframe market. So they decided to abandon their key customer base in engineering, tech and academia to take on Big Blue in high-availability transaction processing. It didn't end well. Management couldn't figure out what to do with the Alpha chipset either. They let it die because it was too much of a threat to VAX iron. By the time it dawned on them VAX had run out of road, it was too late.
It's a shame because in general DEC hardware was well designed and well engineered. The company properly looked after its employees and its customers too. Companies like that aren't around these days. Sigh.
BTW, DEC's management fuckups are to blame for NT. They killed a project for a new Alpha-based OS in case it threatened VAX/VMS. That whole team pretty much upped sticks to M$. If that project had gone ahead, DEC might still be around today.
I don't often contradict other commentators on ElReg but I believe that the following statement simply does not hold water:
>> They let it (Alpha) die because it was too much of a threat to VAX iron. By the time it dawned on them VAX had run out of road, it was too late.
By the late 1980s it had become clear to Digital management that the 32-bit architecture inherent in the VAX (recall the initial introduction of the VAX-11 in 1977 made great show that it was a 32-bit extended architecure - Vitrual Address eXtension - from the 16-bit PDP-11 including a degree of instruction compatability: so VAX-11/780 etc.) had reached the end of the line and that applications and memory needed an address space of more than 4GB. Engineering had been working on the emerging RISC architectures (as well gaining experience with the MIPS-based product lines), and after one earlier attempt (PRISM - that's where Digital management did fail badly and attempted to purge RISC from R&D) that effort eventually further developed into the architecture that became Alpha. What had certainly happended arouind the same time is that the biggest dud of the VAX product line had been introduced and flopped - the so-called mainframe of the VAX-9000 family. That cost Digital dearly - both in $$$ and reputation. I worked with (or within a company that used) virtually every other possible varient of the VAX family (and most of the AXP/Alphas) but I do not believe I ever saw a 9000 in the tin. My employer certainly never ordered or bought any of them (we did order a 'Jupiter' but that's a very different Digital mainframe story ... ).
That is vastly oversimplyfing what happened I know, but what I'm trying to express is that it's my memory that the move to RISC and Alpha was because they could see that VAX's days were numbered. The threat came from other manufacturer's platforms which were already making the transition from CISC to RISC which by this point were architected to be 64 bit models. Something new had to come to compete with the likes of HP's PA-RISC and Sun's SPARC.
While there was a period of several years when both VAX and Alpha were being sold alonside each other, I don't think that was a significant degree of competition between them. Customers whose applications were not yet fully ported to run on Alpha continued to buy VAXen. New customers and those making strategic investment were basically sold Alpha products, unlesss they insisted otherwise. Some customers continued to buy both for as long as they could for different roles.
Indeed. I once had field service engineers from Systime and DEC in the computer hall at the same time - working on different kit of course. (For da yoof, Systime sold cheapo kit built from DEC parts.) The Systime engineer was stunned to see the 1-2cm thick and heavily insulated cables between the power supply and the backplane on our VAX. The equivalent Systime model used the sort of 1p/metre cable needed for a phone.
ISTR the DEC engineers explaining they were trained to remove rings, bracelets, etc before they opened up a VAX cabinet because shorting the power supply could have life-changing consequences.
"they could see that VAX's days were numbered"
That may be true. But DEC's management couldn't decide what to do about that and ultimately did nothing. Which was one of the key reasons why DEC died.
Half-heartedly selling VAX and Alpha alongside each other - because management couldn't/wouldn't decide - was incredibly stupid. It majorly confused customers and developers. It increased DEC's manufacturing and support costs. And it created an avoidable internal war between the Alpha and VAX teams. While they were arguing amongst themselves, competitors got on with gobbling up DEC's customer base.
It could have been *so* different if DEC had said "64-bit Alpha/PRISM is the future. 32-bit VAX/VMS is on the way out. We'll provide the migration tools so our customers can make the move over the next X years. Let's do this together."
Hmmm. Were you actually there? have you perhaps "oversimplified" somewhat?
"if DEC had said "64-bit Alpha/PRISM is the future. 32-bit VAX/VMS is on the way out. We'll provide the migration tools so our customers can make the move over the next X years. Let's do this together.""
32bit VAX/VMS *was* on the way out. 32bit *everything* was on the way out. This was clear to everyone except the Microsoft Muppets by the mid 1990s. Compatibility vs rewriite was the relevant decision, for DEC customers and Sun customers.
Migration tools and services were provided, by DEC and others, on VMS, and on Windows. Many were free to use. DEC already offered SCO on x86, Ultrix on MIPS and then there was OSF/1 on Alpha. There was Linux everywhere (from Alpha to ARM, and AMD64 in between).
For certain hushhush mrkets there was even a 64bit Alpha-focused version of VxWorks, licenced in a manner intended to be less frightening than the WindRiverSystems "pay per project" default.
But in general, Windows or Linux/AMD64 systems appeared, on paper at least, to be cheaper than the existing systems, Which is probably how we got where we are today.
The Wintel IT world was led by a collection of fools who knew the price of everything and the value of nothing, and who could convince people that they were never wrong. These people WERE massively wrong. But somone else's budget generally picked up the cost. of failure, and the Wintel disciples carried on.
From Stuxnet to Spectre, from Cloudstrike to China, these people WERE massively wrong. But someone else's budget usually picked up the cost, just as it seems likely to wiith the AI hypestorm.
Yes, I was there. I was a very happy DEC customer who was forced to look elsewhere when it became obvious DEC didn't have a clue about where to go and had no convincing story about how they'd move to a 64-bit platform. And FWIW by then, Sun kit was *far* cheaper and already offering 64-bit CPUs.
For the sake of conciseness, I deliberately didn't list all those turkeys you listed: OSF/1, Ultrix, SCO. MIPS, VxWorks, etc. [You might have missed a few.] These just underline how badly DEC's management had gone off the rails. Pick something, anything in the hope the law of averages might find a winner amongst all that dross instead of having a clear, understandable product strategy and a vision on how to achieve it. Reluctance to kill off VAX/VMS or make it 64bit was another institutional obstacle to add into that mess.
You're right to say 32bit everything was on the way out. But at that time DEC had confused/conflicting product roadmaps that made little sense to its customers. Worse, there was no clear message or product strategy on how they'd address that clusterfuck and make the move to 64bit. Excuse the pun. Customers had no way of knowing if they should go for Ultrix or OSF1 or (vapourware) VMS64 or... What can customers do in that situation? For me I spent my IT budget elsewhere rather than waiting/hoping for DEC to get its act together. Lots of others did that too by the look of things.
To be fair, Microsoft/Intel in the mid 1990s were targetting at best low-end servers. They didn't need 64 bit addressing yet for things like fileservers, whereas high-end scientific/database computing etc on Unix workstations did.
Intel trying to push everyone to Itanium shows they knew back then that they needed a 64 bit solution. They just chose the wrong way to do it and fucked up the execution, letting AMD in.
There's rarely a single cause of a failure. I'm sure DEC/Digital's management didn't help with some of their decisions, but the pace of evolution of the humble PC was quite fast. The PC was soon moving up into the midrange server market and, for their low (relative) price, PCs were "good enough".
DEC/Digital, HP, Sun, SGI, etc just couldn't compete. Even IBM with their "big iron" felt the humble PC snapping at their heals.
This article does indeed bring back some memories!
I don't think any of the UofA lab PDP's had floppy drives. That top unit is a fancier version of what I had on my first/second home machines - dual 8-inch floppies. Clunk! Whirrr! Clunk!
I *think* the only DEC machines I used were a PDP-11/45, a PDP-11/60, a PDP-9 and a fairly large VAX setup.
The predecessor of Draco was developed on the 11/60, until I found that the beast wouldn't execute some instructions properly (it did not like to be treated as a stack machine!), so I was let onto the 11/45.
First year at uni was all on their cluster of VMS VAX 11-750's that we accessed via an X.25 network. Between 2nd and 3rd year I did an internship at FMC at Warley who were also all VAX/VMS. Got to play around with various tape drives and removable disk packs (about 10MB istr -- which model would that have been?) whenever we needed to move our software down to Dagenham. A coworker told me his problem solving work flow was to first call DEC support to come check the hardware and whilst he waited for them to turn up he would have a look at his software.... He was only partly joking!
After that I got my first experience of unix on a university PDP 11 (wish I knew which model it was). I absolutely hated the absurd brevity of the commands and its all-lower-cased-ness as compared to the sophistication and refinement of VMS. But that set the direction for the next 40 odd years during which I've been pretty much exclusively unix. Two very different worlds, only one of which is still with us.
First year at uni was all on their cluster of VMS VAX 11-750's that we accessed via an X.25 network.
You may, or may not, be interested to know that the DEC X.25 software (for both PDP-11 and VAX systems) was entirely developed in Reading. Some hardware (and firmware) came out of Ireland and France, but the US was almost entirely uninvolved.
Might I suggest a quick revisit to the OSI 7-layer network model (other similar concepts are available)?
X.25 existed down at the Data Link layer, both TC/IP and DECnet utilised this network layer to provide Network Services (slightly simplified because both had parts of their protocol stacks than went down into and below this layer - but both could be run over X.25). As stated, X.25 was more prevalent in the UK and Europe. IIRC in North America the costs of pont-to-point (T1) circuits was significantly lower than elsewhere and later (I think) ATM services were more available and advanced there too, as networks evolved away from T1 circuits. I'm not saying that the IP layer of TCP/IP wasn't actually used to deliver a similar capability to X.25 over T1/ATM.
I write as one of the DECnet gurus of a major global chemical/pharmaceuticals company with it's own extensive private X.25 network (running on GEC minis IIRC). TBH, the overall implementation of X.25 (and the rest of the XXX stack) wasn't all that brilliant and at times failed to deliver exactly what the customer base needed - and I'm talking about the mid-to-late 1980s and early 1990s here.
For running DECnet(-IV) the options were basically a backplane devce or a network appliance configured as a single purpose router (underneath a modified PDP-11/24 and in various configurations ran X.25, SNA Gateway and IIRC pure DDCMP routing). But there were limitations on how many physical connections and speeds each box supported and, again IIRC, it was an OK solution for DECnet-to-DECnet but if you wanted to use it as an "Access Gateway" service for "triple X" terminal connections (from an X.29 PAD to a host service) it was actually quite poor and complex to set up and support.
For one application I worked on this period, we were running highly customised ALL-IN-1 on a VAX-8650 participating in a mixed-use VAXcluster (i.e. there were other VAXen in the VAXcluster but running different application sets, but sharing common infrastructure at the CI level). The users were the division's sales and marketting teams (amd associated hangers-on) - many working "on the road" or in offices away from the major divisional offices in Welwyn and on Teesside (where the computer centre was). They accessed the system if not in an office via dialup to a public network access point and some kind of PAD service then X.25 to X.25 links into the company. The X.25 Gateway solution didn't give enough throughput and the backplane solution (can't recall the product, but used a V.35 connection to the X.25 local switch) was, not to put too fine a point on it, unreliable and took compute resource on an already underpowered host. Not only that, if we had to take the 8650 out of service for maintenance (or whatever) because the X.25 connection went directly to it, there was no opportunity to move the service to another system in the cluster - even if that too had included it's own X.25 card that wouldn't have been a great deal of use as X.25 the address would have been wrong and there wasn't a straightforward way of load-balancing connections between multiple circuits using the single X.25 port address.
What I wanted. and asked for several times without success, was a combination of a beefed up X.25 gateway (probably microVAX based) running the whole X.25 (etc.) stack within itself and then using LAT over Ethernet for connectivity from the Gateway to the host. This would have avoided the CPU load problems on the ALL-IN-1 host and given flexibility and load-sharing had we expanded to run more than one dedicated ALL-IN-1 server.
Don't get me started on the later DECnet Phase V (DECnis) routing/X,25 products .... please (the nightmares haven't really gone away)! Thankfully, cisco were emerging as the MPR (multi protocol router) of choice by the mid 1990s - whatever we think of them today.
X.25 was only a thing in Europe back in the days when it was the only service(?) the monopoly telcos were selling.
Not at all. The difference was that if you had offices 2000 miles apart in the US you could go to AT&T or MCI and rent a leased line that was easily provisioned, (relatively) inexpensive, and ran on one company's infrastructure from end to end, so in the event of a problem you had a single throat to choke.
A similar length link in Europe might have crossed 3 or 4 countries, each with their own (often state-owned) telco, so provisioning a 2-wire or 4-wire leased circuit was a bureaucratic and technical nightmare, and cost a fortune. If there was a problem on the route they would all point the finger at each other and wait for someone else to fault-find. X.25 (and later Frame Relay) had all the advantages that IP has today, you just bought a connection from the local company at each end, it had good error recovery, and it wasn't your problem how the packets got routed.
It wasn't purely European either, at one point some of the world's biggest networks used X.25, including the airline SITA network used for exchanging PNRs for flights. Lots of financial networks, such as ATMs and early electronic point-of-sale terminals used it, it was cheap and easy to set up a new terminal and features like Fast Select were ideal for that sort of short connectionless exchange. Even until quite recently you could look at a credit card receipt, and spot the X.121 address used for the connection. The most recent version of the coloured book standards that I remember working with had even updated some of the timing parameters to allow it to be used on satellite links.
Former $WORK had a contract with ESA and communication was by VAX email over DECnet over X.25.
$WORK had an office in Switzerland, because timezones, and ESA were always amazed we could get one-day turnaround on document updates. The Magic was simple: emailing documents and comments from the Swiss office back to Canada where the timezones mismatched sufficiently that work was done essentially "overnight".
But. Our Swiss office could not interact with ESA and our head-office at the same time; there was no equivalent to a "jump box" or "gateway" in X.25. They had to manually switch the X.25 DECnet link between connecting to home office or connecting to ESA. Which was OK most of the time, except when it they left both links on at the same time. Both DECnets would be trying to route packets to multiple duplicate addresses. Ooops!
Interestingly (or not), I bumped into X.25 again a couple of years later in my first job via the Sunlink package for SunOS. We were working on handlers to talk to a stock exchange system that ran over synchronous serial lines so needed the HDLC low-level drivers from the package. This was all witchcraft to me at the time...
We were working on handlers to talk to a stock exchange system that ran over synchronous serial lines so needed the HDLC low-level drivers from the package.
I worked on Sun's X.25 products. It was really convenient that the early Sun systems used USART serial hardware that could support Sync as well as Async comms.
At one point I saw from the internal specs that newer systems (SS5/SS20 I think, but can't remember for certain) would use a newer serial chip. I contacted the guy who was working on them to make sure that the HDLC driver would still have the ioctls we needed, his response was something along the lines of "no-one told me we need to support Sync as well!". Since he had limited test gear for this we ended up co-operating on the driver, he wrote a new HDLC-capable Solaris driver for the chip, I did some review & testing. Fun times.
Rare as shipped from DEC, yes.
Fairly common for quite a few years as hand-me-downs in academia.
Surprisingly, some lasted well past their sell-by date. I have three of them, and about a dozen disk packs that still work. The plastics are getting extremely brittle, though ... if you run across any of this older kit in your travels, PLEASE ask for help from somebody who knows before messing with it.
We were doing speed tests. So, school PET v, Speccy BASIC v. compiled v. minicomputer.
I bagged the phone number from a mate and, ahem, borrowed some time. No idea whose machine it was. Easy enough to use though. I may have forgotten to end the program. I think 'Neighbours' was starting. The call of Kylie was irresistible. These things happen at the cutting edge of tech.
I recall being introduced to a PDP-8, running Focal, while at Polytechnic. It was our group's first experience of "hands on" computing. Previously we had to hand in paper forms with our attempts at Fortran IV, for the ladies in the office to transfer to punch cards, and then await time for them to run. We got our results about a week later, usually the printout ending in a big, red, handwritten notice saying "Program terminated - stuck in loop!"
With the PDP-8 we could watch our programs crash and burn in real time!
IIRC, the base unit had 1K of ferrite core RAM. We also had an add-on pack - the same size as the PDP-8 - which added an extra 4K! Programming was done via teletypes and paper tape, of which we had three. The fun we had inputting "GO?" and then watching the other users start panicking as their teletypes slowed to a crawl, whilst ours did a trace on our dodgy programs...
Happy days!
My first job was at Mostek in Carrollton a suburb located in north west Dallas County. I began working there in 1976 at just about the time they were going into full production of the 4116 16 Kib Dynamic RAM. They were already producing the 4096 4 Kib dynamic RAM in quantity and would go on to become the largest memory manufacturer in the world until around 1980 when the Japanese almost killed dynamic RAM production in the US. The main IC testing area was mostly filled with memory testers they designed called Masters using PDP 11's to performed the computational duties needed to test the DRAMs. There were also Mini-Masters testers that used LSI 11s. After a while they got tired of loading the test programs in using paper tape and connected all the testers to a PDP 11-70 using RS 232 interfaces. At the time the PDP 11-70 was the pinnacle of minicomputers. It sat in its' own room behind glass windows near the main entrance and every day as I passed by it I yearned to have one of my own. Of course at $10 grand plus that was not to be. I never worked with the PDP 11s, after a year working in Fab 2 where they made the 4116s as an engineering technician I moved on to maintaining the four Fairchild Sentry testers they used to test microprocessors and microprocessor peripheral chips. The Fairchilds use their own proprietary 24 bit processors and the older ones had 4 KiB to 8 KiB of core memory. Luckily for me back in 1975 one of my electronics classes included core memories. The newest Fairchild had 8 KiB to 16 KiB of RAM using Mostek 4 Kib DRAMs. Anyway, I always was impressed by the PDP 11s and was saddened when DEC finally bit the dust. The main reason for its demise was the lack of foresight by the man who had previously used his great foresight to create probably the premier minicomputer company in the world, co-founder and CEO Ken Olson. He failed/refused to see the microcomputer revolution coming and by the time DEC finally reacted with the Alpha CPU which could have been a real game changer, it was too late to save DEC. A little over three years ago I purchased a PiDP 11 kit which unfortunately due to life threatening health problems I have yet to build. That is one of the projects at the top of my list for this year and then I will finally have my PDP 11-70. With blinky lights, front panel switches and everything.
I never worked with the PDP 11s, after a year working in Fab 2 where they made the 4116s as an engineering technician I moved on to maintaining the four Fairchild Sentry testers they used to test microprocessors and microprocessor peripheral chips.
The second digital tester I programmed was a fair child sentry 7. It was a simpler time. I moved on to mixed-signal/RF.
When DEC systems appeared I saw everyone using Apple and MSDOS ... the DEC systems were so much better and way more powerful and DEC was always explaining how their systems worked so well, I wonder if their explanations to help their users resulted in a lot of other companies saying, "Oh look if we do that then our systems will be so much better"
The DEC systems were technically complex and physically complex but quite easy to work on them to resolve problems - that kept me employed to fix things around the world for years!
DEC made excellent computers throughout their history. One of the problems they had in marketing these products, especially to a much larger audience in the fast rising microprocessor age, was that they were very proud of them which priced them well beyond their competitors. The 8088 was probably the worst processor choice available (thanks Motorola) with the only advantage over the 6502 being it was able to (in)directly address more memory. The main disadvantage was the way the architecture addressed that memory using address segment registers, especially for large programs. Of course the 6502 address space was supplemented by paging in some computers but this had much the same problems as the segmented architecture. Even after Intel got it's act together with protected mode in the 80386 and beyond, the DEC Alpha architecture was well beyond them. By the time the Alpha architecture was acquired by Compaq who was in turn acquired by HP the writing was on the wall and the Alpha was no more. Some of it was spun into the HP Prism which was then in a joint venture spun into the Intel Itanic (sic) but we all know where that landed. The demise of DEC was a profound loss to the computer community.
The 6502 is still, to this day the processor I consider the best ever.
The 6502 ran rings around everything at the time. Double indexed addressing, made all sorts of things possible.
It is the processor that we should have had in PCs instead of the 8088
A real pity the Mostek went the way of the Dodo.
At work in the early 1980s we had a couple of Commodore Pets. We ran 6502 assembler programs which could do some impressive stuff, especially as the GPIB/IEEE488 routines were all encoded in ROM and just had to be called in order to control printers, etc. Of couse we were heavily reliant on Raeto West's comprehensive manual. We moved on to C using the Aztec compiler (remember .MAK files?), recommended to us because it was used by the CEGB in their nuclear power sites!
The 6809 had a better programming model, especially for stack handling (the Forth inner loop was tiny, and fast) BUT the 6809 was also really expensive, compared to both the 6502 and the Z80. Being in the UK, after the CDP1802, a 6502 machine really was the next affordable choice to own myself (Acorn Atom, in a kit, of course). And then you grow to love the machine that you actually own (and whose solder joints had the remains of your finger prints in them).
I agree about the 6502 'running rings around everything.'
Back when I & a friend - both of us sixth formers at the time - were setting up the computer science department for my grammar school so it could start offering computer science O-level to the lower years we started off with one ITT 2020 Apple ][ clone & one Tandy (Radio Shack) TRS-80, both with cassette tape recorders for mass storage, by the way. On paper the Z80 instruction set looked far more powerful but in practice the TRS-80's Z80 was seriously outperformed by the 2020's 6502 in terms of clock cycles required to perform a counting loop and similar basic operations. On the other hand, the TRS-80 didn't pop its RAM chips out of their sockets in warm weather but that's a separate issue!
The only thing from the Z80 that I wished the 6502 had had was a 16-bit stack pointer. The 8-bit SP and fixed stack page at 0x0100 basically meant higher level languages always had to implement a call/parameter stack in software. Having said that, it didn't slow down the amazingly fast BBC BASIC interpretter on the BBC Micro which had named & parameterised functions & procedures. This was several times faster than the BASIC on the expensive pre-PC desktop HP machines I later used at college. The BCPL, LISP & Prolog ROMs were pretty nippy too as was Acorn's ViewSheet.
Ah, nostalgia is not what it used to be!
Indeed. Its simple architecture made it an incredibly versatile controller engine for hardware. For example I once extended the single IRQ to respond to multiple interrupts by mapping a prioritised address generator to the fixed IRQ indirect address at the top of memory. And the 6502 was really fast for its clock speed, which helped as well. There are many jobs I now do with PIC that the 6502 would have done more easily.
a prioritised address generator to the fixed IRQ indirect address
Very cool. Your own NVIC but even faster! Kudos.
I quite like PICs too though but the 6502 was definitely easier - not a big fan of Harvard Architecture. Don't mind it in things like ARM IBUS/DBUS if it's hidden below the memory addressing but it just makes life difficult if it's visible to the programming model. Same way I don't like the separate memory and periphiral access model in the Z80 & x86. (Whay have IN/OUT instructions when MOV/LDR/STR work just as well!?)
I have fond memories of DEC. I worked with PDP8, 10 and 11 in various formats, as well as the LSI11 which **should** have been very successful.
Although DEC made some mistakes, these were not really their downfall. The industry was totally disrupted by the advent of cheap microprocessors that simply evolved very rapidly.
I often wonder what happened the the guy at IBM who promoted the idea of a PC. IBM at the time had the power of a medium size country. The PC killed mainframes in short order.
Some good, and some bad about it I suppose.
When I left University in 1981, I was interviewed for a job at the Irish facility in Clonmel (now better known for cider). I didn't get an offer, and went to work for BT in Belfast.
We got a VAX, and a colleague and I were sent to Reading for a System Management course, where we tried to see how far round the world we could get using badly-secured machines on DECnet.
OMG .... DEC-Mate II, my 1st computer bought circa 1982ish. Went to purchase an IBM desktop. The IBM salesman chose to leave waiting myself and a friend whom I dragged along as my "computer expert & adviser". After 15+ minutes of gazing at a blinking "C prompt", we went next door where I eventually walked out from with a $14,000-15,000 (approx $5,000 today) contract for a DEC-Mate II system complete with "dual floppy" drives, and a gray "Digital" shoulder duffel bag as souvenir!. The sales rep thought the 10MB (!!! - not a typo) would be over the top for my needs at the time, plus a printer and the complete 11-12 module accounting program which was the mainframe version of MBSI' RealWorld accounting package. Shortly after getting it up & running I could not stand the constant clunking of, and waiting for, the floppies so I upgraded to the 10MB HDD! Truly amazing that I could run a complete accounting system of a small/medium size company on just 10MB of storage yet had plenty of room to grow. Eventually I ran multiple corporations books. The 1st set of software documentation I received were actual manuscripts of the eventual software manuals: photocopies of the mainframe software manuals with hand written notes & corrections on converting from mainframe to desktop application. There are a couple of still unopened boxes of floppies (paid $50/box of 10, in 1984) somewhere in my office. I also still have all of the equipment except the amber display monitor. Also still here is all of the software in the original boxes. The complete payroll process was reduced from ~8 hrs to 30 minutes per payroll period!!! BTW, of the initial cost, software/hardware was a 50/50 proposition: $7k-$7.5k software/hardware. I still have the receipt as well.
That purchase was followed by a PCs Limited (Dell's company while still in his collage dorm) which I also still have, an Olivetti "luggable" (it sure as hell it was not a laptop at 35-40lb :?), and many many other 1sts, not the least of which a Windows 95 system with 4 single head video cards running 4 monitors.
As I recall, DEC was inflexible in their business approach, during a period of rapid evolution especially on the hardware front. IBM ate their lunch on the PC marketing front, and Sun Micro servers chipped away at the mainframe business. DEC's high price did not help either!
Here's an interesting fact (I hope) to astound you with: DEC had a 'product placement' in the 1984 film for its Rainbow computer. There's a short scene where Harold Ramis and the secretary, (who is filing her nails) are in the Ghostbusters office and Ramis is setting up the printer or trying to. The film was on telly this afternoon, and reminded me. Ordinarily, DEC never advertised publically, and it was only with the advent of the Alpha that ads started appearing on billboards.
This post has been deleted by its author
Enjoyed skimming all these "I remember..." comments, so time to add mine...
I was a developer on a VMS app in the 80s (the whole thing in VAX BASIC) and have fond memories of DCL - Digital Command Line. And I was blown away when I found it was extensible, and you could write your own command line interface for your own app, piggy-backing on the underlying system capability.
I still much much prefer typing (abbreviated) commands to clicking a mouse
The DEC Rainbow on display was donated to the National Museum of Computing by my Dad; it's on loan to Reading Museum. It ran MS DOS 2.2 on two 5 1/2 inch floppy drives of 360 kilobytes each, no hard drive. We had a very basic word processor application. I learnt a lot about computing on that machine, last using it around 1987, before it went into Dad's loft. Also, the Cray 1 I used to sit on drinking coffee in reception while working at Silicon Graphics in Theale near Reading in 1997 or 1998 is in the Science Museum. I'm still working in software and some of the first machines I used are museum pieces, what will we have to display from computing in the 2020s?
"what will we have to display from computing in the 2000s?"
FTFY.
The answer is "nothing". There is no modern kit worth saving. Kinda like modern cars, it's all bland, mirror-image same-same throw-away, with no design to speak of, and certainly nothing worth caring about or remembering three or more decades into the future.
I so wanted to be able to disagree with, so carefully thought about all the kit I've owned.
The Cosmac CDP1892, Atom, BBC, Amiga (replacement after 1st one went), some favourite MCU boards - all still sitting around here, somewhere.
After that - all various PCs, with CPUs from different companies but otherwise, yes, replaceable. A few items I've hung onto (mostly the cases, really) but the guts have been stripped out and replaced, or still working bits moved down the line "and the one on the end fell out".
It is a glaring difference, from the unique points in each of the old stuff, that the only things I want to hang onto are the black anodised (how goth!) bent pieces of metal, because it turns out that those are the things that matter when it comes to usability & how I can stack the kit. Whilst the modern guts inside are ok, so long as they still work, but can then be junked with out too much drama (and I do love my drama).
Nice to see the old kit again. I was a hardware systems trainer at Fountain House Reading for several years then CSS, and later in Sales. Started on the 11/45 and finished up on the 11/70 and RP mass bus drives via every disk DEC sold. Don't see much on the Internet about the Rp02, that was the one with 20 something volt logic levels that blew several cards when one went down. Would be interested if anyone has any Rp02 links to tech info, just for nostalgia.
Thanks to some family I got a part-time job with DEC in Denmark in 1983. I was only in my first year at Comp.Sci. at the university. Worked on a VAX 11/780 and a 11/750, with a network (ha! dialup) connection via DECnet to the rest of the world. Was hired to do some programming using the FMS ("Forms Management System") library for an internal asset management system.
Good times, then...
Sadly not for DEC direct, or possibly thankfully. The place was its own village and had shops barbers/hairdressers, travel agents banks etc all on site and a very nice company car pool fleet we had to organize.
And oh the whitely wiff
Now its a housing estate or something, havent been that area of reading for a while
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
