ae
The Analytical Engine, Volume 3, Number 1, November 1995 Page 1
-------------------------------------------------
The ANALYTICAL ENGINE
Newsletter of the Computer History Association of California
ISSN 1071-6351
Volume 3, Number 1, November 1995
Kip Crosby, Managing Editor
-------------------------------------------------
CONTENTS
EDITORIAL: X-VICTORY!!.................................... 1
LATE BUT GREAT (WE HOPE).................................. 3
CONVIVIAL CYBERNETIC DEVICES:
An Interview with Lee Felsenstein (Part 1)................ 3
HP'S EARLY COMPUTERS, PART THREE:
THE STRONGEST CASTLE: THE RISE, FALL AND RISE OF THE HP 3000,
by Christopher S. Edler.................................. 25
In Memoriam: JOHN V. ATANASOFF........................... 47
In Memoriam: J. PRESPER ECKERT........................... 48
IN MEMORIAM: GERARD SALTON............................... 49
A WEB PAGE FOR THE CHAC.................................. 50
SVERDLOFF SUCCEEDS WALLACE AT COMPUTER MUSEUM............ 50
Tech Corner:
MAKING NEW BATTERY PACKS FOR THE HP-35 CALCULATOR
by Douglas W. Jones...................................... 50
SUPPORT FOUND FOR TANDY PORTABLES........................ 54
Quick Take: SILVER ANNIVERSARY OF XEROX PARC............. 55
Quick Take: APPLE II RESOURCE LIST....................... 55
Quick Take: AMIGA PREVAILS!.............................. 56
SPOTTER ALERT............................................ 56
SPOTTER FLASH............................................ 56
MONEY, THE WORLD, AND THE ORDERLY PROGRESS OF DAYS....... 57
Book Review: Max Maxfield's BEBOP TO THE BOOLEAN BOOGIE.. 57
ACQUISITIONS............................................. 59
LETTERS.................................................. 61
QUERIES.................................................. 63
ARTICLES NOTED........................................... 69
PUBLICATIONS RECEIVED.................................... 70
ADDRESSES OF CORRESPONDING ORGANIZATIONS................. 71
NEXT ISSUE............................................... 72
GUIDELINES FOR DISTRIBUTION.............................. 72
GUIDELINES FOR SUBMISSION................................ 73
NINES-CARD by Tom Van Vleck.............................. 73
-------------------------------------------------
Editorial: X-VICTORY!!
-------------------------------------------------
We scarcely dared to hope, but we dared to work, and work
brought forth what hope alone never could have. The magnificent
SDS 930 came home to California....by a whisker.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 2
On August thirty-first we received e-mail from the Federal
agency that owned the 930, saying that for administrative
reasons, a firm acceptance of permanent loan would be required
within a month. Well, move it or lose it. The CHAC had been
working on this since late last year, and every request we had
made in e- mail, all the pep talks we'd given at conferences,
every stern warning we'd published in the ENGINE, had
netted....a few hundred dollars; and we couldn't hope to load,
and ship, and unload the 930 for less than a few thousand.
Could we raise, in a month, what we had not raised in half a
year?
We have three phone lines here, and 1,600 names in our database.
The only answer was obvious, arduous, time-consuming, expensive,
and a bit scary - but it was the only answer. Telephone calls,
confirmed with e- mail and backed up by stamped return
envelopes, brought in over $7,000 in pledges by the end of
September. It was more than we ever thought we could raise - and
yet it was barely enough, because as we progressed from mover to
mover and described the job, the estimate of costs almost
tripled. Yet energy, community and generosity prevailed.
At 8:30 on Wednesday morning, October eleventh, a moving van
pulled onto a blacktopped lot in the South Bay and finished its
fourteen-hundred-mile trip from the Space Environment Center in
Colorado. We joyously took delivery of fourteen racks, two
Teletypes, a console, a VDT, and approximately forty boxes of
tapes, docs and spares, to a total of 10,300 pounds -- which
only (yikes!) filled about a third of the truck. A picked crew
of CHAC stalwarts spent two hours removing ductape,
non-historical stickers, deteriorated insulation, etc., and
eased the whole computer into a locked, ventilated steel
container. We're planning a Tiger Team Party in November to
clean, dust, lubricate, and otherwise prepare for long-term
storage with zero deterioration. Although the amazing thing is,
how clean and pretty the 930 is even now....
This has to be counted a stunning success - meaning that it
stunned _us._ It's true that the CHAC was in an advantageous
position to raise money, since we had a good cause, a serious
deadline, and a great list. Even so, in the two weeks that
lifted us from bare hope to the edge of triumph, we felt
dizzying relief. The words "emergency" and "computer history"
don't often occur in the same sentence; we had no idea what
might happen when they did.
The donations were as encouraging in their pattern as in their
total; they ranged from $20 and $25 to literally thousands of
dollars. It proves at a stroke that support for the history of
computing exists at every level, whether corporate or
individual, and across a whole spectrum of professions.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 3
In February the ENGINE will publish a photo feature on the 930
with a Heroes' List of donors who will consent to have their
names published. Meanwhile, to everybody who donated, advised,
drove, e- proselytized, or got their hands dirty, our most
heartfelt thanks and regards.
-------------------------------------------------
LATE BUT GREAT (we hope)
-------------------------------------------------
Through clenched teeth we admit that, even by normal standards,
this issue of the ENGINE is late. The reasons are
straightforward: The fundraising campaign for the 930 Rescue,
and the writing and installation of our Web page, together
required about as much time and energy as one ENGINE. We didn't
have it in reserve and magazine production had to slip. Three
points follow from this:
1) For the first time, as we're publishing one issue, we have
almost all the material in hand for the next. November may be
late, but February won't be _as_ late.
2) The CHAC can only increase its resources of time and energy
by enlisting volunteers. We are eternally grateful for those we
have; we can always use more. Please contact us if you can spare
even a couple of hours a month.
3) We promised thicker ENGINEs and we're delivering. This issue
starts a provocative interview with Lee Felsenstein and winds up
the HP's EARLY COMPUTERS series with an article by Chris Edler
on the development, release, redesign and re-introduction of the
3000 series; the letters and queries are here too, along with a
review of Max Maxfield's superb introductory text on
microelectronics, and a lot of current news that we only had
time to summarize. More people seem to be interested in writing,
they are _not_ running out of computer history to write about,
and we'll continue to publish as many pages per year as our cash
on hand permits. Enjoy!
-------------------------------------------------
CONVIVIAL CYBERNETIC DEVICES:
From Vacuum Tube Flip-Flops to the Singing Altair
-------------------------------------------------
An Interview with Lee Felsenstein (Part 1)
[Lee Felsenstein - sysadmin of the pioneering wide-area network
Community Memory, contractor for Processor Technology,
hard-working moderator of the Homebrew Computer Club, and
designer of the Pennywhistle modem and the Osborne One - has
lived a life constantly interwoven with the history and
philosophy of computing. Through it all he's pursued Ivan
illich's ideal of "conviviality," insisting that technology
The Analytical Engine, Volume 3, Number 1, November 1995 Page 4
attains its highest purpose only when it becomes understandable,
approachable, repairable and usable by ordinary people. This
first part of a projected three-part interview takes us from
1959, and a computer club without a computer, to 1975, Homebrew,
and Steve Dompier's history-making implementation of "Fool on
the Hill."]
CENTRAL HIGH
-------------------------------------------------
KC: Let's start with flip-flops in high school....
LF: Yes, at Central High School in Philadelphia; it was the
college prep public high school - actually the third high school
in the nation, founded in 1838. Until 1983 it was a boys' school
but it's since gone co-ed under pressure of a court decision.
But in 1959 my brother Joe was a senior and I a freshman, and he
founded the Central High School Computer Club. He had been
looking in books from the forties that he found in the library,
with vague circuits in them of gates and flip-flops, and he
wanted to build a computer - I think because he wanted to
program one. Of course computers in those days had a tremendous
cachet, they were UNIVACs, the "giant brains," they would occupy
half a floor of a building. He would show me these books and
say, "Can you build this, can you build this?" - and while I had
my doubts, my relationship with him was such that it wasn't
legitimate for me to say no, or so I thought; it was just my
position as a younger brother, to always be tagging along. So
he founded the club and installed me as the chief engineer, and
we would take 6SN7 tubes - dual triodes - and mount them in
sockets in cigar boxes. I had a basement workshop at that point,
I was familiar with the tools, and I even had a rather crude
audio oscilloscope. And we tried to make flip-flops so we could
make logic elements, counters and registers and so forth.
Probably they would have worked quite well, except that I was
completely ignorant of so many fine points. For example, we were
trying to create pulses for counting by flicking wires against
Fahnestock clips on the cigar boxes - and I can't think of any
better way to create a random stream of pulses than that! But
that point never entered my mind and I didn't really have any
mentors who would point this out. We certainly could have used
help from an engineer, preferably in the computer business, but
we never really considered going out and asking for it. It had
only been two years since Sputnik, and the school was dominated
by a competitive aspect that ruled us all. I mean, some of the
boys were keeping running grade point averages up to three
decimal points in the backs of their notebooks, that sort of
thing. We were all supposed to go claw and scramble over each
other and get into the best colleges. Actually, that kind of
thing had been happening at Central High School for generations.
In any case, the Central High School Computer Club managed to
produce a couple of two-bit counters that probably worked about
fifty per cent of the time, using our techniques. I concluded
from that whole experience that computers were not for me. I
The Analytical Engine, Volume 3, Number 1, November 1995 Page 5
knew I had a future in electronics - I wanted to be an
electronics technician at that point - and that gradually
evolved into, well, I'm going to college so I might as well
study electrical engineering. I had gotten into electricity and
electronics at the age of 12, when I read in a chemistry book
that if you wanted to be a chemist you had to learn a lot of
mathematics, and I was having trouble with percentages at that
time. Only much too late in the game did I learn that electrical
engineering required the most math of any engineering. So much
for career planning! My experience with the Central High School
Computer Club made computers simply too frightening for me, from
a hardware standpoint, because they had to get it right every
time, every clock pulse. I had no particular interest in the
software, so that turned me away from computers for a while.
(My brother, incidentally, went on to become a professor of
genetics, specializing in mathematics of genetics, population
genetics and so forth.)
BERKELEY, FSU, AND AMPEX
-------------------------------------------------
My next experience even close to computers was in 1965, when I
worked with what was called the Free Student Union, which was
the successor to the Free Speech Movement at Berkeley. I learned
how to punch cards on an [IBM] 026 card punch. You could walk
right into the card punch room and use it without any questions
asked, so I punched and sorted the membership lists and we used
them for local meetings that nobody came to.
At the end of 1967 I had dropped out of school, I was in a
psychological depression, and in the beginning of '68 I went off
to work as a junior engineer at the Special Products Division of
Ampex Corporation; then at the end of 1969 I dropped out of that
job, and then dropped back in when my money ran out.
Ampex is almost gone now, but it was a big company in those days
and a division might have two or three thousand people - the
Magnetic Tape Division as an example. The Special Products
Division, which was a hundred and fifty people in a little
building on the Redwood City campus, took responsibility from
beginning to end for one-of-a-kind products. We might just take
an item from stock and paint it purple, or we might design
something from the ground up. We'd gotten into the design of a
large-scale audio-visual instructional system, called a Pyramid
system, controlled by a [Data General] Nova minicomputer. About
three of these were built. Well, in 1970 I was put on this
project - that I didn't want to be on, because of that computer
controlling it - and I was rather quickly given responsibility
for catching the bugs in designs that other people had
prototyped, and then teaching other people about how they worked
and to support the ongoing effort; it's called maintenance of
product design, MPD. I started with the tone detectors, which
The Analytical Engine, Volume 3, Number 1, November 1995 Page 6
were nice comfortable analog things; but I moved on to something
I had done previously, which was design of audio circuits for
high speed tape duplicators - IS oscillators at 1 megahertz,
that sort of thing. In effect it was hi-fi design at 40 times
frequency step-up, which was very interesting. But now I
couldn't avoid getting into computers....
KC: Right.
LF: And first of all I was sent to class to learn BASIC at the
Service Bureau Corporation, SBC, which was the setting for some
very important realizations. The instructors at that place were
young guys in three-piece suits who liked to show off how much
they knew. And they would say, "You see how the system sort of
hiccupped there and it's running more slowly? That's because the
computer in Los Angeles has been turned off and it's been
transferred over to the computer in Kansas City." This was my
first experience with networked computers, and I understood that
geography could be irrelevant on a computer network, providing
it extended to the various places. They also showed me how files
could be made public with levels of accessibility, by
pre-pending asterisks to filenames; three asterisks on a
filename and anybody in the system could get the file - in
effect, it had been published. So I saw a hierarchy of
distributed publication possible there.
KC: Now, what operating system was this?
LF: I don't know what operating system it was. I presume that
SBC had won some kind of anti-trust suit with IBM and somehow
gotten an IBM network out of it, probably running on [System/]
360's, but I don't know the details beyond that and you may have
to look them up if anybody's interested. Almost certainly these
were IBM computers, we used Selectric terminals, 2741's. All I
knew was, I was learning BASIC. But I still had some important
realizations there, and several of them related to media and
publishing. I had spent much of my time in Berkeley working for
the underground press, on the grounds that this was a certain
kind of community media - media with less hierarchy. There was
still a hierarchy, by definition, because that's built into any
publication system, whether print or broadcast, where the
information is replicated identically and sent out from a single
point. In fact I had given up on the underground press because
it was subject to many of the same tendencies as the mainstream
press, including centralization, and the temptation to make a
spectacle of itself in order to increase its circulation. That
wasn't the game I was interested in playing, or assisting. I
wanted to help define, and help create, media that contributed
to the development of a local community. And now I was
presented with networking technology that could be a foundation
for communities of interest - communities that could exist in
defiance of geography. We could, at least in theory, untie the
The Analytical Engine, Volume 3, Number 1, November 1995 Page 7
knot that tied a single person to a single community. This was a
vision that I wanted to elaborate, and continued to pursue.
Meanwhile, at Ampex I also learned enough machine-language
programming on the Nova to do little drivers and so forth. By
the end of 1970 I did the programming to demonstrate the control
structure between, if I recall, 12 key pads and 12 buffer tape
recorders. The system worked through a series of master
recorders, each of which had 8 tracks on quarter-inch tape and
could run bi-directionally at high speeds. A matrix switch with
reed relays sent output to a buffer recorder at each student
position, or carrel. Each carrel had earphones, a video monitor,
and a 12-button key pad whose interface I had designed. You
would sit down at the position and punch up the number of a
program you wanted. That would set up a transfer between the
track on the relevant master unit and your buffer unit. So the
master would energize and do a high-speed tape duplication, 40
times speed, across to your local machine. In a minute and a
half [of duplication] you'd have an hour's worth of program
copied over. I think the transfer was carried out backwards, so
that when the duplication finished, your buffer machine was at
the beginning and would start playing, and you would hear the
program material on the earphones. Buried in the program,
meanwhile, were periodic bursts of 55 Hz tone which a tone
detector picked out and turned into a slow serial bit string;
and this would command the computer to do various things - not
only tape motion commands, but also primarily transfers of
pictures from a moving-head video disk recorder with a 14-inch
platter to a set of buffer tracks on another video disk, so
you'd get a still picture transferred from a repertoire of about
300 still pictures. That picture might present you with a
question, and the tape would be stopped, until you responded on
the keypad. The keypad, like the rest of the system, was
interfaced to the computer, and depending upon what your answer
was and the instructional program that was running, the tape
would either continue with the right answer, or rewind to
another track and play back an explanation of why you had been
wrong. It's interesting that, by 1990, I was able to build all
this functionality into a unit that attaches to your belt, works
off a compact disk, has a private-eye display and headphones,
and audio synthesis and speech synthesis and audio playback, and
a little pointer that you hold in your hand - an isometric
pointer; so that's a closing of a circle, in effect. But the
machine language programming that I had done, that allowed the
buttons on the keypads to command the tape recorders to do the
transfer and then start playing, saved my job [at Ampex] during
a reduction in force that was going on.
So I gradually became more familiar with computers, through
designing interfaces. I also did a design analysis program in
BASIC for the active filter components in the tone detector.
Those things are easy enough to design, certainly out of
The Analytical Engine, Volume 3, Number 1, November 1995 Page 8
cookbooks; the hard part is to build them so that the filters'
performance remains acceptable while components range over their
tolerances. I had been given a design with ideal values, and as
part of MPD I was supposed to figure out how to build it with
actual parts so that it would work every time without
adjustments.
KC: In other words, it'll work this way if it's perfect, but
what about when it's not perfect?
LF: That's right. Engineering is mostly about how far off the
ideal you can stray and still be safe. So I constructed a test
suite with a lot of nested loops that would vary each component
through its possible range - that's on the inside loop - then go
out and vary the next component one tick, go back in and vary
the first one through its range. There was a nested loop for
every component. Running this in BASIC on the Nova, I was able
to demonstrate that no possible set of combinations for that
design would work over its entire range. Meanwhile, of course
the units that had already gone in the field - the prototypes,
in effect - were giving all kinds of trouble. So they sent out
an engineer who was clever enough, and simply didn't want to
hear about anything else; and he sent back a cardboard extension
to the board wired with potentiometers and one-shots and some
other parts. He had done almost everything that I wasn't allowed
to do, and I was told "Okay, just put that in the design and
build it." Naturally we did wind up with adjustments, and that
was an excellent lesson in the relationship between engineering
and management.
KC: They realized that there had to be in-line adjustments built
onto the board to compensate for the drift of the components.
LF: Basically, yes. The problem, though, was that this didn't
work particularly well either. What he had done, in effect, was
tune to the performance of the master tape recorder - the AG-440
master. We proved with a recording oscillograph that feeding the
[55 Hz tone] bursts into the master tape recorder caused the
circuitry in there to go into an oscillation, so that the
baseline of the signal would wobble drastically, and the audio
jumped around at a very low frequency.
So this guy had been totally empirical, and tuned his circuit to
that bouncing behavior. He just scoped it and caught the level.
This worked until we changed the master tape recorder for the
next system, and suddenly it stopped working. I could tell that
this was getting us into trouble and I began to advocate using
automatic gain control - control of the signal's variations. I
kept an automatic gain control in development as long as I
could. I had to stand up at review meetings and be told "Kill
that, freeze the design the way it is and go on." Eventually I
did as I was told.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 9
A couple of years later I went back to see what had happened,
and discovered that an engineer named Al Alcorn had been given
the circuit to fix up, apparently by putting in automatic gain
control and increasing the size of it from one board to two - in
short, the things that I had wanted and tried to do.
KC: This is the Al Alcorn -
LF: - who co-founded Atari. And in fact, a year or two later I
was sitting in front of his desk applying for a job. Al was
looking for manufacturing engineers at that time. He didn't
remember much about the tone detector, but it was certainly an
embarrassing and instructive moment. That event and a lot of
others have kept me from ever really feeling good about the
wisdom of management.
At the end of 1971, I had been doing psychotherapy for a while
and things were getting better. I took educational leave to
finish up my degree. Since I was on the co-op work/study
program, I was able to convince myself that my combination of
class work and experience had put me five years ahead of my
classmates; I had eaten up four of those years, from the end of
'67 to the end of '71, so it was time to get my degree - which I
did, in June of 1972.
The Pyramid System project was moved into the Videofile
building, where Alcorn was, and I spent a few weeks commuting
down to Videofile. Then I left, and Ampex basically collapsed.
Everybody got laid off.
WIDE-AREA GOES PUBLIC
-------------------------------------------------
Meanwhile, in 1971, a guy I had known in my activism days came
running up to me and said, "There's some people over in San
Francisco that have a computer, and they're going to use it for
non-profit activity." I decided to investigate. This was a
group of four computer science students who had left Berkeley
during the Cambodia crisis, and essentially dropped out of the
system as it was; they had come to rest at a "warehouse
project," or warehouse community, called Project One in San
Francisco - where a group of people basically formed an
unincorporated non-profit association and leased a warehouse.
Within this Project One, these four guys created Computer Group
One, and were trying to deliver computing power to people and
organizations who lacked access - to non-profits, to radical
groups, to social-action groups of every kind.
Through an inspired act of hustling carried out mostly by Pam
Hardt, they managed to get an obsolete time- sharing computer -
an XDS 940 - donated together with money to set it up and run
The Analytical Engine, Volume 3, Number 1, November 1995 Page 10
it. This machine was serial number 4 and was donated by
Transamerica Leasing; it had been down at SRI and apparently run
a robot known as Shakey. We understood that name very well,
because the 940 had a DMA channel which occupied a whole
cabinet, and we went deep into it and found the terminators for
the bus were wired to the wrong voltage - to four volts instead
of eight, which put them square in the transition region. That
would make anything connected to it "shaky." I think this 940
had also been used by Doug Engelbart, so it had had an
interesting life.
They had also begged a time-shared BASIC and were starting out
with time-sharing, which was ambitious to say the least. I
signed on basically as chief engineer. I was to be trained in
system maintenance by a guy named Al Montoya who lived at
Project One - it was living and working space both, kind of like
four stories of lofts - but Al disappeared the day it was
installed and didn't turn up for months. When I complained about
his leaving all he said was "Here I am." Meanwhile I had
absolutely no tutelage and no source of any; for one thing those
computers weren't all that common, there were only 58 ever
produced including conversions of 930's and 9300's. The
language we used for our information retrieval system, called
QSPL, was only available on 940's or on IBM 360's which wasn't
necessarily a time-sharing implementation.
KC: Now, at that point the computer had been moved from SRI to
San Francisco?
LF: It had been retrieved. Transamerica Leasing had leased it to
SRI, who obviously kept it for the requisite three years. At
the end of the lease Transamerica didn't have another taker for
it and chose to, in effect, donate it or long-term loan it to
this non-profit, Resource One. So it had to be delivered in a
couple of trucks; it was a row of about a dozen 19-inch relay
rack cabinets, each one about two feet wide - 19 inches is the
internal dimension - and so 24 feet of cabinetry. This machine
also required 23 tons of air conditioning. We had to run our
own power lines from the main power busses downstairs to keep
the thing happy, you didn't just plug it into the wall. It had
a fairly big line printer, a console that sat on a table, and a
Model 35 Teletype for the console terminal. The multiple serial
interface handled 8 lines, I think, and I had to design and
build a rack of modems where we could collect, if I recall, four
modem lines. It was usable by ASCII terminals, mostly Teletypes
which we'd begged from Tymshare after their lease contracts had
expired. They'd been used pretty heavily and when we got them
they were kind of sticky.
I think that, to today's computer user, the most amazing thing
would be the disk file we bought for it. This was a double width
cabinet, so it was about four feet wide, and it had two pull-out
The Analytical Engine, Volume 3, Number 1, November 1995 Page 11
drawers each of which would hold a 2314-style disk drive with a
stack of 14-inch platters that were removable; you took a
plastic dome cover and slipped it down over the pack, and you
could detach the pack and pull it out. We got one with double
density, so it was 58 megabytes. To fill just one of the two
pull-outs cost us twenty thousand dollars.
KC: You say like a [IBM] 2314, but not in fact a 2314?
LF: It was manufactured by Control Data, I think. We worked with
people from Systems Concepts, which was a mile away in San
Francisco, and Fred Wright - I think - designed and supervised
the construction of an interface which emulated the Data General
Nova back panel, and let us plug in a Nova disk controller that
we had bought. I did the mechanical design of the whole thing,
and that and the interface got it working. The system also had
a swapping drum, hundreds of fixed heads arranged around a big
conical drum, which would spin up; centrifugal actuators would
fling out and the drum would hop up into engagement with the
heads, because it was tapered towards the top. But this drum was
flaky - the surface was deteriorating, and nobody knew how to
fix it. We had a whole bunch of problems! The Ampex TM-4 tape
drives had gas thyratrons driving little solenoids that actuated
pinch rollers, and if you missed releasing one of them you could
snap your tape, because the tape was going in one direction and
the other pinch roller would come in pulling in the opposite
direction. Mostly it would just squeak and stay there, but it
could snap the tape.
KC: These were capstan drives, not vacuum-column drives?
LF: No, they had tension arms to buffer the speed variations.
The tape wound back and forth along these little roller guides
in the arms and interleaving stationary guides. So the arms
followed these arcs and their positions were sensed, and when
they got too far out, the tape would be speeded up. So no vacuum
columns. I muddled through somehow, and certainly it was all a
good education in antique electronics. But I never really got
trained strategically, to answer questions like: What is the
structure? What is going on inside this computer? Those answers
would have been distinctly useful, but they had to wait till
later.
ROGIRS, A PUBLIC DATABASE
-------------------------------------------------
In 1972 we had the thing installed, and we embarked on writing
an information retrieval system. Richard Greenblatt came through
town at just that time and gave us a combination lecture and pep
talk with a focus of, "Let's write an information retrieval
system in one day." And he sketched out a free-form keyworded
information retrieval system whose data could be arranged
The Analytical Engine, Volume 3, Number 1, November 1995 Page 12
according to new index words on the fly. The easy way to do an
information retrieval system is to determine what words you're
going to use as indexes, put up a list, and have the user enter
an item by choosing from the list. The hard thing is to make
that list expandable in the middle of everything, so Greenblatt
lectured on how to do this. I had brought a friend, a systems
programmer named Efrem Lipkin, who had an appropriate
background, and he took on the direction of the project. The
final code was called ROGIRS, the Resource One Generalized
Information Retrieval System.
We were going to use this for the benefit of the Bay Area
switchboards - volunteer information and referral agencies.
Anybody with a card file box and a telephone could set up as a
switchboard on whatever topic or in whatever area, publish a
free notice in the underground press, and be in business. The
trouble was that, for the great majority of switchboards, the
filing system existed only in one person's head. When that
person got burned out and left, which was only a matter of time,
another person would have to come in and start the filing system
from scratch. It was quite inefficient.
DIFFICULTY AT THE BEGINNING
-------------------------------------------------
Now, Resource One had been attending meetings of switchboards in
San Francisco, because they had taken over the corporate shell
of something called the San Francisco Switchboard, the other
half of which had become the Haight-Ashbury Switchboard. We
were going to give the switchboards a common filing system and
enable them to share resources, thus the name Resource One. We
took the better part of a year to get that retrieval system
written and debugged, at which point we went back to the
switchboards, and discovered that all our contacts had burned
out and left and nobody remembered us - although one person in
the meeting apparently remembered hearing about us. So for
practical purposes we walked in cold, all smiles, proposing that
each switchboard pay $150 a month to rent a teletype and a
modem, so that they could then laboriously key in their files,
and only then could their users get anything out of the system.
Nobody knew how to deal with this, none of the switchboards had
$150 a month to spend, and we were not really treated seriously.
So we then had a reasonably powerful, empty information
retrieval system and went about looking for things to do with
it. We talked to many people, including some librarians at the
Bay Area Reference Council - which is the library of libraries;
if your library doesn't have a book, the Bay Area Reference
Council is the organization through which it gets the book from
another library. The librarian understood what we wanted to do,
but said "You have something a lot like a set of shelves with no
books on it. Why don't you get some books on it and see what it
The Analytical Engine, Volume 3, Number 1, November 1995 Page 13
looks like?" Efrem was inspired by this and had the idea to set
up a public terminal in Berkeley, where he lived.
At that time, about June 1973, I had burned out from the stress
of living and working at Project One. Efrem and I realized that,
if we could establish a combination office and apartment in
Berkeley, I could live there and disengage myself from the
pressures of communal life, and Efrem wouldn't have to commute
to San Francisco. We proposed this to Resource One and
convinced them to finance it.
ON LINE AT LEOPOLD'S
-------------------------------------------------
By August of 1973 we were ready to put the public terminal up.
We had a possible location in a record store that was being run
by the [UC Berkeley] Student Union, called the Leopold Stokowski
Memorial Service Pavilion - later it became Leopold's Records.
We went to the Student Senate and said "We'd like to put a
computer terminal for an electronic bulletin board there," and
they said "That sounds great, why don't you do it?" I built a
foam plastic enclosure for a Teletype 33, with a clear vinyl
flap that attached with Velcro, to muffle the sound of the print
hammers. It had two ports in the front covered with overlapping
vinyl flaps, like a cat door, so you could stick your hands in
and use the keyboard. Now, Berkeley didn't have local phone
service to San Francisco but some Oakland exchanges did, so we
used an Oakland prefix number installed at the store -
apparently it was a residential number and I still don't know
exactly how this worked - to make one call per day; that is, in
the morning we would dial up the phone and plug the handset into
the modem, and have a free connection to the 940 in San
Francisco all day. We were using an Omnitech modem, or something
like that, which was good for 300 baud under the most favorable
circumstances. I remember that the modem cost $300, which would
be the equivalent of $600 to $900 today.
PENNYWHISTLE MODEM
-------------------------------------------------
Then I started exploring the possibility of building a modem
ourselves, and I was encouraged by Fred Wright and the folks at
Systems Concepts, who said, "Well, essentially all you'll have
to do...." These were MIT guys, who gave me that word
"essentially," which really meant "and someone else will do all
the hard work," like the MPD engineers. But I didn't know that;
I just went ahead, tried it out, and hit upon something.
The first part of building a modem is to convert digital data to
tones, and that's easy. The hard part comes when you have to
detect the two tones and discriminate between them. In essence
we have a phase-locked loop oscillator circuit, which produces a
The Analytical Engine, Volume 3, Number 1, November 1995 Page 14
voltage that varies with the frequency of what it's locked to.
Against this we need a reference that says, when the voltage
crosses this line, the bit changes from a one to a zero. The
hard part was setting that reference and keeping it set, because
it would be perturbed by component tolerance, by temperature,
and by any number of other factors.
KC: You were trying to draw a line down the middle of a graph,
and if that line was any less than straight, you risked
misinterpreting bits.
LF: This is, again, "how far off the ideal you can stray and
still be safe." You can draw as straight a line as you want, but
the signal in the graph is going to meander somewhat, jiggling
back and forth all the time. You're dealing not only with
short-term oscillation but with long-term drift. What I realized
was that the modems of that day - and mostly of this day too -
were all specified down to zero baud. That would be preferable
for something like a burglar alarm, where you have a rented
phone line, a modem and a switch, and if that switch ever opens
you want to know about it at the other end. But that's not what
we're using it for. We're using it for data communication, and
that implies a minimum rate of transmission below which, who
cares? So that became the first breakthrough.
The second insight came from the work I had been doing to
survive. At this point I was consulting for my former bosses at
Ampex, who had formed a little consulting company after the
layoffs, and I was learning a lot about serial data
transmission. What I learned among other things was that for
asynchronous data transmission, in the absence of an error
condition, the signal goes back to a one level between every
character. (If it doesn't do that it's a break condition, which
means "The line may have broken, look out.") I set up a floating
reference, such that the "one" condition would always re-set the
reference, and whatever voltage that "one" wanted to be was fine
for the circuit; it would tend to drift slowly down towards
"zero," but then the data signal would come in and bat it back
up to a "one." It maintained very good referencing, unless you
went into a line break situation and after a few seconds your
data would turn to zero - which was appropriate, because a break
is a break. Rather than referencing the signal to the external
standard of a potentiometer, I was tying it to the last known
"one" condition that had come down the line, which was much more
accurate and more flexible. My goal was to run it off a cassette
tape recorder, because that was a popular and inexpensive
storage standard of the day, but the potential variations in
speed and pitch meant you couldn't do that with regular modems.
You could do that with this modem. I developed this in 1973, and
we used it for the Berkeley terminal to the 940, and after
further development it appeared as the Pennywhistle modem - the
commercial kit modem - in 1976.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 15
KC: Okay, the setup of the XDS 940 at the center of this ad hoc
network of modems and teletypes was what became Community
Memory. Now - are we to the Hazeltine VDT yet?
LF: Just about. We opened the public terminal at Leopold's
somewhere between the 8th and 14th of August, 1973, I think it
was the 8th. I planted an article in the Berkeley Barb that
week, describing it and giving a political rationale for that
model of distributed information, which still holds true with
me. But in January of 1974 we decided to move the terminal to
the Whole Earth Access store on Shattuck Avenue, which was then
in its first year of operation, basically as a catalogue store
for hippies and for communes. And we leased a Hazeltine 1500 CRT
terminal capable of operation at a princely 300 baud - actually,
the terminal was capable of much higher baud rates, but the
modem wasn't. We connected it to the Pennywhistle prototype,
which I don't think was called that yet, it was just "the
modem."
Almost immediately, something happened that raised pivotal
issues of public access and control - I wasn't present when this
happened, but I was told about it. We had a service contract
[for the terminal] and the service technician was working on it,
and dropped the circuit board for the keyboard. The chips were
ceramic packs in two clamshell halves, sort of baked together.
The top of one of the chips popped off and you could see the
actual die in there with the leads bonded to wires, and somebody
who was looking over the tech's shoulder asked, "Isn't that
going to be a problem?" And he said, "Oh no, it works." That
experience soured my belief in contract maintenance, and we
began talking about various ways to make a system like this
develop and grow and survive in a public access environment.
Efrem was in favor of armoring the equipment, to keep everybody
out.
CONVIVIALITY
-------------------------------------------------
I took the opposite tack. My father had recently sent me a book
called Tools for Conviviality, by Ivan Illich and published by
Harper & Row. Illich was a former Jesuit rising star who got off
the official track and began writing books about de-schooling
society, that was in 1970, and went on to establish some little
center that he worked from in Cuernavaca, Mexico. He had a
perspective that admitted technology and yet was very much
outside the industrial model of society. He described radio as a
"convivial," as opposed to an "industrial" technology, and
proceeded to describe basically the way I had learned radio, but
from the standpoint of its penetration into the jungles of
Central America. Two years after the introduction of radio in
Central America, some people knew how to fix it. These people
The Analytical Engine, Volume 3, Number 1, November 1995 Page 16
had always been there. They hadn't always known how to fix a
radio, but the technology itself was sufficiently inviting and
accessible to them that it catalyzed their inherent tendencies
to learn. In other words, if you tried to mess around with it,
it didn't just burn out right away. The tube might overheat,
but it would survive and give you some warning that you had done
something wrong. The possible set of interactions, between the
person who was trying to discover the secrets of the technology
and the technology itself, was quite different from the standard
industrial interactive model, which could be summed up as "If
you do the wrong thing, this will break, and God help you." So
radio could and did, in effect, survive in that environment
because it "grew up" a cohort of people around it who knew how
to maintain and sustain it. And this showed me the direction to
go in. You could do the same thing with computers as far as I
was concerned.
KC: Although possibly the computer technology of the period was
less forgiving than tube radio technology.
LF: Certainly; remember, I had backed away from it as a kid
because it was clear it had to work at every clock cycle. Such
reliability was unheard of to me, in light of factors like noise
in circuits.
STRATEGY SESSIONS
-------------------------------------------------
Well, I convened a discussion group around this whole concept,
and announced it in Community Memory. Bob Marsh, whom I had
known in college, turned up, and so did Ray Bruman - I think
there were about five people in all. So we had several
discussions about a computer appropriate for a public access
environment, how it would be built, what it would be like; and
my proposition, following Illich, was that a computer could only
survive if it grew a computer club around itself. What is this
computer like? How will it work? And we decided that the
central aspect of the computer would be memory - random access
memory chips were just then becoming available. Also, as part
of the Resource One effort, I had heard from Don Lancaster who
had written the September 1973 article in Radio Electronics
about the TV Typewriter.
KC: Which he then expanded into the TV Typewriter Cookbook.
LF: Yes. In correspondence with him, and in a phone call from
Resource One, I was trying to find out how to use TV Typewriters
as terminals, because several people had come by and mentioned
his article and said "You know, maybe you could use this."
KC: Okay, now. Just for my sake - in what way did this Hazeltine
terminal _not_ resemble a TV Typewriter, or was it simply too
expensive?
The Analytical Engine, Volume 3, Number 1, November 1995 Page 17
LF: $1500 or $1600 was far too expensive. The promise of a TV
Typewriter was that you could take a TV set and connect it to
this little box, which you could build yourself with a couple of
hundred dollars - not even a couple of hundred, a hundred
dollars worth of parts - and you would have a usable terminal.
Technically, the structures were the same. It was an excellent
exercise for someone who wanted to learn digital electronics,
not just digital but general electronics, and _Radio
Electronics_ got ten thousand paid responses for the two-dollar
plans in the article whereas they might have been expecting
twenty or thirty [responses]. So ten thousand people right away
wanted to build it, and that was positive proof to me that we
were watching the emergence of a convivial technology.
Having said that, I emphasize that the TV Typewriter was a very
difficult thing to construct. There must have been quite a
discrepancy between the number of people who ordered the plans
and the number who actually built something. It used sequential
memory, shift register memory, and was extremely tricky to build
and debug because it used lots of little analog delay pulses.
Bob Marsh had built one and he tried to expand it to improve its
performance, and he never really got it working - but that's how
he learned electronics! and that must have happened to quite a
few people. Also, the TV Typewriter was not entirely usable as a
terminal, because it was a paged display system; when you got to
the end of one page, and that last character went up on the
screen, you had only one-thirtieth of a second before the screen
blanked and you saw the next [character]. So you were actually
likely to be outrun by it.
KC: It didn't have any buffering for back scroll?
LF: No back scroll, that's right. I asked Don, "Why did you do
it this way if it's supposed to be a computer terminal?" and he
said, "It isn't supposed to be a computer terminal, people just
want to put up characters on their TV sets." And he was right.
So I had to think about why they wanted to, why "convivial
technology" depended on doing something so simple. I concluded
that people felt an urge to gain control over technologies that
they knew were really important and were affecting, or would
affect, their lives: computer technology, somewhat
metaphorically in this case, and television. The TV Typewriter
combined the two, and it was perfect. Lancaster was a
significant figure as a result, so far as I was concerned. He
had created a synergy between convivial technology and computer
technology _and_ he had shown that there was a tremendous demand
for this.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 19
THE TOM SWIFT TERMINAL
-------------------------------------------------
So I was picking into the design and working out some details,
and I called Lancaster back, and he said, "I've got a new
version that I'm working on and it uses random access memory."
Now that idea planted a seed with me and I said, "Aha, here's a
route into the convivial computer." Computers need random access
memory, and once you installed RAM in the computer, you could
use the same memory to run this terminal. I believe that that
was, in effect, the genesis of the architecture of the personal
computer, and if any academics want to make their careers by
arguing this point, they're welcome to see me and I'll help
them. My idea was to begin with a memory card and add a card
that was built to put data into the memory, either from a
keyboard or from a UART, and a third card to get information out
of the memory and put it to the screen. Connecting the three
cards implied a bus, so I defined a 44-pin bus structure that
used Vector connectors, which we could get quite cheaply, and
which was good for DMA transfers. That three-card set
constituted a terminal. I defined what the terminal would do
when it got various control characters, like, what happens when
it gets a carriage return? - well, it sets the character counter
to zero, but the line counter doesn't change. When it gets a
line feed, the line counter would increment, and all these would
be pointing to the memory. I put together a specification that
I called "The Tom Swift Terminal, or a Convivial Cybernetic
Device," and I mimeographed it and sold it for 25 cents. That
was in the fall of 1974. But the common memory, and the bus
structure, made this device potentially a lot more than a
terminal. You could plug in a replacement front-end board, or
maybe another display board, or an input editor board with more
smarts and possibly even a microprocessor. Along the way, if you
needed more memory, you could plug in more memory. Just as the
boards plugged into the bus, I wanted to make sure you could
plug the busses together to expand them. I never really
finished designing the whole specification, but the goal was
that the builder, the user, would control the rate at which the
device grew upwards into an intelligent terminal and then into a
computer _per se._ You'd just keep plugging! And that would be
the realization of the convivial ideal.
RESOURCE ONE DOWNS THE 940
-------------------------------------------------
In January of 1975, Resource One decided to shut down the 940.
We had gotten permission to put [terminals] into the Co-op
Markets, which would have meant a significant expansion, and we
didn't trust that 940 to support a larger system, given that in
certain ways it was marginal already. We weren't sure that the
drum storage unit was going to survive, although apparently it
did for many years after that. We weren't willing to risk the
farm. We also didn't want to continue development along the
The Analytical Engine, Volume 3, Number 1, November 1995 Page 20
dead-end line of QSPL, since what was that going to run on?
Finally, I had worked on the [Data General] Nova and we were
aware of the [DEC] PDP-11, both of which made it clear that
minicomputers were the way to go. The Community Memory Project
decided to split off from Resource One and go its own way,
attempt to secure a minicomputer and move the software over to
that, and come back with a system that was genuinely replicable.
I think that, overall, it was a wise decision for the long term;
for the short term, actually, it was not, but we weren't
operating from a tactical perspective.
BEHOLD, IT STREAMS ACROSS THE FIRMAMENT
-------------------------------------------------
As you know, January 1975 also saw the publication of the Altair
issue of the _Popular Electronics._ I was consulting and
publishing out of my studio apartment, which was somehow full of
a desk, a filing cabinet, a little work bench and a rack of
shelves which stood over my heater grate. That was LGC
Engineering - LGC stood for "Loving Grace Cybernetics," which
was inspired by Richard Brautigan's poem "All Watched Over By
Machines of Loving Grace" and had been tested out a little bit,
it was hanging up on the wall at Efrem's place. It was intended
that the Community Memory project would call itself Loving Grace
Cybernetics, and when it incorporated in 1977 I believe it did
use that name for a short while. We figured that LGC Engineering
would be the future hardware arm of this.
THE FOUNDING OF PROC TECH
-------------------------------------------------
Meanwhile, through these meetings in the fall of '74, I got
re-acquainted with Bob Marsh and he was looking for something to
do. Apparently his in-laws were helping to support his family,
so he wasn't in desperate straits, but he was unemployed and
casting about for something to build. He convinced me to go in
on a garage with him, at 2465 Fourth Street in Berkeley, which
cost $150 a month as I recall for 1,100 square feet. I set up
my bench downstairs and he took this little loft office that was
already in there, and put an air conditioner in it.
He and a friend of his, Gary Ingram, had access to a supply of
center-cut walnut boards that were exactly eight inches high and
about a quarter-inch thick - this had come from the Wisconsin
woods through a third party. They were trying to decide on
products to build with this walnut, and considering an
electronic clock that would have a walnut case, trying to sell
that through Bill Godbout or by mail order. That never went
anywhere. They were also looking toward some improvement on the
TV Typewriter, whether it was a redesign or just a kit to
improve the existing one - that's when Don Lancaster told me
"People just want to put characters up on TV."
The Analytical Engine, Volume 3, Number 1, November 1995 Page 21
Right then the Altair article came out. Bob showed it to me and
said "Look at this picture on the front. It's clear it's a
phony. Look at that lump on the side, that's not real." And the
pictures of the boards that illustrated the article certainly
didn't match what we could see on the front. So he said, "This
thing has nothing in it, it's an empty box." From what we could
tell, there was nothing much more to an Altair than the
microprocessor interfaced to a series of connectors. Bob wanted
to start building peripherals for it, so he and Gary formed
Processor Technology Corporation.
I remained a consultant and never became an employee or part of
the corporation, but I took on contract work drawing schematics
- I knew how to draw a schematic properly after doing some
drafting in 1967 - and writing the assembly manuals. I wrote
the caution that basically said "If you are not an experienced
kit builder, find someone who is and get them to help you," in
effect warning that unless you apply convivial techniques to
this you're not going to make it. I sub-contracted Jude Milhon -
who was Efrem's girlfriend, and actually I met Efrem through her
- to draw some little animated drawings of, say, a ceramic
capacitor lifting a top hat and making a dance step, which
demonstrated how you had to form the leads so that the capacitor
would fit between the chips diagonally and still plug in.
Now, I did not do a lot of the engineering. On the 3P+S
[Processor Technology port card] circuit, I figured out how to
jumper the divider counters to get the various baud rates,
although it's not easy to explain how that worked. Other than
that, I may have made very slight modifications to some of the
designs. But I was doing enough then to pick up a certain amount
of money.
KC: We must be about to the first meeting of the Homebrew
Computer Club - if I remember it happening during the first week
of March '75 in Gordon French's garage.
LF: That's correct - I think it was March fifth. I can't recall
whether Bob was doing any of this [Proc Tech] work prior to
that, I don't think so, but he and I kept talking about the
Altair.
PEOPLE'S COMPUTER COMPANY
-------------------------------------------------
Meanwhile, ever since Resource One days, on Wednesday nights I
had been going down to potluck dinners at the Community Computer
Center in Menlo Park, that was run by Bob Albrecht.
KC: Was that the same thing as People's Computer Company?
The Analytical Engine, Volume 3, Number 1, November 1995 Page 22
LF: Yes, I think sometimes they also called it People's Computer
Center, PCC. On Menalto Avenue, on the Menlo Park-Palo Alto
border, they had set up a couple of minicomputers running
time-shared BASIC service to be a game parlor, in effect, for
kids. What Bob Albrecht cared most about was kids and computers.
He had written a book called My Computer Understands Me When I
Speak BASIC, and some games for kids, and he published a
newsletter that was also called People's Computer Company.
There's a picture of Bob on the inside back cover of one of the
earliest Whole Earth Catalogues, sitting teaching a bunch of
kids to use a four-function calculator - which in those days was
a big thing. He's got this brush cut, looks like a porcupine.
The connection to the Whole Earth Catalogue lent a certain
prestige because we all thought of Stewart Brand as the guy who
knew exactly where it was at. So Bob set up the Center, and a
guy named Fred Moore sort of attached himself to it; he would
sign people up when they came in the door and was building a
list, and he wanted to organize some hardware classes, although
he knew next to nothing about hardware. The people at the
Center tolerated him.
Meanwhile, one night Gordon French went to visit the Kaylor
Electric Vehicle Shop a few doors down, and happened in on this
place; so he ended up on Fred's list.
THE FIRST HOMEBREW MEETING
-------------------------------------------------
When the Altair was announced, Fred convinced Gordon to make his
garage available, and then put out a call to the list. Thirty
people responded - including Bob Marsh and me, because we drove
down in a pick-up truck that I'd borrowed from a friend - and we
all stood around looking at this unit.
That may have been the moment at which the personal computer
became a convivial technology. You see, I had this particular
Altair before the meeting; it was serial number 8 or something,
it had been sent to People's Computer Company as a review copy,
and they gave it to me. I took it over to Efrem's place and
asked him what to make of it. Frankly, he considered it useless,
and in a way he was right, since there was nothing to it but
switches and lights. He kept it as a sculpture in his living
room, on the same table with his guinea-pig cage, with its
lights flashing to keep the guinea pigs company. I retrieved it
and returned it to PCC, and it turned up as the centerpiece of
the first Homebrew Computer Club meeting - by which time,
apparently, it had a sort of critical mass around it. Thirty
people stood and looked at it and started to tell each other
what they knew about it. Steve Dompier was there and reported on
the trip he had made to Albuquerque to try to get his Altair kit
from MITS.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 23
KC: Right. As I recall, he had sent MITS a tremendous amount of
money and said "Send me one of everything," and back in due
course, or undue course, came a letter from MITS that said "We
don't _have_ one of everything."
LF: Exactly. I don't know whether he had to go down there to
find that out, but he went down, and I don't think he was able
to bring his kit back with him - he got it a little later. But
he reported on what he had seen there, on what was in process,
and he said it was a very small operation - which came as a
surprise to a lot of people.
So the people in the room, including Steve Wozniak and Roger
Melen, began to understand that maybe as a group we knew as much
as these [MITS] guys, and that possibly the Altair wasn't even
an action item. It changed our focus and we said, "First of all
let's be in touch with each other, and sign this list, and tell
each other what we're doing." The written record of that was
reprinted and distributed to everybody as the first newsletter.
I talked about Community Memory and the Tom Swift Terminal.
Wozniak talked about the Breakout game he had done, and
discussed the video terminal he was working on. Marty Spergel,
who used to put together kits of parts for the _Popular
Electronics_ articles and sell them, actually gave away an 8008
chip at that meeting, which was a very nice gesture.
"WE WEREN'T NECESSARILY IMPRESSED"
-------------------------------------------------
Meanwhile, those of us who opened up the Altair box and looked
inside weren't necessarily impressed. We discovered, for
example, that out of four possible places for motherboards, only
one was filled with a group of four sockets, and of the four
sockets only two were occupied - one by the processor card, and
one by the memory card. The memory card in turn had sockets for
eight 256x4 static RAM chips, so the maximum capacity of the
card was 1K bytes; but MITS only supplied two chips, so the
stock Altair had 256 bytes of RAM, which was not enough to
support the kind of programming that most people wanted to do.
The processor card was nothing more than the 8080 processor
driving the lines on the bus through buffers. They had installed
separate data-in and data-out buses, which was really
inefficient, because you never did data transfers both ways at
the same time. That told me that whoever designed this didn't
know what he was doing - didn't really understand what a
computer bus was.
As we worked with [the Altair] we found problems that only
confirmed that impression. For example, the Phase 1 and Phase 2
clocks were sitting right next to each other on the bus.
Transmission line effects therefore caused coupling between the
two, and the last place you want coupling is on a clock line.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 24
The designer also used a positive-polarity Phase 2 clock - the
critical one - and he should have used a negative- polarity
clock, because TTL is much more effective on its pull-down than
on its pull-up, and you have much more noise margin going from 5
volts down to 2.4 volts than you do when you're going from zero
volts up to .8 volt. Many existing techniques could have been
used to fix these problems, but none of them were, so it was a
flaky design.
Also, the Altair needed everything. It needed I/O, it needed
memory that worked. MITS offered a 1K dynamic memory card, not
when the first machines were shipped but I think shortly
thereafter, and they worked okay. Naturally, then as now,
everybody wanted more memory and there was tremendous pent-up
demand for a 4K board, so that people could run things like
paper-tape BASIC. MITS began producing 4K dynamic memory boards
from a different design, and they loaded all kinds of disk
capacitors on them, but that's not all it takes to make it work.
MITS never really got the 4K boards to work, but they sold them
anyway. Almost all of them went out to customers and straight
back to Albuquerque.
Bob Marsh didn't take long to figure out that he could build a
board from the same 1K x 1 chips which I was using on the Tom
Swift Terminal, [Intel] 2102's. Eight of the 1K-bit chips made
1K bytes, and then 4 ranks of those made 4K; and Bob did a good
enough delay generator circuit, that board was produced as the
4KRA, I wrote the manuals, and Proc Tech was off and running.
At the same time the Homebrew Club - which wasn't called that
yet - was growing amazingly. It met every two weeks. The first
meeting was thirty people in Gordon French's garage; the second
meeting was in the auditorium of the AI lab, John McCarthy's
lab, at Stanford; and the third meeting was at the Peninsula
School. At the third meeting there might have been a hundred and
fifty people, although don't hold me to that, but I'm convinced
there were more than a hundred, because they were going out into
the halls to talk. Gordon French was trying to hold a lecture
on computer science up front, and people were screaming that
half the audience was outside - which I was too, because I
wanted to meet these people. I already knew that somehow we had
to impose some order on this process.
Now [Steve] Dompier in the meantime had gotten his kit and built
it, and he set it up at the third meeting with a low frequency
weather radio sitting on top of it. He plugged in the Altair and
hand-entered the program [with the switches] and of course
somebody kicked his plug out, and he had to toggle it in over
again. We all wanted to know what was going to happen and he
wouldn't tell us, he said, "Wait, wait, listen, wait."
The Analytical Engine, Volume 3, Number 1, November 1995 Page 25
Finally he pushed the Run button, and we heard music, and we
could identify "Fool on the Hill" quite quickly. It was the
strangest feeling we'd ever had, like "My God, where's the music
coming from? What is this?" The radio was picking up the RF
noise generated by the computer, and the tones could be
modulated by programming the computer to do things at different
rates. It was both absolutely brilliant and completely
serendipitous, and more than anything it spoke to the quality of
Dompier's intelligence, because it takes a particular kind of
mind to catch this stuff. I'm not at all sure I ever would have
figured it out.
When "Fool on the Hill" was over, the Altair began to play
"Daisy." Now "Daisy" was the first song that had been played by
a computer, I think in 1957 at Bell Labs. They accomplished
basically the same thing, but with a much bigger computer and a
speaker legitimately wired up to one of the bits. That tune was
historically recognizable as the beginning of all computer
music, which was why, in the movie _2001,_ the computer HAL is
being gradually lobotomized and regresses to singing "Daisy."
Dompier, I'm sure, had picked it up from there - as had most of
us - and he had done precisely the right thing by invoking this
to say that we claimed this history as our own, that we were as
much pioneers as Bell had been, but that the computers singing
for us were computers we could build and own ourselves. There
was a tremendous message in that and we all responded. He got a
standing ovation....
-------------------------------------------------
HP's EARLY COMPUTERS, Part Three:
THE STRONGEST CASTLE: The Rise, Fall and Rise of the HP 3000
-------------------------------------------------
[Note from the editors: The print version of this article
contains sixteen pages of illustrations, most of which
are reproduced documents. We are currently trying to decide how
best to distribute these graphics files to those who receive the
electronic edition of the ENGINE; your suggestions will be
appreciated.]
by Christopher Edler
cedler@boi.hp.com
"The HP 3000 was God's gift to computing" - Hank Cureton, HP
engineer[1]
"Listen, lad: I built this kingdom up from nuthin'. When I
started here, all of this was swamp! Other kings said it was
*daft* to build a castle in a swamp, but I built it all the
same, just to show 'em! It sank into the swamp. SO, I built a
second one! That sank into the swamp. So I built a *third* one.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 26
That burned down, fell over, *then* sank into the swamp. But
the fourth one stayed up. And that's what you're gonna get, lad:
the *strongest* castle in these islands." - Monty Python and
the Holy Grail[2]
THE ALPHA PROJECT
-------------------------------------------------
The HP3000 minicomputer was the first computer developed from
the ground up by Hewlett-Packard.[3] It was conceived of in
1969, designed in 1970 and 1971, and first sold in November,
1972 -- only to be withdrawn from market several months later,
and not re-released until 1973.[4,5] It has since become one of
Hewlett-Packard's most successful products, and to this day
contributes significant revenue to the company.
The history of the project is fascinating. This article will
describe the early days of the HP3000, what the machine was to
be originally, what it actually became, and what changed (and
why) in the meantime. It is a narrative of a machine that faced
daunting failures in the beginning yet, after re-release, found
relatively quick acceptance in the business data processing
market -- a field then unfamiliar to Hewlett-Packard.[6]
The HP3000 was, and still is, HP's premier business data
processing machine. It runs a proprietary operating system,
called MPE for MultiProgramming Environment, and supports both
batch and terminal- based users. It can support these different
users running different computer languages and applications. The
3000 has been very successful in industrial applications,
competing against such industry giants as IBM in manufacturing
shop floor applications, order entry, warehousing, and
production control.[7]
FOOTNOTE: The task of deciding a name for the operating system
was rather arduous, and was the cause of many a bellicose staff
meeting. Finally, the name was chosen by an engineering manager
as one that offended everyone equally. From an interview with
Frank Hublou, op. cit.
The 3000 was a very important factor in Hewlett-Packard's rise
to eminence among the world's computer firms. In terms of
dollar volume, MPE and MPE-based systems have only very recently
been surpassed in sales by the HP-UX line of Unix-compatible
systems that conform to HP's current "open systems" concept.[8]
But to the historian, the HP3000 is significant not only for its
long and lucrative success, but for the advanced computing
principles it embodied at the outset. The HP3000 was:
* the first 16 bit machine to have a stack and virtual memory.
* the first minicomputer to implement COBOL.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 27
* the first minicomputer to run a Database Management System.
* one of the first computers to be completely programmed in a
high-level language.
* one of the first machines designed by hardware and software
engineers.
...all for under $100,000.[9,10,11]
The HP3000 was, and is, undeniably a significant machine, but
its achievements were hard-won. It was actually released twice,
with an abortive introduction, quick recall, massive redesign,
and reintroduction.
ALPHA IS BORN
-------------------------------------------------
After the HP21XX series of real-time computers, released in the
latter half of the Sixties, the next- generation Hewlett-Packard
machine project comprised the 32-bit machine called Omega and a
smaller, 16- bit machine named Alpha. Omega was a truly
ambitious machine, essentially realizing the concepts of DEC's
VAX while pre-dating it by almost 10 years. Unfortunately, it
was a bit too ambitious for such a conservative company as
Hewlett-Packard, and was cancelled in 1970, after nearly 2 years
of work.
The Alpha project was supposed to be simultaneous with Omega,
but there were actually a few engineers at most working on Alpha
at any given time during the Omega development.[12] In fact, the
Alpha 1's External Reference Specifications, included as Figure
2, show a release date of July 20, 1970, less than four months
before the Omega was canceled.
Figure 2 Alpha External Reference Specs[13]
Tom Perkins, General Manager of HP's Data Products Division and
star of the HP21XX line, was the man who cancelled the Omega
project. He was promoted in the Fall of 1970 to head Corporate
Development, after which George Newman was made "GM," as HP-ers
called their divisional manager.[14]
Figure 3 shows the original Project Data Sheet for the Alpha
hardware system. Highlights from the "Objectives" section are:
1. a 16-bit computer system for multiprogramming and real-time
application.
2. an optimum architecture for efficient execution of high level
languages
3. an I/O structure that provides CPU independent multiplexed
data transfers of at least 1 megaword/sec
The Analytical Engine, Volume 3, Number 1, November 1995 Page 28
4. a fast multiple level interrupt structure
5. a modular hardware structure communicating over a time-shared
buss (sic)[15]
Figure 3 Project Data Sheet
Note the estimated costs for the Alpha hardware of $896,000 in
mid-1970. Figure 4 is a preliminary timeline that accompanied
the Project Data Sheet, showing an MR (manufacturing release)
date of February 1, 1972.
Figure 4 Original Timeline[16]
As mentioned, there was great dismay over the cancellation of
the Omega machine, and the decision to go ahead with the Alpha
was not received enthusiastically. Going back to "just another
16-bit machine"[17] had its discouraging aspects even beyond
preoccupation with the word-size; the engineers at HP felt that
they had been designing and working with a machine similar to
Alpha (HP21XX) for a number of years. The prospect of going
"back" to the Alpha might also have seemed pedestrian in
contrast to eagerly anticipated work on the 32-bit Omega. For
whatever reasons, Omega was sorely and widely missed.
But the Alpha, and subsequently the HP3000, were to become
Omega's memorial - intentionally or not - thanks to one
significant decision. The developers, consciously or
unconsciously, decided that the Alpha would be as much like the
Omega as a 16-bit machine possibly could. As one engineer of
that time put it, "We had an Omega mentality in an Alpha
box;"[18] in practical terms this meant that almost everything
about the Omega was "cut in half" but survived into the Alpha
plan. Both were to be virtual memory, stack- based machines with
three modes of operation - timeshare, batch and real-time. The
major differences were in the "virtual-ness" of Alpha memory
(only application code was "virtual", user data was limited to
64K), and in the input/output scheme - a particular
disappointment for the I/O engineers, who had designed elaborate
input/output hardware systems[19] for Omega's 32 bit data path,
which could never be incorporated into the Alpha.[20]
Upper management saw the initial Alpha specifications and had
some concerns over the functionality and feasibility of the
machine. Arndt (Arnie) Bergh, one of the prime hardware
designers for the project, recalls that, "...he [the general
manager and one of the people who ordered the cancellation of
the Omega] said 'You did it to me again. All I wanted was a
simple, clean, inexpensive instrumentation computer that would
do the job.'"[21]
The Analytical Engine, Volume 3, Number 1, November 1995 Page 29
In spite of reservations, the project was approved and
specifications for the Alpha were completed. By the time the
External Reference Specifications were released in July 1970,
the vision for the Alpha was complete in broad outline. It
would have a 16-bit data word with a single storage register. It
was to be stack- based with a maximum memory of 128 Kbytes, or
64K words, of ferrite-core memory.[22] (A common confusion of
the period devolved on the exact meaning of "XX K of memory".
Most minicomputer memories were measured in 16-bit data words
and generally described as nK (thousand)-data-word memories.
IBM, however, introduced the concept of 8-bit words called
"bytes", which became an alternate general usage that clouded
the issue.) The architecture as initially defined allowed for
multiple CPU's, although this feature was never realized in the
finished product.[23]
The system was designed for modularity, with communication
between modules over an asynchronous priority demand data bus.
It utilized an "omnibus" concept in which the devices all shared
the same bus. The maximum number of modules was seven.
THE OPERATING SYSTEM
-------------------------------------------------
A key distinction between the Alpha and other contemporary minis
was to be its operating system - a feature then generally found
only in mainframes. Minis were ordinarily bought with and for a
single application, or were intended to be programmed in machine
code by the user. HP envisioned Alpha as the first "general-
purpose" or flexible-purpose minicomputer, and an operating
system was essential to the concept. Alpha's was to be called
MPE, for MultiProgramming Executive.
MPE was actually three operating systems in one. First and
foremost, it was to be a timesharing operating system. This was
to allow "multiprogramming multiaccess - in particular, time
sharing with good term response".[24] The Alpha was intended
primarily as a timesharing machine, and its architecture was
chosen accordingly.[25]
Secondly, it was to be a real-time system. The designers
described the operating environment as commercial real-time and
process control systems with fast interrupt response time.[26]
Alpha in this context was intended to replace 21XX-series
computers in real-time operation.[27] This was a key issue for
HP, which considered real-time operating systems to be a "core
competency" for the company, and a significant source of
revenue.[28]
The third capability of the operating system was a batch mode,
in which jobs could be scheduled and run just as if from a user
terminal. Proportioning among these three resources could be
The Analytical Engine, Volume 3, Number 1, November 1995 Page 30
fine-tuned through MPE, in essence turning off modes not
currently needed.
How was this to be accomplished? The External Reference
Specifications sketched some of the ways:
"1. Program sharing of re-entrant code by two or more users
simultaneously (e.g. compilers, intrinsics, etc.).
2. Automatic resource allocation and overlay of infrequently
used memory.
3. Protection between users, and between users and the system.
4. Modular I/O organization to maximize effective device usage.
5. Users are segmented such that total residence is not required
to execute a program.
6. Fast interrupt response time and environment switching, plus
nesting of high priority interrupts."[29]
LANGUAGE
-------------------------------------------------
The primary programming language for the Alpha was to be called
ASPL (later SPL), for Alpha Systems Programming Language. It
was an ALGOL derivative very similar to that of the Burroughs
B5500, and - as ALGOL was the first language to handle
recursion[30] - was an excellent language for stack-based
machines. Alpha was designed from the ground up to accept SPL;
in fact, MPE itself was written in SPL, while most other
manufacturers wrote their operating systems in assembler.
FILESYSTEM AND I/O
-------------------------------------------------
The Alpha file system featured named files and directories with
controlled access. Similar to modern-day UNIX machines, the
Alpha relied on device-independent file access, and made I/O
devices accessible as labeled files.
Input and output processing could occur independently of the CPU
through an I/O processor (IOP) scheme. A master device, the
MCU, controlled assignment of time slices of the bus to modules.
This concept was unique enough to earn a United States patent
for the machine; the first page is shown in Figure 5.[31]
Figure 5 Original HP3000 Patent
The Alpha had 170 instructions (opcodes). For comparison, the
IBM System/360 had 142 opcodes. Each code was a 16-bit word, but
The Analytical Engine, Volume 3, Number 1, November 1995 Page 31
stack instructions were packed two per word. Instructions were
stored on a ROM (read only memory) chip 32 bits wide, so that
two instructions were stored per ROM address. [32,33,34]
The instructions were divided into functional areas as follows:
* Memory reference
* Stack & control
* Shifts, bit tests, conditional branches
* Immediate
* Linkage and control instructions
* Special opcodes
* Move opcodes
* Mini opcodes[35]
The machine was initially specified to give satisfactory
response time for 16 users when equipped with 16k of memory, or
32 users with 32k of RAM. If the system was only running BASIC,
the number of users could be increased by 50%.[36]
The schedule for completion, as quoted in the preliminary
document of July 1970, was:
Approval 9/8/70
Preliminary ERS 11/1/70
Final ERS 4/1/71
Begin system integration 5/1/71
System integration 11/1/71
Release 12/31/71
IMS complete 3/1/72[37]
The projected price of the machine was $100,000. It was to be
called the "HP System/3000".[38]
THE SYSTEM IS ANNOUNCED
-------------------------------------------------
The premier showcases of the computer industry, where companies
would announce and demonstrate their new technology, were the
Joint Computer Conferences held in the spring and fall of each
year. The industry and the press followed these conferences
closely.
Hewlett-Packard announced its "System/3000" at the 1971 Fall
Joint Computer Conference in Anaheim, CA. Although most
Hewlett-Packard users and engineers remembered it vividly, the
announcement only merited a small blurb on page 30 of the
November 11, 1971 issue of ComputerWorld, with the headline "HP
adds time-sharing system/3000".[39] The article stated that the
3000 had available RAM memory of 32 to 131K, a maximum cycle
time of 950 nanoseconds (pretty good in those days), an
instruction set of 170 commands, and could "be used as a front
The Analytical Engine, Volume 3, Number 1, November 1995 Page 32
end to an IBM 360".[40] It was to have BASIC, FORTRAN, SPL, as
well as COBOL "before the end of the year" (which didn't become
available until 1973). The release was to be in August,
1972.[41]
Elsewhere, it was advertised to run up to 16 terminal users on a
fully loaded system.[42]
A CLOUD ON THE HORIZON
-------------------------------------------------
In early 1972 things started to go wrong at the HP3000 lab in
Cupertino. The hardware was up and running in the form of three
prototypes, PP1 (Production Prototype 1), PP2, and PR1 (Pilot
Run 1).[43] The software effort was slowing down.
The first evidence of this can be found in office documentation
in early 1972, when the extent of the 3000's functionality was
being reconsidered in an effort to protect the late 1972
deadline. The real-time aspect of the operating system,
specifically, would later cease to be included (or even
mentioned) in internal documentation.
Figure 6 shows a memo from Ron Matsumoto, a manager in the O/S
section of the HP3000 lab, dated February 1, 1972. Notice that
on the 5/15/72 and 6/5/72 lines, real-time has been "stealthed
out". This will be one of the last times that real-time is
mentioned in a project scheduling memo. From now on, emphasis in
Alpha development would be entirely on timeshare and batch
functions.
Figure 6 Memo 2/1/72
MEANWHILE, IN A CORNER OF THE LAB...
-------------------------------------------------
Before we continue, Gentle Reader, allow me a brief aside
concerning a project worked on in 1971 by four programmers in a
secluded corner of the "Applications Lab", a section of the
HP3000 lab devoted to non- operating-system applications such as
the system editor, and to computer-aided instruction
software.[44]
File management software was being worked on in tandem with the
rest of MPE, and the HP3000 designers sought to include a file
inquiry tool (called QUERY) to enable searching. Two of the
programmers involved were Dick MacIntire and Lee Bollinger.[45]
Eventually the designers felt that they could expand their
utility into a data management application that could be used by
not only the operating system, but by all software languages on
the HP3000. The key was a very new concept called database
management systems, or DBMS - which may seem commonplace today,
The Analytical Engine, Volume 3, Number 1, November 1995 Page 33
but were still in their infancy in the early 1970s.
DATABASES AND DBMS'S IN THE 60'S AND EARLY 70'S
-------------------------------------------------
Early DBMS concepts can be traced back to the late 1950's, in
academic papers that discussed "generalized routines", which
could sort any file regardless of its data content.[46]
Early efforts at a DBMS included programs by GE, by SHARE, and
by IBM itself - notably the first release of RPG for the Model
1401 in 1961 - and RCA's Retrieval Command-Oriented Language,
developed in 1962[47]; but DBMS theory languished through the
mid-60s for lack of a perceived need. One of the first
commercially available database systems was written by IBM,
initially for the Apollo program, and publicly released for the
System/360 in 1969, under the name IMS.[48]
CODASYL, a group mandated to create standards for COBOL,
meanwhile formed a List Processing Task Force (later called the
Data Base Task Group) to construct COBOL database extensions.
They released reports in 1969 and 1971 with recommendations for
strategic "building blocks" of a database management system,
such as a data description language (DDL)[49] and use of what
was called the networked model of databases.[50]
In 1970, a third-party software firm called Cullinane released
their database product, IDMS, for IBM 360 and 370, which was
extremely successful.[51] Other key products of the period
included DMS 1100 for the UNIVAC 1108, and DEC's DBMS-10, which
ran on the PDP-10.[52]
IMAGE
-------------------------------------------------
At HP, the file management group and the inquiry group merged in
September 1971 and decided to work on an integrated data
management package. This package, named IMAGE most probably by
Dick MacIntire, would allow access to data files by any process
on the 3000 by the use of intrinsic commands.
The developers looked at a number of database systems then
available. The main data center at HP corporate headquarters had
a mainframe running the TOTAL database management system. The
team also read and investigated the work of Leo J. Cohen, an
early expert in database management concepts[53], as well as the
CODASYL report released in 1971. Image followed CODASYL
recommendations in being a network-based database, but the
product itself was not in full compliance with CODASYL
standards.
Scheduled for a second release of the system[54], Image was not
The Analytical Engine, Volume 3, Number 1, November 1995 Page 34
a high priority item at the time of the first release.
Developers on the project had very little clout when competing
for valuable and rare computing time on the HP3000 prototypes.
Most development was done on either an HP2100 emulating a 3000
or (primarily during weekends) on the third HP3000 prototype,
the one frequently cannibalized to keep the other two running.
Development took place throughout 1972 and early 1973, with
quality assurance testing beginning in mid- 1973. The product
could have been released in late 1973, but a late hire of a
technical writer postponed the introduction until the 1974
rollout of the HP3000 "CX" series.
...now, back to the HP3000 lab in early 1972...
SUDDEN INFANT DEATH OF A COMPUTER
-------------------------------------------------
"...we fired it up, and it was just quite slow..." Engineer
Arnie Bergh on the first HP3000[55]
BACKGROUND - THE HP3000 LAB ENVIRONMENT
-------------------------------------------------
A tension always prevails between the people who develop a
product and those who sell that product. This tension can be
good, in that - in the words of Ed McCracken, then Marketing
manager of the HP3000 and now CEO of Silicon Graphics
Corporation - "you generally have a marketing person and a
manufacturing person who provide some balance against the dreams
of an engineering manager."[56] But in less fortunate
circumstances, the tension can be so strong as to prove
catastrophic.
There were between 60 and 85 people in the HP3000 lab during the
machine's development. This staff were divided into 6
"sections", each devoted to a part of the project, such as the
operating system, user applications, or quality assurance.
General management was the responsibility of Steve Vallender.
Figures 7 and 8 are organization charts of each section in the
HP3000 lab in 1972.
Figure 7 R & D Staff List 1
Figure 8 R & D Staff List 2
The HP3000 lab was part of a much larger R & D organization
devoted to the many products of the Data Systems Division, which
included the HP21XX series of real-time computers.
Marketing was arranged somewhat differently. It was grouped by
sector (Educational/Medical/Government, Industry), and comprised
The Analytical Engine, Volume 3, Number 1, November 1995 Page 35
smaller product marketing and marketing support groups. Figure 9
shows an organizational chart of the Data Systems Division
marketing organization in 1972.
Figure 9 Marketing Org Chart
There was little love lost between the HP3000 lab and marketing;
or, to put it a better way, there didn't seem to be a lot of
mutual respect between the groups - especially with regard to
the "owners" of the project, those who would determine the
functionality of the product. One of the original engineers put
it this way:
"They [marketing] wanted to drive the project from
marketing...if they said it could do something, they expected
the lab to make it happen..."[57]
This tension was so evident and strong that (in the words of
Hank Cureton, an HP3000 engineer at that time,) "People from
marketing were banned from the lab".[58] The turf battle went
even beyond that; engineers were not supposed to discuss the
product or its progress with anyone in the marketing division.
Lab manager Vallender "discouraged us from talking to marketing
people", according to Jim Holl, Quality Assurance manager for
the HP3000 software.[59]
Denied access to development information, marketing was unaware
of the progress of the product, and of its true specifications.
They naively passed on whatever information they could glean to
their sales representatives, who presented it to customers.
Data sheets were created before the development was complete.
Published performance data were, in general, more optimistic
than what the lab could measure on running prototypes[60] - and
this over-optimism was anything _but_ naive. As Ed McCracken put
it, "there was a lot of lying going on."[61] Someone in the lab
was even overheard knowingly giving out "rosy" specifications to
customers on the phone, hanging up, and saying, "Ah, I've just
got to tell them something...".[62]
The tight lid on information about the 3000's progress provoked
some speculation by members of the team. Some engineers
suspected that the project was in danger of getting dropped. In
their view, setbacks could have pushed the HP3000 off the
drawing board - and there had been significant setbacks
already.[63] In light of the antagonism between lab and
marketing, failures on the development end could have persuaded
top management to give overall project direction to marketing.
Vallender used a lot of energy defending against this outcome;
he "knew how poorly we were doing and he didn't want pressure
from marketing."[64]
The Analytical Engine, Volume 3, Number 1, November 1995 Page 36
SPRING 1972: SYSTEMS MANAGEMENT GROUP FORMED
-------------------------------------------------
Top management was indeed concerned. In May of 1972, Dick
Hackborn (who would later become Vice President of HP) hired
Dave Crockett to head up a marketing team called the Systems
Management Group, which would be part of the lab, but at the
same time empowered to "product market-ize" the HP3000.[65]
At this point the lab began a serious effort to determine what
their new product could do. It is interesting to note that not
until 1972, four years after the Omega/Alpha project began, did
the lab hire a person - Jim Peachy of the Systems Management
group - to analyze the performance of the new machine.
Peachy had done performance testing and tuning for one of the
world's first timesharing systems at Dartmouth University in the
mid-60s and had worked at Memorex and at General Electric. Three
days after HP hired him, he announced "This isn't even a
timesharing system."[66] After testing out the instructions, and
timing out the loops, he stated categorically that there was
"absolutely no way" for the HP3000 as it existed to meet its
timesharing targets. Marketing meanwhile was assuring HP's
customers that, at minimum, 16 users could run on a small
HP3000, and 32 to 64 users could run on a 64K memory version of
the machine.[67] The Systems Management Group stuck by its
calculations and insisted that "this thing [the HP3000] won't
timeshare more than three users..."[68]
This was not an occasion for great joy. Some of the engineers
had scant regard for these "polished marketing types from
Memorex"[69]. Unfortunately, it was by then the late summer of
1972, and a full "fix" of the product by the release date was
out of the question. Probably at this point, the August 1972
release date that had been announced at the 1971 Fall Joint
Computer Conference was pushed to November of 1972.
SEPTEMBER-NOVEMBER 1972: DELAYS
-------------------------------------------------
The release date, although pushed, was looming by September.
Management attempted a full definition of the code set to be
distributed as the first release of the MPE operating system.
The new functionality contrasts materially with what was
originally presented in the earlier memo. The new memo, dated
September 25, 1972, is included as Figure 10 and 11.
Figure 10 Memo 9/25/72 Prt 1
This new memo proposes four major versions of MPE, and details
what will be included in each. It mentions that no real-time
capability and no spooling (for batch) functionality will be
The Analytical Engine, Volume 3, Number 1, November 1995 Page 37
included in the first release. Console operator capability was
proposed here for MPE 1, but would later be deferred to MPE 2.
Figure 11 Memo 9/25/72 Prt 2
The schedule for the other MPE releases was as follows:
February 1, 1973 MPE 2: spooling
April 1, 1973 MPE 3: real-time
June 1, 1973 MPE 4: system recovery, performance monitoring
This information was to be released to the sales force, and lab
members were to go to the regional sales offices and tell them
personally.
To say that the salesmen were dismayed would be an
understatement. Many of them had already collected commissions
from HP3000 purchases.[70] HP was forecasting that 120 units
would be sold the first year, and a $100,000+ HP3000 carried a
nice sized commission.[71]
FOOTNOTE: HP eventually shipped 120 units for the year by the
end of 1975. From "Hewlett-Packard takes on the computer
giants", op. cit.
NOVEMBER 1972: "NOVEMBER IS A HAPPENING"
-------------------------------------------------
No one knows who first spoke this phrase, but in the weeks prior
to the release of the first HP3000, dozens of the posters shown
in Figure 12 were placed all over the factory floor.
Figure 12 "November is a Happening" Poster
The picture shows an HP3000 going out the shipping dock door,
ostensibly to its first customer, the Lawrence Hall of Science
at UC Berkeley. Unfortunately, as Frank Hublou put it, "they
should have put it on the truck, drove it around the block, and
brought the machine back. That's what should have happened."[72]
It didn't. HP installed the machine, turned it on, and
discovered - along with the customer, of course - that the 3000
could only accommodate one or two users before falling to its
knees. It was immediately returned.[73]
After the Lawrence Hall of Science debacle, many engineers
quipped that they weren't sure if the "November is a Happening"
poster showed a man sending the machine out or bringing it back
in.[74] Feelings were prevalent throughout the lab that the
machine was released much too early, although the engineers knew
The Analytical Engine, Volume 3, Number 1, November 1995 Page 38
it could not meet specifications. The November release had been
perceived as a firm deadline, which they had to honor
regardless.[75]
Perhaps there was an unofficial "1 year after announcement law"
in effect which had something to do with the November release.
For example, the IBM System/360 was announced in 1963, and the
first version was released (arguably in poor condition) in 1964;
IBM's System/370 was announced in 1970, and released a year
later.[76]
DECEMBER 1972 -FEBRUARY 1973: FURTHER DELAYS
-------------------------------------------------
Things didn't look that much better a month later, although a
prototype used for training in December was able to run
reasonably well with 4 users, rather than the earlier 2. During
the two-week training session with customers, the prototype
crashed about once every two hours, and the operating system
"was patched more than 50 times."[77]
December 11 brought another schedule change, detailed in the
memo included as Figure 13. Note that spooling, originally
promised by February 1, was moved to MPE release 3 (April 1,
1973).
Figure 13 Memo 12/11/72
January 31 saw another memo, and another schedule push-back. It
is included as Figure 14. In it release 2, scheduled for the
following day (February 1), is moved to June 30, 1973. Release 3
is pushed to "late '73", and release 4, mentioned in the
September 25, 1972 memo, is not even mentioned. Real-time is
gone.
Figure 14 Memo 1/31/73
Figure 15 shows a memo dated February 1, one day later. It is
essentially the same as the January 31 memo, except it leaves
out "complete segmentor" from the capabilities of release 2.
Figure 15 Memo 2/1/73
In the meantime, the January, 1973 issue of the _HP Journal_ (a
magazine devoted to the research and products of
Hewlett-Packard), devoted a cover story and two other articles
on the HP3000. They were entitled
"An economical full-scale multipurpose computer system", by Bert
Forbes and Mike Green,
"Central bus links modular HP3000 hardware", by Jamshid Basiji
The Analytical Engine, Volume 3, Number 1, November 1995 Page 39
and Arnie Bergh,
"Software for a multilingual computer", by Bill Foster,
and "Single operating system serves all HP3000 users", by Tom
Blease and Alan Hewer.[78]
This was Hewlett-Packard's most formal announcement yet of the
HP3000. The first article stated that the primary purpose of the
HP3000 was "to provide, at low cost, a general purpose computer
system capable of concurrent batch processing, on-line terminal
processing, and real-time processing, _all in the same
software_." (emphasis added)[79]
Also in early 1973, George Newman, the divisional manager since
after the cancellation of the Omega project, moved to HP's
calculator division. He was replaced by Bill Terry.
SPRING 1973: THERE IS A PROBLEM...
-------------------------------------------------
By Spring 1973 the HP3000 project had been worked on - either as
Alpha or as Omega - for almost 5 years, and had cost over $20
million to develop. It was "by far the costliest [program] in
the company's history".[80]
Some of the engineers felt that considering the HP3000 as having
been in development since 1968 was a little unfair. They felt
that the "clock should have been reset" when the Omega was
canceled and Alpha began. But management didn't see it that
way.[81]
In late 1972, the sales forecasts for the HP3000 had been
downgraded to 80 for the year, instead of 120. But then, in
April of 1973, Bill Terry appeared at an IEEE conference and
said that it was now downgraded to 30. Further, at a meeting
with security analysts, Mr. Terry said that the software wasn't
running as well as hoped, and that it wouldn't support the
original plan of 16 users.[82] (Note the "spin control" of
stating that the original plan was 16 terminal users. The
original plan had envisioned more than 16 users.)
Even though the software was not yet defect-free, the hardware
was remarkably robust. One of the other early customers, Yale
New Haven Hospital, stated that "the hardware has given very
little trouble".[83] But other early customers were not having
as easy a time with the HP3000. An early system was loaned to
RAIR Inc., a timesharing company in Mountain View, to test
timesharing, but it was returned. National Bank of Detroit had
trouble with putting more than 4 terminals on it.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 40
It was becoming clear that the HP3000 was having serious
problems. These problems were noticed all the way up the company
chain, to Bill Hewlett himself. Hewlett asked Barney Oliver (who
would soon become head of all of HP's corporate R & D programs)
to come in and save the product. He had stepped in earlier and
pulled the HP21XX line out of a mess. Oliver refused.[84]
Word was all over the company about the HP3000. That summer, at
the HP company picnic, there were conversations at how much
money Hewlett-Packard was pouring into the 3000 "rathole" and
when the project would be shut down.[85]
It was time to take action. Paul Ely, General Manager of the
Microwave Division, was asked to take over Data Products
Division and fix the HP3000 problems. Ely had turned around the
Microwave Division earlier and had a reputation as a "get the
job done" kind of manager, a driver who could intimidate anyone
easily.[86] His management style was not necessarily a typical
HP one.
About this time there were a few changes in the Marketing area.
Jim Treybig, one of the sector marketing managers, left the
company and eventually helped found Tandem Corporation, and Ed
McCracken became Marketing manager for the entire division.
SUMMER 1973: "WOW OUCH"
-------------------------------------------------
The new management team, once in place, acted quickly.
Production of the HP3000 was halted, and more importantly, the
decision was made to recall the entire existing base of HP3000s.
At this time, Dave Packard sent a memo to the HP3000 team. It
was only two lines long and said, essentially, that they would
never again announce a product that did not then currently meet
specifications. Its succinctness revealed how displeased
Packard was with the outcome of the program.
Steve Vallender, the lab manager, made a copy for every member
of the department. Before sending it out, he made a little
comment on Packard's memo, scribbling the words "Wow" and "Ouch"
in the margin. The memo was henceforth (and still is over 25
years later) referred to as the "Wow Ouch" memo.[87]
The next few weeks were, as Ed McCracken would later say, "one
of the worst two weeks of my life".[88]
McCracken went back to the customers and "de-committed" each and
every HP3000 sold. In essence, he said that:
1. HP could not bring the software components of the system up
to full specifications before Fall 1973.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 41
2. HP was devoting "maximum resources" to correcting the
problem.
3. The 3000 system would support no more than 4 to 6
simultaneous users.
4. Image, for those beta testing the product, would be delayed
until January 1, 1974.[89]
Some customers literally broke down and cried. Many of them were
extremely loyal to HP, and believed in the machines as strongly
as any developer at the Cupertino lab.
The customers were offered HP2000 timesharing systems instead.
Some accepted them as a stop-gap, but still pushed for their
HP3000's as soon as possible.
One customer, Anderson College in Indiana, threatened the
company with a breach-of-contract lawsuit. It was only averted
by the decision of the plaintiffs to contact Bill Hewlett first
before filing the papers. Hewlett issued an edict to do
anything HP could to appease Anderson rather than going to
court.[90]
THE (NEW, IMPROVED) HP3000, PART II
-------------------------------------------------
"if you have a flop in a void, you may have time to resurrect it
and be a success still in that same void" HP3000 Engineer Jim
Holl[91]
Soon after the withdrawal of the HP3000, lab manager Steve
Vallender left the company. Bill Foster, who is now CEO of
Stratus Computers (a competitor to Treybig's Tandem), took the
reins of the lab from his earlier position as a section manager
in the department.
MPE-B
-------------------------------------------------
During the shutdown it was the operating system designers who
were in the "hot seat". The hardware was rather well-evolved; it
had very few bugs upon release. Hewlett-Packard was in essence a
hardware company that did not yet consider software a "core
competency."[92]
After the 3000 withdrawal, the MPE lab staff diminished to about
8 programmers, all working on MPE-B. Mike Green, one of the
brightest engineers at Cupertino, worked personally on the
operating system. Bob Miyakusu, from the file system area, led
the effort. The other applications were essentially
finished.[93,94]
The Analytical Engine, Volume 3, Number 1, November 1995 Page 42
The MPE section attained a frenzy of development. The lab was
still constrained by availability of machine time, so the staff
worked 24 hours a day on the software. The operating system
section split into two 12- hour shifts, to make sure that the
computers were being used whenever possible. When one of the
recalled machines came back, the lab grabbed it and put it to
use.[95]
Functionality was also redefined at that time. The remaining
real-time code in MPE, unofficially cancelled earlier, was
deleted. On several occasions, naturally, a real-time module in
MPE was removed, and other, supposedly non-related code promptly
crashed. There is probably some real-time code buried deep in
MPE to this day.[96]
After about six months spent ironing out the bugs in MPE, the
HP3000 was ready for re-release. It was now able to run 8
interactive users. This in itself was impressive; after the
recall, outside experts had predicted that it would take up to
"two man-years" to fix MPE.[97]
OCTOBER 1973: RE-RELEASE
-------------------------------------------------
The new HP3000 was re-released in October, 1973. It now had
MPE-B, and was thirty per cent faster thanks to tweaking by the
hardware guys. It also cost twenty per cent less. [98,99] The
press praised the new machine for having its "...sights and
promises better aligned with performance...".[100]
Figure 16 shows an advertisement published after the re-release;
it emphasizes the batch and timeshare capabilities of the
machine. Notice that, near the bottom of the ad, the customer is
urged to get "your new brochure" (emphasis added).
Figure 16 Advertisement c.1973
NOVEMBER 1973: EXIT TO TANDEM
-------------------------------------------------
Meanwhile, the HP3000 project lost several key contributors. Jim
Treybig, a marketing section manager who had left in early 1973
to join Tom Perkins (ex-General Manager of Data Products
Division) in a venture capital company, started Tandem
Computing. Tandem was to produce (and successfully has to this
day) a "fault tolerant" minicomputer. Their machine would have
redundant circuitry and other hardware to insure maximum up-time
even in a catastrophic situation.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 43
Hewlett-Packard was going through a slow period, and the company
announced that it would shut down all of its divisions during
the Thanksgiving holiday. During that week, Treybig interviewed
many of his old comrades at HP to recruit them for his new
company. More than a few accepted the offer to join Tandem at
its inception. It should be noted that these people left with no
ill-feeling from Hewlett-Packard, and there was very little
animosity between HP and the newly-formed Tandem.[101]
Nonetheless, the departure stripped HP of considerable talent:
Mike Green (who wrote Timeshared BASIC), Tom Blease (who had
worked on SPL and was an early proponent of the stacked
architecture for the Omega/Alpha), and Bob Miyakusu (who led the
MPE re-work during the recall period), were among the many who
left.[102]
DECEMBER 1974: ADVENT OF THE CX
-------------------------------------------------
In the twelve months after the re-release of the product, the
lab was working on the next version. It was to be called the
HP3000 CX, to distinguish it from the earlier models (which were
to be called, eventually "Series I").[103]
The CX embodied several key improvements in architecture, of
which the most important was probably the main memory. The
hardware designers returned to the original bus architecture and
found a couple of free bits that had been set aside. Using
these, they could increase the system's capacity to 128 Kbytes
of main memory. The type of memory was also upgraded when Paul
Ely issued an edict, "No more core memories", and they promptly
went away[104]; HP used semiconductor memory in the new series
and finally left the '60s behind.
Also gone was the wire-wrapped backplane, where the circuit
boards were attached. The Series I backplane looked like a board
splashed with spaghetti, and generated some interesting
parasitic electrical currents that plagued the early 3000s.
Mysteriously enough, these effects went away if one took some
cardboard and stroked the backplane wires.[105]
A further improved operating system, MPE-C, was included, as
well as RPG - to compete with IBM - and, probably, the first
COBOL compiler on a minicomputer. The COBOL was included to
comply with a 1960 Department of Defense specification stating
that all machines purchased by them must be supplied with a
COBOL compiler. [106,107] Bill Hewlett originally opposed
installing COBOL on the 3000, for fear of suggesting that HP
wanted to take on IBM; but the demands of the market eventually
changed his view.[108]
And finally, HP's database management system IMAGE was sprung on
an unsuspecting market. It was a $10,000 option at first, but a
The Analytical Engine, Volume 3, Number 1, November 1995 Page 44
year later was offered free and bundled with every HP3000
system.
Many people mark this as the time when the 3000 left infancy,
and began its successful ascent. This is also where my story
ends.
-------------------------------------------------
NOTES:
[1] Hank Cureton, interview by author, tape recording,
Cupertino, CA., 14 February 1995.
[2] Monty Python and the Holy Grail, "The Tale of Sir Lancelot",
Scene 18.
[3] Carson Kan, Interview with the author, tape recording, 14
February 1995, Cupertino, CA.
[4] "A 10 Year History of the HP3000," The HP News (1982):4.
[5] Bob Green, Correspondence with the author, December 5, 1994.
[6] George Cullison , Interview with the author, 13 February
1995, Cupertino, CA.
[7] James Cortada, Historical Dictionary of Data Processing (New
York; Greenwood Press, 1987).
[8] Rick Justice, interview by author, tape recording,
Cupertino, CA., 7 April 1995.
[9] Rich Edwards, "HP 3000 Systems Family History [September
1981]." Internal memorandum.
[10] Michael D Green, Bert E Forbes, "An economical
full-scale multipurpose computer system," HP Journal (January
1973):2-8.
[11] Bob Green, op. cit.
[12] Rocky Graziano, interview by author, 21 March 1995.
[13] Alpha 1 External Reference Specifications (Palo Alto,
Hewlett-Packard, 1970).
[14] Phyllis Loise Egan, "Hewlett-Packard, From Instrumentation
to Computers: A Study of Strategy" (Masters Thesis, San
Francisco State University, 1984).
[15] HP ALPHA Project Data Sheet (Palo Alto, Hewlett-Packard,
1970).
[16] Ibid..
[17] Graziano, op. cit.
[18] Kan, op. cit.
[19] Bill Foster, interview by author, 27 April 1995.
[20] Jim Holl, interview by author, tape recording, Cupertino,
CA., 14 February 1995.
[21] Arnie Bergh, interview by author, tape recording, Los Altos
Hills, CA., 13 February 1995.
[22] Bob Green, op. cit.
[23] Mark Matoza, interview by author, tape recording, Palo
Alto, CA., 7 April 1995.
[24] Steve Vallender, "Alpha Multiprogramming System, [28 August
1970]." Internal memorandum.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 45
[25] Bergh, op. cit.
[26] Alpha 1 External Reference Specifications, op. cit.
[27] Bob Miyakusu, interview by author, tape recording,
Cupertino, CA., 14 February 1995.
[28] Kan, op. cit.
[29] Vallender, op. cit. pp. 1-2.
[30] Rene Moreau, The Computer Comes of Age, (Cambridge, MA;MIT
Press, 1984).
[31] U S Patent Number 3820079 "Bus oriented, modular,
multiprocessing computer." issued to A. Bergh, B. Forbes, J.O.
Hamilton, J. O. Mixsell.
[32] Daniel Siewiorek, C Gordon Bell, and Allen Newell, Computer
Structures: Principals and Examples, (New York; McGraw-Hill,
1982).
[33] System/3000 Software General Information (Palo Alto,
Hewlett-Packard, 1971).
[34] Bill Foster (lecture presented to HP3000 R & D staff,
Cupertino, CA., c1971).
[35] Alpha 1 External Reference Specifications, op. cit.
[36] ALPHA Multiprogramming System, op. cit.
[37] ALPHA Multiprogramming System, op. cit.
[38] HP ALPHA Project Data Sheet, op. cit.
[39] "HP adds time-sharing system/3000," ComputerWorld (17
November 1971): 30.
[40] Ibid.
[41] Ibid.
[42] "System/3000 runs into time-share problems," Electronics
News (30 April 1973): 1
[43] Bob Green, et. al., Image/3000 Handbook, (Seattle;
Wordware, 1984).
[44] John Bale, interview by author, tape recording, Cupertino,
CA., 13 February 1995.
[45] Bob Green, et. al., op. cit.
[46] W C McGee, "Generalization: Key to successful electronic
data processing" Journal of the ACM 6 (January, 1959):1-23.
[47] James W. Cortada, Historical Dictionary of Data
Processing: Technology,
pp. 126-27 (Westport, CT; Greenwood Press, 1987)
[48] E H Sibley, "The development of data-base technology," ACM
Computing Surveys 8 (1976): 2-7.
[49] Cortada, op. cit.
[50] J P Fry, E H Sibley, "The evolution of data-base management
systems," ACM Computing Surveys 8 (1976): 7-42.
[51] R W Taylor, R L Frank, "CODASYL database management
system," ACM Computing Surveys 8 (1976): 67-101.
[52] Cortada, op. cit.
[53] John Bale, op. cit.
[54] John Bale, op. cit.
[55] Bergh, op. cit.
[56] Ed McCracken, interview with the author, tape recording,
24April 1995, Mountain View, CA.
[57] Graziano, op. cit.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 46
[58] Cureton, op. cit.
[59] Holl, op. cit.
[60] "HP 3000: A new way of thinking," Measure (Magazine for
Hewlett-Packard Employees) (November, 1973).
[61] McCracken, op. cit.
[62] Frank Hublou, interview by author, tape recording,
Cupertino, CA., 14 February 1995.
[63] McCracken, op. cit.
[64] Holl, op. cit.
[65] Jim Peachy, interview with the author, tape recording,
6 April 1995, Mountain View, CA.
[66] Ibid.
[67] Ibid.
[68] Ibid.
[69] Graziano, op. cit.
[70] Cureton, op. cit.
[71] "System/3000 runs into time-share problems," op. cit.
[72] Hublou, op. cit.
[73] "System/3000 runs into time-share problems," op. cit.
[74] Bob Heideman, interview by author, tape recording,
Cupertino, CA., 13 February 1995.
[75] Graziano, op. cit.
[76] "As time goes by," Datamation 28 (September, 1982):65.
[77] Thomas Harbron Ph.D., correspondence with the author,
Anderson University, Indiana, 5 February 1995.
[78] HP Journal (January 1973).
[79] Ibid.
[80] "System/3000 runs into time-share problems", op. cit.
[81] Graziano, op. cit.
[82] "System/3000 runs into time-share problems", op. cit..
[83] "System/3000 runs into time-share problems", op. cit.
[84] Foster, op. cit.
[85] Cullison, op. cit.
[86] Bergh, op. cit.
[87] Hublou, op. cit.
[88] McCracken, op. cit.
[89] Harbron, op. cit.
[90] Harbron, op. cit.
[91] Holl, op. cit.
[92] Bergh, op. cit.
[93] Miyakusu, op. cit.
[94] Graziano, op. cit.
[95] Holl, op. cit.
[96] Miyakusu, op. cit.
[97] "System/3000 runs into time-share problems," op. cit.
[98] Bergh, op. cit.
[99] Laton McCartney, Harvey Wilkinson, "The year mini users
shed the security blanket," Infosystems (January 1974):24.
[100] Ibid.
[101] Miyakusu, op. cit.
[102] Kan, op. cit.
[103] Edwards, op. cit.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 47
[104] Bergh, op. cit.
[105] Cullison, op. cit.
[106] Edwards, op. cit.
[107] Andrew L Freidman, Computer Systems Development: History,
Organization, and Implementation (Chichester; Wiley, 1989).
[108] Foster, op. cit.
Copyright [c] 1995 by Christopher Edler as an adaptation of a
thesis submitted in partial fulfillment of the Master's of
Science degree at California State University, Chico.
-------------------------------------------------
_About the author:_
Christopher Edler works as an Information Technology Specialist
at Hewlett-Packard Company in Boise, Idaho. He is currently
completing a Master's of Science degree at California State
University, Chico. He also holds a Master's of Business
Administration degree from the University of Arizona and a
Bachelor's degree in Economics from the University of Michigan.
He has a wife, Kirsten, and three young children.
-------------------------------------------------
IN MEMORIAM:
JOHN V. ATANASOFF
-------------------------------------------------
Dr. John Vincent Atanasoff, a pioneering researcher in binary
electronic calculation, died on June 15, 1995 in Frederick, MD,
USA. He was ninety-one.
Dr. Atanasoff is widely credited with exploring or developing
several concepts crucial to the construction of the digital
electronic computer. He first became interested in the problem
of computation at the University of Wisconsin during 1929 and
1930, while he was finishing a dissertation for a doctorate in
physics, using only a Monroe calculator and scratch pad to solve
equations. Like Konrad Zuse a few years later, he was convinced
that complex mathematical problems could be solved by machines
that had not yet been built.
At Iowa State University in 1938 Atanasoff began a collaboration
with a graduate student in mathematics, Clifford E. Berry, with
the goal of building an electronic digital computer. After a
year of conceptual development, they began construction of the
Atanasoff-Berry Computer (ABC) which could store numbers using
capacitors and Bakelite drums, and solve differential equations
using concatenations of simple arithmetic steps. Input was by
punched cards or keypunch, and the ABC converted decimal input
to the binary numbers used for computation. Though it was a
The Analytical Engine, Volume 3, Number 1, November 1995 Page 48
very limited device, it contained elements - input- output,
arithmetic units, and storage memory - which would later become
qualitative to standard computer architecture. If Atanasoff and
Berry's work had not been interrupted by the Second World War,
it might have resulted in a complete and operable digital
computer; but in 1942 the collaborators were obliged to close
down the project.
In 1940 and 1941, Atanasoff struck up an acquaintance with John
Mauchly, later a primary developer of ENIAC, EDVAC, BINAC and
the early UNIVAC computers. The meeting was fateful and in part
unfortunate, since any knowledge that the two shared would
become a point of argument in the controversial _Honeywell v.
Sperry Rand_ case, which pivoted on an attempt to determine who
had actually invented the electronic digital computer. That
case was settled in favor of Honeywell - and implicitly of
Atanasoff - in 1973, but the controversy has barely cooled in
the intervening years.
During and after the War, Atanasoff worked primarily at the U.
S. Naval Ordnance Laboratories, in specialties including fire
control, acoustics, phonetics, projectile tracking and package
handling. He was widely recognized as a pioneer in computing
only after the verdict in _Honeywell v. Sperry_, during the
middle 1970's; in 1984 he summed up his contribution in a long
memoir published in the _Annals of the History of Computing_.
For his efforts he received the Computer Pioneer Medal from the
IEEE in 1981, and the National Medal of Technology in 1990.
The ANALYTICAL ENGINE extends condolence to his wife, Alice
Crosby Atanasoff, to his daughters Elsie Whistler and Joanne
Gathers and his son John V. Atanasoff 3rd, and to colleagues and
friends.
-------------------------------------------------
IN MEMORIAM:
J. PRESPER ECKERT
-------------------------------------------------
John Presper Eckert, co-developer with Dr. John Mauchly of the
first programmable electronic digital computer in the United
States, died in Bryn Mawr, PA, USA, on June 3, 1995. He was
seventy-six.
Mr. Eckert was a lifelong computer engineer, continuing in
consulting work until shortly before his death; but his name is
most often associated with his trailblazing work on problem
solving in ballistics, between 1943 and 1946, which culminated
in the creation of the ENIAC computer at the Moore School of
Engineering, University of Pennsylvania. ENIAC, a truly vast
undertaking that contained over 18,000 vacuum tubes and was said
to consume 150 kW of power, could compute almost 2,500 times as
The Analytical Engine, Volume 3, Number 1, November 1995 Page 49
fast as a human operator with a desk calculator; it was destined
to become a legend of electronic engineering. The device ran
from 1946 to 1955, performing military computation including
gunnery tables, and design calculations for the Manhattan
Project.
Taking the lessons of this work to private industry, Eckert and
Mauchly co-founded the Electronic Control Company, soon renamed
the Eckert-Mauchly Computer Company. This firm was purchased in
February 1950 by Remington Rand, which bankrolled the production
of UNIVAC I, the first commercially successful American
computer. The prototype UNIVAC was delivered to the U. S. Bureau
of the Census in March 1951; ultimately forty UNIVAC I's were
sold. An example, possibly unique, is currently displayed in the
Computer Museum in Boston, MA.
Eckert was also a primary designer and developer of EDVAC (the
"von Neumann computer") and of a pioneering airborne guidance
device, BINAC, constructed for Northrop Aircraft. Thereafter he
continued to make substantial contributions to computer
engineering, earning a reputation for brilliance. In 1963 he
reached his highest position at the UNIVAC Division of Sperry
Rand, as Vice-President and Technical Advisor to the President.
In 1989 he retired from Sperry's successor, Unisys. He received
a doctorate _honoris causa_ from the University of Pennsylvania
in 1964, and the National Medal of Technology in 1968, among
many other honors.
The ANALYTICAL ENGINE extends condolence to his wife Judith, to
his daughter Laura Phinney and his sons John P. Eckert 3rd,
Gregory Eckert and Chris Eckert, and to colleagues and friends.
-------------------------------------------------
IN MEMORIAM:
GERARD SALTON
-------------------------------------------------
Gerard Salton, a leading authority on the design of database
retrieval systems and the primary developer of the SMART text
retrieval engine, died in Ithaca, NY, USA on August 28, 1995. He
was 68 and a professor in the Cornell University computer
science department, which he helped found in 1965.
SMART, an acronym for System for the Manipulation and Retrieval
of Texts (but sometimes parsed as Salton's Magical Retriever of
Text,) was one of the earliest search engines that relied on the
frequency of a term's occurrence as one criterion for searches.
This innovation increased the efficiency of retrieval as well as
convenience for the user; it is the basis for many retrieval
systems in use today.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 50
Professor Salton was born in Nuremberg, left Germany during
World War II, and reached the United States in 1947. He
received a bachelor's degree in mathematics in 1950, and a
master's in 1952, from Brooklyn College; he then studied at
Harvard, earning a doctorate in 1958 and serving on the Harvard
faculty in various capacities. He joined the faculty of Cornell
in 1965.
The ANALYTICAL ENGINE extends condolence to relatives,
colleagues and friends.
-------------------------------------------------
A WEB PAGE FOR THE CHAC
-------------------------------------------------
Weeks of work and a lot of deeply appreciated advice have put a
CHAC page up on the Web. Its topics include:
* What the CHAC does, and why
* Every issue of the ANALYTICAL ENGINE available in plaintext
via ftp
* The story of our (fomerly!) imperiled SDS 930
* Pictures of notable micros from our collection
* A comprehensive list of other computer history pages indexed
by topic
* A list of other computer history organizations and periodicals
* Plenty of room for suggestions!
Our friends the Wombats e-mail us a hit log every night, and
we're gaining a new appreciation of the phrase 'World Wide Web'
as the accesses pour in, not only from the US, the UK and
Western Europe, but - in smaller but still tantalizing numbers -
from Mexico, South America, Japan, and the former Soviet
republics. Once more we feel the exhilaration that was so
welcome two years ago, when the CHAC announced itself to USENET
and to the mailing lists. Honestly, computer history is sparking
interest all over the world - and attracting a population of
enthusiasts dedicated enough to keep that interest vibrantly
alive.
Give us a hit! Cruise over to
http://www.chac.org/chac/index.html and sample the CHAC's latest
online goodies. We'll be looking for you.
-------------------------------------------------
SVERDLOFF SUCCEEDS
WALLACE AT COMPUTER MUSEUM
-------------------------------------------------
Brian Wallace, former curator of historical collections at the
Computer Museum, Boston MA, has left that post to continue
graduate studies. Brian has given crucial support to the CHAC
The Analytical Engine, Volume 3, Number 1, November 1995 Page 51
since our earliest days, and while we certainly wish him luck,
we hope he doesn't drift too far from computer history.
His successor is Brent Sverdloff, who comes to the Computer
Museum from an administrative position at the Department of
Germanic Languages and Literatures, Harvard University. Before
that, he served as Archivist of Special Collections of the Getty
Center for the History of Art and the Humanities (Santa Monica,
CA,) for five years. He has also taught, and translated to and
from, Romance languages extensively.
Mr. Sverdloff received a bachelor's degree in Romance
linguistics and literature in 1986, and a master's in Spanish
and linguistics in 1989, both from UCLA; he was principal
flutist with the University's symphony orchestra while still an
undergraduate.
The CHAC welcomes this variously talented curator to the
rough-and-tumble field of professional computer history. His
genius for languages, his musician's timing and his appetite for
detective work will all be exercised to the fullest.
-------------------------------------------------
Tech Corner:
MAKING NEW BATTERY PACKS FOR THE HP-35 CALCULATOR
-------------------------------------------------
Douglas W. Jones
University of Iowa
Today, an old HP-35 Calculator is likely to be as useful as it
was when it was new, but finding new battery packs for one is
difficult. Thus, most people who use one today must put up with
the tether to its plug-in power supply. Fortunately, HP-35
battery packs are fairly simple to make. Three 1.25 volt NiCd
cells, wired in series, produce exactly the 3.75 volts the
calculator is rated at, and three AA sized penlight cells fit
comfortably inside the calculator's battery compartment.
Furthermore, the battery charger side of the HP-35 power supply
is well matched to the rated 45 milliamp trickle charge current
of the AA NiCd cells I bought from Radio Shack. Before going
into detail on the battery pack, it is worth documenting the
details of the HP-35 "wall wart" power supply and battery
charger. This unit contains a transformer, a voltage regulator,
and a current limiter, with the connection to the HP-35 through
a 3-pin plug, as follows:
The Analytical Engine, Volume 3, Number 1, November 1995 Page 52
Figure 1
[ -----------------
| | gnd
| ---|---
| | bo |
| |ao co |
| -|---|- +
| - |o o--o o---
-o |
The plug is shown as viewed from the bottom of the calculator.
The switch S2 is the on-off switch on the front of the
calculator. Switch S1 is a spring shim that shorts pins a and c
when the calculator is unplugged from the power supply, allowing
the battery to power the calculator. When the supply is plugged
in, battery charging is provided by a current limited 50
milliamp 30 volt supply between pins a and b, while operating
power is provided by a regulated supply between b and c; a 3.75
volts, 0.15 amp supply should suffice, but the HP supply I have
puts out 5 volts. I gleaned the above by disassembling both my
power supply and calculator; I don't recommend disassembling
HP-35 calculators if they work, but mine was broken when I got
it. After disassembly, I found that the only problem was dirt
under the slider of the on-off switch; and after cleaning and
reassembly, it works quite well.
To make a new battery pack, start with three AA NiCd cells,
arrange them side by side with the positive ends pointing in
alternate directions, and bundle them together with vinyl
electrical tape, as shown:
Figure 2
_-_ ___ _-_
| + || || + |
---------------
| |
| |
| |
| |
| |
| |
---------------
|___||_+_||___|
-
The next step is to jumper the cells together and add contact
pads at each end. I gently clamped my stack of cells in a vise
to solder the necessary connections to each end. To prepare the
batteries for jumpering, I melted a button of solder on each end
of each cell. Be careful soldering to batteries; the heat boils
a bit of the electrolyte inside the battery, and you'll do the
least damage by using a very hot iron very briefly; I used a
The Analytical Engine, Volume 3, Number 1, November 1995 Page 53
soldering gun. Also be careful not to fill any vent holes in the
battery with solder.
I used brass shim stock for the jumpers between cells and for
the contact pads, and I connected the pads to the cells with
stranded hook-up wire. The contact pads should be 3/8 inch wide
and between 5/8 and 7/8 inch long. The connections to each
contact pad should be soldered on the back of the pad, and the
wires and jumpers should be soldered as shown:
Figure 3
____
_-/\ __/ _-_
| + || || + |
---------------
| | |
| | |
| | |
| _|_ ___ |
| | || | |
| |_ _||___| |
----------|----
|___||_+_||___|
- \/
It is critical to get the polarity right! Make your battery pack
exactly as shown above, with the positive pad at the bottom left
side of the pack. If you accidentally build a mirror image of
this, you will either end up reverse charging your NiCd cells
(which can damage them) or you will end up putting a reversed
voltage into the calculator (which might damage it).
Finally, wrap tape over each end of the battery pack, as shown:
Figure 4
____
_-/\ __/ \
| |
| |
| |
| |
| |
|_____________|
| | || | |
|__|_ _||___|_|
---------------
|_____________/
The contact pads should be securely held by both their top and
bottom edges so that they are between 1/8 and 1/4 inch apart.
The tape covering the top half of the battery pack should cover
The Analytical Engine, Volume 3, Number 1, November 1995 Page 54
the pads to a point about 1/4 inch beyond the center line of the
battery pack, and the tape over the bottom half of the battery
pack should extend about 1/4 inch from the bottom shoulders of
the battery shells. I used a narrow strip of tape around the
pack for the bottom end, while a full width piece of tape worked
fine around the top. At both the top and bottom, I taped over
the solder and wires at the ends of the battery pack before
securing everything with tape around the pack.
The battery pack I made this way came out a bit on the small
side; better small than too large, but as a result, it
occasionally slips out of registration with the spring finger
contacts inside the HP-35 battery compartment. The problem is
not severe enough to make me consider rebuilding my new battery
pack; the 3/8 inch squares of exposed contact pad are big enough
that it can slop around quite a bit inside the calculator and
still make good contact, and the geometry is such that if the
battery pack is ever accidentally inserted backwards, it won't
hurt anything because it only makes electrical contact when it's
inserted the right way.
I don't guarantee that you won't damage your valuable antique
calculator by following my instructions, and I certainly don't
want to be held responsible for any errors you might make in
trying to duplicate my work. Nonetheless, if you feel confident
in your ability to handle a soldering gun and electrical tape,
and if you know enough electronics to verify my reverse
engineering of the HP specifications for the HP battery charger,
you should find these notes useful.
[And one more note: If you aren't comfortable with a soldering
gun, throw money at the problem instead by calling
Edu-Calc
27953 Cabot Road
Laguna Niguel CA 92677 USA
+1 800 677-7001
+1 714 582-2637
to see if they still have replacement HP-35 battery packs for
$14.95. They're also a source for other HP accessories. Thanks
to Guy Ball for the tip. - Ed.]
-------------------------------------------------
SUPPORT FOUND FOR TANDY PORTABLES
-------------------------------------------------
Remember that great Tandy laptop you had in college, in the
desert, or in some minor war? Is it still in your attic or
garage, gathering dust because the evolution of microcomputing
seems to have passed it by? Well, you might want to buy some
batteries today, because Rick Hanson can help you bring your
The Analytical Engine, Volume 3, Number 1, November 1995 Page 55
Tandy or NEC portable back to life.
Hanson, the proprietor of Club 100 in Pleasant Hill, CA, USA,
sells a package that will connect the Tandy's disk drive
directly to an IBM-compatible PC serial port. His Lapdos II
software will then display a file directory of the Tandy drive
on the PC screen and permit a variety of file and disk
manipulation. Lapdos II is available for $39.95 and the
appropriate CompLink cable sells for $17.50.
Club 100 stocks an assortment of other useful goodies for the
Tandy 100, 102, 200, WP-2, and the NEC PC8201a, and you can
request a free catalog by calling +1 510-932-8856 or faxing +1
510-937-5039. Hanson also operates a Tandy support BBS at +1
510-939-1246.
-------------------------------------------------
Quick Take:
SILVER ANNIVERSARY OF XEROX PARC
-------------------------------------------------
To the rigorous aficionado of comp. hist., it can seem that
almost every day is an anniversary. (Or is that just us?) But
even among the current welter of commemorations, June of 1995
stands out - as the silver anniversary of the founding of the
Xerox Palo Alto Research Center. An exhaustive list of PARC's
inventions and developments would take several pages, but let's
just mention
* WYSIWYG text processing
* Cut and paste
* Bitmapped screens
* Icons and windows
* Mouse-based drawing
* Laser printing
* Ethernet
* Smalltalk and InterLisp
Which means that when you're sitting and working at a Mac, or an
Intel box running Windows or GeoWorks, or a newer Sun, an Atari
ST, an Amiga, or....well, lots of things....you have cause to
remember Xerox PARC fondly. Certainly we do, and the ANALYTICAL
ENGINE hopes to bring you a feature article on PARC's history in
the very near future.
-------------------------------------------------
Quick Take:
APPLE II RESOURCE LIST
-------------------------------------------------
A new friend of the CHAC, Roger Aitken of Foster City, CA, sent
us an Apple II resource list that we planned to include in this
The Analytical Engine, Volume 3, Number 1, November 1995 Page 56
issue; but we circulated it to a few friends and they keep
adding to it! If you have any interest in the newest Apple II
apps, don't miss this resource list - in February's ENGINE
whether it's finished or not.
-------------------------------------------------
Quick Take:
AMIGA PREVAILS!
-------------------------------------------------
David McGlone reports in _Z-Letter_ #38 that Escom AG, having
succeeded in purchasing Commodore's assets, plans production of
Amiga 4000 video production systems, entry-level Amiga 1200's,
and the Amiga CD32 game machine. The Escom Amiga 4000's will
feature a SCSI interface and include SCALA, a multimedia
prototyping and production tool from Scala of Norway; they
should be available by the time you read this, probably from
video hardware retail outlets. The ANALYTICAL ENGINE, once
again, declares itself unequivocally in favor of _more Amigas_
and congratulates Escom for backing a courageous decision with a
big hunk of money.
-------------------------------------------------
SPOTTER ALERT
-------------------------------------------------
Copies of the ENGINE, the FAQ, and project information have been
pouring out to print and broadcast media, especially in Silicon
Valley. We do have tearsheets of most of the ink we know about.
But is there ink we haven't heard of? Once more, with feeling:
If you spot any mention of CHAC or the ENGINE in any periodical,
_please_,
* If your copy of the piece is clippable, clip and mail to the
Palo Alto address.
* If you can't spare the physical copy, send the text as
net.mail to engine@chac.org, or photocopy and fax to the Palo
Alto address.
* If you're too busy for that, just send the publication name,
date and page number and we'll do the hunting.
Thanks! (And thanks to the spotters who have given us invaluable
help with keeping up so far.)
-------------------------------------------------
SPOTTER FLASH
-------------------------------------------------
"Save vintage mainframe from extinction," trumpets the September
1 issue of _EDN_, leading a tidy quarter-page about the 930
The Analytical Engine, Volume 3, Number 1, November 1995 Page 57
Rescue and our urgent need for funds. The column winds up with
"If you have any ideas or want to help, please call or e-mail
CHAC...." and the power of the press delivered another solid hit
as, through that, we located almost a dozen former members of
SDS' technical staff or management. Enduring thanks to Max
"Bebop" Maxfield for suggesting the story, and to _EDN_ editor
Fran Granville for writing and running it.
-------------------------------------------------
MONEY, THE WORLD, AND THE ORDERLY PROGRESS OF DAYS
-------------------------------------------------
Just a reminder that, even though we raised enough in donations
to save the 930 from getting tipped, the CHAC is still - in the
old phrase - broke at a higher level. As soon as the last bills
from the Rescue are paid, and this issue of the ENGINE is
printed, no more than pocket change will be left in our bank
account. Take a careful look at this robust copy of the
ANALYTICAL ENGINE and ask yourself - isn't this the time to
subscribe? Thirty-five dollars a year will still bring you four
of our new, thicker, illustrated issues. Subscribe today, if
you don't yet, and join the CHAC's perennial celebration of the
world's most fascinating technical history.
-------------------------------------------------
Book Review:
BEBOP TO THE BOOLEAN BOOGIE
-------------------------------------------------
Clive "Max" Maxfield
Solana Beach, CA: High Text Publishers, Inc., 1995
471 pages, $35.00 (paper)
ISBN 1-878707-22-1
Reviewed by Tom E. Ellis
The first impressive thing - and not the last - about this book
is its sense of humor. Start, naturally enough, with the cover:
three-dimensional gate logic symbols flying over a printed
circuit board, trailing a glowing blue staff of musical notes.
Follow the trail down to a couple doing the bebop, to the music
of a saxophone player who looks remarkably like the author,
Clive ("Call me Max") Maxfield. This is a survey text in
microelectronics? Yes, and a very good one.
The humorous and inimitable style of the _Foreword_,
_Acknowledgments_, and _About the Author_ set the tone for the
entire book. Maxfield's keen interest in his subject matter
becomes obvious as he takes you on a journey that you won't soon
forget. As Pete Waddell mentions in the _Foreword_, technical
books are usually "as dry as West Texas real estate" - which I
take to heart, having been born and raised there - but this book
is anything but dry; while it is jam-packed with highly
The Analytical Engine, Volume 3, Number 1, November 1995 Page 58
technical information, the format and style make it incredibly
readable. Illustrations almost outnumber paragraphs as complex
topics are rendered in the most understandable terms.
As you make your way through the book, Maxfield's talent for the
absurd will drive you forward, while you wonder what's around
the next corner. One minute you'll explore the traces inside a
memory IC; the next, you'll learn how to perform duo-decimal
calculations on your fingers, using your thumb to point to
finger joints "while maintaining a free hand to throw a spear at
someone...." Yes, this is a textbook with nearly 500
large-format pages, but it becomes as compelling as a Christie
mystery. And although the foreword suggests that you "plunge in
and out [of the book] as you wish," the material presented has
been elegantly arranged to build fundamental understanding
before drilling down to the nitty-gritty. Once hooked by
Maxfield's light-hearted wackiness, you're likely to read
_Bebop_ straight through and absorb a huge amount of valuable
knowledge, somewhat in spite of yourself.
_Bebop_ assumes no prior understanding of electronics and
begins, engagingly, with "a fun-loving fool sliding down a ramp"
to illustrate the difference between analog and digital
viewpoints. Even when you move on to _Atoms, Molecules and
Crystals_, you discover reassuringly that electricity is only
"vast herds of electrons migrating from place to place," and
that the science of electronics is all about "deciding where
they can roam, and determining what they are going to do when
they get there." Like a good _Jeopardy_ board, _Bebop_ reveals
each new truth with a just-out-of-reach familiarity that rings
the "I knew that!" bell in your head.
But in almost no time you're saying "I knew that!" about
"correlated electron movements in conducting planes," because
the sure-footed author shepherds you through inner workings at
the particle level and then connects, through the most lucid
illustrations, the theoretical world of circuit design to the
physical world of substrates and semiconductors. Packaging
technologies are compared, as well as common techniques of
forming conducting paths, vias and lead-holes. Breadth as well
as depth of knowledge is served with full explorations of
_Alternative Numbering Systems, Binary Arithmetic, Boolean
Algebra, ICs, Programmable ICs, ASICs, Circuit Design, Hybrids_,
and _Multichip Modules_. To read _Bebop_ is to understand
absolutely the progression from particles, to paths, to
circuits, to modules, to components, to processes.
Maxfield then declares that his "potpourri of
technologies....[has] been offered for your delectation and
delight." But as the final chapter rolls to a close, he quotes
Churchill: "Now this is not the end. It is not even the
beginning of the end. But it is, perhaps, the end of the
The Analytical Engine, Volume 3, Number 1, November 1995 Page 59
beginning." This is the literal truth since the next hundred
and fifty or so pages are filled with "oodles of yummy
appendices" several of which discuss various logic concepts, and
one of which includes several C programs for "the computer
programmer that lurks within us all." _Bebop_ is rounded out
with a robust _Abbreviations and Acronyms_ listing, a wonderful
_Glossary_, and - rarity of rarities - an index comprehensive
enough and well enough organized to be truly useful. Even the
plentiful sidebars and some of the wacky quotes have been
indexed, lest you miss "the blind obedience of fools" and "the
purple tint in San Francisco Bay." And at the very end of this
extraordinary wealth of information, the diligent reader is
rewarded with a great "No-Holds-Barred Seafood Gumbo" recipe.
I'm not kidding.
You could not find a more delightful way to absorb complex
electronics theory, meanwhile speculating on such things as how
life developed on Earth and why window shades spontaneously roll
themselves up. Again and again you'll be fascinated by the
previously obscure, and you'll come away thinking that
microelectronics isn't difficult after all. But don't kid
yourself; Maxfield's unrelenting fun only facilitates his
expert, lucid and very approachable descriptions of how and why
things work. _Bebop_ is a serious asset for scientist and
layperson alike.
-------------------------------------------------
ACQUISITIONS
-------------------------------------------------
[Even though we currently have no more storage for micros, we
can't seem to stop collecting them, so this summer we
concentrated on little ones.]
CONVERGENT WORKSLATE
-------------------------------------------------
Douglas Mandell
Sometimes an idea before its time has a certain charm that's
hard to articulate. So it was with the Convergent Workslate,
which first appeared in 1983 and was determined to be a notebook
computer, no matter how many hurdles it had to jump to get
there.
At 8.5"x11" and about an inch thick, it's a true notebook and
weighs roughly three pounds without peripherals. The screen is
a 16-line by 46-char LCD, integral with the computer and the
size of a large index card. Overall the machine is very
handsome, in "slate" gray with lighter gray and green keys, and
a diamond-shaped cursor wobble-key that looks like it escaped
from a video game.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 60
While the Workslate could be fairly versatile, it was
fundamentally designed as two things: a portable spreadsheet and
a communications terminal We're not sure yet whether ours has an
internal modem or whether communications required the optional,
external, and (so far) missing box called the CommPort; but
we'll know, and say, more about this intriguing little slab
after we get it booted. Thanks, Douglas!
HP 110 and PORTABLE PLUS
-------------------------------------------------
Roger Sinasohn _et al._
In these days of fan-cooled processors and expanding keyboards,
when a five-pound notebook can pack fully as much punch as a
"real" (desktop) computer, it's salutary to remember the time -
1984 or so - when an easily portable computer was inseparable
from real adventure.
The HP 110 and its gutsier successor, the Portable Plus, were
some of the world's first laptops. As usual with HP's computers,
they feature robust construction - the off-white plastic
clamshell cases would probably survive a small explosion - and
use of innovative techniques to assure expandability; the
"bottom drawer" expansion chassis of the early HP desktop
computers translated well to these portables. As for the
sort-of- green-on-sort-of-yellow LCD screens....that's part of
the adventure, and the intrepid user quickly gains the knack of
getting the desk lamp at the exact proper angle to the screen.
With 80C86's as processors, these are slow by modern standards
but certainly usable. A suite of applications and applets in
ROM, including Lotus 1-2-3, eases impact on conventional memory.
Warnings to the unwary: <Return> and are _not_ the same
keystroke, and the reboot sequence is _not_ Control-Alt-Del.
Now let's see - was that Shift-Extend-Contrast, or
Shift-Contrast-Enter, or....
Thanks to Roger and another, anonymous donor, we now have one
110 and several Port Pluses, as well as two external stiffy
drives and two ThinkJets. Your favorite Computer History
Association is ready for the road, in style.
PMC MICROMATE
-------------------------------------------------
Kevin Rudd
Nowadays a desktop computer tends to be manufactured in one of
two formats - beige flat box or beige tall box. But not so long
ago, computer designers were more experimental in their case
layouts....resulting in fascinating devices like the Micromate.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 61
This Z80-based micro is the size and shape of a small toaster.
One half of the case is occupied by a 5.25" floppy drive mounted
on its side; the other half contains a quite tidy motherboard
and some ports. If it were sitting next to a terminal with a
swivel base, the whole shootin' match would hardly take up more
room than the terminal.
We haven't booted this one yet either but - given our fond
memories of Z80 micros - we can hardly wait. Thanks, Kevin.
-------------------------------------------------
LETTERS
-------------------------------------------------
DATA DEGRADATION ON 7-TRACK TAPE
-------------------------------------------------
The University of Iowa Physics Department has a longstanding
problem with the preservation of archival data. They built the
Explorer I instrument package back in the 1950's, and they have
been building satellites and instrument packages for satellites
ever since. Over the years, they have accumulated a huge
archive of data recorded off of satellite downlinks, and most of
this is on magnetic tape in various recording formats.
The old data is quite useful today, particularly when long-term
trends are being studied, but maintaining access to old data is
difficult. One of the major headaches the University of Iowa
physics department faces, for example, centers around the
maintenance of their 7-track tape drives. These drives are
connected to a VAX-11/780, itself something of an antique these
days, but it is hard to find newer machines with reel-to-reel
tape interfaces that are compatable with any kind of 7-track
drive.
Having working 7-track tape drives, the University of Iowa
physics department has found that data conversion to modern
media can be a significant source of income, but recently, they
have had difficulty finding new heads for their 7-track drives,
so they are using them only very sparingly for their own
internal work.
It is clear, at this point, that the availability of new (or as
good as new) tape heads is currently the factor that limits the
ability of the few sites that still maintain 7-track tape drives
to read and convert the data from old tapes into modern data
formats. I suspect that, unless someone has a cache of spare
7-track heads hidden away somewhere, or unless someone somewhere
starts manufacturing small lots of new 7-track heads on a custom
basis, we will alltogether lose our ability to recover data from
the vast storehouses of 7-track tapes that are out there!
The Analytical Engine, Volume 3, Number 1, November 1995 Page 62
The data we will lose includes not only the scientific data that
motivated the University of Iowa physics department to preserve
and maintain a set of 7-track drives, but also the 1960 census
and large libraries of corporate records.
_Doug Jones_
jones@cs.uiowa.edu
HP'S EARLY COMPUTERS: OLIVER INTERVIEW
-------------------------------------------------
In reading your interview with Barney Oliver, I was tickled that
you cited my spirograph program for the HP 9100, but you were
wrong in saying that the program was an old one! While I used a
9100 back in 1972, I didn't write the spirograph program until
about a month before I sent it to you. I had just been given a
surplus 9100B, with plotter, and the obvious exercise was to
turn it into a spirograph. I'd written a similar spirograph
program for a CDC 6600 back in the 1970's, and with both a
plotter and a the polar-to-cartesian function on the HP 9100,
the algorithm was an obvious application to try out.
Later in your interview, you commented on the relation between
HP and DEC. Barney Oliver mentioned that, for a while, David
Packard was thinking about buying DEC, but that he hadn't heard
of HP buying the PDP-8 on an OEM basis. My understanding was
that an HP subsidiary was, briefly, DEC's largest OEM customer
for the PDP-8, in the early part of their production run.
Combining what with what Oliver said, it sounds like the
subsidiary was probably Dymec, and I wonder if this relationship
might explain HP's brief flirtation with the idea of buying DEC.
Finally, I want to note that, although I have a somewhat
battered HP 21MX sitting next to me as I write this, ready to be
boxed up and sent to CHAC, my only real experience with the 2100
family is with the HP2115B; I spent the summer of 1971 building
custom I/O interfaces for one at the University of Michigan
Physics Department. That machine, with the interfaces I helped
build, ran for many years as part of a high energy physics
experiment at Fermilab outside Chicago. It's worth noting that
in addition to some TTL, our interfaces used an awful lot of DTL
chips!
_Doug Jones_
jones@cs.uiowa.edu
HP'S EARLY COMPUTERS: 21xx MEMORY
-------------------------------------------------
Two points about the Schoendorf interview:
The Analytical Engine, Volume 3, Number 1, November 1995 Page 63
The 2100 was *not* based on semiconductor memory; at least
initially, it used core. I suspect that it may later have used
semiconductor memory (and the guy who wrote the emulator seems
to think it is within reason to make it do so), but the
schematic set indicates core planes. *sigh*. Now if I could
just find some for my machine.
Early in the article he makes reference to the 2100 "making
provision for" a megabyte of memory, at Bob Frankenberg's
initiative. That's very interesting, because the 2100's memory
cage is laid out so you can't put more than 32KW into it; there
are two sections, each with space for two core assemblies, each
of which can be 4KW or 8KW depending on the driver card
installed for that section.
The successor 21MX CPU had a Dynamic Mapping System (DMS)
feature that might be described as a bank-switching scheme --
you could map different physical regions into certain sections
of the address space under program control, and thus address
more than 32KW of real memory, but no more than 32KW was visible
at any given time. I think this was an option comprising
additional hardware and microcode ROMs to extend the instruction
set.
I really need to pull the 21MX manual and check this, because
it's been a while. I should also pull the 2100 schematics and
find out whether it really brought out additional address lines
-- for all I know, maybe the DMS stuff was originally done on
the 2100 after its introduction.
This in conjunction with the mention of semiconductor memory
makes me wonder if what's identified as the 2100 in the
interview is an inadvertent confusion of the 2100 and the 21MX.
_Frank McConnell_
fmc@aphasia.us.com
-------------------------------------------------
QUERIES
-------------------------------------------------
ASI SPEEDER: NEW OWNER PUZZLED
Does anyone know of, remember, or use a beasty such as the "ASI
Speeder" Addressing Systems International Model 131 A. What is
it? I've "obtained" one, and it seems to be functioning - a
keyboard/printer/disk drive unit but that's about all I can
tell. It wants a disk on startup - if anyone has a copy of this
disk (maybe an OS disk?) or manuals, or *anything* about it, it
would be useful!
_Michael Brown_
mjb@dcs.warwick.ac.uk
The Analytical Engine, Volume 3, Number 1, November 1995 Page 64
ATARI ATW800: DOCS AND VENDORS WANTED
Hi. I'm trying to get some information about an Atari Transputer
Workstation, model ATW800. It seems to date from about 1990.
It's in a large tower-style case. On a cursory examination, it
seems to contain most of the innards of an ST, along with a
large board with a T800 transputer on it and another board that
seems to be a video card of some sort. All I've got is the box
and the keyboard; no monitor, no mouse, no manuals. I'm told
that it runs Helios.
Basically, I'm looking for any information about this machine;
in particular, I'd be very grateful for pointers to any
companies that might still be able to supply documentation for
the machine and its software.
_J. Lothian_
jlothian@castle.ed.ac.uk
BAUDOT CODE LISTING WANTED
Back in the ancient days....Teletype made a model that used a
five level (read <five bit>) code called Baudot. I have a
couple of interesting (to me) questions (or requests):
1) Can someone post a listing of the *entire* Baudot five level
code?
2) From info I have, the code did *not* represent letters in
alphabetical order. What are the reasons behind the arrangement
of the letters in the code?
Any other information or anecdotes about the Baudot code or
Teletype would be appreciated. Please mail me and I will post a
summary. Thanks in advance!
_Charles Richmond_
richmond@plano.net
BLIT TERMINAL: PRETTY MUCH ANYTHING
I have acquired an authentic Bell Labs Blit for which I have no
documentation. It works, and the 13-year- old termcap entry from
Rob Pike also seems to work, but I'd like to know how to get it
running faster than the current 1200 baud. The 'SETUP' key does
nothing obvious. Any tips or pointers to Blit resources on the
net? Or Blit manuals you don't need anymore? Thanks,
_Jon Leech_
leech@cs.unc.edu
The Analytical Engine, Volume 3, Number 1, November 1995 Page 65
CANON LBP-CX PRINTER: POSTSCRIPT CONVERSION FEASIBLE?
I've a couple of Canon LBP-CX printers that I'd like to continue
using "as is", and also be able to add some circuitry to allow
them to be used to print regular ASCII text, Postscript and DVI
files. These are printers with the "raw" CX interface. The
type of computer system that I now use them with requires this
raw interface, so it's not just a simple matter of getting new
printers to use.
Besides, the printouts from these printers look very nice. What
I'd like to do is be able to flip a switch and use them, via a
serial port, with my Sun, or use the raw CX interface with the
other systems.
A while back, I recall seeing a book that is supposed to tell
one how to convert a Canon LBP-CX to a Postscript printer, but I
don't remember the title, or who the author is. Can anyone
comment on what all's involved in such a conversion, or on any
other things about this book? Thanks very much in advance for
any information that anyone can provide about this!
_R. D. Davis_
rdavis4@umbc.edu
CROMEMCO XXU CARD: MORE THAN A PAPERWEIGHT?
I was prowling the KC area old and funky computer shops
yesterday. I *bought* a Cromemco card, XXU XDOS 2.14. It has
two Motorola chips, a 68020 and a 6888. There is a sticker that
says "19k-CM" on the heatsink (if that's what it is). The
sticker is hand printed and looks like it was trimmed out with a
pair of scissors so I don't have confidence in its significance.
The solder side of the board has two "factory" stickers (i.e.
round cornered and dot-matrix printed) with
L/T #3
and 520-0176-G
REV. AC
The Motorola chips say
MC68020RC16E
and MC6881RC16B.
The aforementioned sticker is on a bent metal plate that covers
some socketed IC's and what I take to be an op amp. But I can
only see the sides. Silkscreened on the plate is
XXU (tm) Cromemco U.S.PATENT PENDING
The Analytical Engine, Volume 3, Number 1, November 1995 Page 66
A poster in comp.os.cpm said that they might have made a Unix
box and this might be for it. Soooo, now what? How do I find a
box to put it in, software to make it work and a little expert
advice?
_C. W. Fertig_
cwfertig@axp2.umkc.edu
CURTA CALCULATOR NEEDS REPAIR
Any idea where I might get my Curta repaired? I bought the
smaller model over the net but when I received it the mechanism
appears to hang up now and then. The crank doesn't have any
sort of tactile feedback on being pulled out and I guess that
someone pulled it part way out and then forced the mechanism.
It will work at times but I would like to see if there is any
U.S. source of repairs. I am told that attempting this myself
is not a good idea.
Thanks,
_Don Taylor_
dont@agora.rdrop.com
[We'd tend to agree. A Curta, for those who've never met one, is
a hand-held mechanical drum calculator made in Liechtenstein and
popular in the late 1950's; it looks like what you'd expect of a
black crank-type pepper grinder with eight digits' precision, if
it were made in Liechtenstein. They're complex, obsessively
precise, and cost lots more now than they did new. - Ed.]
DEC VT101 SETUP/B CODES WANTED
I have a VT100 with the VT101 upgrade board, and I was wondering
if anyone had a list of the Setup/B codes (1-4) All I can figure
out so far is speed (obvious), Inverse, and Block-Cursor. TIA,
_ Jason Mcmullan_
jmcc@m5.vi.ri.cmu.edu
DIGICOMP PLASTIC COMPUTER WANTED
I'm building a small museum of the computers that I have used,
and I would love to add the first computers I played with.
They were called the Digicomp I and Digicomp II Computers. The
Digicomp I had used little flip-flops and was programmed with
sections of a drinking straw. The Digicomp II ran on marbles
and gravity.
_Bob Roswell_
broswell@syssrc.com
The Analytical Engine, Volume 3, Number 1, November 1995 Page 67
EAI ANALOG COMPUTER WANTED
I'd love to find one of these marvelous machines as a nostalgia
item. A TR-20 or TR-48 would do fine. Functioning or not,
doesn't matter. Must be affordable.
_Dick Mills_
dmills@albany.net
GENIAC: NOTED COLLECTOR SEEKS COROLLARY MATERIAL
Still busy with non-computer-history activities, but I have
managed to capture a 1955 Geniac "Electric Brain Machine"
(original model) unconstructed kit in original box. Inventor and
manufacturer: Edmund C. Berkeley, who was also author of the
classic 1949 book, _Giant Brains_.
I am looking for a advertisement or brochure that portrays the
computer in finished form.
If anyone can help, please contact me. Thanks.
_Hal Layer_
P.O. Box 27676
San Francisco, CA 94127
email: hlayer@sfsu.edu
ph: +1 415-338-2637
HONEYWELL H-316 MONITOR DOCS WANTED
Anybody got any info on OP-16, a real-time monitor program that
used to run on the Honeywell H-316 mini? I spent several years
working with it about 20 years ago and would like to find a copy
of the doc for both OP-16 and the 316 hardware.
_Bruce Grant_
bgrant@montego.umcc.umich.edu
IBM PCJR SUPPORT DESPERATELY NEEDED
Does anyone have any old manuals or info on support groups for
IBM PCjr's? I gave a friend my old PCjr and they are still
refusing to upgrade.
They are driving me CRAZY with technical questions.... Any info
or help would be greatly appreciated. Thanks.
_Michael Ribeiro_
LdgImage@ns.net
The Analytical Engine, Volume 3, Number 1, November 1995 Page 68
INFORMATION STORAGE 525WC OPTICAL DRIVE: INFO WANTED
I just acquired an Information Storage Inc. type 525WC optical
disk drive. This company is (or was?) in Colorado Springs. The
drive is a 5.25" full height device which accepts standard 5.25"
disk cartridges.
What I would like to know (lacking _any_ docs):
- what is the interface used? It has a 20pin and a 34pin edge
connector (like a ST412 or ESDI interface)
- what is the capacity of this beast?
- is it WORM or MO read/write?
- anything else worth knowing.
Help is much appreciated.
_Wilko Bulte_
wilko@yedi.iaf.nl
MICROPOLIS 1568 AND WD7000ASC: SETTINGS WANTED
I have a Micropolis 1568 760MB ESDI drive jumpered for 1024
bytes/sector. I need to jumper it for 512 bytes/sector for a PC
interface.
Anyone got a refcard for this baby? I also need a copy of the
jumper settings for a WD7000ASC.
_Peter da Silva_
peter@nmti.com
OHIO SCIENTIFIC C3 OPERATING SYSTEM NEEDED
I have an OSI C3 OEM. I believe that the hardware is in good
working order. The machine will no longer boot. I think that
this is because the magnetic image on the disk has not been
refreshed in over 10 years.
I got the machine with no software except what was on the hard
disk. There was no floppy formatting program, so I was unable to
back anything up or make a bootable floppy. When the machine
booted, it came up in OS-65U Timesharing. I have three 48K user
partitions and would love to see this machine come up in
something other than the ROM monitor. Thanks,
_Bill Sudbrink_
bill@umsa7.umd.edu
OLYMPIA OL-H004 PROGRAMMING DOCS URGENTLY WANTED
I have recently acquired a "new" Olympia OL-H004 (Panasonic
RL-H1400) HHC (Hand Held Computer)....the HHC is a "palmtop"
computer circa 1982, with 6502 MPU, 4k RAM (Wow!<g>), its own
The Analytical Engine, Volume 3, Number 1, November 1995 Page 69
built-in operating system/programming language called SNAP, 26
char x 1 line LCD display; it accepts custom options & ROM
modules called Capsules. I have found it very handy for note
taking....[and] would like to tinker with it to make it even
more handy.... I am very keen to obtain programming
information/software/etc. for it and for the SNAP built-in
interpreter. If anyone could supply me with these materials, or
direct me to a source for them, I'd certainly appreciate it! (I
would, of course, gladly recompense you for your
shipping/media/etc. expenses.) Alternatively, if you could
suggest a better place to ask around, I'm open to suggestions.
Cordially,
_Richard Kanarek_
72371.111@compuserve.com
RCA COSMAC VIP: NOT MUCH WITHOUT DOCS
I have two RCA COSMAC VIP computers for which I'd like docs.
Anyone out there have a copy they'd either be willing to be part
with or copy? I'd be willing to pay a reasonable fee for
either.
Please e-mail if you can help me out! Thanks.
_Barry Kline_
kline@juncol.juniata.edu
SYLK DATA FORMAT SOUGHT
I need the specification for SYLK, which was used in the
MS-Multiplan spreadsheet. I think it was described in the
Multiplan user manuals. Does anyone have manuals they could
check? TIA,
_Russell Schulz_
Russell_Schulz@alpha3.ersys.edmonton.ab.ca
TELEVIDEO: THAT DARN CAT
_Ann Radnich_, annr@scs.unr.edu, would like any available
information on a Televideo desktop computer she inherited. We
think it's a TeleCat, which was Televideo's 286 AT clone, but we
can't find any docs for it. Anyone who has docs, e-mail please.
-------------------------------------------------
ARTICLES NOTED
-------------------------------------------------
"Let's Boot Up the Trash-80 and Play Some Oldies," by George
Johnson, New York _Times_ Week in Review section p. 2, Sunday,
The Analytical Engine, Volume 3, Number 1, November 1995 Page 70
August 20, 1995. A summary of issues related to hardware
collecting and software archiving, written with tongue firmly in
cheek, but a welcome sight in the mainstream press even so. The
author seems to think that software emulators, virtual antique
stores, and problems of media deterioration belong to the dim,
distant future.
-------------------------------------------------
PUBLICATIONS RECEIVED
-------------------------------------------------
_Australian Computer Museum Society Newsletter_.
#5, 8 June 1995. Committee news; Historically Significant
Computers and Australian Top 10; Golden Oldies Profile; General
Meeting notice. Unpaged.
#6, 1 August 1995. Committee news; Memberships and New members;
WWW sites; Book review; PDP-8 Story part 1 by Doug Jones.
Unpaged.
Charles Babbage Institute NEWSLETTER, Volume 17 Number 3, Spring
1995. Year of the Computer in MI; Fundraising campaign; Business
History Conference; Bruemmer elected to SAA Council; Herbert
Simon lecture; SHARE 40th anniversary. 6 pp. From Judy O'Neill.
Hewlett-Packard _Journal_, recognizing and publicizing technical
contributions made by HP personnel.
Volume 46 Number 3, June 1995. Capillary electrophoresis
instrumentation; Fault-tolerant mass storage; CASE tools for
microprocessor design. 98 pp.
Volume 46 Number 4, August 1995. 100VG-AnyLAN; AccuPage 2.0;
Large LCD flat-panel display; Economic modeling for programming;
Benchmarking ASIC evaluation. 74 pp. From the editors.
_HISTORY OF COMPUTING: An Encyclopedia of Computer History_ by
Lexikon Services. Deluxe Edition, July 1995. Approximately
1,000 pages and 70 digitized photos; requires 5 Mb disk space,
VGA graphics and MS-DOS 3.3 or better. US$15.00. From Mark
Greenia.
_International Calculator Collector_, Issue #9, Summer 1995.
Dallas Show, Summit: A Man and an Idea, Pocket Calculators: The
Early Years, HP Handheld Calculator and Computer Guide,
classifieds, resources, more. 16 pp. US$12 per year with
membership ($16 foreign). From Guy Ball.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 71
_Random Output_, monthly newsletter of East Bay FOG.
Volume 11 Number 6, June 1995. Educational software; Using CAD;
Annual elections. 4 pp.
Volume 11 Number 7, July 1995. CAD for Construction; Web
browsing; Q&A. 4 pp.
Volume 11 Number 8, August 1995. BASIC through Windows; Passage
to Vietnam; Taglines. 4 pp. From Pete Masterson.
_The Z-Letter_, newsletter of the CP/M and Z-System community.
Number 37, May/June 1995. TS-802H system tracks; Z-System on HP
125; reversing BACKSPACE and RUBOUT in DR CP/M; resources,
publications, letters and classified. 20 pp.
Number 38, July/August 1995. Spellbinder soft keys for
Televideo; introduction to Z-System shells; resources,
publications, letters and classified. 20 pp.
US$18 for 12 issues (2 years); Canada/Mexico, US$22;
International, US$36. From David A. J. McGlone.
-------------------------------------------------
ADDRESSES OF CORRESPONDING ORGANIZATIONS
-------------------------------------------------
Australian Computer Museum Society, PO Box 103, KILLARA 2071,
NSW, Australia. Michael Chevallier, secretary.
Charles Babbage Institute, 103 Walter Library, 117 Pleasant
Street SE, Minneapolis, MN 55455. Judy E. O'Neill, associate
director.
The Computer Museum, 300 Congress Street, Boston MA 02210. Brent
Sverdloff, curator of historical computing. Note change of
contact.
East Bay FOG, c/o Pat Watters, 5497 Taft Avenue, Oakland CA
94618. Tom Lewis, president.
Hewlett-Packard _Journal_, Hewlett-Packard Company, Box 51827,
Palo Alto CA 94303-0724. Richard P. Dolan, editor.
Historical Computer Society, 2962 Park Street, #1, Jacksonville
FL 32205. historical@aol.com. David A. Greelish, director and
editor.
International Association of Calculator Collectors, 14561
Livingston Street, Tustin CA 92680-2618. Guy Ball, Bruce L.
Flamm, directors.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 72
Lambda Software Publishing, 149 West Hilliard Lane, Eugene OR
97404. David A. J. McGlone, editor and publisher.
Lexikon Services, 3241 Boulder Creek Way, Antelope CA 95843.
lexikon2@aol.com. Mark Greenia, director.
_The Mathematical Intelligencer_, Springer-Verlag New York, 175
Fifth Avenue, New York, NY 10010. Chandler Davis,
editor-in-chief.
Perham Foundation, 101 First Street #394, Los Altos CA 94022.
Don Koijane, president.
Silicon Valley Engineering Council, 145 W. San Carlos Street,
San Jose CA 95113-2006. Edwin V. El- Kareh, director.
Unusual Systems, 220 Samuel Street, Kitchener, Ontario N2H 1R6,
Canada. Kevin Stumpf, president.
-------------------------------------------------
NEXT ISSUE
-------------------------------------------------
As much SDS as we can cram in, more Felsenstein, and a review of
David Packard's autobiography. Definitely an "ENGINE Plus."
Don't miss it!
-------------------------------------------------
GUIDELINES FOR DISTRIBUTION
-------------------------------------------------
The ANALYTICAL ENGINE is intellectual shareware. Distribution of
_complete, verbatim_ copies through online posting, Internet
mail or news, fax, postal service or photocopying is encouraged
by the Computer History Association of California.
Excerpting or brief quotation for fair use, including review or
example, is also permitted, with one exception: Any material
copyright to or by a third party and reprinted in the ANALYTICAL
ENGINE by permission shall not be used in another periodical or
context, unless the permission of the copyright holder is
separately secured for the new use.
Alterations, abridgments or hacks of the ANALYTICAL ENGINE which
change the intent or meaning of original content; or which
contrive to bring income to any person or organization other
than the Computer History Association of California; or which
contrive to injure the Computer History Association of
California, its officers, contributors, volunteers or members;
are PROHIBITED. Reproduction of the ANALYTICAL ENGINE without
its subscription coupon is abridgment in this sense.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 73
-------------------------------------------------
GUIDELINES FOR SUBMISSION
-------------------------------------------------
The ANALYTICAL ENGINE solicits manuscripts of 750 to 2500 words
on the general topic of the history of computing in, or with
significant reference to, the State of California. Articles
should focus on one interesting or illuminating episode and
should be written for a technically literate general audience.
Submissions are welcome from both members and non-members of the
CHAC. Article deadlines are: July 15 for the November issue,
October 15 for the February issue, January 15 for the May issue,
and April 15 for the August issue.
Each author may publish a maximum of one signed article per
year. This restriction does not apply to letters, queries, book
reviews or interviews. Thank you for cooperating to protect
diversity of voices and topics. Previously published material
will be republished only in clearly attributed quotations or
citations; or when its publication in the ANALYTICAL ENGINE will
bring it to the attention of a significantly broader audience;
or when the original publication is materially obsolete or
inaccessible.
Decision of the editors is final but copyright of all published
material will remain with the author.
The preferred document file format is Microsoft Word for DOS or
Windows, but almost any DOS or Macintosh word processor file
will be acceptable. Submit manuscripts on DOS 5.25" or 3.5", or
Mac HD (1.4) diskettes. Alternatively, please send your article
as ASCII or ISO Internet mail. Please avoid submitting on paper
unless absolutely necessary.
-------------------------------------------------
NINES-CARD
-------------------------------------------------
SOME BUGS TAKE A LONG TIME TO SURFACE...
-------------------------------------------------
by Tom Van Vleck
http://www.best.com/~thvv/tvv.html
In 1972, I wrote a program for Multics that created wall
calendars. I wanted to find the date of Easter, so I went to the
library, and discovered a simple algorithm for calculating when
Easter came in about 7 steps, attributed to Gauss. I copied it,
used it in my program, and tested a few years to make sure it
worked. The program worked fine for years, and then I got a
trouble report in late 1979, that it was off by a week for
Easter 1980. Sure enough, it was wrong.
The Analytical Engine, Volume 3, Number 1, November 1995 Page 74
Dennis Capps kindly researched the fix, and included a page-long
comment in the revised program, quoting an article from the
American Mathematical Monthly that said that Gauss's algorithm
failed occasionally: the first time since he wrote it was 1980.
What I learned was that others may get by for 400 years with
trying a few test cases, but If *you* try it, you'll get caught.
-------------------------------------------------
ADD MONEY, MAIL....
-------------------------------------------------
and enjoy fascinating articles, letters, queries and editorials
while you support the study and preservation of California's
unparalleled contribution to computing. Annual membership will
bring you four issues of the ANALYTICAL ENGINE and the
satisfaction of working toward a world-class computer museum for
the Golden State.
____ Yes! Please enroll me in the Computer History Association
of California for the next year. I enclose
Individual membership: $25 on-line / $35 paper (circle)
Corporate/institutional membership: $75 on-line / $85 paper
(circle)
Low-income/student membership: $15 on-line / $25 paper (circle)
and send four issues of the ANALYTICAL ENGINE to
____ Internet address: ______________________________
____ CompuServe ID#: ________________________________
____ Other gateway: _________________________________
My mailing address is:
Name: _______________________________________________
Company: ___________________________________________
Suite, Box, Mail stop: ______________________________
Street: _____________________________________________
City: _____________________ Zip/postcode: ____________
Country: _______________ Phone: _____________________
The Analytical Engine, Volume 3, Number 1, November 1995 Page 75
____ I will submit an article to the ANALYTICAL ENGINE. (Please
refer to the guidelines for submission, above.)
____ I will help produce the ANALYTICAL ENGINE or do other work
for the Association. Please contact me.