DEC: The best of systems, the worst of systems Which were the greatest DEC computers and why? Which were the worst - and why? Everyone has their own definition of greatest and worst, and exemplars of each, but I'm looking at the machines that had the most or the least influence. Since DEC under Olsen got a lot of things right, it's quicker and easier starting from the …
Who could guess where I studied ...
Main computer facilities were PR1MEs (yay !) and Norsk Data (running SINTRAN). However, tucked away in our faculty were two gems, a VAX 730 running VMS and a PDP-11. The year I started they had stopped using the PDP-11, so it was open season ... I got myself setup as an Admin, and taught myself sysadmin skills ...
Wonderful machine, for what it was.
Thames Polytechnic had Norsk Data and PR1ME machines in the 1980s, so I'd guess you studied there. I did too. We used the PDP-11 for cross compiling stuff for 8085 boards, so it was either the same faculty or they had more than one PDP-11. One of my mistakes used enough punched tape to go right around my room in the halls of residence. I also got the badge of honour on the PR1ME, which was to get it to respond "fatal error in crawl out". In my first year there the PR1MES didn't have a full screen editor, so there wasn't much "yay" about them.
My first real taste of industrial scale software development - writing a compiler, no less! Using 300b/s thermal printer terminals over dial-up. Learned a lot about s/w development, and even started investigating the chapter structure of GIII. Was probably quite hackable if I had spent more time on it, but we moved off that and on to PDP11s & VAXen on another project. RSX-11 device drivers in assembly code... Learned a lot on that project too.
.
.
PDP-15 -- like half a Dec-10, with an 18-bit word. Almost the same instruction set. Used 5/7 Ascii (5 7-bit characters) but stored in two words (with the unused bit in the middle).
Decsystem-20 -- the poor man's Dec-10, running Tops-20 (Tops-10 with a different hat on).
My first real programming job was on a PDP-15. It had core memory and the assembly language manual had a big red warning not to use the: "JMP ." (jump to this location) instruction as it caused thermal damage to the memory. Back then DECUS would give you a LISP interpreter that ran in 8KB or something minuscule.
Then I moved on to Dec-10s and 20s for a while.
I've gone all misty eyed. Time for a beer or three.
"Decsystem-20 -- the poor man's Dec-10, running Tops-20 (Tops-10 with a different hat on)."
There was of course considerable rivalry between the supporters of the two (mainstream) operation systems for the "PDP-10" family. (Other operating systems were available - but not from DEC). There is a recorded view that the DECSYSTEM-20 was indeed marketed at a smaller customer than the equivalent -10, and the -20 never evolved to support multiprocessing as the -10 did in the 1088/1099 models (two KL10As back to back). Where identical hardware (1091/2060 KL10-E) was deployed, you could probably attach more terminals to a TOPS-10 system. But perhaps that was the blue paint.
However, the two operating systems were significantly different. TOPS-20 was perhaps one of the most interesting Operating Systems of its generation and the internals were completely different from TOPS-10. TOPS-20 was perhaps even more thread and process driven than UNIX, and exploited virtual memory and mapping techniques that were not seen in other systems for another 20 years. There are a number of accounts available of the evolution of early versions of TOPS-10 into TENEX (with the addition of university developed paging hardware for the KA-10), and then ultimately into TOPS-20 at the hands of Digital themselves with the introduction of the early KL-10 - but -10 and -20 models ran different microcode to provide the different virtual memory management required (-10s were an evolution of the KI-10, -20s had the full native mode).
What is true is that many utilities and applications (including many DEC products) were shared between the two platforms and the availability of a compatibility package (PA1050) provided with TOPS-20 allowed aspects of the TOPS-10 stack to run under TOPS-20. To the best of my knowledge, native TOPS-20 code could never run under TOPS-10.
Both TOPS-10 and TOPS-20 were however evolutionary dead ends, sad to say. My memory is beginning to fail, but my recollection of TOPS-20 was that the bulk of the OS code was written in MACRO-20 and was highly tailored to the unique PDP-10 architecture with its 36-bit word structure. Extending memory addressing beyond the 18 bits provided in pre-KL and on the KS models always appeared to me to be a real kludge. (I generally found extended sections to be more trouble than they were worth.) It was this dependence on the hardware architecture that would have really prevented movement to other hardware architectures - as was proven as UNIX developed. It is perhaps sobering to recall that VMS went through several major re-writes during its lifetime, and that the OpenVMS that was ported across to originally the Alpha architecture by Digital and later to Itanium under HP (I'm still waiting to hear if it evers makes it to x64) bears little source code resemblance to the V1.0 version VMS that shipped for the VAX-11/780 in 1977.
(mines the one with 36 pockets)
TOPS-20... sob... I get all misty-eyed...
Over the years I've worked with/on these systems:
ICL 1903/George II
PDP-8 (assembler programming in PAL)
ICL 29xx/VME (I think... the memory isn't what it... erm...)
DEC/Tops-20
IBM VM/SP, VM/HPO, VM/SF, VM/XA, z/VM
IBM OS/VS1, MVS, DOS
various Vaxen
DR DOS, MS DOS, MS Windows 3/3.11, 95, 98SE, ME, 2000, XP, Vista
Apple Mac OS 8, 9, X
GNU/Linux (various distros, my favourite's Debian but don't ask me about the organization)
various others like BeOS, Symbian, the BSD variants, ReactOS, PETs, Zillog m/cs etc.
and there still isn't anything (not even my beloved VM) that can hold a candle to TOPS-20! Decades ahead of its time!
Sob, sob, sob...
Slag the Alpha as much as you will, it was still a performance leader until poor management killed it.
Much of the architecture used today in X86-64 cpu's have DEC engineers to thank for getting them to where they are today.
Let's also not forget DEC's contribution to storage. They had pioneering work in SCSI systems and created what is today's Storageworks division in HP.
Had the company had better leadership and marketing the current lineup of vendors may have been somewhat different..
Its the single best chip I've used[*].
We used an AlphaServer 1000 (a PC minitower sized box with a single 150 MHz alpha chip and I forget how much RAM, but probably 255 or 512 MB) to support an 18 strong development team, writing a system in C that sat on a RedBrick data warehouse. Members of the team used PCs running eXceed as terminals with a copy of RedBrick for everybody. Despite this load response times were excellent - editing and trivial commands were instant. I don't remember ever waiting longer than I expected to for a system build or a test run. The Alphaserver's only draw-back was the rather uninspiring Mach-based DEC UNIX.
[*] I say this despite the fact that I was and still am a 6809/88020 fan. I still have an OS-9/68000 v2.4 system that gets used several times a week. I've had it for almost 20 years and never fallen over a bug in the OS or utilities. IME only OS/400 can come near that record.
Yes, many interesting memories over the years. Here's one that few people may have realised was possible. Back in the late 1980s a certain large British (nay imperial) chemicals company was implementing a 'market intelligence' system based around the ALL-IN-1 products. Availability was wanted fairly much 24x7 (yes, it was on a VAXcluster) however as anyone who has designed infrastructure to support ALL-IN-1 will recall, it was necessary to ensure that the whole of the file store was backed up while fully consistent. That really meant shutting down the system and trowing all the users off while the backups were performed. Our solution was to use the (RA8x) disk mirroring capability of the HSC storage controllers to break out a member of the mirror-set(s), mount it up and run the backups against those volumes ... then of course re-sysnc them back into the mirror sets. EMC BCVs eat your hearts out - this was when EMC2 (remember the 2 superscript?) was still a bit player selling add on RAM and other boards. I still have the glass tankard given me by an EMC2 salesperson to prove it!
I guess that alongside the other great Digital systems I've worked on from DECsystem-10 and DECSYSTEM-20 of various flavours (including having a Jupiter order canceled under my future employer when the LCG part of DEC was killed in 1983 - does any body in the UK remember the York meeting when this was commincated?), a number of PDP-11 hardware variants and operating systems, virtually all types of VAX system (save the 9000 which ought to be explicitly called out in the list of DEC super-losers) and through into many flavours of Alpha with both VMS and Unix, I stayed an advocate of Digital storage through to the end of the true StorageWorks era and participated in the Digital Storage Fellowship programme.
So, like many others on this and other threads I too owe a considerable debt to Digital Equipment Company. Although I have never worked for the company, the skills and attitudes have left me well positioned to meet many career challenges. Even today, working in an outsourcing business it is still fun to run through asset lists from contracts to see how many VAX and Alpha boxes are still running out there. It's far more than many people might expect.
I deployed and administered Alpha systems for years. I like several things about this system
- speed
- clean 64 bit. There was never any 32 bit baggage lying about, and so no worrying about which friggin' kernel you're running, or if the correct libraries are installed.
- Tru64 Unix - Compared to other mainstream vendors, this kicked ass. One great example - fiber channel storage just worked. Another - ethernet link aggregation.
- TruCluster - Version 1.5 was administered from a single command - asemgr. The problem with so many clustering solutions today is that they are so complicated that they undermine uptime. Version 5.x featured "single root" clusters. No other Unix system could do that.
- Tech support, forums, and support in the open source community. Mostly, I could just build open source software and it would just work.
What I hated, was DEC's licensing program. If your licenses expired, you were dead in the water with a non-functional system. Not so good for national systems.
It was my way of circumventing procurement rules during dot.boom
In the company I worked at the time procurement and someone from engineering located in the higher layers of atmosphere set a rule: "Only Sun Solaris allowed". So the choice was between Netras and later Netra T1s which the deployment team stacked by the lorry load into racks and left powered down until needed (usually never). Both sucked performance wise and both ran only Solaris in those days.
So I circumvented both suckage by saying "I need 64 bit for my stuff, sorry, get lost" and ordered the Samsung Alpha PC clones and put Debian on them. 64 bit linux in 1999. It rocked. They could run circles around a contemporary dotbomb netra any day of the week performancewise. It is a pity that it died a slow death during all the mergers DEC/Compaq/HP executed in those days.
assembler, I have to say I loved the VAX architecture, reminding me immensely of the Motorola 68000 architecture.
The debug tool for VAX/VMS languages (all VAX/VMS languages, from MACRO-32 to C/C++ to COBOL) was also years ahead of many similar tools found on other operating systems.
"Don't get me started on the Alpha…"
Maybe I am sick but I really liked the Alpha. They were my first introduction to DEC/Digital and the great support and approach to their technical users that they provided at the time. I kind of worked my way backwards from Digital UNIX to OpenVMS, then VAX VMS in a kind of weird collecting responsibility for systems that began with 'D'. I still miss my AlphaServers.
Memories...
The thing about the VAX is probably a sacrilege - this was the system which brought 32-bit computing to the masses, after all... I started on a 730, well built but slow; then a few 750s, 780, 785 and ended with 8800 (and some 4000 as far as I remember). And also a few MicroVAXen, had one beside my desk, real object of pride (it was actually a VAXstation).
The Rainbow wasn't *that* bad when it arrived - comparing to the other similar pieces of crap we had at the time; one could run either CP/M or PC/DOS, but what killed it for us was the weird pre-formatted floppies we had to use. Anyway, I think we had only two of these.
You've missed the Professional 350 and 380 workstations - again something to behold... The 8800 VAX I worked with had one of these as its console... still remember how to turn the VAX on - wellm the command was 'POWER ON', given at the console prompt of the Professional ... all the fans then came together...
To this list I'd add a few 11/40s, a single 11/45 and several 11/70s, which I liked a lot. Got my first UNIX on one of these, although don't remember the exact edition.
As far as the PDP-15, at one stage I was about to start doing my master thesis (in interactive computer graphics, that was 1980...) on one of these - actually an XVM - so I went through the manuals and especially the assembly, but was lucky - the machine was deemed too sensitive for a student to use (it was used to design PCBs at the time), so my experience with these is nowadays limited to playing with SIMH - still have a few virtual machines running DOS/15. The master thesis had to be done on an early HP - 2637A, called "Intelligent Terminal" - had to program a lot of linear algebra, matrix analysis and differential geometry to get the thing running - in BASIC...
SIMH is also what I run when I want to remember the VMS days (the VAX machine running under OpenSolaris on a quad-Opteron is faster than anything I've seen in metal...). As far as the LISP machine mentioned, I got the interpreter running on a SIMH PDP-1 machine - weird... computes the S-exp after you close the bracket, no returns.
Memories...
It was sometime in the early 80s and I was more interested in what could be done with it.
We had some fine kit in the next few years. I seem to recall an Evans and Sutherland colour vector graphics display run by a bit-slice processor and with a PDP11 as its file store.
By the time I retired we had stereo-graphics equipped dual xeon workstation running Linux with access to 1024 machine Linux clusters for the 'hard' stuff. Some of the easier protein modeling took a weekend to run on dual xeon machines
Remember DEC's funny turn with the DEC-10 and DEC-20? They were a little bit cool.
As the the VAX.. I used to run a VAX 11/750 which had the innovation of running on single phase supply, which meant that you didn't have to rewire your office for three phase. Yes, that kind of thing actually helped to sell it in the old days..
No sorry, the KL-10 was by no means 'cool'. How many times did we find our DEC on-site Field Services rep curled up having a kip in the KL-10E (2060 ie an orange one) expansion cabinet? Very nice warm comfortable spot if I remember correctly among all that ECL logic!
Talking of KL-10's, was the 'Massbus' replacement CI and Ethernet option the most expensive NIC ever? My memory is of the order of $36K (Thirty Six Thousand US dollars) in the late 1980s.
BRIAN: I haven't got anything against the VAX. Consider the Alpha.
ARTHUR: He's having a go at the Alpha now !
------%<------
BTW what do you have against the Alpha ? My only personal memories were of a 500MHz Alpha Firestorm workstation I used that was the fastest thing I saw for years... and they seem very well respected in the HPC community.. so what gives ?
I still have a rosy glow about the day when, as an apprentice, I was shown how to put together a small programme on an PDP11( but don't recall the variant) then switch off the power, move the core store card to another machine and start it up and run my programme.
After that came the history lesson in bootstrapping with three way switches to feed in the commands...that was when summer where always sunny and big companies still hosted hog-roasts on open days.
"(Be prepared for an extended performance. Earplugs are recommended. So is a fire extinguisher.)"
I would also recommend a full nomex firesuit, down to the underpants. :D
Too young to have seen a PDP or a VAX, but I do remember the alpha- interesting chunk of hardware, that was.
I spent a lot of time working on DEC PDP-11 and VAX, even a PDP-10 system at one location. I was an accomplished RSX system programmer at one time, and I still admire features of that operating system that Windows has never gotten right.
I still remember the day that the local DEC sales staff came to our shop (a major DEC account) to put on a seminar on how Unix was the future (DEC having seen the light), after bashing Unix and promoting the advantages VMS for years. They seemed lost and uncertain, and in retrospect that was the end of DEC. The failure to launch a successful microcomputer, and the subsequent purchase by upstart microcomputer maker Compaq were just the nails in the coffin.
Had huge rooms of these to do satellite command & control, telemetry processing, etc., when I was a mission controller in the 70's & 80's. The PDP's just ran and ran 24/7 and virtually never failed. Even after the VAX was introduced, the 11/70's were kept to do the real-time stuff.
The only pervasive problem that I recall was when the techs took the systems down every 6 months or so for "preventative maintenance". Upon re-powering, more often than not, some of the "boxer" fans used for cooling failed to spin up again and had to be replaced.
Have to agree, that was *the* PDP, but I disagree about the VAX. Maybe not so simple, but clean and elegant. Macro32 was a joy to program in, what wouldn't I give for a MOVC5 occasionally :)
Nova? Can't comment, closest I got to DG was "Soul of a New Machine".
For a real flamewar, though, you'll have to go to OSes. Nothing compares to VMS, which was perhaps the last real OS to be *designed*, rather than to have simply evolved from a hacked prototype...
<nomex on>
"The" Boston Computer Museum was the result of Gordon Bell's personal project, the Digital Computer Museum, outgrowing its quarters at DEC's Marlboro facility (itself a relic of technological advancement: it used to be an RCA facility):
http://en.wikipedia.org/wiki/The_Computer_Museum,_Boston.
PDP-11 blew the Nova away. There was a reason Bell chose the 11 over the Nova architecture. The 11 architecture and the concept of auto increment/decrement general purpose registers which could be used as either data or address registers lives on in the Motorola (Freescale) 68000 CPU design (disclaimer: I used to work for DG designing comms boards)
//mine's the one with the (pocket sized) PDP-11 hardware manual in the pocket
TTY terminals with paper tape readers, machine code patches via computer front panel switch register entry, Mylar tape for "Golden" delivery. Magnetic Tape OS, Real Time OSs, even hybrid analog/digital computers using linear analog circuits for computing transcendentals because digital math was too slow. Rivalry between DEC, Data General, Prime and even HP.
Fond memories, all.
The DEC engineer said it would do no harm to move our 11/23 upstairs as long as we removed the disks first. What he didn't mention, and we didn't discover until several hernias later, was that the cabinet (about 5 ft high by 2 ft wide) contained huge lead weights for stability.
The company bought the 11/23 with a turnkey accounting package, but the MD haggled the price down so far that the suppliers went bust before they could implement it properly so the machine just gathered dust up a corner. I taught myself to program in Dibol on it.
I won't hear a word against the VAX or VMS. Exploring the amazing system sevices and run-time library was an unending source of fascination - and the results were often actually useful. It would make my day when I could find an excuse to use LIB$TPARSE, a finite-state parser. (What a saddo!)
PDP11/70, 11/85 running RSX and RSTS/E were the first 'proper' computers I used. I remember when we started moving over to VMS - we took delivery of the systems and the biggest bit of packaging by far was the wardrobe-sized documentation set!.
I also learnt about telecommunications accessing Essex Uni's DECSystem 10 timesharing system via JANET to play something called 'MUD', which I believe was the world's first multi-user adventure game. A £600 local rate quarterly bill resulted, and this was nothing to be sniffed at, especially at early 80's prices!.
As a computer science student, I fell in love with VMS as an operating system - it and the VAX were the architecture reference used on the course. I continued to work with them for years afterwards and always appreciated the rock-solid reliability and multi-year uptimes that they provided.
I later moved to programming and spent 20+ years on VMS systems VAX and Alpha.
The VAX architecture was for its time the best by a long way, easy to use, easy to debug, and probably still the most stable and reliable OS you can buy. There may have been some instructions that were hardly ever used, but DEC did the right thing when it came to machine checks.
Every (and I mean EVERY) instruction possible on a VAX was ether correct and verified or it was guaranteed to throw a hardware exception. This was also true of the Alpha, so unlike the early SPARC, MIPS and other processors you couldn't crash a system from user mode just by creating duff machine code.
As a result DEC were able to both add and remove instructions in later hardware and just add code to the exception handlers.
For example the MOVC3 and MOVC5 and other instructions were not in the MicroVAXs hardware, they became functions in the OS that were called when the CPU throw an exception.
Likewise the later Alpha CPUs had new instructions for accessing single bytes in memory, this improved performance of later Alphas a lot, but running that new code on older Alpha would run (slower due to the exception handling).
Likewise VMS was (and is) source code compatible with all previous versions, and image compatible within a hardware platform, so I can run a program compiled 30 years ago on an 11/780 and it would still run on the MicroVAX I have at home or a SIMH emulator today.
Somewhat different to the crap OS's we have today with Windows or this weeks release of Linux not being compatible with a year old application without a rebuild.
I'm certain anyone who truely got to know and understand VMS misses it.
PDP11/45.
80Kwords of RAM - 4Kw Shared with a PDP 11/05
TWO Unibus Repeaters
Two RK05 Disks
I TU45 Magtape
All sorts of A-to-D & D-to-A plus digital I/O stuff. Including a programmable clock
The software was a mixture of fortran & Macro-11. It ran in a 20mS cycle controlled by the clock. The applicatino was driving the Avionics System for the RAF Harrier. This was 1975 at Hawker Siddley, Dunsfold (Where Top Gear comes from).
Man that system was good. The 11/45 was about 250KHz..... Kilo Hertz. not MHz or GHz.
Now for my confession. I worked for DEC from 1979 to 1999. I was the systems Engineer that took the RL02 drive off the top of the VAX 11/730 and put a Tape Drive in. We called it the Compact Vax.
Now I'm off down the pub to toast the great team of people I worked with at DEC CSS in Reading.
jrst @ .
Happy days clocking up 'resource units' used in the dark hours of early mornings.
However, as to its OS (TOPS-10 presumably) being rock-solid - Not when it came to a batch file which assigned too many drive letters, popped the kernel stack and brought the whole system to a shuddering halt.
The Alpha processor was the hottest ticket around when it came out. The company for which I worked had embedded DEC engineers, and they could hardly contain themselves. The big problem was how much a system like that cost, and so it was never going to end up with home enthusiasts.
The thing I remember about VMS was that the root user wasn't top dog. There were also a few bigger accounts, including the site engineer account. User: site. Default password: engineer. I still wonder how many DEC systems never had the site engineer password changed.
You Unixhead, you!
You mean SYSTEM (password ADMIN). I don't remember it being a more powerful login than FIELD (SERVICE) though.
Then there was the one that so many sysadmins forgot to disable, UETP. Amazing how many VAXen on JANET still had the default password for that... (not that I'd ever have taken advantage, of course)
First computer I used in 1980 was a TI-990/10 using an operating system called DX10. There is former TI engineer who has put up an emulator on his web site, so I was able to spin up a copy on my PC recently. I was amazed I could remember exactly how to create and run programs in the assembly language.
At Thames Poly, I also used Primos, which I thought was a great OS. I too used the Norsks with the dreadful SINTRAN OS. It allowed abbreviated commands AND filenames (no wildcards). In the COPY-FILE command you specified the destination file as the first argument and then the source. Not only that, the hardware was abysmally unreliable. Don't even mention the Unix port from Norsk, NDIX.
I also used numerous VAXes including the TP 11/730. Great machines.
"Don't get me started on the Alpha…"
How dare you trash the Alpha. Heathen!
The Alphas might have been power hungry heat pumping beats, but they screamed performance wise. Not only were they fast, but their design was a HELL of a lot cleaner than anything Intel ever designed. They were clean, fast, and just all around awesome.
At least when buying Alpha gear from DEC, you knew you were buying a machine that could literally get the crap kicked out of it on a continual basis and not even flinch. I wish I could say that about our Sun gear!
A friend of mine got himself an Alpha 233 workstation back in the day, he used it for photographic rendering, the heavyweight architectural stuff. It ran Lightwave on NT4.
It was nearly an order of magnitude faster than top of the line Intel based machines or Macs.
It now sits in a corner in my lab, minus its Quantum Atlas SCSI HD (long dead) and its CDROM drive (ditto).
When I'll get round to it, that is, when I'll be able to locate the above two items at less than extortionate prices, I'll fire it up and put BSD on it, just for the heck of it.
Some of the MIPS Rx000-based DECstations/servers were quite impressive machines and ran Ultrix, a fairly vanilla BSD Unix variant. The only problem was that they were introduced late in the game, and DEC salespeople would rather shoot themselves than sell you one. I remember explicitly asking for a DECstation 5000 quote, and then getting a visit from the DEC rep pushing VAXstations.
VAX-11/780 was my first taste of DEC, but in truth I had more fondness for the dinky little PDP-11/03 that bootstrapped it. Some years later I worked with VAX 6xxx's, and they gave so little trouble I took them for granted. Still later I worked with Alphas, they were quick, they were reliable (running NT 3.51 or DigitalUNIX) and they were a joy to cut code on. It took me less than an afternoon to grok the disassembled output of some broken C code having never seen an instruction set manual. My all time favourite ISAs are Alpha, T222/T800, 6809, and VAX-11 for the sheer kitsch of it (the -11 bit isn't just there for show folks) ... PDP-11s are fantastic boxes too, but I never learnt to enjoy the PDP-endian thing.
I find it odd that DEC don't get more credit for what they achieved with silicon down the years (as a low-volume niche player they had the odds firmly stacked against them). Time and time again they pushed the back boundaries with the -11, the uVAX and the Alpha. What would you rather have to cut code on 6MHz 80286 or a 15MHz J-11 ? Then years later you had the choice of a 333MHz PPro or a 600MHz 21164.
Those were fun to play with. I remember building an RT-11 system on an 8" floppy and having it print some scary console messages when booted. Swap the floppy with the 'VAX' boot one and watch the sysadmin trying to figure out what the hell had gone wrong with the 780.. :)
These days they're called "service processors" and boot from flash. Takes all the fun out of it.
Another +1 for the Alpha here -- I was a placement student when I first came across DEC kit in the form of a DEC 3000 supporting a not insignificant development team. In a world of 32-bit, 64-bit seemed like the future :-) I now have a DEC 3000 acting as a monitor stand on my desk, but keep wondering what I could use it for if I powered it back up again...
I had the opportunity to work with both systems at the same time. The differences in architecture really came out when there was a hardware problem. With the Nova, the Data General tech would show up with a 14" x 14" board extender, coat hanger (no kidding), chip clip and digital scope. Each board had more than one function on it. He would stand there with the print set, scope and probe around until he figured out which chip was bad. Then came the soldering station.
When the PDP broke, the DEC guy would drop the diagnostics pack in the machine, run it, figure out what was wrong and replace the card. Each UNIBUS card did one thing. Serial Mux, memory, card reader interface, etc.
Maintenance was quick and efficient for the PDP. The Nova was an interesting exercise in component level diagnostics and repair in the field.
A big selling point and what put the PDP on the map was the open architecture. Anyone could (and did) build cards to go on the UNIBUS that did all kinds of things. DEC would even ship a print set with the system. When DEC's prices for peripheral hardware were twice (or more) of the going rate in the industry, someone would come along and develop a solution that would beat the DEC price. Remember the RM02 and RM03? It was a CDC 976x drive. 3rd parties designed and built a controller for the standard drive and sold them for a significant discount over the standard DEC hardware. This continued on with the advent of the Q-Bus in both the PDP and VAX. I build many a MicroVAX with 3rd party drives and memory. When DEC balked at supporting the hardware, up popped companies to provide support.
Then came the BI Bus. Its closed architecture required you buy an expensive "license" to design and build a card for the BI bus. Designing a board was complex and expensive. Guess what. No devices that competed with a DEC product were granted a license. The cost a DEC system went up and people began to look to other solutions.
This has played out over and over in the industry. Fruit computing vs. the IBM PC is yet another example. Closed architecture never leads to the growth that open architecture will in the long term.
Spent the Dinnertimes at Tech College playing Lunar Lander on a Dec PDP ??
with RK08 disks GT40?? Vector terminal
I Went From this is GREAT (How do I Build One)
Then to the 77-68 Then Acorn Atom BBC A/B Amiga, I all ways Wanted a Alpha
By The Way You COULD Screen Edit On A PR1me
We Had Dacoll Terminals with a Custom ROM it could display Teletext also
(Any Colour as long as its Green ) & Software on the Prime to Do Full Screen Editing...
I've not replied to any of the commenters because I've been having too much fun reading the comments. But *this* one! I had the pleasure of working along side Jack Burness in the early '90s. Jack was the creator of Lunar Lander on the GT40, still one of the best hacks in all of computerdom. One day, while rummaging through my trove of retro-computing documentation, I came upon an original green-bar source listings of Lunar Lander, with marginal notes written in Jack's handwriting. I presented the listing to him, and was very surprised when he reacted with horror.
I guess he'd had quite enough of Lunar Lander by then.
I, myself, am a Spacewar! fan. I've nothing against the PDP-1 version, except for speed, but in my mind the canonical version ran on a PDP-7 with a 340 graphics display. I might have gotten my bachelor's degree 2 years sooner had I never met Spacewar!
-G. Rochat
..the lacerated fingers.
Thing I instantly recall about DEC PCs was the razor-sharp, unfinished metal edges inside. Very nasty to work on, especially as they seemed to go for ultra-compact layouts which meant digging-in tight corners to fit HDs etc..
Only ever pulled one PDP apart, and I don't recall it having the same 'sharps' problem as the PCs.
(There isn't a thumb dripping red stuff icon so..)
We used a PDP-11/34 and later an 11/70 at Caltech's Space Radiation Lab. The 11/60 let you write user microcode. Not a bad machine, but just no market for that capablity.
I don't agree with the comment about PDP-10 vs. VAX. But certainly the PDP-10 had a huge influence. A whole generation of academics grew up on TOPS-10, and there was quite a culture clash when they met up with Bell Labs UNIX. The modern UNIX is sort of a blend of philsophies, Bell Labs ideas about simple tools and modularity with the TOPS-10 style of big feature-rich command tools. "ls | c" vs. "ls -c". Not that much simplicity is left in modern bloated UNIX systems.
VMS was a good system, not the greatest user interface, but much better technology under the hood than UNIX. Berkeley tried hard to bring UNIX up to the level of VMS, with a decent file system and virtual memory and proper libraries and linkers. BSD never could beat VMS's performance, and UNIX never had really good compilers like DEC's until pretty recently.
The alpha was not too bad, but a huge power hog. To get clock syncronization, they drove a separate metal layer with a meter-long transister (folded up into a little square in the center of the chip). "TICK! TICK! TICK!" was what people jokingly said about alpha's clock.
Seriously, though nice list. I didn't even use most of these (other than running a MicroVAX briefly) but it STILL brings back nostalgia, because I was way into reading old 70s and 80s folklore of those who did.
VAX? Architecturally, I must agree -- it was like the ultimate CISC chip, just throw more and more instruction sets on. This thing even had an instruction set specifically to accelerate COBOL. But, this worked out pretty well since people actually did hand-written assembly back then to a much larger extent than now, so having an extensive instruction set to use made that nice. And I think they became pretty culturally significant.
Alpha? Don't know what you had against them. I can't say the systems had.. well lets say the personality... of the older systems, but they sure were fast, and had pretty wide OS support.. besides DEC UNIX, VMS, and the brief Windows NT port, they also have Linux and all 3 main BSDs (Open, Free, Net) ported to them. After Compaq bought DEC, and HP bought Compaq, they should have kept up on Alpha development -- that was a fast chip, and quite a nice instruction set and overall design that would have allowed for much faster chips if they'd kept developing it.
@FrancisKing, Yep the infamous field service account. Username: FIELD, password: SERVICE. If you look up the Phrack issues from the 80s, it seems there were huge numbers of systems with default passwords back then, and people would essentially take the odd VAX or Prime for a joyride. (People now would assume the reason to bust into a computer would be to plant viruses or trojans, cause mayhem, run bots, or steal info. But back then, the "big iron" really had a mystique much more than now, and many the school-aged kid within local call of a university of X.25 dialup would look for these systems just to get to a command prompt, maybe pull up a process list or directory listing, and then log back out, like being able to touch an exotic car in a sense.)
The PDP-14.
This was meant to be an "industrial" controller (nowadays called a PLC) that one programmed in pure Boolean form, no "language" as we understand it was available. Once you had your program all designed, you sent the design to DEC and they would create a core memory board with the Boolean logic implemented by weaving wires through the cores. The resulting board was shipped back and you put it in your PDP-14, turned on the power and prayed you hadn't made any mistakes in the Boolean that would result in a machine malfunction. If you had goofed, you had to go through your Boolean code again, send the corrected logic back to DEC and wait for a replacement board. Meanwhile, your production machinery was down and you weren't making any money.
We had one (and only one) machine that had a PDP--14 that had gotten programmed correctly so nobody in Manufacturing Engineering was allowed to request any changes to the machine.
PDP-14's didn't last long being beaten in the market by Modicon 084's and Allen-Bradley PLC-2's that used standard computer memory and were easily reprogrammed at the machine with a "programming panel" that translated "ladder diagrams" into internal machine code.
----------
I know of one Data General Nova at the University of Michigan that became so hated by both the sysadmin and users, they took up a collection, rented a backhoe which they used to dig a six-foot deep hole in the lawn next to the building, then tossed the Nova from a third-floor window into the hole, back-filled it and tamped it down hard.
-----------
Not all of us old timers had BSCE's. My degree was in Physics, but I still groked how a computer operated almost at an organic level. I often could literally "see" the code working and the bits moving about.
Vax written off in just a sentence! Sacrilegious! As recently as five years ago I worked on 3 Vax systems, two of which were running a financial and a safety critical system. Reliable as hell, but any graphic screen changes (where supported) were, well, just a bit slow.
'Rubber banding' was basically clicking the mouse button (and they were awful mice) and then dragging to select, but nothing would actually happen, not even a dotted outline. Returning after a cup of tea would have resulted in the 'selection' of the desired icons etc. However if you'd have let the button go at the wrong time, and had not selected what needed to move/change etc. it was time to click, drag, and have another cup of tea...
You, sir, have a rather peculiar sensibility, that I cannot bring myself to concur with (*)
VMS, DEC machine code, Assembler, JCL and Ultrix were my best friends back in the day.
* : Downside was seeing a VAX (I recall it being an 11/750) swapping out its VMS Swapper, thereby requiring a hard restart.
Scripting to rename my user process to a preferred (not currently chosen) Process ID was also standard practice. Being a Marillion fan, "Warm wet ()()()" was first choice.
Interesting that you should consider VAX not Gordon's best work, and lacks elegance. Well as somebody who wrote device drivers for DEC in the first days of the VAX and for 10 years on PDP 11 I for one consider the VAX some of Gordon's best work.
While the PDP had an elegant instruction set you still wrote code for the hardware.
The major step forward on the VAX was that the hardware was designed for the operating system. Take a look at how the Exchange/Jump instructions work and you will find hardware that automatically dumped process context onto the stack or the process header. Suddenly when you called a subroutine/function the interface was through a hardware instruction that put the calling parameters into a frame on the call stack. The hardware was so integrated with the software that when we upgraded from VMS 1.0 to 2.0 we changed all the CPU boards.
Next lets look at Virtual memory, in 1978 we were in an office with 8 users running all the packet network development code, with one 11/780 which had 256K of memory. It was still quicker than we got from our 11/70 running RSX-11M+.
The VAX took DEC from a small computer company to a monolith that didn't know how to spend its money. There are many reasons to show why DEC got it wrong, but VAX/VMS was not one of them.
Though the PDP 11 was my first love after programming a CDC 6600, VAX/VMS was spectacular with an instruction set that made high level languages obsolete. It was only later when we returned to MIPS/INTEL/RISC/ALPHA hardware, that we lost the wonders of the 11/780 instruction set.
PDP-11/34 seemed so high tech in 1988, yet I suspected I had more power in my Atari ST at home? Had to use one to download data from flight data recorders on GR5 Harriers!
Plug in the "Black Box" which is actually bright orange, (only goes black when it gets burnt, but it is fireproof) select the data sources you wanted, get a print out on some weird multi trace wet plotter, then hang the traces to dry or all you got was a huge multi-coloured smudge.
Possibly for @Chavdar Ivanov
I started my computer career using a PDP 15/20 to design printed circuit boards - as far as I know we were the ONLY company producing that software - REDAC.
I remember being on a night shift and had gone for a break and the fire alarm started - oops back to the computer room, and there was smoke pouring out of the machine, I just had to get the DEC Tape (remember that media) off the machine as it had my designs on it!
Closed the machine down ran around the building trying to find a CO2 fire extinguisher - I was ex-military and we expect things colour coded 'correctly' Black and white. EU take note!! Having all fire extinguishers RED means you have to be able to read English in a hurry with smoke all around you - stupid :-(
Found one and put out the wee fire.
That 32KB machine was repaired and back in operation fairly quickly and shortly afterward we had an UPGRADE to 48KB.
Great machine 1MB fixed head hard disc 2 foot in diameter at least.
Thats computing for you.
Having sampled the wonders of punch-card batch-programming in Fortran on the UNIVAC-1107 in the mid-'60s and with a subsequent stint in navy communications and cryptography - which were just going digital at the time, I returned to grad school to find a new PDP-8S being used to replace electromechanical logic-programming devices for data acquisition and control of behavior and physiology experiments. Data analysis was done on an interactive IBM-360 in various languages.
Say what you will about stodgy serial data-buses and scant core memory, as a student, the experience of "toggling in" the "boot-loader" from the front-panel toggle switches (in octal), subsequent control programs from paper-tape - bringing a heap of dead digital circuits and core-memory to organized life one step at a time, mastering my first assembly language, writing interrupt service routines, and creating critical programs on which expensive research depended, provided invaluable insights into the workings of and appreciation for subsequent micro-processor systems with all the basics automated and choices of low, medium and high-level languages.
In the almost 40 years since, I've seen many changes, stayed with most of them to produce ever more capable data acquisition, control and analysis systems, and developed a hypothesis about programming and programmers that I've yet to see violated.
That is, The "level" of programming (assembly, low, medium, high or specialized apps) which one masters first and in which one produces the first complete project, sets the level below which an individual rarely, if ever, masters or succeeds. If starting with a medium level, higher levels will be easy to appreciate, grasp and utilize, but lower levels will frustrate and be abandoned. Unfortunately, most programmers today started with medium- or high-level programming and have little feel for what's going on "under the hood" of their compilers or libraries, much less, the operating system controlling their apps. They argue "why should we?" at which point I find something more productive to do than argue with someone who doesn't understand the concept of actualizing the full potential of a given amount of compute power. It might be claimed that it's all relative to the resources available and the incentives, but that misses my point.
2am, in a computer room, with a Cray Engineer wondering why our Vax would not connect to the brand spanking new Cray XMP. Out with the pulse oscilloscope and digital signal monitor, crocodile clips on the massbus, and HEY - we found two pins bent on the mass bus plug so that touched.
Job done and a very happy bunch of seismic engineers next morning.
I loved that job.
In their day, yes, though in their day they were designed for fanless heat sinks because fans were considered too unreliable.
These days, routine desktop and server chips use almost as much power as the early Alphas and folks are perfectly happy to rely on fansinks (150W max for Alpha 21064, 130W for current x86).
"clean, fast, and just all around awesome."
That they were. Not just in the nice clean architecture and instruction set, but some of the system design features such as integrated memory controllers and a high speed bus for glueless SMP etc. Even Intel eventually caught on to those ideas, once they realised that IA64 was on the road to nowhere.
@Steve Davies re CSS
You and I will have to disagree about the importance and significance of CSS. Important, yes. Positive contributor? Far from clear.
In my experience initially as a customer and later as a DEC employee (though not in CSS), CSS entirely deserved their popular nickname of Cowboy Special Systems. Some of the products (such as the Compact VAX) did indeed address an interesting and valuable niche, but mostly CSS in the field seemed to be about being creative with DEC internal accounting so that two sales teams (CSS and the customer's own account team) rather than one could get credit for the same sales.
"All sorts of A-to-D & D-to-A plus digital I/O stuff."
DEC sold some handy stuff much of which was rebadged Data Translation cards (at least on the Qbus kit I used). Nothing necessarily wrong with that except unlucky DEC field service engineers typically didn't have a clue about "calibrating an A-to-D". Understandable but unfortunate.
"Including a programmable clock"
KWV11 was the Qbus version. Was it another Data Translation card? I can't remember.
National Instruments have long since taken over that test and measurement computer market. Their prices in comparison with the alternatives make DEC vs its alternatives back then look quite affordable; how on earth do NI manage to do that and stay in business (other than by lots and lots of advertising and marketing, eg Processor Brian Cox as keynote speaker at their most recent UK user group )?
And then there was the CSS Qbus graphics boards. Even in the days when workstations were taking off (after even DEC field management realised workstations were going places), there were CSS folks trying to extend the outdated VSVxx line. Madness.
DECdirect UK?
In the former Reading HQ (now demolished), not far from CSS, but a whole lot smaller and more productive, lived DECdirect UK. In the early 1990s their performance in terms of product awareness, demand creation, sales support and product delivery put most of the official box-shifters er sorry "channel partners" to shame, which is why DECdirect UK had to be abolished. DECdirect UK even produced useful glossy but not content free catalogues (later for UK+Europe), with information and prices for most of the commonly ordered stuff (software as well as hardware). They also managed together with the factories (primarily Ayr) to get commonly ordered stuff set up to do 5 day turnround from order to shipment, which was unheard of back then, and is still not entirely routine these days.
Tell that to the young people of today and ... you know the rest.
I worked for a software house that wrote warehouse automation software, and one of their clients was still running on a pair of MicroVAX 3200 machines when I left in 2003. The company had one Fortran programmer on the staff solely to work on enhancements for this system, since all the other clients were running a sucessor system written in C for Alpha hardware.
During my time there I acquired an unused MicroVAX 3200 (it had been kept boxed up as a spare) and a PDP11 (a 23 I think) that had been decomissioned. I still fire up the 3200 occasionally, now running NetBSD, and it is a beautifully built machine. I also got a VLC, which has colour graphics and was a good desktop machine - especially if you developed for VMS.
The PDP was rudimentary inside, and sounded like a jet plane taking off when you fired it up, but I gave it away to an enthusiast since it lacked a RAM card (what I thought was the RAM card turned out to be a custom board of unknown purpose).
We have run our business on PDP hardware since the early 1980's and may be one of the last remaining holdouts doing so. We have slowly archived and migrated over 25 years worth of data to a Windows network, and for the most part all of our processes have been migrated to modern platforms. We still have one business process still running on a PDP 11/84 (but not much longer). We have accumulated quite a collection of spare PDP boards and other parts, and still have a functioning tape drive and storage units. I'm not sure what we're going to do with the systems. Wondering if anyone else knows someone still running the 'old iron'.
I can't understand how anyone can denegrate VAX.
First encountered DEC kit in the form of a 2060 running TOPS-20 at the Poly of Wales (now the University of Glamorgan), programming in Pascal and COBOL using LA-36 teletypes at first and then VT52's. Managed to cajole the ops staff in to giving me a login on the 11-750. Spent a year working for DEC at DECPark, Reading as part of my BSc course where I got to use various VAXen, Pro-350's and -380's, the odd Rainbow. Fell in love with VMS at version 3.7. Sponsored by DEC for my final year project doing data warehousing in Rdb/VMS then went back to work for them after graduating. Moved to a software house developing on a MicroVAX 2000 and then a 3100, before contracting for them at various times. Messed around with LAVC and VAXstations (kinda had a love/hate relationship with DECwindows).
For me VAX/VMS and the layered products were the business, providing superb development and production environments. Alpha could have taken up that mantle with better management. Seeing the emasculation of DEC as products and divisions were sold off, then the Compaq takeover and the subsequent HP takeover leaves me feeling sad still, even though I've not touched a VMS machine for 7 or 8 years.
DEC was my first job out of school in the '70's. I had interviewed with IBM (amongst others) but was turned down for my grades being too low. DEC hired me because I had a bunch of real-world design experience while I was in college. I'd also been responsible for the maintenance of the Chem dept's PDP-8/i and was an operator for the engineering department's PDP-8/e.
My first job was working on the memory and memory management for the 11/44. One day I was cussing out the board, looking at timing issues, when I hear this guy behind me say, "What's wrong?" Without looking up, I said, "Oh this damn memory timing is off," while turning around, and there's Ken Olsen and Gordon Bell, doing their walk-around the Mill labs. They were then doing the "oh have you checked XXX?" and "let's hook another scope up to the row lines and see the timing there." I've never worked in another large company where the CEO was grabbing test leads and looking at debugging information!
As I said, I worked primarily on the 44. I also worked a little on the still-born 11/68 (11/60 upgrade) and the 11/74 (multiprocessor 11/70 system, basically 4 cooperative 11/70s). We used to love the 11/60 because you could rewrite the microcode and mess with people's heads! :) We also used to sit down the hall from the RSX guys, and would cadge source code so we could put hacks on our 11/70 development system to annoy our fellow engineers. Good times.
One last story. While on the 11/44 project, the lead came to me and said, "You're the young kid, you know hardware and software. We have these oddballs coming in to test their operating system on the platform. If that goes well, they'll buy these." The "oddballs" were people from Bell Labs, running Unix on the 44. I learned a lot about Unix working with them; I've been parlaying that knowledge into work for the past 30-something years!
I was supposed to go work on what became the VAX 11-730, but I was young and left the company to do other things. I ended up back there 20 or so years later as a consultant but that's a story for another day. I still have all my PDP-11 manuals and some of the software/OS "helper cards".
I worked a bit wit a PDP running VMS. Nice business OS as I recall. I'm told a lot of banks ran VAXen clusters because it gave them affordable reliability. Perhaps they still do.
I cannot get my head *why* anyone would think a data word that was *not* a power of 2 would be a good idea.
That said I've some experience of the boxes of the Harris Corp. 24 bits with an assembler (IIRC) whose mnemonics changed depending what part of the word you're addressing and for which the preferred programming language in terms of functions to access the OS was FORTRAN.
They're meant to have been quite good for running geological survey imaging systems and the DOGS CAD package. Rarely has something being *so* well named.
Fair Well Ken, although at least some of the VMS architecture lives on under the covers of NT and its successors.
Microsoft have never understood security, nor "doing the right thing" (aka real engineering).
NT 3.5 was a halfway decent operating system. But this is Microsoft we're talking about. A place where both security and engineering take a distant third place to Marketing.
The graphics wasn't fast enough, so they ripped holes in the O/S's security architecture to produce NT 4.0. What they did thereafter in the guise of Windows 2000 and Windows XP doesn't bear thinking about. They made such a mess of it that it was completely beyond repair after XP, and they had to start over.
Hence ... Vista.
VMS does not live on at Microsoft in any shape or form. It was being horribly tortured from day one, and crossed the line from life to zombiehood well before Windows 2000.
> I cannot get my head *why* anyone would think a data word that was *not* a power of 2 would be a good idea.
Because 6 bits is enough for A-Z, numbers, and a few stray control characters, and 36 bits gave you an acceptable level of precision in decimal numbers. so IBM were happy to work in multiples of 6. That became 'standard' for a long time.
Ah, the days when 64K was a lot of RAM, and you had the fun of RAD50 encoding as well...
You knew when a VAX/VMS was running slow with the delay echoing characters back on a vt-100 terminal, with a 3270 terminal you had to wait until you filled a whole page of code before you got that feedback.
The greatest contribution though has to be providing a platform for Oracle.. with DB2 we used cost-based optimiser application plans, but with Oracle’s rule-based optimiser you worked-out the plan yourself and coded the SQL accordingly.. getting instant feedback if the query was running slow from all the other users.
Without DEC, we’d all still be time-sharing computers in the cloud from terminals with some kind of SGML markup..
DEC and its descendants have been paying my wages for the past 25 years, as a VAX and then Alpha BOFH, and any OS I've been press-ganged into attempting to drive other than VMS has been a pale imitation of the real thing. It Just Works.
Also, I loathe Un*x from the depths of what passes for my soul
Well clearly the VAX 11/750, there was a time when no self respecting CS dept around the world would be seen without at least one of these machines running BSD ...
Which leads to the 'big brother' the 11/780 and 785, and VAXClusters (HSC-1) ...
not also to forget the DECStation which introduced the MIPS R2000 processor ...
and last but not least, the much underrated Alpha line of processors!
I don't remember the model numbers of all the VAXen I've worked on, from '85 to ES40s in 2009, but I absolutely loved VMS. None of those machines ever let me down and DEC's field service was fantastic. I still refer to babies' changing bags as Field Support Kits.
My modest claim to fame was to hook up the Call Detail Recorder printer output from a Nortel SL1/st PABX (another box I loved) to a terminal port on a DECserver 200, to capture all the call details. I wrote a billing system to charge all the phone calls to the proper department's budget, instead of the IT budget. It was a part-time project, what would now be called a 20% effort. But it was a great success and reduced our annual increase in phone bills from around 40% to 5% or so.
3,300+ lines of DCL. Took about half an hour to run, once a week. Worked perfectly. It was right at the limits of what one DCL program could do.
I also had some small batch jobs which checked through backup log files and emailed me a report. One of those ran automatically every night for 8 years without modification. And a bunch of batch jobs which purged records and compacted files in a TOLAS ERP system on a 13 week cycle. Again, all automatic, and ran for several years more or less by itself.
First thing I always did was to remove BYPASS from the privs on the SYSTEM account.
Legend has it that there was a VAXcluster somewhere in DEC Engineering in MA with 200 nodes in it. IIRC, the officially supported figure was 32.
VMS, virus free since 1978. Nothing to match it for reliability. I miss it immensely.
The Elliott 503 also had an extra bit in the middle: 39 bit word holding 2 instructions, the bit in the middle being a flag bit that if set caused the result of the first instruction to be a modifier for the 2nd instr.
Which takes me to the spoof about ICL New Range: that it would have a 49 bit word (8 x 6 to emulate 1900, or 6 x 8 for NR native mode), plus a spare bit. "What is the spare bit for?" was the core of the spoof. Two of us created it, and it ran quite some distance.
I joined DEC in September 1969 to work on peripheral product design. I got to have my own PDP-8e in my office. What a thrill to have my own personal computer. I think it had only 4K of core memory. My first job assignment was to design a paper tape punch mechanism for the LA30 as it was planned to be a replacement for a KSR33 teletype machine. I used the PDP-8e to run a dynamic simulation program that I wrote in FOCAL for the punch solenoid designs I created. With the limited memory I had to print each computed result as there was insufficient memory to store all of the results. Before I completed my design efforts the paper tape punch feature was eliminated from the LA30. I got to keep the PDP-8e for future design projects.
After 27 years in Field Service I've seen every thing from the first an only 8K PDP-5 in the world,(we had to add a extra SWR switch to address the upper 4K) to a CSS designed 11/05 machine that made Michelob bottles. For me the 11/45/55/70 were some of the best PDP's ever made. The great thing about the PDP was that when you went to a site that you had never been to before. You could never tell what might be hanging off the Unibus. Pumping machine language into the switch register to massage the periph's was such fun. As it was said then, I could 12737 with the best of them. Everything on the system could be gotten to from the SWReg, PDP8's were okay, but a bit slow. VAX780's were a dream come true for FS people that had logical snap to be able to fix them. Alpha's were really a gas. We had a saying "Intel, Alpha inside" those old Pentiums would burn your finger until Intel got DEC to tell how to cool them down.
For a few years I was support for the RA81, spent a pile of Ken's money fixing the original design. Dropped 67 Mil swapping HDA's with FCO13, but I did manage to kill the ECC epidemic with a single piece of wire. The Ground Strap FCO eliminated gound noise on the pre-amps from 40 Miilvolts to zero, which made for a nice reference.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
