I already wrote about the Burroughs B205 which was fun to do since it just looked so good! Sadly, I never used a B205. The Burroughs B1700, however, was a completely different matter. By the time the 1970s came around, Burroughs had 3 product lines of computers. These product lines were called, with a certain lack of originality: large, medium, and small.
The B1700 was one of the small computers!
What made the B1700 different from a lot of other machines at the time is that it had a writable control store. OK, that's jargon, and here's a bit more. What that meant is that users could easily microcode the machine. That's maybe still not helpful. So, here's a simple explanation. Every computer has a set of instructions, each of which performs a small action. With a micro-codable (writable control store), it is possible for smart people to change the instruction set the machine uses. Normally, we don't do that, but the B1700 encouraged it! This way the machine could behave in an ideal way for whatever programming language was being used.
Every Burroughs computer came with something called the Master Control Program (MCP) which was the computer's operating system. I'm sure that was as small as possible and on the large machines, there was no problem, that I'm aware of, running MCP. On the B1700, though, it slowed down the machine a lot. Too much for the lecturers at the university.
What they did (and there's a paper out there describing it - see below for the reference) was to create a new operating system written in BCPL. They chose BCPL because it compiled into an ideal abstract machine represented in OCODE. So how does that help? Not much, unless you have used the writable control store of the B1700 so that the computer's instruction set is the OCODE instructions.
This was a huge achievement and permitted a small operating system to be written that could switch between 4 different tasks.
That's all neat stuff, but it also affected me more directly. As a student, I was tasked to join a group and write our own operating system for the B1700 for one of our classes. I don't remember the details of the assignment but I do remember the somewhat cumbersome process for getting our code to run.
- The first thing, of course, was to write the operating system functionality in BCPL on the IBM/370.
- The code was then compiled using the BCPL compiler that produced OCODE. This was then punched onto cards.
- We'd then go down to the batch station and wait for the operators to put our recently punched cards into the appropriate pigeon hole.
- Now we were in business! We'd walk up two flights of stairs and into the room with the B1700.
- Toggle some switches and load our cards into the card reader; load them into the computer and then spend anxious hours trying to figure out what was going wrong and then, yes, you guessed it, back to the beginning so that we could fix the bugs.
Reflecting on the experience, some years later, the very cumbersome approach we had to take was a very good reminder to think hard and not just edit, compile, and test our code.
Reference: C.R. Snow, "An Exercise in the Transportation of an Operating System," Software -- Practice and Experience, Vol. 8, No. 1, Jan.- Feb. 1978, pp. 41-50.