An Interview with Bob Wyman
BW = Bob Wyman
GAM = George Michael
GAM: Today, 2/4/97, we are interviewing Bob Wyman, just about the first
Computer Engineer to be employed by the Lab. Bob's early career was quite
interesting even before he came to the Lab . Bob, why
don't you start by telling us how you got to the Lab and when.
BW: All right. I got an MS from Purdue University in 1957, and I stayed on at
Purdue for a few more years in the Ph.D. program. All the computer people,
by that time, had left Purdue so I was sort of on my
own and I tried to do something in servomechanisms. I didn't get anything
going. I then went to work for Northrup Nortronics in Hawthorne,
California, and stayed there for a year and then decided that I didn't really
want to stay at Northrup for any length of time. So, I went to a job fair that
was going on in the northern part of Los Angeles and talked to a guy
from Lawrence Livermore Laboratory (then the Lawrence Radiation Laboratory).
I didn't know anything about the Laboratory at that time.
He said "Well, the Laboratory is a Physics
Laboratory and we don't do computer things." I told him I was a Computer
Engineer and he said "Well, we don't do computer things at the Laboratory,
what we do is counting. That's what we do; we do counting." I said to
myself, "Well, O.K., maybe it's time for me to make a big career change
and go into counting, what the hell, whatever that is, O.K.?" They invited
me up for an interview and I went up in early 1961, January of 1961. I came
up to the Lab and I met with George Michael, Sid Fernbach, and Ed
Lafranchi, and all they talked about was computer problems that the Lab
had. The moral of the story is that when they send out a recruiter, they
should send out a recruiter who knows what the Lab does in all phases rather
than just one very narrow phase.
So, they talked about computer problems, and it was, to me, one of the most
interesting interviews that I'd ever had in my life. They actually presented
me with problems the Laboratory was facing and I began thinking, "What
am I expected to do, provide solutions to these?" when Sid jumped in and
said "Well, we don't expect you to solve these problems right now, but
these are the problems we are facing." So, they made me a job offer and I
came up in February of 1961 and worked for Ed Lafranchi in Electrical
Engineering as part of what was then called the Special Projects Group,
because digital work was not a big thing in electronics at that time. They
had all the people lumped into one small group headed by Ed Lafranchi
under Alex Stripeika, who was the Division Leader doing all of the digital
electronics that was done throughout the Laboratory. That was just about
the time that the IBM 7030, the so-called "STRETCH" computer was being
delivered. Shortly after I received my clearance the PDP-1 was delivered.
This was, I think, the first PDP-1 that was delivered outside of commuting
distance from Maynard. Ben Gurley came out to describe how the arithmetic
unit worked. The Lab people were going to do all the maintenance on the
system and so I sat in on those maintenance courses with Gurley. Shortly
after Ben joined Ed Fredkin at Information International, a disgruntled
memory designer at Digital murdered Gurley . It was a real loss.
BW: The PDP-1 got delivered, and I was just sort of fooling around, and I did a
little thing with regard to multiple typewriter interfaces. I think we were
using teletypes, but I'm not quite sure.
GAM: It was an IBM Selectric at first, and the idea was to see if these
typewriters were rugged enough to be our standard input/output device.
BW: Oh, Yes, I remember now. I had to take this rather bizarre code
(EBCDIC) that the IBM Selectric used and convert it internally to
something. Then, while I was fooling around with that, which
was really just sort of a hobby job, Lafranchi came in to me one day and
said "You now have a real job, you've got to interface the IBM 1402 card
reader to the PDP-1. The so-called Uptime card reader, that they had
bought with the PDP-1, gave too much trouble. It was a very fast card
readersomething like 2000 cards a minutebut also, a very unreliable card
reader, and Uptime Corporation had only one maintenance man who flew all
over the country trying to maintain these machines. One of the really bad
problems with this machine was that it had this friction cam which hit the
cards right in the middle of the deck in order to feed one card down through
the knives. Because the reader went so fast, the cam hit these cards with
tremendous force, and after the cards had been through the reader two or
three times, they were as limp as dishrags. They'd lost all of their
stiffness and then they couldn't be read again. Then they'd have to be
duplicated and sometimes that was hard because the deck had lost so much
of its strength, so it was not a particularly successful system. So they
decided they wanted to connect the 1402 card reader, which was part of the
IBM 1401 system to the PDP-1. The 1402 card reader read 200 cards minute
and punched 100 cards a minute. It was a
pretty reliable machine. That was my first really big interfacing job. Now,
one of the things that I will never forget about that system, is that I got
reintroduced to what's called "brush drop". In DC motors, when the brush
runs on a commutator, there is a non-linear voltage drop across the brushes
of about 2 volts. It doesn't make any difference how big or how small the
motor is, its always two volts. This card reader had a carbon roller that was
run at ground potential. It was switched to ground, and then there were these
little copper brushes that ran on the roller and as the punch card went
through, the brush would drop through a hole in the card and make contact
with this carbon roller. That would be the sensing mechanism for whether
there was a hole or not. The brushes were run up at some potential,
but then it was grounded when it hit this
thing and it floated up to the brush potential when the brush was not making
contact. So that's how IBM sensed this thing. I figured, what the hell, that's
the mechanism to use, so I jiggered the system which supplied the voltage to
the brushes so the voltage was consistent with the Digital Equipment
Corporation voltage which was �3 and ground.
At that time, we were using so-called germanium PNP transistors and the
signal voltage was �3 or ground. That changed later on.
The Lab was using the so-called DEC system
modules. Well, I had the brushes floating at �3
volts. When they made contact they were supposed to go to ground. But
what they did was they went to �2 volts, which was not enough to trigger
the circuits. We read a card and it didn't make any difference, the card came
through indicating no holes. We went fiddling around with scopes and
things and discovered that, in fact, we were getting brush-drop potential on
this thing. So, then we had to build a circuit which biased the roller above
ground potential. This would allow us to actually get the brushes to ground
when they ran into this thing. But then we ran into some other voltage
problems, and so we had to change our whole input circuitry, although this
was not too hard, Digital provided diode input which would, in fact, take a
much bigger voltage swing than the transistor base inputs. So we jiggered
things up. I think we went to
slightly above ground which was always a problem we had to face when we
were doing something like this. Slightly above ground to about �4 volts
below ground, which was enough so that the diodes in the diode circuit
were properly biased and then everything worked fine. As a matter of fact,
that was one of the few things that I ever put together which lasted more
than a year or two. This one, in fact, stayed on and continued to read cards
through the entire PDP-1 life. It may not be the biggest thing I ever did, but
it is a thing in which I have a great deal of pride, because it was the first job
I did and I was able to make it work despite of all the junk. I think the big
thing that we did, of course, during that time, was the beginning of the
GAM: Yes, and that is what that your typewriter system was for.
BW: Yes that was a start, but it never went anywhere. The big start came when
the first 6600 was delivered. This is one of the saddest, saddest tales that
might have been; I wrote a memo to Sid saying "O.K. we know how to
connect these machines together, we can now build this system for you." He
wrote back, he sent me the memo back, the one that I had sent to him, and
on the bottom he'd scribbled, "Go ahead." That was the actual beginning of
the OCTOPUS and I lost that darn memo.
You just wonder what the hell you're doing. I mean, you lose these
things, and you really don't appreciate what you have in your hand when it
happens. Certainly one of the more historically important pieces of paper
from that era, and I lost it! So, anyway, we had made some rather grandiose
plans, which we really couldn't realize. We were going to build a
super fast multiplier, but that all went away. What we did do though, was do
some very initial connection of teletypes to the 6600. Now, Norman Hardy
was the one who said that this was the way to do the connection. His idea
was that we would have a sensor circuit which would deliver ones and
zeros to a peripheral processor (PPU) of the 6600, and that the peripheral
processor would pick these ones and zeros up and actually assemble
characters out of them. In fact, it would do all of the timing, it would do
everything. All we would do is just provide the one or zero signal to the
thing. Norman would sit there and continuously sample these input bits.
When a bit went from mark to space he would say "Aha! This is the start of
the character." He would wait some short period of time to be sure he was in
the middle of the baud and then he would begin picking up all of the bits for
the next train. He would assemble those into a character and then wait for
the next start bit to come along. We actually connected twelve teletypes to
this system because that was the word length of the PPU. We had little
sensor circuits in there which would deliver the correct information to the
PPU and that was the first work that was ever done on so-called
time-sharing at the Laboratory. I don't know how long that went on, I think we
built a multiplexer which delivered considerably more than just twelve
teletypes to this system.
GAM: Oh yes, but that was several years later.
BW: Yes, but there'd been a number of generations that had gone through there,
and we were also in the process of connecting all of the machines together
into a huge network using the PDP-6 as the central machine.
I remember some of the nightmares that George Michael and I got into
when we tried to buy a
camera from Westinghouse Corporation that would allow us to actually
digitize opaque images using an image dissector tube, which was one of the
original TV tubes. We spent a lot of time on that but we never ended up
buying anything, even though we had a contract with Westinghouse to buy
it. They simply couldn't make the whole thing work. I think one of the
funniest things about the whole thingwe didn't know what we were doing
eitherwe wrote the specification which sounded like what we wanted. Then
Westinghouse said, "Oh sure, we can build this thing." So they plunged
ahead and started building something. Then they came and said that they wanted to
change the tube and we said, "well you've got the contract to do this, change
it to anything you want". So they changed the tube to another Image
Dissecting tube that Westinghouse made rather than one that IT&T made,
and then when we went down there for the first test of this thing, we met
with their chief scientist. This had been in development for a year or so
when we met with their chief scientist. The chief scientist said, "well we
have certain problems with this thing because, in the specification, the time
that the aperture has to look at a particular pixel on the screen, the number of
electrons that come through can be counted. So the amount of current we
are dealing with is minuscule and we have a great deal of problems with
signal-to-noise ratio", which was absolutely true. They could never make it work,
and we later defaulted them on the contract, They never balked. They just
ultimately realized that they couldn't meet our specification, although we
said we thought it was reasonable, and they could have taken us to court.
GAM: I remember they had to illuminate the target with so much light that it
caught the sample holder on fire. But, all in all, it was a very bitter thing to
have to put up withI had such big hopes.
BW: I guess that's the one real failure we ever had on this thing.
Along the line, I became the group leader for what was called the
Computations Project Group. In that group were all the technicians and
engineers that maintained the computers that the Lab had. Not all of them,
because IBM was under contract for maintenance, but the LARC, and a
bunch of other equipment, were maintained locally. Along that line, were the
PDP-6s. PDP-6s were very interesting machines. Everybody just loved the
instruction set the PDP-6 had; you could do more in the PDP-6 with one
instruction than you could with half a dozen instructions in almost any other
machine. The PDP-6 also had more interesting ways of doing nothing than
any other machine. There was an instruction which was "Test A &
B and do nothing." This was a great instruction for delay because it took
several hundred microseconds to do this one instruction and then it did
nothing. It was timed precisely so you could just loop on this thing and
delay several hundred microseconds every time you went through the loop.
But the 6 had some very peculiar problems. One was not so peculiar.
We were one of the few people to actually connect
stuff to the I/O bus. When we did, it was a disasterthings just didn't work
properly. We had one of the first PDP-6s. That's the history of the
Laboratory. We always got one of the first of a brand of a machine. So we
called Digital and started to talk to them about this problem we were having.
Their attitude waswhich was the attitude that all the computer vendors
had"Well you guys don't know what you're doing. You obviously have done
something wrong," and "we're not going to get involved." So, we made them
an offer they couldn't refuse "You send out a consultant and let him look at
this particular problem and if he finds that the problem is ours and shows us
where it is, we will pay for his consultation. If he finds that the problem is
yours, then you will pay for the consultation and you will fix the problem."
They said "Boy that is an offer we can't refuse," because they knew they
were going to be right on this thing. So, they sent out Alan Kotok who was a
very bright guy. He was one of the designers of the PDP-6 and he looked at
what we were doing and he said "Jeez, that looks pretty straight forward."
Then he started looking at the bus and, sure enough, where there was
supposed to be one pulse, there were two pulses coming out very close
together. He found the problem, fixed it, and went away, and all of our stuff
worked after that. Which was just greatit couldn't have been any better.
We also wanted to connect a bunch of memory to the PDP-6, but we didn't
want to pay the price that Digital wanted for their memory. So we solicited
memory for this thing, assuming that what we would do is make an interface
connection between the memory modules that we bought and the PDP-6
memory bus. It looked to us like the PDP-6 memory bus was pretty
straight forward. We got a low bid from Lockheed, of all places, and these
were not people who you would normally expect would be providing
memory to the commercial world. But we looked at their product, and it
looked pretty good, so we decided we'd go along and do this. Now this story
is an indication of the kind of man Sid Fernbach was. He was the director of
the Computation Department at this time. We were well into this
procurement and I was going to do the interface to the PDP-6 memory bus. I
got a call from Ken Larson, who was the salesman for the PDP-6, and I
always trusted him. He said "Bob, I've talked with our people back in
Maynard, and they think that you're biting off a very big mouthful here and
that your ability to make this thing work is under some question." They
didn't say that directly, but that was the implication of all this, "and we
think that you're going to have a lot of trouble with this particular problem
and we'd like to recommend against it." Of course they'd like to recommend
against it because they were losing a lot of sales money on this thing. We
were buying the memory for approximately half the cost of the PDP-6
memory. I said, "Well, thank you for your input" and then I went to see Sid
because I was worried. I told him about the conversation and he said "Bob,
when I ordered the LARC and the LARC was two and a half years late, I
was getting heat from all sides, but I knew I was doing the right thing, and it
all worked out. Now don't worry about this, I have confidence in you and I
know that you're going to make this thing work." I said, "Well, thanks" and
as I walked out of the office he looked at me and said "Feel better?"
He was a great guy, and I did feel better. I felt a hell-of-a-lot
better, and we did make that thing work. It was a real eye opener to me; we
didn't really have any problems with this thing. The interface was pretty
straight forward, I did some rather complicated things in the design of the
priority system, because the original memory for the PDP-6 was a four-port
memory and we made ours a six-port memory. I had two high-priority ports
and then four ports that were "first come, first served." And trying to work
out the first-come, first-serve thing so that there were no conflicts in it was
kind of an interesting problem. Because you have this question "What is
simultaneous and if you get simultaneous requests in, how do you fix the
problem? We discovered a way that we could put the whole thing together,
and we would never lose any memory requests, and they would be handled
pretty much in the order in which they were received, except for the two
high priority ones. These were all very interesting times.
The PDP-6 was, for Digital, a disaster. The problem with the 6 was that
they had converted to silicon NPN technology rather than Germanium PNP
technology. The silicon transistors they used, these stacked transistor gates,
had a 0.8-volt offset on the base. You had to get the base at least 0.8 volt
above the emitter otherwise there was no conduction. And, in Germanium,
that was down around 0.2 volt rather than 0.8 volt. So, when you began to
stack these transistors up you began to get into noise level problems. Well
they thought they had that solved by putting in, as a restriction, that you
could only stack them two high instead of three high. It turns out this was
not a particularly good idea and they only made something like twenty
PDP-6s. That wasn't very many. Each one required enormous tuning before it
could go out the door, and there were always big maintenance nightmares out
in the field. Well, we had pretty good maintenance people,
so we didn't have too much trouble with them. But, nevertheless, the
troubles were there; we had a lot more down time than we should have had.
They were just not a particular success. As a matter of fact, Digital sort of
decided it was not going to try to build a big machine again. But they
changed their mind some years later in the mid 60s. They decided they
would build the PDP-10, which was a copy of the PDP-6 only with much
better circuitry. The 10 was a very successful machine.
The PHP-10 went on and on and on for years and years through a number of different
incarnations. It was replaced by the VAXs but, over its lifetime, it was a
very successful machine. And the instruction set was essentially the same as
that in the 6, which everybody loved, but the circuitry was just done so
much better. The thing about those machines was they'd finish testing them
on the floor and they'd shut the machine off. Then they'd take them apart
and ship them to the site. Then they'd put them together at
the customer's site and turn the power on and they'd jump to the standard
first instruction and it would run the test that was last on the machine. This
was something the PDP-6s would never do, but the 10s would do it every
time. They were just great machines.
GAM: We had two of them eventually.
BW: Yeah, we finally got two of them. We had two 6s as a matter of fact, and we
replaced those with two 10s. The memory bus standard was still the same,
so we were able to use the PDP-6 memories on the 10.
One of the more interesting anecdotes, and this has nothing to do with the
design of the 6s and how bad they were, was a really, really, funny problem
which I remember to this day, because it was so great finding what the
problem was. They were having problems on the memory bus and, Jack
Noonan, who was the premier service technician of the organization finally,
called it quits. I mean, he was giving up. He said, "I do not know what the
problem is here." But the memory was not working; it just absolutely was
not working. So he showed me what was going on and, Jeez, it looked pretty
good to me, and then he made a critical statement. He said "That pulse,
where it looks good, is twice as wide as it should be". I looked and it was
twice as wide as it should be and I said, "The terminator is out at the end of
the bus." He went to the end of the bus and the terminator was gone. He
plugged a terminator in and that pulse went to standard width and the whole
thing took off like dynamite. This is what was happening and it was so
funny, he had picked the one place on the bus to look where, when the
reflection came back from the other end, it hit that pulse just as it turned off
so that the pulse looked twice as wide. But, it was actually a pulse coming
back, and that reflected pulse was just raising hell all up and down the bus.
He made that comment and it just instantly hit me that that was what was
going on. He checked and, by God, I was right! How many times do you get
As a matter of fact, that was something that I actually tried to demonstrate to
some of my students in a class that I had up at Davis. We got a bunch of
coaxial cable that we had coiled on the floor and I picked the place in the
middle and I had it unterminated, and I'd launch a pulse into the end of that
and sure enough I could get these two pulses to come together. I'd say now
notice that pulse is twice as wide, now look down here and you see one
pulse and then another pulse. Now, what's happening is that this reflection is
coming back. It was a real education on reflections in transmission lines.
GAM: And the importance of termination.
BW: Oh yeah. We had a number of different problems connecting the PDP-6 to
all of the other machines in the system. I mean these complicated projects
get started and you don't know what you're doing when you start.
I built this data channel. It had word counters and
memory address registers and buffer registers, and it was bi-directional and
it was designed for sending 12 bit bytes between the PDP-6, which was a 36
bit machine, and any other of the machines that we had in the system. The
3600s were 48 bit machines so they were multiples of 12. The 6600s and
later the 7600s all used 12 bit interfaces. The 7090s were 36 bits so they
were all 12-bit bytes. The STRETCH was 60 bits so it was 12 bit bytes.
GAM: The STRETCH word was 64 bits. As it came out of the memory it was 72 bits
with 8 bits for error control. IBM used ECC for the memories.
The memories were actually 72 bits wide.
That's why these memories could be used for the IBM 7090s and 94s. 64
bits also is also a power of 2, which was important for their addressing
GAM: Yes and the Stretch operands were 64 bits, and they always allowed the extra
8 bits for ECC.
BW: 8 bits ECC right, O.K. Well, what the hell! I forget what we did there.
Anyway, I called that channel the "Line Unit" because it drove the lines
to these external machines.
It had line drivers in it and, even though it was a data channel, I
called it the Line Unit and the name stuck. People came up to me and asked,
"why did you call that thing the line unit? It's a data channel."
One of the great stories about that thing, because the unit went on for years
and years after I left the Lab, was that one of the guys said to me one time
that somebody had asked for a change in the line unit to do something or
other. He was told "No, you can't make any more changes in the line unit,
every gate is used, every card slot is used, there is no way to make any
changes and so that's the way it stayed. We had just used up everything that
it had. But it was, apparently, a very successful circuit because it worked
reliably over the years.
Now in the 7094, which I also did the interface on, the interface simulated a
magnetic tape unit. To do that, we had to generate these rather
bizarre analog signals because the magnetic tape units were used to analog
signals coming off the heads and using peak detectors. The peak detector
circuit was very sensitive to peaks and I'd have a really sharp peak right at
the top of the signal. But, every so often, I would generate a rather benign
peak, but it would see that peak too, which gave us certain problems.
We actually had to use 10-megahertz logic to overcome this other
peak problem because I was generating these peaks by simply generating
steps into an integrator. Then I'd turn the integrator off. The integrator
wasn't a very good integrator and sometimes it would go a little bit far
above the baseline and, when I turned it off, it would want to sag back and it
would find that little bitty peak in there which wasn't supposed to be there.
So, I had to have some circuitry which behaved very quickly to get rid of this
spurious peak. Now, I don't believe that anybody ever programmed the data
transfers from the PDP-6 to the 7094s. We made the connection, but I don't
think anybody ever really got involved in that stuff, and after some number
of years the 94s left and all that circuitry went away.
One of the funny things that happened on the 6600 interface was that I read the
book. The book was all very clear about how to make a connection to the
6600. This was when we were building the Teletype interface. There was
a signal in there, which was called "clear". When the clear signal came
along, we were supposed to disconnect from the I/O bus. But every time
there was a connection made, the very first thing that happened was an
address came out on the I/O bus, a 12-bit address, and a pulse came along
saying "connect." If you were the device addressed, you connected, and if
you were not the device addressed, you disconnected. Because of that, I
couldn't see any reason to use the clear pulse. So I didn't wire the clear
pulse into the system. It didn't make any sense to me since I'm
either going to connect or disconnect depending on what they want. We got
a call from the 6600 maintenance people and they said "Well, we had this
dead-start problem and we absolutely could not get the thing to work until
we shut your box off, and as soon as we shut your box off than everything
worked fine." It turns out, and the book didn't tell you this, it turns out that
in dead-start, the first thing that comes out is a clear pulse, no address is sent
out. When that clear pulse comes out, certain devices connect and the rest
disconnect. It turns out the device that is connected is the switch panel and
then they would read the switchs. Only now, I was connected and every
time they asked for data, I'd send stuff up which would get OR'd in with the
stuff from the switch panel, and the computer wouldn't start. So we
connected the clear pulse up, and it cleared like it was supposed to, and
that took care of that problem.
When we made the connection to the 3600, we got the same argument
from the maintenance people. They said, "The only way we can make this
system work is to disconnect your box." But, at this time, I had a lot more
confidence and I'd known I'd done everything right. We got in on the 3600
box, and started to do some maintenance on it, and we discovered that ,inside
the 3600 mainframe, one of their power supplies wasn't on. And so, when
we tried to do anything, the fact that this power supply wasn't on screwed up
their logic enough that the thing didn't work. We said the problem is not
with us, it's with you, you've got this power supply failed in there, make
that power supply work and all our troubles will go away. They made the
power supply work, all the troubles went away, and they never called me
about problems anymore. Whenever they had a problem, they went in and
fixed it. That was sort of the standard solution that all of
these maintenance contract people had, that if
anything was wrong it must be Wyman's boxes causing it. But after the
3600 debacle, they figured that, well, maybe these people do know what they
are doing after all.
GAM: Well, you guys had that extremely good reputation all over the country.
Everybody said the best crew anybody ever had and I must say that one of
the greatest things in life is having others know that you are right.
BW: Well, it was a good crew, we had really, really good people in our
organization. They knew what they were doing and we got a reputation that
I think was deserved. But, I do remember one time, this was in the 6600
connection, the 6600 people required a rather interesting pulse. It had to rise
to a certain value and then it had to backswing. It rose to about 2 1/2 volts
above ground, and then it fell back about 2 1/2 volts below ground. The
reason they needed the backswing was critical. They needed the backswing
because they had to turn the circuits off hard and the only way they could
turn the circuits off hard was to suck the charge out of the base, and the
only way they could do that was with this backswing. It turns out that
Digital made a pulse amplifier that was a little bit wider than the 6600 pulse,
but it had the backswing and the amplitude was a little bit higher. I said
"Well what the hell, the amplitude's a little bit higher, let's try it." So I tried
it out, and it worked like gangbusters. I told Jerry Russell what I was doing
and he said, "That's Wyman's motto: Make Do!" That's right, there's no
reason to design a circuit if you can steal one.
Do you know Carver Hill?
GAM: Yes, quite well.
BW: He joined us very early in the OCTOPUS project and he was responsible for
a bunch of the communications, the Teletype interfaces. Carver went
on, in later years, to become chief architect of a computer data-collection
system for the Nevada Test Site. He came from one of the Carolinas, North
or South, I forget which. Then, of all things, he read that the University from
which he had graduated with a BS degree, (he got his Ph.D. from the
University of Oregon,) was offering an MD degree to anybody with a Ph.D.
in the Physical Sciences. They could get the MD degree in something like
two years of study at the school. He applied, got accepted, completed his
MD work, and is now practicing in the Carolinas.
GAM: He left the Lab and worked as some sort of a designer for a little company
down at the end of the valley.
BW: Yes, he did a digital oscilloscope thing. He worked for them for a while but
that didn't last too terribly long. I'm not sure if he did that as a consultant
job while he was working at the Lab?
BW: But he's now Doctor Hill.
One of the interesting things that we did in the Teletype world, the interface
to the computers, was always the Model 33 Teletype. In the Model 33
Teletype, there was a thing called the line shaft which continuously rotated
while the machine was turned on. The lifetime of the machine was
determined by the ability of that shaft to stay true in it's bearings, and it had
pretty crude bearings, so it was not designed for a long life. So, we installed a
little timer on it, and if people didn't strike a key or if nothing came across
the line for a certain period of time, it would shut the Teletype down.
This required, then, that before any message was sent to the Teletype, there
was a wakeup call and what the programming people had to do was send out
a character, wait for a couple of character times while the thing to came up
to speed and then send the message. That was the way the Teletype worked.
GAM: Yes, it was John Fletcher who had to make these accommodations.
BW: Yes. Now my group did that and one other thing; it was Warren Wilson and,
I think, Lou Janey who got involved in making a Braille Teletype for Jim
Willows. They made a special cylinder for the 33 Teletype. That special
cylinder had the little nubs on it so that it could actually dent the paper.
They actually had to strike two characters per character because they
couldn't make it work otherwise. They had a special reversing mechanism
in there; I'm not quite sure how this worked.
GAM: Well, it would dent the paper for half the Braille character and then the
other half of the Braille character, but then the fingers would need to feel
the other side of the paper where bumps instead of the dents could be felt.
BW: That's right, but it actually had to do it side by side. Otherwise the character
spacing might have been a little strange. But, nevertheless, they put that
thing together and they just sort of did it without any money. They were
paid salaries, but projects like this were sort of hidden
away in the various accounts.
GAM: That was the nice thing about the Lab; things got done because there was a
real need for them before there was a chance to be shown in somebody's
BW: Yes, and they made that thing work. Jim used that for years and years. Of
course, people had to understand they were talking to Jim Willows, and they
had to then run the ASCII through the translator, which would allow it to
print the Braille out.
GAM: It had to also be reversed because he has to fold the paper down over the
teletype case to feel the dents.
BW: Yes, yes, it was a rather interesting task. One of the more interesting things
about all of that though was that we read that IBM had been working on a
Brailler for their people and they'd spent a couple of hundred thousand
dollars developing their Brailler and nobody had any interest in it. We went
to the blind community and said, "We've got a Brailler that will work, you
can build it for maybe one hundred and fifty bucks per Teletype," but
nobody had any interest that either. Nobody had any interestit was
GAM: Well, I don't know what to say except there are all sorts of jaded palates.
BW: Well, it's a case where, what you need is, to get some blind people behind it.
The blind self-help organizations aren't typically all that great. What you've
got to do is get the blind people beating on the shoulders of these people
saying "We want this thing for us," and then maybe something will happen.
But there weren't very many blind computer programmers at that time, and
so it was kind of a problem. IBM spent all that money in the hopes of
attracting some interest, and they couldn't attract any interest. Of course,
they had a cost problem. We didn't have a cost problem and we still
couldn't attract any interest. It's just bizarre.
One of the things about the Teletype business was that every time we
bought a Teletype we got a three-volume set of maintenance manuals. Now
we had 300 Teletypes, and they got up to a thousand terminals finally.
So we had a room full of these maintenance manuals and there was
no way we could get rid of them because you can't just junk Government
property like that. I suppose we could have surplused it sometime or other.
But I remember one time when I came back to the Lab, and I was doing
other things, and I needed a Teletype manual for someplace. I went and
asked one of the guys in the Computer Projects Group if I could have a
manual, and he said "come on over, how many do you want?" and sure
enough, he had this room full of these manuals, it was wonderful.
GAM: Speaking of when you left the Lab, it was somewhere along in there that
Dave Pehrson took over?
BW: Yes, well when I left, Kent Pryor took over. Kent ran the thing for a
number of years and then Pehrson took over. He ran
it up until the time there was a re-organization in Computations and then
Pehrson moved to Computations and someone else took it over after that.
GAM: When did you leave the Lab? What's the date?
BW: 1966. I was there through 1965 and early in 1966 I left and went to work for
Digital for a year and a half.
GAM: And then you came back through Davis?
BW: Yes, I went to Davis and I spent a couple of years on the Davis campus in
school, and during that summer in between the two years I was down
working in Mechanical Engineering doing some computer support for those
guys. Kind of an interesting summer job. They were building, out at Site 300,
a four-head shaker system. The problem with shaker systems is the load
affects the response of the system. So, with a four-head shaker system the
big problem was trying to make sure that they could control the heads in
some reasonable way. I designed it, but I didn't build a system. What I did
was describe a paper exercise on how to use the matrix pseudo-inverse.
Because one of the things they wanted to do was be able to control each
head individually, but because of the coupling, they didn't have any nice
controls that would do that. All of the controls were cross-coupled. The
effect was they had a very complicated mechanism with something like
sixteen dashpots, sixteen knobs, that the operator was supposed to tweak
to uncouple this thing. How he was supposed to know what knobs
to turn was never specified. I developed a system, just a FORTRAN
program, really, which would determine what
the pseudo-inverse was to do this uncoupling operation and do it
even in the face of a singular matrix. Nothing ever came of it, but that's
what I did during that summer.
GAM: And when you came back to the Lab. At one point, weren't you in charge of
the mirror magnet control system?
BW: Oh, yes, that was quite a ways down the pike. I came back to the Lab and
went to work down in Experimental Physics, down on the Linear
Accelerator they had down there, and did a data collection system for them.
They wanted to do a three-dimensional pulse height analysis, and they built a
hashing scheme for storing the data items. Most of those
three-dimensional pulse height analyzers have very sparse matrices. You
have an enormous number of points in the thing. This was a thousand by a
thousand by a thousand. It was a lot of points or a lot of cells. A lot of
emptiness, so they handled the whole thing by a hashing technique. They'd
take in this, say, 30 bits and hash it down into 10 or 20, something like that,
and then store that off on a drum somewhere. That way, they'd compress it. I
was involved in that, I bought the drum for them and they were using a PDP-15.
That's another story, because one of guys who used to work for me in the
Computation Project Group at the Lab was now the man in charge of field
service, in the bay area, with Digital. We got this PDP-15 delivered, and there
were big stickers on the box, "Guarantee void if you open this box." So I
called this guy up, he was a friend, and I said "Look, we want to open this
thing up and get it ready to go." He says, "Well, you're going to void the
warranty if you do that." I said, "Really?" He says, "Yeah, really." I said,
"Ok, when can you come out?" And he says, "Oh, it'll be about two weeks."
So, they came out in two weeks, and they set the thing up, but I refused to pay
the bill, and I held them off for six months. They said, "Why won't you pay
the bill?" and I said, "The contract's not complete." They said, "What's
wrong?" and I said, "We don't have the maintenance manuals." And he said,
"That's all?" and I said, "That's all, but we can't pay it until we get the
contract completed," and he said, "Ok." So, I got the only two maintenance
manuals for the PDP-15 on the West Coast, and then we paid them.
I got to the point where I didn't like Digital very much. I worked for
them for a year and a half, and I thought they were the most difficult
organization I'd ever been with in my life. Of course, working for the Lab
spoils you. The Laboratory, I thought, had really good personnel policies,
and they seemed to know what they were doing, and the Lab was just a great
place to work, and Digital was not such a great place to work. Which is why
I only stayed a year and a half .
GAM: Back to your adventures. You were developing what is now called the
Computer Support Group. You collected a good bunch of guys and I don't
know where they all went, but they certainly aren't around anymore.
BW: Well, Chuck Cole who was one of the lead guys, is now
in charge of computer security at the Lab. He is the
computer security guru .
And he knows a lot about it. He's learned a lot and he's got the confidence
of management. He's a very sharp guy. He's always impressed me as being
one of the sharpest guys we had.
GAM: Yes. Incidentally, I was also pleased to learn that he was one of the stars on
the LARC. But go on...
BW: Jack Noonan went off to school, and got himself a BS degree in Electrical
Engineering, and went to work for Hewlett Packard for a number of years,
and then came back to the Laboratory.
GAM: Now he's teaching classes at Las Positas. I just interviewed him. He told
the story about how he and Nevin Sherman tracked down a logic error in the
LARC, arithmetic unit. This was long after the LARC had been delivered.
BW: Great! Jim Lyons retired.
GAM: Yes, I just talked to him too.
BW: And Teddy Rambo retiredgot Multiple Sclerosis and he retired. I
think he died here just a little while ago.
GAM: Oh, I'm sorry; I hadn't known that. He was a great person.
BW: Yes, well MS is not a nice disease. Who else is there? Well, we know about
GAM: Dr. Hill.
BW: Yes, and Kent Pryor, who was the leader of that group for a while. I taught
him when he was in graduate school at Berkeley. He went down to Silicon
Valley and he's worked at half a dozen places.
GAM: He's a disk specialist though?
BW: Yes. Pehrson designed the paging system for the PDP-6 that was never
used. I mean it was a thing that the programming people absolutely had to
have and we built it with SUHL  logic, which was the
original TTL logic, and it moved super fast, and he made it all work, and then
they never used it.
GAM: It started to work just when the group itself started to die. Bill Mansfield
was one of the pushers of that thing and he fell out of favor.
BW: Yes, and Pehrson went on, he was a Division Leader in Computation for a
while, and then he was a Division Leader in Electronics for a while. Then he
was Department Head in Electronics for a while, and then he was head of the
Personnel Division for a while, and now he's back doing something in Electronics.
GAM: Why did you leave the Lab, since you were having a ball?
BW: I wasn't having a ball, ok? Number one, when I took over, we had
about 20 people in the group. Engineers and Technicians, I think. When I
took over, we were maintaining the LARC and that was it. That was the sum
and substance of the whole thing. I added several Engineers and we started
building all this interface apparatus, we built apparatus and we built
apparatus. We had apparatus all over the place, and we never changed the
size of the group. One day, we were fighting a problem on the PDP-6, and the
LARC went down. We had Bob Garcia, who was, at that time, almost the
sole maintenance guy on the LARC. But, of course, we had Cole and we had
Lyons and we had Noonan. All those guys who really knew the LARC
intimately, but they were all working on other stuff. Garcia said, "Boy, I
really can't make this thing work. I really need some help." I said, "Well, we
can't give you any help, we're just spread too thin. Just turn the LARC off
and we'll get to it tomorrow." A few hours later, Sid called and said, "You
can't shut the LARC off" and I said, "Sid, I'm stretched too thin."
Well, we got the LARC working a day or so later and everything was ok for
a while. But I was getting harassed about budgets. All the time having to do
more and more budget work, and it just wasn't so much fun anymore. I
didn't have time to do anything that I really liked to do. Digital made me
this offer, it wasn't a particularly good offer, but it was no worse than the
one I had. Except it looked like I was going to get heavily involved in the
PDP-10 and I did get heavily involved with the PDP-10. For a short time, I
was Engineering Manager, but boy, was that a real bad deal. They just
didn't want to pay anything for that kind of stuff. You had to work like hell
and you had to put up with this crap from everybody all the time.
GAM: Was Allen Kotok in your group then?
BW: Yes, yes, him and Bob Clemens. They were the two super kleagals on that
stuff and they were almost totally unmanageable .
Initially, when I was there, I did some fun stuff. We put the first disk on the
PDP-10, I built the data channel for the PDP 10, and that was kind of fun.
But, then, it became all this other crap and it just wasn't a lot of fun.
GAM: So, the administrative stuff began to encroach on you and remove all the
BW: Yes, and working in a bad organization. I felt it was just a bad situation. It
had some really great guys and I really liked working with them. Then they
also had some real klutzes and I just hated working with them. Yet, I had to
work with them. At the Lab I just didn't run into those kind of people very
much. Anyway, I came back and worked on the LINAC for a while. Then
they were just starting the Laser Program at the Laboratory and I was done
with the LINAC stuff and they were looking for somebody to work in the
Laser Program. Ralph Speck was the Director of the Laser Program at that
time. Working directly for the German guy, a Director. The guy with the
GAM: I bet it was Carl Hausmann, sadly, now deceased?
BW: That sounds right.
BW: He was an ex-military guy of some kind or other.
Anyway, he was the guy who was in charge of Lasers. He's the guy
who hired Emmett. Speck was running this thing and they wanted some
computer stuff, and I was elected. So, I went to work in the Laser Program,
and then Emmett came in and, before one could blink, Speck was way, way
down in the mud. I mean, he was off operating one of the Lasers somewhere
and Emmett was bringing all his superstars in. He's got this one
computer superstar that really got himself into big trouble here a while back.
And I can't think of his name either, but he'd given his account number to
his sons and the sons were logging into the Lab computers at night and
using lots of time. It hit all the newspapers, and I don't know what ever
happened to that. But, anyway, I was doing computer stuff for a while for
them trying to build computer controls. Then they hired another guy from
Electrical Engineering, who came in and said, "Well, we don't want
computer controls on these lasers. These computer controls are out, we're
going to have push buttons and flashing lights and ringing bells and that's it."
Well, the Laser people thought he was great, OK? So, anyway, I said "well,
OK, I'm done with Lasers". I was working on my Ph.D. thesis at that
time, so I went to work in the Electronics Research Division. At that time, I
negotiated a deal with the Electronics people: They'd let me have
three-quarters time to work on my theses and the other quarter time to clean up
the shop. So, anyway, I did that for a year and a half. I got the thesis done; I
did a lot of computations on it.
GAM: What was your thesis topic?
BW: Clock Distribution Systems for Digital Computers. There was a theory on
distributed computers which says that, if you clock these computers in some nice
way, you can do distributive computing all over the place. I put together a
clock distribution system that would work in the face of pulse shortening
and pulse lengthening amplifiers. It would standardize the pulse at every
level, and guarantee to standardize it at every level. So, if you had a big shift
in the clock pulse, this shift would propagate through the whole line, but you
wouldn't eat any pulses. Why do you write a thesis like that? To get
the requirements for the degree done. But, Hershel Loomis and I got
a patent out of it. Then, after that was all over, I went to
work in MFTF and did the computer control there for about a decade.
GAM: I thought that was a very nice system you were putting together there.
BW: It was a very nice system, yes. There was a lot of very, very good
engineering done. Not just in the control system, but in that whole system. It
just broke my heart to see the whole thing never turned on. I thought I was a
big boy, and I could handle this kind of thing, but the more I think of it the
less I like it.
GAM: It was kind of a sad decision. But from the physics point of view, the
machine, even though it was ready to run, couldn't answer any questions
BW: The question they couldn't answer was, "Why in the hell do the thermal
barriers go away when the plasma density goes up?" The thermal barriers
were the big things that they had to make work. They'd sold the DoE on
thermal barriers as being the answer to the confinement question in the
mirror machines. They had demonstrated thermal barriers at low density.
Then they said, "OK, now our job is to the raise the density," and then the
density got up a couple more orders of magnitude, way below where it still
needed to be and the thermal barriers vanished. They could never explain it,
they could never get the thermal barriers to stay, and so the DoE decided it
wasn't going to throw good money after bad and so they just killed it.
GAM: Well Bob, this has been a most interesting and wide-ranging chat, and I
want to thank you for it. I believe we have finished.
 While in the Army, Bob was stationed at the Aberdeen Proving Ground, assigned to the ENIAC, originally built for the Army by J. P. Eckert and J.
