In retrospect it would surprise some at how advanced the B5000 arch. and implementations were, virtual memory and concurrent, parallel, quorum processing and so on. I learned the stack based, superscalar B7800 CPU to the gate, bit level; single clocking and chasing the op codes and small code through the entire machine including the IO and stacks in memory. I was supporting 4x4 (cpuxio) B7800 and a 2x2 B6700 and all peripherals including hundreds of disk spindles at a 24x7 site. As well as the IOM and then new 4k chip memory infrastructure. Unfortunately I was not able to spend any time at the OS level though, running an early C(?) and Cobol compilers maybe. Spent months taught by Jerry Jackson at the Paoli plant. And sadly no longer have any tapes or docs. My last experience was confguring host devices allowing high speed direct parallel communications between disparate running systems. I cannot describe how powerful the exposure to these technologies were for my future understanding.
You can almost always go back to mainframe for inspiration - back in the day they pretty much solved every problem you can think of. It has just taken 40-60 years to be able to do the same thing on consumer class hardware.
Last I checked there was still no mechanism where I could bill back resource usage in a multi-tenant kubernetes cluster so I think there is still work to do.
> bill back resource usage in a multi-tenant kubernetes cluster
I feel a bit dumb for asking, but what about process accounting? I'm not sure if it can deal with RAM and I/O, but it's better than nothing. (https://linux.die.net/man/8/sa)
Computer architecture books of the 1980s mostly featured the B5000 and the CDC 6600 as poster children for what could be done with hardware. Some IBMs too, of course.
Interesting how minimal the operator's console is, compared to the IBM System/360 machines from the same era, which you can see photos of here: https://en.wikipedia.org/wiki/IBM_System/360
There was a completed cabinet devoted to outputs for the field engineer. All the register were displayed, as well as buttons to set them. At least on later systems, they were in a big square, and someone patched the OS to display the Burroughs, big B, logo during the systems idle time.
I recall; miniature incandescent bulbs embedded into push switches that could display/set registers, it was very important to test the bulbs before trusting them (a long press) else a burned out bulb may catch you off guard. Right next to the core memory cabinet, someone accurately patched it to show huge "$" during idle time!!
Our high-school had a B 5500 for the school district's administrative functions and it eventually was also used to teach students software development (the course was titled Computer Math and taught by the same teacher I had for statistics). Naturally, having students on the same system where their grades were stored led to some interesting "events". I also remember one of the kids (a fast typist) entering SpaceWars into the system.
We had 10 card punch stations and ten glass terminals in our classroom which was adjacent to the room housing the computer. I don't remember seeing a separate operator's terminal but there was definitely the field tech cabinet described by 4x5-Guy.
Both my parents worked for Burroughs and my father retired from Unisys 20 years ago. I grew up in the server rooms and accidentally pushed the big red emergency shutdown button once when I was about 6. I helped my mom debug COBOL code on our dining room table. I've been in IT for 30 years and it is always amazing to see how much has changed and yet how much hasn't. Thanks for the nostalgia trip.
A notable fact about the B5000 (1961; the first model of this family) is that it was the first commercial computer to implement (segmented) virtual memory. It was preceded only by Ferranti Atlas which was the first to implement paged virtual memory.
Gary Kildall of CP/M fame, used the B5500 and was heavily influenced by it.
His graduate thesis involved an implementation of APL on the B5500, using words instead of the special characters that APL usually used, such as 'RHO' instead of the Greek symbol.
Having experiences like this is something incredibly valuable for an engineer. This is why, when people ask me what language should they learn, I suggest they learn something completely different from what they know. If you know Python, don’t learn Java. Learn Lisp instead. Or APL (or “learn to make good comments the hard way”). Or FORTH.
What a great link! And quite the coincidence for me.
My dad worked at Burroughs in the Medium business group (B2500-B4900 series). He was there from '76-'92, even after the Unisys merger (Burroughs+Sperry). I've been looking for a good condition user manual of one of products in the medium series to keep in my home office.
Wow cool to see this pop up here. My dad worked for this company in its heyday before it was acquired by Unisys I think. Used to make mainframes. He came to the USA from an Indian village without any formal cs education. Completely self taught his way through tech. Gave me a copy of K&R when I was a kid and kickstarted my own journey.
John Dvorak has a interesting piece on Burroughs here :
"The [ElectroData derived Burroughs 205] drum had two sections. The high speed access section which had each piece of data duplicated 10 times and offset on various bands on the drum to increase the access time by 10. Here the average data access time was .85 milliseconds."
my mom performed her bank clerk job on Burroughs Adding Machines, in the early 50s.
Good a time as any to ask if anyone has come across the sources for the OS. Bob Supnik has been looking for it a long time for simh. The story is it disappeared at some point into the bowels of the company that took over the service contracts for these machines. Possibly Indian. Anyone know for sure or have any contacts?
I remember at CCE (consumer electronics company in Brazil) they had an A-6 with hot failover to a bank’s A-10 across the street. It was pretty normal to see the MCP guru reading the source code for the OS (in ALGOL).
"Burroughs software was designed to run only on proprietary hardware. For this reason, Burroughs was free to distribute the source code of all software it sold, including the MCP, which was designed with this openness in mind. "
You can download an official emulator from their website. It’s proprietary and runs on Windows, and you have to sign a license promising you’ll only use it for development.
But I have to warn you: It is one of the most user hostile OSs I’ve have ever seen.
If anyone thinks vi or Emacs are hard, they should play with CANDE.
Part of the technical school tranship was on OS/400 state of the art in early 1990's doing system backups to tapes, I also did my typing exam for computing in PCs running MS-DOS 3.3 with edlin, I think CANDE is manageable. :)
CANDE is not software you use. It's software you fight and submit to your will. It's a bit like Emacs, but made by people with 4-digit IQs, for people with 4-digit IQs.
Unisys has been very supportive of our efforts to find and preserve early Burroughs software and generously provided corporate time to arrange licensing and provide copies of anything they still had.
Burroughs B5000 series now has a rich library of software and several emulator implementations (web-browser, simh and standalone). However the B6000/7000 family software recovery is sparse with critical pieces still missing, we are unable to bootstrap a working MCP as yet.
Nice to know, navigating the site to get stuff like the latest NEWP manuals, the new Web interface and other similar stuff, seems to have moved into "talk to sales" kind of stuff, so hence why I was wondering that.
You have to take a moment to appreciate that a "Major Computer Company" (Burroughs) made bank selling these systems to large businesses to handle things like their accounting etc. And yet today you can emulate the entire system with all of its peripherals on an ESP32 microprocessor that you can buy for $5.
It was this sort of realization by people in the 80's who were seeing Microprocessors that could do much of what computers could do at the start of their careers, who thought "Wow, we can make a 'microcomputer' that does all that too."
It is possible today to write a full accounting package that tracks an entire families budget for all the things they buy and all their expenses and income that runs on a $2 chip with another $5 in peripherals. If you re-use the family TV for a display, you can build an inexpensive appliance that could help a family manage their budget, wirelessly send required data to a tax calculation service or program, and never need software "updates".
This is the opportunity of the "new" microprocessor revolution (in my opinion), which is basically one computer per program. And the whole package "just works."
Friend refused to take small computers seriously, this was late 80s. Reminiscing about Control Data back in 60s. Looked up specs, even then an 80386 with math coprocessor could run rings around the CDC systems.
Don't get me wrong, the CDCs were great achievements, it was just my friend didn't keep up with the times. He'd gone into non-technical work so he can maybe be excused.
I was thinking something like the RP2040 which is Cortex-M4 based. 8 bit Arduinos are nice and all but since you can get a 32 bit processor with hardware floating point for the same price points you don't have to "go that low."
Very true! But probably for different reasons. Interfacing to a micro-controller or a PIC is a bit more complicated than plugging a keyboard and monitor in.
1MHz CPU cycle time
49-bit memory words, 48-bits user/programmer visible and one bit for parity
Maximum of 32KW of memory (32K x 48-bit words, in modern terms 192 kilobytes of directly accessible memory).
Either one or two CPUs.
Four "DMA-like" (direct-memory-access) channels.
Fascinating machine in so many ways. The founder of the company was the grandfather of William Burroughs, author of (among others) Naked Lunch.
Burroughs was a late entry to the mainframe market, but when they went there, they did not have to worry about backwards compatibility, so they could do fancy stuff like virtual memory and a stack-oriented architecture.
You just have to love this item: "multiprocessing of independent programs, with dynamic scheduling by the operating system". These days, we call it multitasking and forget just how cool it is.
> they did not have to worry about backwards compatibility, so they could do fancy stuff like virtual memory
IBM did have to worry about backwards compatibility, but they delivered a virtual memory machine, the System/360 Model 67, by 1966.[1] The System/370, on which virtual memory was standard, was delivered starting in 1971.[2]
Their VM/370 operating system (1972) was a hypervisor (IBM coined the term back then) that provided virtual System/370 machines.[3] You could actually run instances of VM/370 in VM/370 virtual machines. It amazes me that this technology was already being used a half-century ago.
When I was in high school (1974) they started a "computer" class, we logged into one of these puppies with a Teletype in a little room that used to be a storage room.
There were two of us that signed up for the "Computer Class".
BTW, the other guy that signed up for it was my best friend in High School, and, the other biggest nerd like me, who, happened to be the only Black kid in the whole school. Which just thinking back and in honor of black history month...
Just brought back a bunch of memories (pun intended :) )
Cool brochure. I think they might have gone a little nuts with the tiny dots representing "computing"... I would have thrown some fun graphics in those boxes. Maybe some hot secretaries in sunglasses, martinis, olives, stretching toes on the beach while your monster 8k computer churns away in the office...
