An Interview with Bob Wyman

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 [1]. 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 [2]. It was a real loss.

GAM: Indeed!

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 reader—something like 2000 cards a minute—but 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 OCTOPUS system.

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 thing—we didn't know what we were doing either—we 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 with—I 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 disaster—things 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 was—which 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 great—it 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 that lucky?

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 scheme.

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 budget.

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 interest—it was absolutely amazing.

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 [3].

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 [4]. 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 retired—got 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 Carver Hill.

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 [5] 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 [6]. 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 engineering fun?

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 German name.

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 anymore.

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.

Footnotes:



[1] 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.]



[2] 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.



[3] [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.



[4] Chuck Cole retired in 1997 or so.



[5] 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 standard stuff.



[6] 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.