I had a 3B2 in the 1980s; it was an okay Unix machine that AT&T had no idea how to market. The development tools (C compiler, etc.) cost extra, and came on about 30 floppy disks that you had to load in a very fussy order. The machine's black-and-white user interface was, well, terrible, and the documentation had been written by out of control PM/marketing types (you didn't press a button, you "touched" it. You "touched" everything in the UI; this oddball wording, and affectations, permeated the manuals and dialog boxes).
Right: But hey, real Unix!
I got Emacs and GCC and uucp/netnews/email working, but when it came to developing something on the 3B2, it turned out that programming Macintoshes was a lot more fun, and certainly paid better.
One day its 67MB hard drive made a groaning noise and a thin, straight trail of smoke rose up from it. I walked across my office and turned the 3B2 off, and didn't shed a tear.
The "touch" button thing was a big deal back then - Apple and others kept reminding devs that is was not a good idea to tell users to "hit" keys as sometimes this was taken a little too literally :-)
That's what everybody else uses. If you want to write edgy, hip and modern documentation you need to use words that other people don't. "Touch" implies a friendly, approachable and non-threatening user interface. It lets your boss know that you're all-in with this edgy new Unix UI stuff.
tl;dr: It's marketing bullshit.
The UI on the 3B1 was definitely nothing to write home about . . .
The 3B1 AKA "UNIX PC" AKA "PC 7300" wasn't even Intel inside, it was Motorola 680x0. The true 3Bs (3B2/3B5/3B20) had WECO processors. (The first UNIX machine I used daily was a 3B20, in fact -- dog slow compared to the 680x0-based Sun 2s and 3s the cool kids got to use.)
The actual first UNIX PC (Intel processor) was the 6300 series, which were rebadged Olivettis. I ported a product line to the 6300 Plus, which at least had extended memory capability.
I learned C on a 3B2, and for a while had access to a 3B20S at UIUC. You were right about the 3B20; UIUC had a pair of them that were originally called "shark" and "tornado", but were quickly nicknamed "snail" and "turtle" in honor of their performance. They were the size of refrigerators, and, IIRC, they were roughly equivalent to a VAX 750 (maybe a 780 at best).
To the best of my knowledge, the 3B20D, a dual-processor fault-tolerant system running a UNIX variant called DMERT, was only used in the #5 ESS telephone switch - and was eventually replaced by an emulator running on a Sun system.
Real 3B20/3B21's live on - as far as I know, the emulator was only used with the 5ESS VCDX (very compact digital exchange) - essentially a baby 5E that lives in a single rack.
(I've seen a 3B21 living in a real running 5E within the last three years)
There was a time "PC" stood for "personal computer", not "poorly architected computer with off-the-shelf parts and the cheapest CPU that could do the job", also known as IBM PC.
May the one that never had to deal with the A20 line or ask the keyboard controller for the favor of resetting the system throw the first stone.
The phone and note handling were amazing demos of what multitasking really offered. At the time it was still the domain of IBM's Top View and similar character-based pseudo mutitasking extensions to MS/DOS.
Doing a demo where the phone rang and a notepad window popped up on its own was just short of voodoo. It didn't make any sense but I always privately fantasized Bell and Control Data would decide to get married and make a Plato terminal out of 7300s.
What amazes me more than anything else is the fact I'm still UNIXing for food nearly 40 years later.
> What amazes me more than anything else is the fact I'm still UNIXing for food nearly 40 years later.
It's both amazing and disappointing. It's amazing Unix is still used after almost 50 years. It's disappointing we never managed to come up with something better that was also viable.
The CS program at UIUC in the 1980s had a pile of 3B2s in the programming labs. The "intro to assembly language" weedout course was taught on the WE32100 processor. I think the architecture class also did some primitive gate simulation on the Blit terminals.
It wasn't a bad chip. The C language integration was really understated here. It's the only chip I've ever seen with a strcpy() opcode. Totally dangerous now, pretty wild back then.
FWIW, those crazy single instruction copies you see on pretty much every classic CISC machine did make a lot of sense on systems without instruction caches. You could easily get a third of the throughput if you had to share the data bus with instruction fetches.
Yup, I remember those very well. The course, IIRC, covered both assembler and C. Teaching myself 6502 assembler back in my high school/junior college days helped me a great deal, even though the 6502 was vastly more limited.
I later did some 8086 assembler in my first job as well, mainly some routines for testing a QIC tape drive.
Mad props if you spent weekends in the Woodshop trying to make your MPs compile. Nice to see a fellow Illini around.
And yeah, there was C in that class too. Mostly enough to make sure you understood pointers so that you could get into the homework and shoot yourself in the foot repeatedly.
It was one of my favorite classes during my time there. I also had some 6502 experience which helped. But I think CS225 solidified the idea of "either you're going to understand this for the rest of your life, or you're not. Choose now."
The best part was when they gave an entire class of 250 CS students one ancient Pyramid to compile their C code on. Compile times of 30 minutes and more for hello world were not unheard of. Thanks UIUC.
I was on that Pyramid too. uxa.cso.uiuc.edu for life, yo.
The key was having some kind of terminal and modem back at the dorm so you could log into the system after the labs were closed. You literally had the entire machine to yourself all night long. =)
The CPUs were microprogrammable. It's no surprise that they had a strcpy() opcode. VAXes too had crazy complicated instructions, including list traversal instructions and arbitrary precision BCD instructions (IIRC anyways).
> The table address operand points to a table of polynomial coefficients. The coefficient of the highest-order term of the polynomial is pointed to by the table address operand. The table is specified with lower-order coefficients stored at increasing addresses. The data type of the coefficients is the same as the data type of the argument operand. The evaluation is carried out by Horner's method, and the contents of R0 (R1'R0 for POLYD and POLYG, R3'R2'R1'R0 for POLYH) are replaced by the result.
But Lucent already has a 3B2 emulator.[1] It's used to run MERT and DMERT, real-time operating systems used by central office phone switches for auxiliary functions.
Lucent's emulator is for the 3B20D, a very different beast from the 3B2/400. They use the same CPU set, but have a different system architecture.
But the bigger problem is that Lucent's emulator is not open source, or even widely available. You can't even legally get the binary as far as I'm aware.
In 1994, I was a 3C0X2 in the USAF (Air Force), 'Computer Programmer', at the 81st Medical Support Group, in Biloxi Mississippi. Curiously, I had more experience with general UNIX administration than anyone else in my unit, so I was in charge of the UNIX servers in the basement of the hospital where I worked.
There were at least 10 different UNIX variants there, including the (even at that time) venerable 3B2. We had a couple of them handling some 'lightly' classified ('SECRET') data.
They weren't quite enough, so we put the word out that we needed more. My OIC (Officer In Charge) took care of 'putting the word out'; I didn't really know what that meant.
A few months later, a crate arrived on our loading dock, and inside were probably a dozen 3B2s! They had come from Homestead AFB, Florida.
All of the servers had clear signs of submersion. As in, there were old algae stains on the cases. Two of them had been partly submerged, since there was a straight line across the center, apparently a high water mark.
Being young, crazy, enlisted and bold, we decided to give them a try. So we found a long, heavy extension cord and ran it out to the parking lot next to the loading dock, and plugged them in, along with a required external serial terminal.
Much to our surprise, most of them booted up just fine! One of them started smoking, so we unplugged it.
In the end, after a lot of outside 'burn in' time, we were able to mount four in our datacenter and begin using them for classified data processing.
I collect vintage telephone equipment - I've seen much 40+ year old hardware that still works without trouble, the build quality for AT&T/Western Electric hardware was amazing - so none of this surprises me.
Yup. Re: the 3B2s, I don't know how much they cost at the time, but I heard that they were extremely expensive. Everything was, of course, but the AT&T hardware especially.
That computer was used at sdf.org. Some Linux "smart" people suggested to switch to Intel and Linux. The system got uber exploited. Then, they switched to NetBSD under Alpha.
No issues registered until today.
My company had an IO device ATT wanted to support on the 3B2. I got to visit their lab and work with them for a few days. They were a bunch of great guys who really believed in what they were doing.
For some reason "Frasier Crane" preferred the 3B2, and had one in his sound booth for many years. This seems a rather contrarian choice given his locale.
Right: But hey, real Unix!
I got Emacs and GCC and uucp/netnews/email working, but when it came to developing something on the 3B2, it turned out that programming Macintoshes was a lot more fun, and certainly paid better.
One day its 67MB hard drive made a groaning noise and a thin, straight trail of smoke rose up from it. I walked across my office and turned the 3B2 off, and didn't shed a tear.