Stan Brewer wrote:
>
> Joel,
>
> Hi! I ran across your resume while searching the Net for
> "Burroughs B205".
You gotta be kidding.
> Is there any chance that you might have any information, stories,
> or photographs you would like to share with the world concerning
> the B205?
No photographs (at the time, it seemed unremarkable), but certainly I can
describe the machine. If you decide to use any of this, please include the
source.
In the summers of 1962 and 1963, I worked as a programmer in the computing
center of a state university, which I will not identify except to say it wasn't
really a state, it was a commonwealth, and it was north of North Carolina and
south of Maryland. Cynics may feel that I got this job because my father was a
professor at the university, but I'd like to think it was my great reputation as
an eighteen-year-old programmer ...
Be that as it may, that's how I met the best computer I ever used, the Burroughs
205.
This was pre-core memory, so its volatile memory was stored on a rotating drum.
There were 4000 40-bit words, organized into 10 4-bit bytes. Each byte, having
16 possible patterns, was interpreted as a decimal digit (i.e., 10 values were
used and the other 6 were just wasted). For character data, 2 decimal digits
were used to represent up to 100 different characters. As I recall (may be
mistaken about this), those would be the 52 mixed-case letters, 10 decimal
digits, and a rather limited set of special characters (enough to support
Fortran or Algol).
Average access time was 20 milliseconds. In addition to the 4000 words, there
were four 20-word blocks of so-called fast memory, which was simply replicated
10 times around the drum, resulting in an average access time of 2 milliseconds.
We wrote in machine language. As I recall, each instruction took up one word,
including a two-digit instruction code; there may have been some half-word
instructions, I just can't remember. Because of the fast memory, code would be
written in twenty-word blocks, which could reside in fast memory. The last
instruction of each block was a "transfer and block" instruction, which would
bring in another block of code from regular memory and start executing it.
This made patching a real pain, because if the patch made the code longer, it
screwed up the blocking. One was often faced with the choice of having a few
words of code execute outside of fast memory, having a block fragment, or just
redoing the whole damn thing.
There were three i/o devices that I can recall. There was a single tape drive
that was actually quite reliable, but slow by modern standards. I think the
blocks were in fixed and marked positions on the tape. I didn't handle the code
for using the tape, but I think it was used to store compilers and elements of
what might generously be called the operating system. There was an operator
console which was really just a teletype. It served as the printer, too.
Finally, there was paper tape input (Cards? We didn't need no shteenking
cards). Each column on the tape had five positions that could be punched or
not. These were the four bits of a byte, plus a vertical parity bit. Then,
after each word, I think there was a column of horizontal parity bits. The
paper tape was rolled up, and there was a take-up reel. After reading it, you
had to rewind it (manually) so it wouldn't be rolled up backwards.
I mentioned earlier the difficulty of patching. In physical terms, patching
involved cutting and splicing the paper tape. Although the bulk of the hole
punches in a paper tape were made on a machine similar to a typewriter, for
small patches we would use a small hand-held punch. In addition to changing the
code, we had to make sure to check all the affected parity bits. Quite a ways
from using a modern editor or word processor, eh?
Users ran the machine themselves. They would sign up for a particular time
slot, then come in and read their paper tape in, and take away the printed
output from the terminal. I can tell you, they prepared pretty hard for that
time slot. One stupid mistake and it might be tomorrow before you get another
crack at it. This was called "open shop", as opposed to "closed shop"
operations where you would have a computer operator on staff, and users would
submit their jobs and retrieve their output from bins. That came later, with
the faster machines like the Burroughs 5000.
This marvelous little machine filled an entire room, and required a full-time
engineer from Burroughs to maintain it. It had a gazillion vacuum tubes, so I
imagine a lot of the maintenance involved just replacing burned out tubes.
In those days the computing center staff was quite small. It consisted of the
Director and, I think, two programmers. We supported the entire computing needs
of the university. In those days, if you knew something about computing, you
had an unusual skill (and you didn't have to worry about competition from
precocious 10-year-olds).
It was a very informal setting, with friendly, hard-working but laid-back people
to work with, and I miss those days.
During my tenure there, we first wrote a compiler for Algol 60, then a
translator to convert code written for a locally developed assembly language
into Algol. The assembly language had been developed before my time. Yes,
there was such a thing as "before my time".
A bit more about the compiler. That was my first assignment. When I arrived, I
had written a few simple programs but had little concept of what an algorithm
was. My boss (the Director) gave me what amounted to a board game, the function
of which was to parse statements and expressions into Polish suffix notation.
Polish suffix notation, incidentally, owes its name to its inventor, who was
Polish, and whose name was, to most Americans, unpronounceable. I'm afraid I
don't remember the actual name.
Anyway, in this notation, which some modern calculators use, you enter a simple
expression consisting of two operands and an operator, e.g., A + B, with the two
operands first, followed by the operator, e.g., AB+. The advantage of this
scheme is that you don't need parentheses. For example, D = C * (A + B) becomes
DCAB+*=.
We developed the compiler into three parts. The Director wrote a parser, which
scanned the input characters and produced tokens (operators, constants, variable
names, keywords, etc.). I, having studied the board game (a wonderful training
device for a neophyte), wrote a section which converted the tokens from the
parser into Polish suffix notation. We called that part the "Polisher" (no,
it's not a floor wax). I can't remember whether it was he or I who wrote the
last part, which converted the Polish suffix strings into machine language.
This all seems pretty mundane now, but at the time, I felt like the original
inventor of the wheel. As I think back on it, he handed me the algorithm on a
platter (well, on a board). I just coded it. It was perhaps his leadership
ability which made me feel that this coding was true creativity. In any case,
since that time, I've had no trouble developing new algorithms to solve new
problems. That little board game gave me that. I wonder what ever happened to
it.
We all loved Algol, which was truly a well thought-out and internationally
standardized language, as opposed to Fortran, which in the early days was
strongly identified with a particular computer company, and seemed to have a lot
of arbitrary rules. Algol used block structure and strong typing, and was
similar to the later language Pascal.
About a decade ago, I served a short stint on the Fortran standards committee.
It's getting better, but I still miss Algol. Looking at that word now, it
reminds me of Rush Limbaugh's rendering of Al Gore, "Algore". But I digress.
Finally, an anecdote. One day we had a visit from a representative of one of
Burroughs' rivals. This was a company with a very different culture than that
which we enjoyed. I mean, they wore suits! And they didn't like Algol! We'll
call them JCN to protect the guilty. So while this JCN representative was
talking with the Director, my programmer colleague, who was much braver than I,
wrote a short program for the printer, which typed out "JCN sucks" repeatedly.
He made it perpetual by splicing the paper tape into a closed loop. It was
running when the Director and the JCN rep emerged from the office to tour the
computer room.
JCN is probably still looking for pay-back, so my colleague will remain
anonymous. I hope you appreciate my discretion, John, wherever you are.
Good luck,
-- Joel Rose