Mauchly at the Moore School of Engineering, at the University of Pennsylvania.
BW: After being drafted into the Army, I was stationed at the
Aberdeen Proving Ground from mid 1954 to February 1956.
While there, I also met Roger Anderson, another person who
ended up at the Lab. Aberdeen was quite an experience, and it
set my career onto a different path from what it was on
when I was drafted. I had been a power systems engineer, but
after a bit more than a year at Aberdeen I was strongly
interested in the computer field and, after a couple of years in
graduate school, I was set for life. So, it was a good experience,
all things considered. I do have the dubious distinction in
late 1955, of shutting down the ENIAC.
While I was on duty. it had had a failure in the motor-generator
during the midnight shift (my shift) and I reported it
to the computer lab boss. He said, "Shut the whole thing off."
Although I didn't know it at the time, usage by then was way,
way down and they were contemplating the shutdown. The
failure in the MG simply precipitated things.
[Editor note: The ENIAC was designed and built at the Moore School of
Engineering by John Mauchly and J. Presper Eckert. It was intended to
calculate ballistic firing tables for the army. After checkout at the at the
Moore School, it was moved to Aberdeen, and used successfully until its
career ended one (dark & stormy) night in 1955.]
 The murder of Ben Gurley was both bizarre and unheard of in
that area of Massachusetts. In the end, a private detective, that had been
hired by Ed Fredkin and Edmund Berkeley, succeeded in uncovering suitable evidence
of the crime to satisfy the new grand jury. Mr. Blumenthal, the gunman,
is said to have had a list of persons he accused of harming his career that he
intended to kill; Gurley happened to be the first on that list. He never stood
trial, being remanded instead to a home for the criminally insane.
 [Editor note: The discussion of Bob's experiences at
Digital do not seem to have a direct effect on the main thrust of his work at the Laboratory. Accordingly, I present that discussion here.]
GAM: Well, I think the difference was partly that we didn't have to show a profit.
BW: Yes, but you can show a profit and still organize things better than they had it.
GAM: Of course, the early Digital was much different from the Digital you went
to, I think.
BW: Oh, yes, but they had really bizarre, bizarre problems. When you wanted
some drafting done, there was a central drafting organization and you had to
schedule those guys. Months ahead you had to schedule them, for when your
stuff would be ready for drafting and, if you were late, tough turkey, you lost
your position. And if you got the stuff to drafting, and they ran into any little
problem, they'd set your work aside and start something else, and they
would never tell you. Never, never, never tell you. You would negotiate
something with somebody and then someone else would come in and
completely dynamite your plans; you could never depend on anything. It
was just a terribly, terribly upsetting.
If you want a great story about how Digital was functioning, they made
these DECTapes. The PDP-10, the group for which I was working used
DECTapes. The manufacturing people had built a bunch with anodized
aluminum tape guides. What happened with the anodized aluminum was, as
the tape ran across them, the tape guides would charge up. After a while, the
little motors couldn't pull the tape across the tape guides because the tapes
would cling so hard to these tape guides. So, they decided that they were
going to have to fix that. They started building transports with chrome-plated
tape guides, which worked fine. Well, we had, in the PDP-10 group, a
bunch of these anodized aluminum units, and we wanted the organization
which made the DECTapes to take them back, refurbish them and deliver us
chrome-plated units. They didn't want to do it. They wanted us to buy new
chrome-plated ones and just junk the anodized aluminum ones. We didn't
want to do that. So there was a big meeting. I was there because I was the
Engineering Manager of the PDP-10 group, and Bob Seville was there
because he was the Product Line Manager for the PDP-10. There were
several other hangers-on, and then there was the guy in charge of the
manufacturing of DECTapes, and there was his boss who was the man in
charge of production. We filled up this conference room, there were about
20 people there with this guy who was in charge of the DECTape
production line sitting at the head of the table running the meeting. He said
to everybody assembled, "We're here because of a complaint from the PDP-10
people about the units which have the anodized aluminum tape guides
that we have delivered to them. They want us to take back the anodized tape
guides and supply them with chrome-plated tape guides. Well, I'm not going
to take back those anodized tape units without the explicit order from my
boss," His boss, who was sitting there right at the table, said, "Take 'em
back". And that was the end of the meeting. I mean you wonder what the
hell was that person doing? Why didn't he talk to his boss about it in the
first place, before calling this meeting, to find out what his boss wanted to
do about this thing? Why didn't he just agree to take them back in the first
place all on his own? Well, he was frightened to death of his boss because
he was a profit center, and this would be an added cost to his group. Well,
that's the way it worked. Everybody was a profit center. I think such
policies helped to ruin Digital.
GAM: They sure made nice machines; at least to begin with.
BW: The VAX is certainly a very workable work-horse machine.
GAM: That was a design of Gordon Bell and his students at Carnegie?
BW: Yes, and they finally made DECNET work and it's been very successful.
Now they're not so successful in recent history. They've got a lot of
problems recently. They fired old Ken because he wouldn't lay anybody off
and got a new president in there and Digital is still struggling to figure out
what their place is in the market.
 Chuck Cole retired in 1997 or so.
 SUHL stands for Sylvania Ultra Highspeed Logic. It was the original TTL integrated circuitry. SUHL and TTL, both, were IC versions
of the Yourke or Yourcke circuits developed by IBM for STRETCH and later used in the
7090 and 7094. SUHL preceded TTL by a few years, but the military
adopted the TTL standards and Sylvania abandoned SUHL in favor of the
 Editor's addition: I reminded Bob of that famous law;
managing two good programmers or engineers is like trying to herd a dozen cats.
He didn't laugh.
For information about this page, contact us at: firstname.lastname@example.org