ae
The ANALYTICAL ENGINE
Newsletter of the Computer History Association of California
ISSN 1071-6351
Volume 1, Number 2, October 1993
Kip Crosby, Managing Editor
Jude Thilman, Telecommunications Editor
-------------------------------------------------
CONTENTS
EDITORIAL: Hello, World......................................2
INITIATIVE 1999: Warnings of Extinction......................3
Compilation Project: Getting It All Together.................6
Digital's History Project.....................................6
Volunteer Liaison Between CHAC And DEC........................7
Intel Museum Refreshes Its Exhibits...........................8
Museum Plans At University Of California, Davis...............8
Urgent: Spotters Wanted......................................9
Desperate Plea For Storage...................................10
Desperate Plea For Money.....................................11
And Speaking Of Money.... ..................................11
Overview Of Bureaucratic Processes...........................12
LOGO AND SMALLTALK, Aaron Alpar..............................13
OF THEE I SING, Tom E. Ellis.................................18
THE CHARLES BABBAGE INSTITUTE, Judy E. O'Neill...............21
PROGRAMMING THE 1401, Leo Damarodas..........................26
Book Review: THE DREAM MACHINE..............................32
Acquisitions: IMSAI 8080....................................34
LETTERS
Historical Accuracy.......................................35
1401 As Slave Processor...................................36
1401: Recollections And Corrections.......................36
More On Autocoder.........................................37
1401 Fortran Compiler.....................................38
More Glitches.............................................38
1401s I Have Known........................................39
A Common Bond: Welcomes For Our Association
From The Smithsonian Institution..........................40
From The Babbage Institute................................41
What Ever Became Of The Otrona?...........................42
Starting From Scratch.....................................42
Greetings From Iowa.......................................43
Museum Plans In The Northwest.............................44
"The Job Needs To Be Done"................................44
Considerations Of History And Reliability.................46
Resource For Those Working With CP/M......................48
Face Down, 9-Edge First...................................48
Questions Of Policy.......................................49
Attribution Of Electronic Mail............................50
QUERIES
Mainframe Front Panels Eagerly Sought.....................51
Citations Wanted On Computing In Insurance................52
Hunting Paleo-Jargon......................................52
The Analytical Engine, Volume 1, Number 2, October 1993 Page 2
Pesky GNAT In Sweden......................................53
Flying Blind On SOL-20 Assembler..........................54
Firebottle Query..........................................54
Computers In Military Command And Control.................55
Old-Iron Specs Wanted.....................................55
Origin Of "Minicomputer" Wanted...........................56
Does The S-100 Bus Stop Here?.............................56
One From The Editors......................................57
Publications Received........................................57
Addresses Of Corresponding Organizations.....................59
Thanks To.... ..............................................59
Next Issue...................................................60
Guidelines For Distribution..................................60
Guidelines For Submission....................................61
Subscribe!...................................................62
Nines-Card...................................................63
-------------------------------------------------
EDITORIAL: Hello, World
-------------------------------------------------
As I write this, there's a week of tightening and formatting
to be done before ANALYTICAL ENGINE Volume 1, Number
2, gets uploaded to the Internet and our growing list of
private bulletin boards. We know now how much work --
and how much fun -- producing the ENGINE really will be.
Luckily, for us, for you, there's joy in our hearts as we do it.
What a scramble! What a puzzle! What elation! What an
education! Above all, what a sense of that good old, great
old.... Right Thing.
Some people answered the editorial in the July ENGINE by
commenting that it almost sounded panicky, as if we
thought we were alone. Well.... not exactly. It was just
that, working almost entirely from experience in the East
and Midwest, we were afraid that we wouldn't find a
comparable level of dedication in California -- one of the
most interesting and pivotal places in all of computer
history. We lobbed ENGINE #1 into the dark of the future,
thinking that we had "dropped the rose petal into the well
and waited for the splash," really only scared of silence, of
politely spattering applause, of nothing.
The Internet's fiber backbones glowed. The lights of our
modems lit up and stayed lit. The snail-mail arrived with
rubber bands around it. The first phone call came from
Toronto; the first twenty-five-dollar check, from Idaho, the
second one from Pennsylvania. We heard from the Computer
Museum in Boston, the Smithsonian Air and Space, the
Babbage Institute, from DEC and Intel and SUN, and the list
went on.
The Analytical Engine, Volume 1, Number 2, October 1993 Page 3
Californians especially tended to reply by e-mail, so since
the first week in July when the ENGINE hit the net, we've
received almost five hundred pieces of e-mail. That
_doesn't_ count global postings on USENET, either. We
heard from people who understood what we were doing
and people who didn't. We were applauded for our guts
and excoriated for our mistakes. We found inquiries,
smiling from our screens, about starting the Computer
History Association of Iowa; of Colorado; of the Northeast
and Northwest. (Keep that going! It's great!)
So we've learned more and slept less, and now we know --
begin to know -- what's really out there. We are not alone,
and there is no silence. There are _thousands of people_ in
California, in this nation, and in the world, who care about
computer history, about keeping it safe, and about making
it known. This is no silence. This is a roar.
And if that's what came of ENGINE #1 --
Thank you, everybody who called, posted, wrote, grinned,
welcomed, barked or bit. Thank you, everybody who
subscribed or donated. Thank you, everybody who wrote
an article -- or even promised one. Thank you, everybody
who gave advice and ideas and time.
Welcome to ENGINE #2. It's six times thicker than ENGINE
#1. And it's all yours!
Hello, world!!
-------------------------------------------------
INITIATIVE 1999: Warnings of Extinction
-------------------------------------------------
If you love old iron -- and so many of us do -- consider this
quote from _Accidental Empires_ by Robert X. Cringely,
Addison-Wesley, 1992:
....you and I can go even further [than Bill Gates].
We can predict the date by which the old IBM -- IBM
the mainframe computing giant -- will be dead. We
can predict the very day that the mainframe
computer era will end.
Mainframe computing will die with the coming of
the millennium. On December 31, 1999, right at
midnight, when the big ball drops and people are
kissing in....Times Square, the era of mainframe
computing will be over.
The Analytical Engine, Volume 1, Number 2, October 1993 Page 4
Mainframe computing will end that night because a
lot of people a long time ago made a very simple
mistake. Beginning in the 1950s, they wrote
inventory programs and payroll programs for
mainframe computers, programs that process
income tax returns and send out welfare checks --
programs that today run most of this country. In
many ways those programs have become our
country. And sometime during those thirty-odd
years of being moved from one mainframe computer
to another, larger mainframe computer, the original
program listings....were just thrown away. We have
the object code....which is enough to move the
software from one type of computer to another. But
the source code -- the....details of how these
programs actually work -- is often long gone, fallen
through a paper shredder back in 1967. _There is
mainframe software in this country that cost at least
$50 billion to develop for which no source code
exists today_.
This lack of commented source code would be no big
deal if more of those original programmers had
expected their programs to outlive them. But hardly
any programmer in 1959 expected his payroll
application to be still cutting checks in 1999, so
nobody thought to teach many of these computer
programs what to do when the calendar finally says
it's the year 2000. Any program that prints a date....
and that doesn't have an algorithm for dealing with
a change from the twentieth to the twenty-first
century, is going to stop working. I know this
doesn't sound like a big problem, but it is. _It's a
very big problem_.
Looking for a growth industry in which to invest?
Between now and the end of the decade, every large
company in America will have to find a way to
update its mainframe software or....write new
software from scratch.... Either solution is going to
cost lots more than it did to write the software in the
first place. And all this new mainframe software will
have one thing in common; it won't run on a
mainframe.... which is why the old IBM is doomed.
The reasoning behind this is various, but the simple case is
that many older mainframes store their dates in the format
YYMMDD
and, when YY returns as 00, will halt on error. Sure, there
The Analytical Engine, Volume 1, Number 2, October 1993 Page 5
may be workarounds. But for lots of older computers, the
programming overhead of dealing with this kink will be the
last push over the cliff. Cringely's right; mainframes will be
scrapped wholesale, and the oldest first. From the
standpoint of function it only makes sense, since the oldest
hardware is usually the slowest. But to the historian and
preservationist, the oldest hardware is often the most
significant.
If we intend to respond to this crisis, we have seven years
to make plans and marshal resources; seven years to find
and equip facilities; seven years to nail down funding. And
for a project of this size, seven years is not a long time.
Anyone seriously interested in preserving the history of
computing -- which certainly means any reader of this
newsletter -- is actually advised to figure that we're in a
screaming hurry.
With this issue of the ANALYTICAL ENGINE, the Computer
History Association of California announces INITIATIVE
1999. What this is, and what it becomes, will be
elaborated in future issues. For the moment, just plant two
cardinal points in your mind:
1) On or before January 1, 1999, we would like to see
chapters of this Computer History Association established in
every state of the Union. To that end, we will advise,
collaborate with, and give moral support to any responsible
groups of historians and preservationists who express
serious intention of founding such an Association.
2) On or before January 1, 1999, we intend to open a
museum large enough to display a significant part of the
history of computing in California, presenting the broadest
available spectrum of appropriate artifacts, and using the
(then) most contemporary technology for instruction by
interactive and virtual means. To that end, we would
appreciate the donation of (for example) a large disused
factory or warehouse, convenient to freeways, and with
loading docks; of pertinent hardware and software; of
expert consultation, particularly with reference to accession,
registration and curatorship; and of appropriate amounts of
money.
We reiterate: Seven years is not a long time. What we're
trying to do here can only be done once, or given up for
lost. If you're reading this newsletter, you _can_ help, with
a $25 donation to the ENGINE or with that factory.
_Save the mainframes!_
The Analytical Engine, Volume 1, Number 2, October 1993 Page 6
-------------------------------------------------
COMPILATION PROJECT: Getting It All Together
-------------------------------------------------
As basic research, fundamental to tracing the provenance
of donated hardware, software, and documentation, the
Computer History Association of California is compiling a
list of
1) Computer HARDWARE developers/manufacturers
2) Computer SOFTWARE developers/manufacturers
3) Computer PERIPHERALS developers/manufacturers
now or formerly incorporated or headquartered in the State
of California. Since information on businesses currently
operating is relatively available from published sources,
priority should be given to citation of businesses no longer
operating.
Information wanted in each citation is:
Business name
Primary business address
Telephone or fax number
Date of first business done, or incorporation
Date of last business done, if known
Types of hardware or software produced
Maximum annual dollar volume and year in which recorded
Names of officers, as known
Please do _not_ include citations for retail outlets; regional
offices of non-California companies; or reseller/distributors.
Depending on its length, this list may ultimately be
published as a request supplement to the ANALYTICAL
ENGINE, or as a separate publication. We are grateful for
all contributions and for your attention. Please reply by
Internet mail, or by paper mail to the CHAC El Cerrito
address.
-------------------------------------------------
DIGITAL'S HISTORY PROJECT
-------------------------------------------------
Lawrence C. Stewart at the Cambridge Research Laboratory
of Digital Equipment Corporation (DEC) has sent a memo
about an interesting and ambitious project to produce
comprehensive, documented emulations of historically
important computer systems. This is the summary:
"The idea of the Computer History Project is to
The Analytical Engine, Volume 1, Number 2, October 1993 Page 7
preserve the history of computing systems, and to
make that history readily available to everyone....to
publish a CDROM, or perhaps a series of CDROMs,
which would contain emulators for historic
computing machines and copies of their operating
software and documentation.
Modern computers are so much faster than historic
machines that it is possible to emulate the
instruction set and I/O systems of a historic machine
at full speed. Thus students will be able to actually
sit down and use TENEX running on an emulated
PDP-10, or Bravo on a Xerox Alto, even when no
more PDP-10's or Altos exist."
To receive a copy of the complete memo, a highly
worthwhile document, send a message to
engine@win.net
with a _subject_ line of
decmemo
or request hard copy from the El Cerrito mail address.
-------------------------------------------------
VOLUNTEER LIAISON BETWEEN CHAC AND DEC
-------------------------------------------------
Richard Secrist of Digital Equipment Corporation has
volunteered to act as an informal focal point for employees
of Digital interested in contributing to CHAC.
Physical address:
R.C. Secrist
Digital Equipment Corporation
412 Executive Tower Drive, Suite 300
Knoxville TN 37923
Internet: secrist@kxovax.enet.dec.com
[Thanks, rcs! This and the previous item exemplify the
concern for, and commitment to, computer history
demonstrated by many DEC employees. A similar tip of the
hat to our friends at Apple, Intel and SUN. Conversely,
there are some awfully big corporations that we only
_wish_ we'd hear from....and you know who you are. ]
The Analytical Engine, Volume 1, Number 2, October 1993 Page 8
-------------------------------------------------
INTEL MUSEUM REFRESHES ITS EXHIBITS
-------------------------------------------------
The Intel Museum, established in 1992, has been renewing
and polishing its exhibits, and makes a highly
recommended stop for anyone interested in recent
computer history.
Intel Corporation was founded in 1968, in a small building
in Mountain View, CA, USA, by Robert Noyce, Gordon
Moore and Andrew Grove. The company's first-year
revenue was less than $3,000! Today, of course, Intel's
25,000 employees make thousands of products, ranging
from memory chips to supercomputers and including the
famous ix86 microprocessors that power the majority of the
world's small computers.
The company has packed an amazing amount of history
into twenty-five years, and the Intel Museum uses the latest
assistance -- including interactive video and real-time
automated displays -- to give the visitor a sense of that
history in depth. While the focus is understandably on
Intel's particular accomplishments, there's a lot to be
learned here about the techniques of technology, as well as
history. If you've ever wondered "what makes a computer a
computer," this one's for you.
Intel Museum
Robert Noyce Building
2200 Mission College Boulevard
(off Great America Parkway north of 101)
Santa Clara CA 95052
8 am -- 5 pm Monday through Friday, admission free
408/765-0503 for information
-------------------------------------------------
MUSEUM PLANS AT UNIVERSITY OF CALIFORNIA, DAVIS
-------------------------------------------------
Dick Walters of the UC Davis Computer Sciences
Department writes:
> I have been involved in the microcomputer revolution
since 1975, building my first IMSAI in 1976. A few years
back, I started to collect....with the idea of setting up a
museum at Davis. The idea is gaining momentum, but very
slowly.
Some of the items we now have on hand include:
The Analytical Engine, Volume 1, Number 2, October 1993 Page 9
Altair; 5 or more IMSAI systems, some with disk; TRS-80
Mod 1 and Mod 2; Osborne; Kaypro; Data General DT-1
laptop; 3 or more Cromemco systems; Heath 89; Franklin;
Processor Technology SOL; Sanyo; Ohio Scientific; Zendex;
IBM Mod 10 keypunch; Teletype, peripherals, and
miscellaneous items. We also have documentation for most
of these systems.
I am interested/willing to serve as a focal point for the
collection of more gear relating especially to the micro
world. We do not have room here for....mainframes and
workstations are probably a little beyond our current
capabilities. I would also propose exchange of some
duplicates for wanted items....
I welcome people interested in....applying pressure to
promote the formation of a real museum/display facility for
these items. We show off many of them on our annual
UCD Picnic Day (last year our first effort in this regard) but
we need more permanent housing than my research lab.
Interested parties should contact me at:
Department of Computer Science
UC Davis
Davis CA 95616-8562
phone 916/752-3241
fax 916/752-4767
Internet: walters@cs.ucdavis.edu
-------------------------------------------------
URGENT: SPOTTERS WANTED
-------------------------------------------------
With this issue, the ANALYTICAL ENGINE goes mainstream,
or sort of. In late October or early November, a paper
edition will be distributed to selected metropolitan
newspapers, to the computer press, to archival sites, and to
paying subscribers who request it.
This raises the question of finding reviews and
announcements in the press. Tearsheets are a bygone
courtesy and clipping services -- especially for magazines --
startlingly expensive. Yet we need to know what the media
are saying about us, and for more reasons than simple
vanity.
Save us from the dire choice between ignorance and
poverty! If you see any mention of CHAC or the ENGINE on
published paper, please do one of these three things:
The Analytical Engine, Volume 1, Number 2, October 1993 Page 10
* If your copy of the piece is clippable, clip and mail to the
El Cerrito address.
* If you can't spare the physical copy, send the text as
net.mail to cpu@chac.win.net, or photocopy and fax to the
El Cerrito address.
* If you're too busy for that, just send the publication
name, date and page number and we'll do the hunting.
Thanks!
-------------------------------------------------
DESPERATE PLEA FOR STORAGE
-------------------------------------------------
We need storage space for hardware and documentation --
tight, dry space -- and lots of it.
Admittedly, we had a few micros before the CHAC ever
began, and now we have quite a few more. Most of them
are in excellent condition and almost all are bootable.
Shortly they'll be housed in a rented locker, which is
expensive, and it isn't completely appropriate.
Before long, the inappropriate will become impossible,
when the bigger iron arrives. We've been offered a full-
house PDP-8i that spent its whole life in honorable service
to the State of California -- but we can't afford rented
storage for it, and it won't fit in anybody's garage. Will we
have to watch it end up as landfill? And when we're asked
about other, bigger, computers, will we have to let those
go too? Because we have no place to put them?
Just as we need the museum for the computers (see
INITIATIVE 1999) we need the computers for the museum.
Collectively we're awed by mainframes, fascinated by minis
and completely smitten with micros; we're constantly
fighting the constraints that would force us to be
"architecture bigots" and favor the platforms that take less
space.
The history of computing in California takes up _serious_
racks. We're getting our 501(c)3 nonprofit status precisely
so that we can offer deductions to those generous people
(and companies) who will donate the things that we can't
pay for. Do you have warehouse space you're not using?
Donate it, please! and we'll give you a writeoff, put your
name on a plaque....
The Analytical Engine, Volume 1, Number 2, October 1993 Page 11
-------------------------------------------------
DESPERATE PLEA FOR MONEY
-------------------------------------------------
We don't just need money. We need _more_ money. And
there's a special reason.
The Computer History Association of California is a very
small organization that needs room, in its architecture, to
get much bigger over the years. We don't want to be
intimidated by current constraints, build tight, and then
hang bags on the sides without being strategic. We all
know what that would lead to....
We _will_ succeed in our mission, _if_ we can reach out to a
truly representative sample of the computing community.
This means going beyond electronic communication to hard
copy of the ENGINE, to press releases and news stories and
events. It means making the ENGINE into a "real magazine"
as soon as our subscriber base permits. It means forging
links with trade publications, industry executives, and
foundations. It means, in a word, being taken seriously.
That's why our watchword is "Do it now _and_ do it right."
With a handful of members and one tiny office, CHAC
doesn't _need_ to be a corporation -- but incorporating
now will smooth our path as we grow larger. With a trickle
of donations, we don't _require_ nonprofit status -- but that
voluminous paperwork is easier to file now than later. We
don't _have_ to arm-wrestle a VISA provider into handling
subscriptions, but....
Remember: The earliest money is the best.
Help us do it now.
Help us do it right.
Help us be what we must be, today and in 1999.
Please subscribe, and give.
-------------------------------------------------
AND SPEAKING OF MONEY....
-------------------------------------------------
E-mail is like the lunch date you make over your shoulder.
It's too easy to commit and forget. Tapping out an "Oh,
sure" and hitting the SEND button is no trouble. Finding
your checkbook, writing a check, preparing an envelope
and finding postage -- that's trouble.
We're sympathetic, but we're also pushy. No one _has_ to
pay for the ANALYTICAL ENGINE; it's shareware. It's yours
whenever you want it. But please....if you send us mail that
says "I'll subscribe right away," then take your next chance
The Analytical Engine, Volume 1, Number 2, October 1993 Page 12
to write that check and mail it. Money pledged is money
that we count on.
-------------------------------------------------
OVERVIEW OF BUREAUCRATIC PROCESSES
-------------------------------------------------
A. VICTORIES
Since the release of ENGINE #1 we've acquired:
1) A bank account. This sounds like a simple thing, but it
wasn't; paper bureaucracy and electronic communication
move at such disparate velocities that we actually held
checks made out to the Association before we had a place
to put them. This has been fixed and subscription
payments are now deposited immediately. Thanks to all
those who were patient about their cancelled checks.
2) An International Standard Serial Number (ISSN). This
registers the ENGINE with the U. S. Library of Congress and
the International Serials Data Center in Paris.
3) A new Internet mail and news address. This is the
visible part of our effort to make our organization less
reliant on one person. (It's also partly legalistic nonsense,
but never mind that.) Those of you who mail or post to
CHAC, please use
cpu@chac.win.net
effective immediately.
4) An Internet server request daemon. Not as daunting
as it may sound, this clever item automatically provides
ENGINE back issues and related useful text files via Internet
mail. For instructions and a list of what's available, send a
message to
engine@win.net
with a _subject_ line of
help
and the reply will be on its way to you within minutes. (The
less wired may request any of these files in hard copy from
the El Cerrito mail address.)
The Analytical Engine, Volume 1, Number 2, October 1993 Page 13
B. PROCESSES
We are in process of selecting directors and officers, filing
articles and bylaws, and generally complying with the
regulations that govern establishment of a California public
benefit corporation. Once this is done, we will be able to
apply for Federal and state nonprofit status as an
educational institution. This will save us money because it
has favorable tax implications; it will also mean that
donations to CHAC will be tax-deductible to the donors. All
this takes time and a discouraging amount of paperwork to
do properly, but it's important.
C. FRUSTRATIONS
We had hoped to announce in this issue that we could
accept subscription payment by credit card. This is a tough
nut to crack. Several MasterCard and VISA providers have
muttered that they don't much care to handle subscriptions
and that low volume isn't worth their while. At any
mention of electronic mail and the Internet, they turn pale.
The bottom line is that they avoid dealing with any entity
other than a traditional corporation.
To potential ENGINE subscribers who prefer to pay with
plastic, and especially non-U. S. subscribers who have
trouble paying in dollars, we have to say: Please hold. We
want to make payment convenient for everyone, including
ourselves, but the right mechanism hasn't appeared yet.
-------------------------------------------------
LOGO AND SMALLTALK: Languages that Changed the Rules
-------------------------------------------------
by Aaron Alpar, ParcPlace Systems
Relationships between computer languages are often more
intimate in their full depth than they appear on the surface.
This is especially true of Smalltalk and LOGO, two of the
most experimental -- and most influential -- languages of
the last twenty years. They were designed for substantially
different purposes and primarily used in very different
contexts. Yet a brief review of their history will
demonstrate that they have a great idea in common: the
tremendous extensibility of the computer as a tool for
people.
LOGO: A TEACHING LANGUAGE THAT GREW
Developed by Marvin Minsky and Seymour Papert at MIT,
LOGO began as a teaching language, to introduce children
to computers. The language that resulted accommodated
three central facts:
The Analytical Engine, Volume 1, Number 2, October 1993 Page 14
* Children perceive work and play as unified;
* Children care more about results than about process,
meaning in this context that as they build something,
they want to watch it being built;
* Children are intolerant of technical limits. When they
are told that "The computer cannot do that," their
first reaction is either "Yes, it can," or "Why not?"
LOGO's response to these truths was brilliant. First of all, it
was a "working language" and at the same time a "playing
system" -- a language that turned the computer, screen and
keyboard into a toy that was deeply absorbing, completely
interactive, consistently rewarding and (incidentally) very
educational. Through its use of "turtle graphics," a
pioneering graphical programming metaphor, and a split
screen -- half input, half result -- it showed _immediate_
output of every programming step taken. Finally, LOGO
became progressively more complicated as the user's
proficiency grew. Someone who went in knowing nothing
more than halfway how to type could still achieve enough
to provoke a great rush of self-satisfaction. Then, as
curiosity took over, LOGO's simple and uniform syntax and
concepts would facilitate exploration of other parts of the
system, expanding knowledge and programming skills.
In itself, LOGO was a triumph, and the proof is that it has
been very durable. As a teaching tool, it is still widely used
in elementary schools. It became a cornerstone of research
and literature in artificial intelligence. Its influence on
professional programming is inestimable. (The author has
spent plenty of time blissfully, and ignorantly, typing
thousands of lines of BASIC, assembler, machine code, and
Pascal. None of this stimulated any thinking about real
possibilities of computer/human design in programming
languages. Then I encountered LOGO, which was powerful
enough for reasonably serious, if slow, application
development, and at the same time intuitive enough for
children to perform "useful work". I interpreted this as a
leap in computer usability that promised to make the
technology much more broadly accessible.)
RISING UP AGAINST THE "TYRANNY OF NUMBERS"
LOGO's most profound influence has been as an
_ultimatum_, not as a language. It was developed by
people who knew computer architecture and programming
backwards and forwards, but it was a _product_ of thinking
about people -- of saying "What do people want to do that
computers can help them do?" And the people who are
most insistent about what they want to do, of course, are
children.
The Analytical Engine, Volume 1, Number 2, October 1993 Page 15
LOGO, and after it Smalltalk, freed computers from the
tunnel vision of _computing_ -- from the tyranny of
banging numbers together. The users of these languages
(who became, in a very real sense, their co-developers)
were ten-, twelve-, and fifteen-year-olds who wanted to
draw pictures, play music, make movies and create games.
Minsky's staff at MIT, and later the working group at Xerox
PARC, refused to give the turn-off answer of "The computer
can't do that." Instead they plunged headlong into research
and brought forth computers that _could_ do "that."
Ultimately, this turned the whole hierarchy of computing
upside down -- from
Hardware to User
Software Software
User Hardware;
although it took decades for the implication of this to
become clear. As Alan Kay said in a recent article,
Hardware is really just software crystallized
early....far too often the hardware has been
presented as a given and it is up to software
designers to make it appear reasonable. (1)
Even for the original LOGO, the hardware was a given; it
just happened that this was an unusually minor constraint
because the hardware (and hardware support) available to
the MIT AI Lab of the day was formidable. Smalltalk leaped
the next gap; its "given" was not the software and not the
hardware, but a principle. In a 1977 survey article
published in _Scientific American_, Alan Kay skewered the
notion that the hardware made the rules:
Ideally the personal computer will be designed in
such a way that people of all ages and walks of life
can mold and channel its power to their own
needs.... Although the hardware of the computer is
subject to natural laws....the range of simulations the
computer can perform is bounded only by the limits
of human imagination. (2)
SMALLTALK AND PARC: COMPUTING FOR PEOPLE
It's worth remembering that when this article appeared,
very few people had ever seen an Apple II; the IBM PC was
four years away, the Apple Macintosh seven. Programmers
in a hardware-dominated context were preoccupied with
files, compiling, libraries, syntax, railroad diagrams, virtual
machines, and the fearful convolutions of installing 16k
memory boards.
The Analytical Engine, Volume 1, Number 2, October 1993 Page 16
But the developers at Xerox PARC -- Kay, Peter Deutsch,
Adele Goldberg, Butler Lampson, and many others -- had
been crucially influenced by the operational sequence of
LOGO:
_Turn on computer_
_Type command_
_<Enter>_
_See result._
To the user, there was no distinction between language,
environment, and operating system.
Enter the Smalltalk language, in its several versions. While
LOGO wasn't the _only_ ancestor of Smalltalk -- much was
also inherited from LISP, Algol and SIMULA -- the
connection between the two is worth emphasizing because
of the tenets they shared:
* extensibility
* nominal syntax
* avoidance of data types
* concentration on objects
* persistent connection between action and result
* minimal demand for background knowledge
* priority of fun and intuitiveness
Smalltalk-72, the first "complete" version of the language, in
several senses began where LOGO had left off. Its
extensibility was the extensibility _of objects_; it made the
leap from LOGO's visual-object-as-metaphor to genuine and
sophisticated object-orientation, building on the great start
of turtle graphics to present friendly and familiar "objects"
that were also abstract, manipulatable, and the building
blocks of programmed systems. A later version, Smalltalk-
76, adapted SIMULA's crucial abilities of inheritance and
class support, treating classes as objects.
Was it still fun? In 1973 Marion Goldeen, age 12, wrote an
object-oriented paint program in Smalltalk; Susan Hamet,
age 12, wrote a drawing program much like MacDraw; 15-
year-old Bruce Horn wrote a music score capture system.
These and many other Palo Alto middle school students
provided the "intolerance of technical limits" that spurred
development. They were also the first, or nearly the first,
children and adolescents to sit down at a computer and
have fun.
Here, of course, innovation rested on innovation -- because
the children, like the PARC scientists they taught, refused to
accept the answer "The computer cannot do that."
The Analytical Engine, Volume 1, Number 2, October 1993 Page 17
HARDWARE: COMPUTERS THAT COULD "DO IT"
In step with the development of Smalltalk, corollary
hardware issues were being addressed -- still with
confidential development in a largely closed laboratory.
Problems were formidable. Smalltalk was conceived as a
completely graphical language and environment; it needed
to be run on a bitmapped device. At the time, few
computers other than mainframes could compose bitmaps
for display, and then crudely. The disparity between
hardware and software was huge. _But the hardware had
stopped making the rules._
Chuck Thacker, Doug Englebart, Gary Starkweather, Bill
English and the other PARC builders responded with a
hardware context that combined innovative brilliance with
a rare grasp of systems integration. To SLOT, the first laser
printer -- a wildly modified Xerox high-speed copier -- and
the Research Character Generator, the first bitmapped font
composer, they added the famous Xerox Alto and the
Ethernet network.
Integration and daring were the keys that made PARC's "on-
line office system" so memorable. The Alto, now often
called the "first personal computer," was not the first
computer sized and priced for the single user -- the DEC
PDP-8/S preceded it by seven years; and the first practical
LAN architecture was not Ethernet, but the token-ring Pierce
Loop developed at Bell Labs in 1971. The Alto was unique
as a deliberate exploration of what a personal computer
should be like, rather than a small general-purpose machine
that accidentally gravitated to personal use.
With these inventions, the inversion of the classic hierarchy
was complete. _The user drove Smalltalk; Smalltalk drove
the hardware._
LOOKING BACK: WHAT HAVE WE GAINED?
This is not the place to argue, pro or con, about Xerox
Corporation's use and pursuit of these assets. Information
distributed on paper had made the company into a billion-
dollar establishment and a household word. To put it
charitably, the balance between sustaining old technologies
and exploiting new ones was not a trivial concern.
Certainly the successes of Smalltalk, of LOGO, and of their
underlying metaphors have outlasted the involvement of
any single corporation or institution. Graphical interfaces
and object orientation now provide a unifying theme over
almost the full spectrum of computing -- from Microsoft
The Analytical Engine, Volume 1, Number 2, October 1993 Page 18
Windows to Macintosh System 7, and on to NeXTStep, X
Windows, OSF/Motif, and through language products like
ObjectVision, Visual Basic and the various flavors of C++.
This pervasiveness of object-orientation and of the
graphical interface makes it all the more pleasant to realize
that LOGO is taught in schools to this day, and that
Smalltalk -- having gone through four major and several
minor revisions -- is a mature, flexible and contemporary
language, still commercially available and used worldwide.
The next time you sit in front of a computer that uses a
windowing system, and enjoy the convenience and
flexibility of the tools it brings you, remember that --
through LOGO and Smalltalk -- the real work of computing
was changed forever by the impatience and the gravity of
play.
_Notes_
(1) Alan C. Kay, "The Early History of Smalltalk," _ACM
SIGPLAN Notices_, March 1993, page 87.
(2) Alan C. Kay, "Microelectronics and the Personal
Computer," _Scientific American_, September 1977.
-------------------------------------------------
OF THEE I SING
-------------------------------------------------
by Tom E. Ellis
When I first heard about the Computer History Association
of California, I was excited by the task of gathering
together the objects of our machine inheritance, for all to
enjoy. Thinking about seeing a SOL-20 again, or toggling a
program into an IMSAI 8080, brought great cheer.
Preserving our hardware heritage is an important step in
the mapping of our craft. Yet another piece of computer
history is as worthy of our attention: the software.
Initially, of course, software tended to be utilitarian in
nature. The business of computing was expensive and
resources were limited, so programs had to have a
significant purpose. But even in that regimented context,
some people insisted on the "luxury" of writing code purely
for fun, or to try something that had never been done.
Much of this software, even if not "serious," included
innovative snippets of code that made a change in the way
we did things; code that broke the bonds of conventional
wisdom and strode bravely forward into new territory.
We've all been "explorers" of this type at one time or
another, and I hope we always will.
The Analytical Engine, Volume 1, Number 2, October 1993 Page 19
When I was hired by the San Francisco branch of a large
nonprofit organization, to assist in the conversion from a
3x5 card system to a donor tracking system on a Honeywell
2020, we had a small problem. The system was to be
based on a large master file on tape, with a weekly
transaction file for updates. Pretty ordinary stuff.
A master file update was time-consuming, since it involved
reading and writing every record in the system.
Transactions flooded in daily from units all over the state.
The more data we collected, the longer the process
became. We wanted to collect our daily transactions and
apply them _en masse_ to the master file at the end of the
week.
We had three tape drives, each as big as a side-by-side
refrigerator: Master In, Master Out, Transactions In. Each
drive used two long columns of air to pull the tape past the
heads. You'd spin the take-up reel and the supply reel in
opposite directions to produce a small buckle in the tape,
the vacuum in the air columns would pull the tape down
into the chamber, and the reel motors would take up the
slack. The whole process was a sight to see and hear.
The problem was that you had the choice of opening a tape
drive in "read mode" or "write mode" -- not both, or so we
thought. Tape devices wrote data as a linear set of blocks,
beginning with a header describing the record size,
blocking factor and number of blocks in the file, and
ending with an EOF record following the last data block. In
read mode, when you hit that EOF record, you had few
choices. The concept of updating an existing file was
unheard of.
I was searching for a way to open the tape drive in read
mode, grab the details from the tape header label, proceed
to EOF, back up a block, switch into write mode, add blocks
to the end of the tape and write a new EOF record. A
simple append, right? Not so.
The last data block is hardly ever full. Rarely does the
number of records you need to write work out to a multiple
of the blocking factor. So I had to back up twice -- once for
the EOF record and once for the last data block -- read that
block into the current data buffer, set the internal buffer
counters and pointers, back up again and flip the tape drive
into write mode. When I finished writing all the new
blocks, I'd have to write the new EOF record, rewind to the
beginning of the tape, and re-write the tape label with the
(now current) block and record counts.
The Analytical Engine, Volume 1, Number 2, October 1993 Page 20
The guys at the data center said it couldn't be done; the
positioning of the tape was never meant to be so precise.
When you re-wrote the label at the beginning of the tape,
they insisted, you'd undoubtedly write data beyond the
inter-record gap, stepping on the first data block and
ruining the whole thing. And of course there was no way
to make sure your last block would obliterate the EOF
marker. And what if the EOF marker fell into the inter-
record gap? And how would you get around the EOF
condition flag that had been triggered? They had a
thousand reasons why it wouldn't work!
I became obsessed with the idea. The data center turned
me on to a guy that knew tape drives like no one else; I
recall that his name was Jimmy. He had studied the
machine code for directing tape drive movement until he
could make a drive do just about anything. With his advice,
I was able to build a small routine that would fool the
machine, and turn a tape drive that had been opened in
read mode into a tape drive that was available for output.
It was a great day when we successfully appended new
data to the existing tape. And never once, during my
tenure, did that routine fail to run properly.
But as happy as I was to solve my problem that day, I was
even more pleased by a little assembly program of Jimmy's
that put the tape drives to very creative use. Depending on
the movement of tape in the columns, the voltage applied
to the record head, and a thousand other conditions, the
drives would make a wide variety of buzzing, hissing and
humming noises. And the pitch of the sound produced
would change, depending on how far down in the column
the tape was pulled.
Jimmy had figured out just what series of instructions
would produce just which tones, using the tape to vary the
length of the column of air in the vacuum chamber. Mind
you, there were no commands available to move the tape
to a certain depth in the air column -- that would have been
senseless; the specific tones were a by-product of starts and
stops, read/write instructions, and tape movement
commands strung together in an ordinarily meaningless
series.
So precise was Jimmy's code that he could produce not only
the tones he desired, but the rhythm required to reproduce
a complete musical number, with percussive sounds thrown
in for good measure. The effect was remarkable. People
who hardly expected to hear a familiar song coming from a
massive tape drive could listen carefully and hear the strains
of a Souza march, Mary Had a Little Lamb, or America the
The Analytical Engine, Volume 1, Number 2, October 1993 Page 21
Beautiful. We must have coded twenty songs before we
were through, and Jimmy gave me a tape of the program --
which has to have been the first shareware of my career.
Naturally this became a favorite trick to play on visiting
executives. We would log every tape drive to the same
physical address, start the program, and soon, from what
looked like a busy computer working hard at its task, out
would come Happy Birthday, or God Bless America, or
whatever. The computer operator would play dumb, of
course, when one of the VIP's would recognize the tune. It
never failed to brighten our day.
I'm sure other such programs deserve similar recognition.
In the days of paper tape, everyone had a utility that would
punch words right onto the tape; people's big treat on their
birthday was to get a strip printed with birthday wishes
from the computer. The guys in my data center wrote a
routine to play baseball, using the print head on a Selectric
typewriter as the ball. The pitcher controlled his throw
with the keys on one end of the keyboard and the batter hit
the return key for a swing. What glorious fun!
Do you know of some innovative use of traditional
techniques? Something that breaks the mold? These
programs, like the hardware they were born on, are
trapped in their own time, gone away with the succession
of improvements that have rendered them moot. We've
got to catalog these bits of creativity while there are still
people who can put them into perspective; and we have to
find ways to foster the same kind of creativity in the
programming being done now. Today's neat hack is
tomorrow's breakthrough algorithm. Today we can watch
SimCity (tm) unfold on our screens; tomorrow I want to
watch it roll by from a comfortable seat on my own virtual
train!
-------------------------------------------------
THE CHARLES BABBAGE INSTITUTE
-------------------------------------------------
by Judy E. O'Neill, Associate Director
The Charles Babbage Institute (CBI) is a research institute
dedicated to promoting the study of the history of
information processing, bringing historical perspective to
the study of its impact on society, and preserving
documentation relating to the development and application
of the computer. An alliance of industrialists, professionals
and academicians with a common purpose -- to record and
study the evolution of the digital computer and modern
electronic communications -- formed the Institute in the
The Analytical Engine, Volume 1, Number 2, October 1993 Page 22
late 1970s. CBI has contributed substantially to the
literature in the history of computing through its historical
research projects. Through research and archival
acquisitions the staff has developed expertise in
management of records associated with the computer
industry, professional organizations, and individuals. The
interaction between archives and historical research is a
crucial part of the philosophy of CBI: usable and
appropriate records are essential to historical research while
the knowledge gained through historical investigation is
essential to the development of archival collection
strategies.
HISTORICAL RESEARCH
Like the computer industry itself, the discipline of the
history of computing is relatively young. Consequently, our
knowledge of many areas in the history of computing is
incomplete. Since the late 1970s, members of CBI's staff
have engaged in significant historical research related to
technical developments, industrial growth, technology
transfer, and the government's role in technological
change. CBI's staff, at times cooperating with colleagues at
other institutions, have produced several historical studies
which span the period from 1800 to the present.
Recently, CBI's primary effort in historical research was an
investigation of the computer activities of the Advanced
Research Projects Agency (ARPA). The resulting report,
summarizing four years' study of the Information Processing
Techniques Office (IPTO) of ARPA, incorporates computing
developments after 1960 into the framework for analysis of
the history of computing. IPTO provided substantial
research support for the development of computer science
and engineering from its founding in 1962 to the mid-
1980s. CBI's study is a history of IPTO's origins,
development and evolution, and research programs it
supported during this period; it includes an analysis of the
management of the office, the interactions of its staff with
the research and development community, and its military-
related mission. The influence of IPTO programs in
computer science and engineering is charted through case
studies of four significant developments: time-sharing,
networking, graphics, and selected areas of artificial
intelligence. More generally, the study investigates the
growth of computer science programs, various technical
developments in computing in the 1960s and 1970s, and
the pertinent interaction of government, academia, and
industry. The authors are revising the report for publication
by the Johns Hopkins University Press.
The Analytical Engine, Volume 1, Number 2, October 1993 Page 23
CBI staff has engaged in studies of the computer industry
through ongoing collection of information about
companies active in various areas of the computer industry.
This material helps to identify computer-related companies,
understand where they fit into the larger picture of the
computer industry, and see how the industry has changed
over time. One project currently underway, "Computers
and Commerce," considers the development of Engineering
Research Associates, Inc., the Eckert-Mauchly Computer
Corporation, and Remington Rand after it acquired each of
these companies. This study of the origins of the computer
industry shows various strategies for technical development
and the interplay with customers in the earliest days of the
industry.
One of CBI's new research projects is a history of women in
computing. The purpose of the project is to recover the
achievements of women in computing and analyze the
history of women's participation in the institutions of
computing. The project will report its results in scholarly
articles about women's roles and contributions.
CBI's new director, Dr. William Aspray, will take the Institute
in previously unexplored directions, including a new focus
on microcomputing. Initial activities will include recording
interviews for future research, investigating current sources
describing its origins and developments, and working with
the industry to heighten awareness of and interest in
preserving corporate and individual records. The Institute
will also strengthen its international focus.
ARCHIVAL COLLECTION
Given the importance of the computer to modern society,
its application and development remain relatively
undocumented. The CBI archival collection exists because
of the advocacy of individuals in business, academia, and
government. Without their interest in the preservation of
resources for the history of computing, little documentation
would be available for research at CBI and other archives.
CBI serves as a clearinghouse for information on all archival
collections relating to the history of computing. CBI
maintains information about other repositories' holdings,
and researchers have access to a file of finding aids on non-
CBI collections. The Research Libraries Information Network
and the University of Minnesota's LUMINA catalog describe
much of CBI's collection in summary form. LUMINA is
accessible through the Internet.
The Analytical Engine, Volume 1, Number 2, October 1993 Page 24
The primary components of the archival collection are:
RECORDS -- Collections of records at CBI document
computer organizations and businesses, computer industry
involvement in antitrust and patent litigation, and
individuals' records.
PUBLICATIONS -- CBI maintains a collection of printed
matter including: manuals for specific computers and
systems, product literature produced by computer
companies, publications related to market analysis in the
computer industry, and third-party surveys of computing
machinery. CBI holds certain serial publications that offer
unique perspectives on computers and computing, such as
early microcomputer periodicals, that other research
libraries have not retained.
ORAL HISTORY INTERVIEWS -- CBI holds a large collection of
oral history interviews relating to the history of computing.
PHOTOGRAPHS AND FILM -- The photograph collection
documents the computer and its use from 1946 through
the present. In addition, CBI has a collection of commercial
16mm film prints on computing, and videos on the history
of computing topics and conferences.
GENERAL REFERENCE MATERIALS -- CBI's non-circulating
library contains a reference collection of works on the
history of computing, a selection of books considered to be
classics in computing, and reference volumes supporting
research of primary materials held by CBI. Biographical,
company, and subject files, as well as files on the holdings
of other repositories, are also available.
ENCOURAGING RESEARCH AND INTEREST IN THE HISTORY
OF INFORMATION PROCESSING
CBI fosters research in, and writing about, the history of
information processing. CBI has offered pre-doctoral
fellowships in an effort to increase the number of active
participants in the history of computing. It currently offers
the Adelle and Erwin Tomash Fellowship in the History of
Information Processing, a graduate fellowship for pre-
doctoral study of the history of information processing.
Tomash Fellowships have supported historical studies of
magnetic recording, international networks, group decision
support systems, and a comparison of United States and
British computer industries.
An important part of CBI's work is the development of tools
to aid historical research, including oral history interviews,
The Analytical Engine, Volume 1, Number 2, October 1993 Page 25
biographical and company information files, and published
bibliographies and guides. Examples of published
bibliographies and guides are a selective chronology and
annotated bibliography of software sources; _Resources for
the History of Computing_ (the first comprehensive
research guide to archival material held by repositories in
the U.S. and Canada); _The High-Technology Company: A
Historical and Archival Guide_; and _Guide to the Oral
History Collection of the Charles Babbage Institute_. CBI
has also produced a _Reprint Series in the History of
Computing_, in sixteen volumes, which makes scarce
material in the history of information processing available
to a wider audience of researchers and other interested
people.
CBI encourages and facilitates information interchange
among people interested in the history of information
processing. Members of CBI's staff maintain a wide-
ranging correspondence and participate in many
professional activities that serve the historical and archival
communities. CBI's educational program includes teaching
in the University of Minnesota's Program in the History of
Science and Technology and the Program in Management
of Technology, sponsoring lectures relating to the history of
information processing, and making presentations about
both the history of information processing and CBI. Visitors,
both national and international, stay at CBI for varying
lengths of time conducting research and interacting with
the staff. CBI staff responds to hundreds of research
requests from diverse groups including participants,
historians, sociologists, archivists and records managers,
journalists, lawyers, hobbyists, and the general public. CBI
sponsors or helps to organize conferences and symposia.
These conferences include a technical documentation
appraisal workshop (1984), a conference for archivists and
historians to discuss the state of the history of computing
(1986), _Computing in the 21st Century: A Symposium on
Computing and Society, Past and Future_ (1986),
_Manchester Meetings on the History of Computing_
(1988, 1990). Staff members also participate in many other
conferences and symposia.
INFORMATION, USE, AND SUPPORT FOR CBI
The _CBI Newsletter_, published quarterly, contains current
information about CBI and the history of computing.
Through the _Newsletter_ the Institute informs the
community of work in the field, conferences, publications
of interest, and its own activities. It is available free of
charge to anyone who wishes to follow developments in
the history of information processing.
The Analytical Engine, Volume 1, Number 2, October 1993 Page 26
CBI's archival collection, at its facility in Minneapolis, is
open to all researchers. Prospective visitors should consult
the archival staff in advance to ensure that relevant
materials are available and open to research. The archives
staff also attends to the needs of researchers unable to visit
the Institute personally. Many requests do not need
extended research time and copied documents can be
mailed or faxed. CBI is experimenting with other
techniques of document delivery, such as Internet
transmission and interlibrary loan of oral history transcripts.
The CBI Friends program accommodates individuals who
would like to support our work directly. The Institute
encourages inquiries about donating pertinent records, and
values requests from individuals, organizations, and
businesses to assess the historical value of collected
information in all formats, including machine-readable.
CBI's collection is built cooperatively with other programs.
If another facility is a more appropriate repository for a
given set of records, CBI staff will work to match donor and
repository.
If you would like to receive our Newsletter, information
about our Friends program or other donation programs, or
any further information, contact:
Charles Babbage Institute
103 Walter Library
117 Pleasant Street SE
Minneapolis MN 55455
Telephone: 612 624-5050
Fax: 612 624-2841
Internet: cbi@vx.cis.umn.edu or
jeo@maroon.tc.umn.edu
-------------------------------------------------
PROGRAMMING THE 1401
-------------------------------------------------
Part 2: THE 1401 AND BEYOND
Leo Damarodas
Interviewed by Roger Louis Sinasohn
_They must have been expensive to run. You had all those
components, the air conditioning. The electricity...
Punched cards weren't cheap considering how many you
would need. Now, say you wrote a program, ran a test,
and found a bug in it, what did you do?_
Well, you could approach it in one of two ways. You could
go back to the source code, fix the bug in the source code,
The Analytical Engine, Volume 1, Number 2, October 1993 Page 27
recompile, which took time, get a new object deck out, and
test that. Or say that to fix the bug, you had to add
instructions to the program. You could use an instruction
called Branch-and-Store that would branch to a location,
and store the location of the next instruction -- the
instruction following the branch...
_So it was like calling a subroutine?_
Yeah. And you would have it branch into high memory, up
into a space the program wasn't using. You would write
your additional instruction...maybe what you wanted to do
was insert instructions between two existing instructions.
So the instruction that you wanted to insert code after
would become the first one at the location you were
branching to, then you would add your additional
instructions, then your return instruction, which would
bring you to the location after your branch. By doing that,
you could take the object deck that you already had, patch
it, and run the test again. You didn't have to wait for a
compile.
_So that just involved repunching one of the cards from the
middle?_
Right. What you could do with some card-punchers was
feed a card in and duplicate it. In other words, most card
machines could punch at a punching station and verify at a
reading station. You could take your card that you wanted
to duplicate, advance it to the reading station, which would
pull in a blank card behind it, then you would duplicate
column by column until you got to the column you wanted
to change, make whatever changes you had in mind, and
then dupe the rest of the card.
_And then just switch them?_
Yeah, put it in the place of the other card. If a keypunch
wasn't available, and you really wanted to work hard, the
lead operator had, just for fun, a manual card punch... you
could feed a card into the thing, set up which positions you
wanted to punch, pull a lever, move the card a column, set
up where the next punches go, pull a lever...
_Did the IBM 1401 use the ASCII system, or was it EBCDIC,
or did it have...?_
The memory locations were set up looked just like an 80
column card -- plus two more bits. So there was a bit that
represented zero through one, eleven and twelve, which
were the zone overpunches, and then there were what was
The Analytical Engine, Volume 1, Number 2, October 1993 Page 28
known as the record mark and the word mark. They were
two other memory... well, what we would consider bits.
They weren't called that, but memory looked like a punched
card with two additional positions. Each memory location
was like a column on a card. The addressing structure used
three positions to represent 1K. But then you had
overpunches, and I know the overpunches were used on
the left and the right... there's a combination of four
overpunches, so you can... Is five enough to get up to
sixteen? Yeah. If you had no overpunches, it would be
zero through a thousand. or zero through nine-nine-nine. I
can't remember exactly what the scheme was, but they
used the overpunches to make up the difference.
_Now, being a programmer on a 1401, in a typical day,
how much of your time was spent working directly with the
computer?_
That would depend on what state your project was in. If
you were in a coding stage, you wouldn't be near the
computer at all. See, now, when you're writing programs,
you can write part of it on the fly, because you're
interactive, and your compiler's so fast, and everything's so
easy; you can have access to the machine the whole time,
write small parts of that program, and recompile, and run
it. Well, you could do this with a 1401 if you had access to
the machine all day long. But where I was working with a
1410, there were eight programmers, two analysts, a lead
machine operator, and two shift operators. The two shift
operators were running production jobs on the machine all
day long. So the machine wasn't available to programmers
during regular hours, except sometimes by prior
arrangement, or maybe during a little slack space, when the
operators were waiting for data to arrive for a run. Then
you've got 8 programmers and only one programmer can
use the machine at a time. So what we wound up doing
was just about coding a whole system before we loaded it
on the machine for the first time. We didn't punch up our
own programs, either; we'd code them, they would go off
to keypunch, come back in card form, and then we would
come in at midnight and run our compiles. Or we could
leave it for the night operator to compile it until the
compiles were clean. You did a lot of desk checking.
_Desk checking?_
You would go over your code looking for syntactical errors,
because it took so long for a program to compile. You had
to spend time rereading your code, checking for syntax,
weeding out as many errors as you could yourself. You
couldn't spend a whole lot of time compiling and
The Analytical Engine, Volume 1, Number 2, October 1993 Page 29
recompiling, because the machine wasn't available. It
wasn't a resource of one machine sitting in a room out of
sight, and everybody's hooked into it, and using it. That
didn't even happen with the 360 and the 370; really, in my
experience, not until the mid-70's when the HP came out.
_Did you ever run into any non-business programming?
Was it possible to do games on the 1401?_
About the only things like that were... you could run
calendars with pictures of Snoopy or Santa Claus, do
banners. But other than that I don't remember any games,
until the 360. I'm not even sure there were games on the
360. But now that I think of it, there was one thing on the
1410 that was kind of like a game. This tremendous
amount of circuitry developed radiation of the type that the
radio could pick up. So we could get these programs that
didn't have any function, but if you loaded one and ran it,
took a radio and you set it up on top of the memory unit
and tuned it between stations, the radio would play a
song. It would be playing a song like on an organ or a
violin or something; the program would exercise the
memory circuits in a way that would generate radiation for
the radio to pick up and translate into music. There were a
whole series of programs that could play Happy Birthday,
or Jingle Bells, or a number of other songs.
_Is there anything about the way you worked, or anything
about the 1401, that you miss in the modern machines?_
Not a thing. (Laughs) Other than making that music. But I
don't miss the cards, I don't miss having to keypunch... you
know, write code on a piece of paper, and then sit down at
the keypunch and punch it myself, or have somebody else
translate it into punched cards, and loading the cards into
the machine. Dropping decks of punched cards and having
to sort them back into order. No, I don't miss any of that
stuff.
_When did you make the transition from batch to
interactive programming?_
I didn't really see any interactive programming until '78
when I started working on the HP [3000]. So it was just the
last 15 years. And actually, I started programming in '65
but I took about a four-year break from 1970
through....mid '74. I burned out. I wiped myself out.
_So what did you do in that interim period?_
Took a year off. And then I recapped tires. Once I got
The Analytical Engine, Volume 1, Number 2, October 1993 Page 30
sufficiently bored with that I said, I'm wasting my time
doing this, I'm going to try programming again. That was
'74, and I've been at it.... the longest break between jobs I
think has been about a month.
_So how do you keep going now, then? How do you avoid
burning out?_
I don't do it when I'm not at work. I burned out because I
was programming 24 hours a day, seven days a week,
whether I was at work or not, I was programming. I mean,
I was always thinking about work. I love to program. I love
to play with computers. But you can't do it all the time.
_So, since that break, you've been going nearly twenty
years, probably close to twenty-five years total, and you still
like it?_
Yes. I found my niche a long time ago, and I'm happy with
it. At one place, I was actually told to find myself another
job, another company to work for, because I didn't want to
go into management. I was offered the job of
programming manager, and I said no thanks. I even
avoided being a project leader whenever I could. I didn't
want to deal with managing people, be responsible for
their work, see that they got it done. That's not fun to me.
Programming's fun. I'm totally amazed that I make what I
make for doing what I do, that people are paying me to
have a good time.
_You burned out earlier because you were programming all
the time. Was that because of the non-interactive-ness of
the system then, as opposed to now, where if you're not
sitting in front of the computer, you're not really
programming?_
No, because when I came back into programming, it was
still primarily a batch environment. It was an IBM 370 then
and it was faster, it could handle a bigger workload. But it
was still the type of environment where you sat down and
did flowcharting and did your coding on paper. Compiles
had become fast enough that, instead of a big program
with multiple overlays....like a 60K program taking three
hours to compile, a 60K program [on the 370] might take a
minute and a half. I mean, now you can compile a 60K
program in seconds! But it was still the same technique of
doing programming. It was just that I learned how to put it
away. It's like when you're having a good time skiing, you
don't ski through dinner and ski while you're sleeping.
When you're at the ski resort and you're sitting at the bar,
you're not skiing anymore. And I had to learn how to do
The Analytical Engine, Volume 1, Number 2, October 1993 Page 31
that with programming. Okay, you're enjoying yourself, it's
time to stop and do something else, give yourself a chance
to rest. I mean, I was going into work on week-ends, I
would be sitting having dinner with my family, and I would
get up and go off into the living room, sit down, and start
writing code because the solution to a problem had
suddenly come into my head. I don't do that anymore. You
can't, and survive.
_What do you foresee for the future of the computer
industry?_
I've never been good at predicting that. That's the reason
I'm still an applications programmer.
_As technology gets better, and faster and smaller, what
excites you the most about the advances since the 1401,
and about the possibilities looking ahead?_
When I started programming, it all was done in a shop
environment. You went into an office and you sat down,
with a bunch of other people, because the machinery that
you worked with had to be in a specific place. You can
carry around today, in your briefcase, a computer that
outperforms an IBM 370. There's more power, more speed,
and you're carrying it in an eight, six, four-pound package.
And the stuff is going to get smaller. It has yet to reach any
size limit as far as circuitry is concerned. Computers haven't
reached the processor density or circuitry density of the
human brain or any animal brain. The only thing that's
going to stay about at its current size is the physical human
interface. I mean, there's no way you can get a screen too
much smaller and still have it intelligible to the human eye
-- if you're going to carry thousands of characters on it.
Keyboards can't get much smaller and still fit our fingers.
What'll get smaller is the circuitry and the storage. I
eventually see the disk drive going away. There's no reason
to have any mechanical devices, to have magnetic devices
with moving parts for storing information. With flash
memory, you can store information solid-state and not
need any batteries -- you set the information up inside the
chips and it stays there. As far as I'm concerned, it's magic.
But that stuff is going to keep on getting smaller.
Somebody someday might figure out how the gray matter
between our ears works, and start building circuitry that
works that way, and then maybe computer programmers
will be in trouble.
_One last question. The IBM 1401 that you started out with
was new at the dawn of the transistor. Now what about
the last vacuum tube?_
The Analytical Engine, Volume 1, Number 2, October 1993 Page 32
Oh, the one-eyed monster? That's gotta go. The LCD, or
some future version of it, has to replace the CRT eventually.
The CRT is so bulky, now that there's such an appetite for
bigger screens.... If you have a twenty-inch screen it
requires, I don't know, a foot and a half depth? That's a lot
of desk space, shipping space, automobile space. But an
LCD display is an inch thick, no matter how big it gets. So
the last vacuum tube will eventually disappear. Sooner
than later, I hope.
-------------------------------------------------
BOOK REVIEW
-------------------------------------------------
THE DREAM MACHINE
Jon Palfreman and Doron Swade
BBC Books, 1991
208 pp., 16.95
Reviewed by Kip Crosby
This book's subtitle, "Exploring the Computer Age," is
telling. Survey volumes about young sciences tend toward
adolescent awkwardness, and this one is no exception, but
at their best they also display the vigor and excitement that
derive from an honestly new subject. In its eager narrative,
majestic vistas, zigzag progress and breathless grabs for
overview, THE DREAM MACHINE is truly an exploration.
Later treatments will be smoother and more settled but a
lot less immediate.
The ground plan here is ambitious: A reasonably rigorous
history of computing from the abacus to artificial
intelligence and beyond. The subject threatens to sprawl,
as always, but is well contained here by the focus implicit in
the title -- the _computing machine_ in its broad historical
and philosophical aspect. Of the book's 208 pages, over
150 treat the century bracketed by Hollerith's tabulation
experiments in the late 1880s and the great AT&T system
crash of 1989. A more descriptive subtitle might have been
"The Computer and its Development."
To their credit, the authors recognize that inventors are as
fascinating as inventions, and give us a steady parade of
portraits -- not only of true giants like Hollerith, Babbage,
von Neumann, Eckert, Mauchly, Minsky and Wozniak, but
lesser-known (and not less interesting) figures such as
Maurice Wilkes, Tommy Flowers and Doug Engelbart. In
this very European book, there's a much more thorough
treatment of Alan Turing's life and work than there might
be in an American work on the same subject; Konrad Zuse
The Analytical Engine, Volume 1, Number 2, October 1993 Page 33
too is given the space he deserves. As a survey history, THE
DREAM MACHINE definitely passes the test of inclusiveness
-- even if it's odd to find no mention of John Atanasoff, or
to see the developers of VisiCalc described as "a Harvard
Business School student and his friend" both left nameless.
The book is less sure in its sense of proportion and, for
every really thorough treatment of a subject, too many
others are half-column sound bites. Still, there's nothing
wrong with a book that leaves you hungry for more.
(Incidentally, a lot of interesting material is buried in the
notes at the end.)
Any book derived from a TV mini-series is a chancy
proposition, but THE DREAM MACHINE exploits most of the
inherent advantage while it avoids all but a few of the
pitfalls. The copious photographs came from a really good
archive. The research is careful. The writing and pacing are
in the BBC's best style -- a big vocabulary and short, well-
knitted sentences -- making this book an engrossing
straight-through read without a hint of condescension. It's
a refreshing collection of words and pictures that, finally,
conveys more than the hours of TV it descended from.
Unfortunately, poor design almost wrecks the good
impression made by the research and writing. The coffee-
table format tries to match the impressiveness of the parent
series, but only adds gratuitous blank space and curious
typography that threatens to swamp a valiant little book.
The aggressively postmodern graphics are distracting at
best -- this reviewer likes his page layouts constructed, not
deconstructed. Sometimes, as in the discussion of artificial
intelligence, the artwork is so intrusive that it makes the
book literally hard to read. And the relationships of
photographs and their captions are arbitrary, to put it
mildly.
Nonetheless, THE DREAM MACHINE manages to be
comprehensive, intriguing and satisfying. It's accessible to
the interested but "nontechnical" reader, with many
amusing or startling facts included to make up for
occasional lack of depth. A real survey of the field wants a
thicker book, but as a quick, well-illustrated guided tour,
THE DREAM MACHINE is definitely worth your time and
money.
The Analytical Engine, Volume 1, Number 2, October 1993 Page 34
-------------------------------------------------
ACQUISITIONS
-------------------------------------------------
IMSAI 8080
Funds from subscriptions to the ANALYTICAL ENGINE were
used to purchase a pristine, well-equipped IMSAI 8080
from Winston Gayler of Cupertino, CA.
Sometimes called the first micro produced in California --
an honor that actually belongs to the Intel Intellec series --
the IMSAI is secure in computer history as the world's first
micro clone. In 1975 the Altair 8800, made by MITS in
Albuquerque, NM, fired the imaginations of electronic
hobbyists all over the country; but, bowled over by
demand, MITS found it almost impossible to keep up with
orders. The Altair was also difficult to build and finicky in
its operation.
Under the leadership of Bill Millard -- later the founder of
ComputerLand -- IMS Associates in San Leandro, CA, moved
aggressively to fill the gap. Engineers Joseph Killian and
Bruce Van Natta produced a handsome microcomputer
based on the Intel 8080 CPU and the "Altair bus" (later
called the "S-100 bus") but with cleaner design and more
robust construction than the original Altair. The first IMSAI
8080 kits were shipped from the San Leandro factory on
December 16, 1975; the IMSAI, like many later clones, went
on to outsell the machine it had been inspired by.
CHAC's new IMSAI was purchased from Ithaca Audio in
Ithaca, NY, in March 1978. Shortly thereafter, Gayler
equipped it with a Bytesaver EPROM board and a Godbout
Econoram II board. Fifteen years later, he shipped it to
CHAC's El Cerrito office and included a full complement of
accessories, program listings, all the original paperwork,
IMSAI and Intel manuals, IMSAI and Byte Shop catalogs,
complete handwritten instructions, and even full-page
IMSAI ads clipped from contemporary electronics
magazines! As you might expect, this beauty is in literally
flawless condition; and when we set it up on a worktable
and plugged it into a UPS, it booted at the first flip of the
red RUN switch. The dizzying elation was like a ride in a
time machine.
Our micro collection has a new crown jewel. Thanks to Win
Gayler for years of fanatical care, to Tom Ellis for
knowledgeable unpack and setup, and to our subscribers --
of course -- for making the purchase possible.
The Analytical Engine, Volume 1, Number 2, October 1993 Page 35
[For the story of IMSAI at full length, interested readers are
referred to:
_Once Upon a Time in ComputerLand_
Jonathan Littman
Price Stern Sloan, 1987. ]
-------------------------------------------------
LETTERS
-------------------------------------------------
IBM 1401: _Amplifications and Corrections_
HISTORICAL ACCURACY
> In the interest of accuracy, I hope I am not the only one
left on the planet who remembers that the IBM 1401 was
*NOT* a vacuum tube machine. The 1401 was all solid
state with core memory. It was very compact, built in
modular bays and would probably be considered the first
"departmental" computer because of its reasonably compact
size and modest power and cooling requirements.
I remember them being rolled into regular office
environments, with good air conditioning of course, and
fired up and operated, without false floors and special
cooling and power wiring.
Perhaps Leo is referring to the IBM 650 which was a small
vacuum tube computer, but it had a drum memory, or the
IBM 604 which was really a calculator in the sense that
programming was done on a plug board like the tab
machines, but it was all vacuum tubes including whatever
memory it had.
The rest of his reminiscence brought back fond memories
of my first programming work on the same machine in
1963. I wish I would have kept all of the free
documentation about the machine that IBM gave us during
class. It would make for a much more accurate discussion.
-- from Dean Billing, UC Davis, via Internet
[Blame that one on a rotten desk check! The closest source
for correct information on this point, Cortada's _Historical
Dictionary of Data Processing_, was within arm's reach and
yet not consulted. We will pay closer attention to our verify
pass from now on -- and we're very grateful to have an
audience that can be relied on to trap errors. -- Editors ]
***********
The Analytical Engine, Volume 1, Number 2, October 1993 Page 36
1401 AS SLAVE PROCESSOR
> The first 3 cards of the program deck were a "bootstrap"
that set up the machine so it would load the rest of the
program cards from the deck.
A large utility where I worked used them for a substantial
amount of processing of property and cost information.
When files or processing were significantly larger, a 7074
was used to process. The 7074 was also used for billing,
and had "slave" 1401's to read the output tapes and print
bills. Billing input was from paper tape! and keyed-in data.
-- from Harriet L. Coleman via Internet
***********
1401: RECOLLECTIONS AND CORRECTIONS
(lines with double pointers are from Damarodas part 1)
>> all the data. You couldn't go back and forth
between overlays because the programs had to run from
card decks.
> 1401s often had tape drives on which programs or data
could be stored. While their primary use was business DP,
the were also frequently used as off-line I/O processors for
larger machines (putting jobs on tape for batch input and
printing output).
>> Data resided on disk, but not programs.
> Again, anything could be on disk. Disk drives were rare -
- I only recall using one. I think it was called the 1405 --
wrote a file sort using it. Disk drives became more common
on the 1440, which followed the 1401.
>> _What happened if you had a deck that's data to be
input, and you have a deck that's a program -- what
happens if you mix them up? That is, you put the data in as
if it were a program?_
> You put the data deck, if any, after the program deck. If
they were mixed up, it would blow up.
>> _So a small program might fit on a single card?_
> None that did meaningful work -- most instructions
required 1 or 2 addresses. Other instructions had an
optional op-code modifier. The instructions were variable
length, the start of each being indicated by a seventh-bit
The Analytical Engine, Volume 1, Number 2, October 1993 Page 37
(the "wordmark") being set. Data fields were also delimited
with word marks. Addresses could also be modified by
index registers, but there was no indirect addressing. (That
came on the 1410, the 1401's big brother, which also had
asynchronous channels, interrupts, and more memory). [J.
Philip Miller's comment: "I sure wrote a lot of 'single card'
programs. What was even better was that there were
toggles and push buttons on the console and you could
enter your programs without a card reader at all!" ]
>> Only about a year, and I think the machine I worked
on was actually a 1410. 1410's were the ones that had disk
drives.
> He may be thinking of the 1440 here -- they were much
more common than 1410s, and had disk drives....I worked
on an experimental system where we had a 7094 and 1410
sharing the same 1301 [Winchester disk subsystem,] and
working with engineers from both [IBM Data Processing
and Data Systems] divisions to see what would happen
under various conditions was a challenge. In our system,
the 1410 did I/O for the 94, feeding jobs to IBSYS -- the
1410 was multiprogrammed and IBSYS took its input from
the 1301 and left its output there. IBM never made a
product of the system, but it was a lot quicker and more
flexible than preparing tapes and printing with a 1401,
which was the usual way things were done at the time.
....While I am at it -- there were other tools -- one was RPG,
and another was called FARGO; a quick way to convert a
unit record application to the 1401 -- describe the card
layout, report layout, totals, etc., and FARGO did the rest. (I
think the A stood for "automatic" -- 1401 Automatic Report
Generator -- but what about the "O")?
-- from Laurence I. Press, via Internet
***********
MORE ON AUTOCODER
> Autocoder was an assembler, not "kind of" an assembler.
Its big advance over the standard assembler was that it was
free form and, at least in later years [after 1960,] also
included macros. Thus it was, for those days, a "super
assembler" when compared to the standard, fixed field
assembler [SPS or _Symbolic Programming System_]
-- from J. Philip Miller, via Internet
***********
The Analytical Engine, Volume 1, Number 2, October 1993 Page 38
1401 FORTRAN COMPILER
> The 1401 FORTRAN Compiler was an "in situ" system
which used 64 (yes, 64!!!) passes to compile the program.
The trick was that someone (and I don't know who, I would
love to see the proof sometime) worked out that the object
code for a compiled program was not greater than that for
the source code (this was the early 1960's, remember!). So
they replaced the source code in core with the object code!
Each pass (pretty well) dealt with one aspect of the
language. The details are in the appendix to my first
edition of "The Anatomy of a Compiler", 1967.
-- from John A. N. Lee, via Internet
***********
MORE GLITCHES
> There were indeed more than a few errors in that [July]
newsletter!
1) The IBM 1401 was not a vacuum tube machine! It was
transistorized.
[We're not likely to forget _that_ again.... -- Editors ]
2) Pong was not a computer game! It was a video game
implemented with TTL logic, with no computer.
3) Spacewar wasn't a video game! Video encoding of data
was not used to paint the image on the face of the CRT.
Instead, the software drove a pair of ADC's to handle
deflection in the X and Y directions, and the software
painted each dot on the screen. The resolution was far
better than standard video, but the number of dots that
could be painted without causing flicker was limited.
(By the way, I have played Spacewar myself on a DDP 224
computer at the University of Michigan -- that machine was
a nice 24-bit minicomputer, and their version of Spacewar
used two joysticks on the graphics display.)
In any case, the folks at CHAC clearly have their hearts in
the right place, and the kinds of errors [you] made in [you]r
newsletter only serve to prove the point of [you]r opening
editorial! History is indeed being lost and forgotten at an
impressive rate!
-- from Doug Jones, via Internet
The Analytical Engine, Volume 1, Number 2, October 1993 Page 39
[From the strict technical standpoint, Pong is absolutely not
a computer game. In our original statement we assessed it
as collectors rather than as engineers; most collectors, it
seems, would find that distinction less critical. And we're
still astounded that there are only nine left.
Your comment about the PDP-1's display logic raises
another equally salient point. If the rate of loss of _history_
is impressive, what about the potential rate of loss of
_working knowledge_? As the Babbage Institute has
correctly maintained for years, there's a lot of scope here
for recorded interviews. -- Editors ]
***********
1401s I HAVE KNOWN
> I had a summer job operating & programming 1401 and
7070 in 1962 and '63. The 1401 had tape, card
reader/punch, and printer. It was used for some card
manipulation stuff, but mostly as card-to-tape and tape-to-
printer for the 7070. Our machine had a minimum
configuration, 1400 bytes of core.
The 7070 and 1401 both had assemblers called Autocoder.
Our teeny 1401, though, was too small to use Autocoder,
so we programmed it in SPS, the Symbolic Programming
System, a much less fancy assembler, fixed card fields, no
macros. You loaded the reader with the assembler deck,
your source, and pass 2 of the assembler, and hit LOAD.
SPS read in, read your program & punched an intermediate
file, and stopped. You took the intermediate file from the
output hopper and put it behind pass 2, and hit START to
complete assembly.
The next summer I got a job at a company that had two BIG
1401s, 12K each. On these we could run Autocoder, and
use a primitive debugger called Autotest, which let you
patch programs, compare core to the object deck, and even
set breakpoints. These machines did payroll, wrote
dividend checks, stuff like that. Such applications were
written in 1401 COBOL. I was an Autocoder jock though,
had my own private library of tape error recovery code,
merged in the center pocket, hot stuff.
A few years later at MIT Project MAC I was able to use my
1401 knowledge; MAC had a 4K 1401 used as reader/print
for the 7094, and we had a need to print in mixed case. We
designed a solution which produced 7094 tapes in ASCII
and printed them using a special RPQ on the 1401 which
used the word marks as a 7th bit in the print band.
Squeezing the printer management & character translation
The Analytical Engine, Volume 1, Number 2, October 1993 Page 40
into 4K was tough; I had constants in between the index
registers.
Many 1401 programmers learned the machine by going to
IBM school. I didn't, but I have here an exam from the Basic
1401 Programming course: Part 1 is on general stuff, parts
of the machine, etc.; part 2 covers flow charting, bits in the
word; part 3 asks what happens when specific instructions
are executed. All multiple choice.
The main thing to remember when programming the 1401
was that IF THE B-FIELD IS LONGER THAN THE A-FIELD, AN
UNEQUAL COMPARE WILL RESULT (if you were lucky
enough to have a 1401 with the arithmetic compare
function.) Make this your mantra.
-- from Tom Van Vleck, via Internet
***********
A COMMON BOND: _Welcomes for our Association_
FROM THE SMITHSONIAN INSTITUTION
> I am glad that you are starting an organization devoted
to computer history on the West Coast. Right now there is
activity at the Smithsonian, in Boston, in Bozeman, MT,
Minneapolis, MN, and of course the _Annals_, edited out of
Virginia. But nothing, until you came along, in California. I
was very disappointed to hear that the Silicon Valley
Information Center at the San Jose Public Library was closed
due to lack of funding -- as was, incredibly, the Foothills
Museum of Electronics. Good luck and feel free to use the
History of Computing Bitnet List as a forum whenever you
choose.
P.S.: The Smithsonian is trying hard to preserve artifacts.
We have a Xerox Alto, an Apple I, an Altair & other S-100
PCs, a CRAY-1, a PDP-8, as well as lots of stuff from the
earlier days -- going back to the 17th Century but including
the ENIAC, UNIVAC, and Harvard Mark I. Be on the lookout
for a book by myself and another Smithsonian curator
about our holdings.
-- from Paul Ceruzzi, Smithsonian Institution, via Internet
[Thank you very much for your encouragement and
cooperation, which gives a big boost to (at this point) a
very small organization.
The idea of "an organization devoted to computer history
on the West Coast" is proving popular to an extent that we
The Analytical Engine, Volume 1, Number 2, October 1993 Page 41
also find very gratifying. It's early days yet, but the
ANALYTICAL ENGINE currently has more paying subscribers
_outside_ than _inside_ California -- which is startling and
certainly not what we expected. The feeling that we have a
national base, albeit a tiny one, is creating a lot of
enthusiasm among us.
It's important to note that the foundation that underwrote
the Foothills Museum is still very much alive, so we
might hope for some cooperation there.
Certainly we're "on the lookout" for your book, and good
luck with it....especially if you're still winding up the
writing. -- Editors ]
***********
FROM THE BABBAGE INSTITUTE
> We read with great interest your recent newsletter,
_The Analytical Engine._ Your enthusiasm for the history of
computing is obvious and encouraging to those of us who
have been working in this field....
Fifteen years ago a group of people gathered with
concerns, and plans, remarkably similar to yours. They
formed the Charles Babbage Institute and the Charles
Babbage Foundation. For the past fifteen years CBI has
been working to preserve and understand the history of
computing and information processing....
CBI has always recognized that the field is too big for the
small number of repositories collecting records. The
archivist keeps in close contact with other professionals in
the field, and encourages other archivists to collect in this
area.... It is great to see people actively interested in the
history of computing but none of us need to work in
isolation. By cooperation, we can all be part of an active
movement towards preserving and understanding the
history of computing.
-- from Judy E. O'Neill, Charles Babbage Institute
[excerpted]
[Thank you for your kind letter and elaborate package of
materials. The CBI's resource listings make it clear that your
Institute has done formidable work especially in collecting
oral history, documentation, and the personal papers of
noted scientists and industry executives. Truly, we are not
all "working alone," and in great measure we have the CBI
to thank for that.
The Analytical Engine, Volume 1, Number 2, October 1993 Page 42
Thank you also for pointing out that the quarterly _CBI
Newsletter_ is available free of charge. We encourage
ENGINE readers to request it from the Institute at the
address on page 59. ]
***********
WHAT EVER BECAME OF THE OTRONA?
> It has always amazed me that nothing like CHAC existed
before. In fact, I've been wandering the Net for....months
now trying to find a newsgroup for defunct computers in
general or....home computers in particular.
As one schooled in history, I was quite disappointed to see
so much history in software and hardware, primarily, being
thrown out. In fact, when Computer Shopper used to carry
"classic" computer articles, I wrote to them explaining that
if they were willing to foot the bill, I would write a series
of "what-ever-became-of-?" articles. I've always wondered,
for example, about the development history of computers
like Mattel's Aquarius and Exidy's Sorcerer. Some of these
companies (and computers) flashed across the computing
heavens like a meteor. I and, I'm sure, others would like to
hear their stories. I hope CHAC and the ANALYTICAL
ENGINE can pursue something like this.
I will be forwarding my subscription in the next week or so.
Please consider me a member of your worthy group.
-- from Allan Hamill, via Internet
[_You_ of all people will be delighted to know that those
Computer Shopper articles have been expanded, spliced,
smoothed out and reformatted into:
_Stan Veit's History of the Personal Computer_
304 pp., paper, WorldComm, 1992, $19.95
available from: Computer Museum, Boston, address on
page 59.
As for "pursuing something like" stories of dimly
remembered hardware, you bet! No computer too small or
too large. (Refer to the "Desperate Plea for Storage"
on page 10.) And thanks for the sub. -- Editors ]
***********
STARTING FROM SCRATCH
> I just read a copy of the ANALYTICAL ENGINE, which
some kind soul e-mailed me, and ....your philosophy about
the value of historic technology is right in line with my
The Analytical Engine, Volume 1, Number 2, October 1993 Page 43
own.... I am a sort of amateur computer historian who is
trying to collect enough info to start thinking about writing
a comprehensive work on computer history. Unfortunately,
[since] the subject area is so vast, getting the kind of details
I want (deep-down specifics and info) will take a lot of
time. Anyway, thanks again, and let me know what is
available!
-- from Don Congdon, via DELPHI
[Don, if you manage to assemble a "comprehensive work on
computer history," we'll be first in line to buy a copy -- or a
set! Anybody thinking comprehensively about computer
history, meanwhile, should go in search of
_Historical Dictionary of Data Processing_
3 volumes: TECHNOLOGY, ORGANIZATIONS, BIOGRAPHIES
James Cortada
Greenwood Press, Westport, CT
Unfortunately these are expensive at US$265 for all three,
but they're the closest thing to a complete treatment that
we've uncovered so far. Thanks for the good word. --
Editors ]
***********
GREETINGS FROM IOWA
> How about forming a Computer History Association of
Iowa, sister organization to CHAC? I'm interested in these
historic systems and would like to learn more. A local
organization would be great, so we can get together and
socialize. Having a larger geographic distribution will make
things more interesting too. That is, unless there's some
local organization that fits the bill that I'm missing.
-- from Jeffery C. Ollie, University of Iowa, via Internet
[Well, go for it! We look forward to encouraging, assisting
and collaborating with CHA's in every state in the Union.
_Anybody_ who wants to start a CHA in their state, please,
write or post to us while the idea is still a lit triode above
your head. Our hard-won knowledge of protocols,
processes and priorities can save you major agony. --
Editors ]
***********
The Analytical Engine, Volume 1, Number 2, October 1993 Page 44
MUSEUM PLANS IN THE NORTHWEST
> I am an avid collector of old iron and interested in
computer history. I would like (eventually) to form a group
like CHAC and a museum in the Northwest. I know of
several others in this area who are collecting larger or
smaller systems (I collect large ones) and who might be
interested. In the meantime, I would like to join CHAC and
offer what help I can....
-- from Paul Pierce via Internet
[Our hat is off to anyone who "collects large ones" while
we're still frantic over what to do with our small ones! If
you decide to form a CHA, do get in touch with us first for
strategic discussion; meanwhile, if by "Northwest" you
mean Washington/Oregon, we suggest you contact David
McGlone at the address on page 59. -- Editors ]
***********
"THE JOB NEEDS TO BE DONE"
....It's clear that [CHAC's] goals are very much in keeping
with the goals of many of the readers who follow these
newsgroups.
As near as I can figure, they're the first general membership
association devoted to historic preservation of computers.
Thus, they may be able to provide the kind of hacker-
centered orientation that is lacking in [some other
institutions]....
These people are doing the right thing, with essentially the
same goals that led to the formation of _alt.sys.pdp8_, but
with a broader charter and a more formal organization.
They clearly have a regional focus, but at the same time, the
job they're talking about needs to be done nationally and
internationally.
I feel that we preservationists should support them actively,
either by joining their organization (particularly, those of us
in the Bay Area), or by referring California hardware and
documentation rescue work to them. They've picked up a
significant membership outside of California, but my long-
term hope is that we can get similar local organizations
running on the east coast and in the midwest. We've got
the critical mass in both places, but here in the midwest,
we may not have the critical density....
-- from Doug Jones, via Internet
The Analytical Engine, Volume 1, Number 2, October 1993 Page 45
[Doug,
Thank you for this glowing tribute! and, beyond that, for all
the critical support offered to us through _alt.sys.pdp8_.
We wouldn't change a word of what you've written (why
would we need to?) but just a couple of comments:
1) If indeed we are "the first general membership
association devoted to historic preservation of computers,"
we're not surprised. We started it because _we also_
couldn't find an existing one. But it's our hope, too, that
someday soon there'll be "similar local organizations" in
other parts of the country. That would ultimately provide
the strong, broad grassroots base that would facilitate the
organization of a true Computer History Association of
America.
Now, before we started the CHAC in April, we toyed with
the notion of _founding_ the CHA of America. After the
CHAC's first four months, we're glad we didn't try. First of
all, we have to get _some_ sleep. Secondly, even with our
avowedly strict focus on California, we've had (welcome!)
correspondence not only from (e. g.) Iowa, Pennsylvania,
Massachusetts, Florida.... but (e. g.) Finland, Denmark,
Sweden, Germany, the UK, and Saudi Arabia. The Internet
is astounding, which is a separate topic, but none the less
true. And third, the hardware....! (Details on page 34.)
2) I'm not sure we're "hacker-centered" but we're hacker-
propelled. To be "hacker-centered" would, I think, risk
being exclusive in a negative sense and tend to push aside
certain real pillars of computer history in California; for
instance, the Bank of America's pioneering of electronic
check processing with ERMA, which wasn't especially
hackish but it sure is part of what we're about! On the
other hand, it's true that a lot of California's (and especially
Silicon Valley's) computer history is inseparable from a
certain....effervescent ad-hockery, ebullience, zaniness. And
we'd like to keep that as a flavor.
3) "the job they're talking about needs to be done
nationally and internationally." Absolutely true! At the
same time it's important to know that it _is_ being
_begun_, nationally and internationally. In our brief months
we've heard from many fine people and organizations....
and one of the most important things we've accomplished
is to get some of _them_ talking _to each other_. The work
before us is big enough that, as we confront it, we can be
bolstered by the knowledge that we're not alone in this. It
makes for a tremendous sense of friendship and
community.
The Analytical Engine, Volume 1, Number 2, October 1993 Page 46
4) Finally, I take your point about "critical mass and critical
density." If you want to know about critical mass, just
count the interesting micros we have stacked up in boxes!
But I think any doubts about critical density of interest are
alleviated, if not wiped out, by the speed and rate of
diffusion of net.communication. (That, incidentally, is why
we're currently composing an RFD of a newsgroup.)
Computer history _is and is not_ a local pastime -- or, so to
speak, "Talk locally, post globally." We have before us the
means to overcome isolation completely.
5) Yes, we will try to take on rescue work. Our current
capacity for it is very limited, but we at least want to know
about it.
6) We need:
_Money_ because we're getting bigger faster than we ever
thought we would. Right now, and for the foreseeable
future, CHAC is all-volunteer. But by the time we're
working on some of what we outlined in the July ENGINE
(like the museum,) we will be facing significant
administrative expense and at least part-time salaries.
_Space_ (storage) because people are offering us hardware
that we don't want to see junked.
_Members_, first, because without members we're nothin'.
CHAC is _about_ computers, but also _about_ the people
who create them, and _by and for_ the people who work
with them and respect them. Second, because only with a
substantial membership can we confront corporations and
ask them for real support. Fundraising, too, is about
people.
A couple of days ago we got net.mail from someone that
began "Is this legit? If so I think it's wonderful!" Well, it's
wonderful. We know that already. We know that it's real.
We know, above all, that it's needed. It can also be "legit" if
-- and _only_ if -- enough people are willing to join us in
what we're trying to do. Thanks again. -- Editors ]
***********
CONSIDERATIONS OF HISTORY AND RELIABILITY
> I truly believe in the intended cause the CHAC people are
attempting, and I really hope they succeed, but
unfortunately, they seem to be victims of their own
predictions. In order for such an organization to succeed, it
must *flawlessly* pursue its subject matter. Towards that
end, I would suggest that [USENET] groups such as
The Analytical Engine, Volume 1, Number 2, October 1993 Page 47
_alt.sys.pdp8_ act as super-proof-readers of such material,
i.e., post draft copies here first and allow us pedantic pdp-
8'ers and other interested hanger-outers to tear apart their
articles for technical accuracy, all in the interest of upping
the quality of the product, etc.
As it stands now, it's a little too revisional for me, although
admittedly only a little. Forgive me for saying it, but from
my vantage point, someone who happened upon a 1401 in
1965 ain't a pioneer! This is only marginally before my
time, and I already knew enough to know the mistakes
pointed out elsewhere, and I consider myself "second
generation", not a true pioneer in the industry, etc.
....If those who are committed to wanting to preserve
history can't quite get it together, we can't possibly
succeed! We must help these folks get their act together
completely. All of us have a part to play to get it correct,
before the entire history of computing is personally
attributed to Bill Gates, now sometimes erroneously
attributed to as the author of the original BASIC among
other things!
-- from Charles Lasner, via Internet
[ We're delighted to have super-proofers -- that's a lot of
why we're on USENET to begin with. Tear away! (Not that
people haven't.) On the other hand, I will concede (being
one) that editors are human, and no less fallible in that
capacity than in any other; flawless pursuit of subject
matter is perennially desired and less often attained. If we
publish articles that need no correction, great. If our
articles go out to readers and somebody finds a bug, then,
to publish the article _and_ the correction still does a
service to the community and enriches the public record.
This issue of the ENGINE demonstrates that we do publish
corrections, even at a length that placates the most
pedantic proofer.
I don't quite get the intent of the word 'revisional', but
certainly "someone who happened upon a 1401 in 1965
ain't a pioneer." IBM announced the 1401 in October 1959
and, in fact, projected in an internal report that the end of
the useful life of the series would occur in 1965. But while
pioneering work is important to CHAC, and preserving the
record of it is an important part of our mandate, it ain't the
whole story, either. If somebody can make an interesting,
illuminating point about computer use in California, at the
appropriate length, then it doesn't matter whether they
were the first to gain experience with a system or (as might
be equally intriguing) the last.
The Analytical Engine, Volume 1, Number 2, October 1993 Page 48
As for Mister Gates, I wouldn't worry about him getting
_all_ the credit. He was born in the year that the first IBM
704 was delivered, so vacuum-tube computing is probably
safe from the attribution.... ]
***********
RESOURCE FOR THOSE WORKING WITH CP/M
I....hope to found a museum of CP/M and Z-System
computers, and to that end I have been collecting the
computers, software, manuals, newsletters, magazines, etc.
I am still compiling an inventory of....100-200 computers,
and many file cabinets full of diskettes and printed
material.
From time to time, no doubt, you get calls or letters from
people who have CP/M computers but do not have the
manuals, software, or both. If you cannot help them, I
hope you will refer them to me. If I cannot help them, I
probably know someone who can.
-- from David A. J. McGlone [excerpted]
[Mr. McGlone, by way of being a nearly universal resource
for the CP/M and ZCPR3 communities, is a licensed
distributor of CP/M and of various commercial and public-
domain software. He also offers repro documentation, a
disk-copying service, and a fine newsletter, _The Z-Letter_,
eminently worth reading at $18 for 12 issues (2 years).
"Finally," he says, "I am always looking for boot disks,
since....CP/M helps no one if I do not have the right boot
disk for a particular machine." Collectors and restorers owe
it to themselves to contact Mr. McGlone at the address on
page 59. -- Editors ]
***********
FACE DOWN, 9-EDGE FIRST
Save those old punch cards from the dump! Punch cards
are a thing of the past, thank goodness, but that doesn't
mean we should discard every last one. In their heyday, use
of custom-printed cards with corporate or institutional
logos was a point of pride for many organizations. As an
example, prior to the Reagan-era substitution of new and
somewhat garishly patriotic forms, the US monogram was
prominently used as an elegant repeated background on
the cardstock on which US government checks (such as tax
refunds) were printed. These checks were printed on
cardstock because they were punched cards, suitable for
automated processing in the 1900-to-1970 style of
automation. I dearly want a blank punched card in that
format to add to my collection.
The Analytical Engine, Volume 1, Number 2, October 1993 Page 49
I have an extensive stock of duplicates. If you have old
unused cards sitting around, I'll gladly trade! It's not stamp
collecting, cards are bigger and fewer people collect them,
but it can be interesting. My standard offer is simple: Mail
me a stack of cards that you have a surplus of, and if you
include an addressed envelope, I'll stuff it with an equal
number of equal quality cards from my trading stock and
pay return postage. Unless you're an established collector,
there's little chance that you'll get any duplicates this way,
and you'll end up with more variety than you started with!
-- from Doug Jones, 816 Park Road, Iowa City, IA 52246,
USA, via Internet
[But no lace cards, please, they jam the mail sorters. --
Editors ]
***********
QUESTIONS OF POLICY
> I have seen the first issue of the Analytical Engine and a
question naturally arises. The Charles Babbage Institute has
existed for some years now and it archives manuals, and
other computer documents; also, the Computer Museum
(Boston) preserves hardware and documents; the Annals of
the History of Computing publishes articles in this area. So
the question is why are you launching your project when
these other possibilities exist?
-- from Lloyd Fosdick, University of Colorado, via Internet
[Thank you for raising that point. In our view, computing is
such a formidable field -- and currently has such
momentum -- that it's natural to consider the establishment
of _multiple_ computer museums and archives, for the sake
of regional emphasis. There are, as comparable examples,
multiple art and science museums, multiple specialized
libraries for other topics, and that's come to be expected.
Computing will sustain a similar level of interest.
The Computer Museum in Boston, for example, is a truly fine
institution and does a particularly good job of tracing
computer development at MIT, along Route 128 (the
"Silicon Ring") and at East Coast establishments further
afield, like IBM. TCM has a nicely presented chunk of
Whirlwind -- one of the most important of the early digital
computers or the earliest of the important ditto, take your
pick -- which is entirely proper, since it was developed
across the river. It's similarly proper for the Smithsonian to
have ENIAC, which was designed and built at the Moore
School of Engineering in Pennsylvania.
The Analytical Engine, Volume 1, Number 2, October 1993 Page 50
But at the moment, there's no such institution in and for
California. That's the rationale, or part of it, for CHAC.
Certainly Silicon Valley, in order to tell the story of what
happened there since Hewlett and Packard built their first
oscillator in 1938, could endow and support an institution
comparable to TCM! And while we're not taking that
on singlehanded, we _are_ pushing for it, making spikes,
acting as a clearinghouse for expressions of interest.
As for archiving: Having archives in dispersed locations
makes sense. The materials are more accessible, and they're
safer, especially if a degree of redundancy is built in. On-
line databases have reduced the need for physical
archiving, but they won't eliminate it in the foreseeable
future.
The final assessment, probably, is that while we as a nation
and society might someday come to the point of having
"enough" computer museums, archives, and historical
periodicals, we aren't _nearly_ to that point yet. We hope
for success for CHAC, but we wish it just as fervently to our
colleagues at TCM, at the Smithsonian, at Apple and
Intel, at the ACM, and at many other institutions all over
the nation. Plenty of room for us all. -- Editors ]
***********
ATTRIBUTION OF ELECTRONIC MAIL
> Recently there was a discussion on this mailing list
regarding the use of messages posted to a
newsgroup/bulletin board etc. in a scholarly publication.
....The messages are quoted directly....but no attributing of
the messages to authors appears.
-- from Dr. Rajeev Pandey, via Internet
[Thank you for raising this point and for drawing attention
to a presently turbulent and indistinct border -- the
boundary between net.traffic and the print media.
Many publications, including PC Magazine, WIRED, and
others, are reprinting Internet messages as letters, and they
pursue several different policies in this regard. WIRED in
particular prints the Internet address of the respondent,
unless they are asked not to, in which case they run
"Internet address withheld" or "unlisted Internet address."
Withholding of these addresses seems to be more common
now than formerly.
The Analytical Engine, Volume 1, Number 2, October 1993 Page 51
The ANALYTICAL ENGINE will reproduce Internet messages
in its Letters column according to the following proposed
policy:
1. We will ask all writers, in our net.replies, for permission
to reproduce the message, if such permission is desired,
and specifying whether all or part of the message is to be
reproduced.
2. Current debate on privacy in electronic communication
is as furious as it is copious. In recognition of this state of
ferment, the ANALYTICAL ENGINE _will not_ reproduce the
Internet address of any individual or organization unless the
owner of that address specifically requests its publication.
3. Reprinted messages will be credited with a line at the
end in this format:
-- [author's name], [author's affiliation], via Internet
where "Internet" is taken as generic, also comprising BITNET
and USENET; or, where appropriate, "AOL," "CompuServe,"
_et al._
4. If such a message is again reproduced, on public paper
or on the net, it must be credited both to the author of the
message and to the ANALYTICAL ENGINE.
Thank you for the opportunity to set forth this policy. We
solicit your comments. As part of the broader issue of
net.privacy and the evolving view of intellectual property,
this is an important point and we thank Dr. Pandey for
raising it. -- Editors ]
-------------------------------------------------
QUERIES
-------------------------------------------------
MAINFRAME FRONT PANELS EAGERLY SOUGHT
Unusual Systems, a consulting and development firm in
Toronto, Canada, is collecting front panels (control panels)
of mainframes and minicomputers, with the eventual
ambition of providing museum-quality display for these
important artifacts. This addresses a necessary compromise
since, as Kevin Stumpf notes in the materials we received
from him, "collecting entire systems is a costly venture." We
can only agree with a sigh.
The collection now comprises 50 panels but Stumpf is
looking for more; he claims to have "acquired every relevant
The Analytical Engine, Volume 1, Number 2, October 1993 Page 52
[type of] panel or console in Canada" and is expanding his
search to the United States. He is careful to note that this
work is being done in the spirit of preservation and not in
any sense for profit. If you are dismantling any of the
computers in this list:
* Burroughs B5000, B6700, B3500, B8500
* CDC Omega, 3200, 3500, 1604, 1700
* DEC LINC-8, PDP-8, PDP-8/S, VAX 11/780
* GE 415, 435
* HP 2114, 2100, 3000
* Honeywell 1XX, 2XX, 4200, 8200, H316
* IBM:
650
1401, 1410; 1130
7010, 7040, 7090, 7094
360/44, 67, 75, 85, 91, 195
370/165 or 168
* NCR Century 101 or 300
* RCA 3301, 1230 or Spectra 70/xx
* Scientific Control x700
* SEL 810, 85
* Sperry UNIVAC -- any
* Varian 620/i, 520i, V73
consider writing Mr. Stumpf at the address on page 59 or
calling him at 519/744-2900. His work seems to us
particularly relevant in light of the immense shakeout of
mainframes that will take place during the next seven to
ten years.
***********
CITATIONS WANTED ON COMPUTING IN INSURANCE
> I am working on a study of the transition to and early
use of computers in the life insurance industry. I would
appreciate any information on this subject, and particularly
names of people I might interview who were involved with
insurance industry computing in the 1940s, 1950s, and
1960s.
Thanks very much for any information, references, or leads.
-- from JoAnne Yates, Sloan School, MIT, via Internet
***********
HUNTING PALEO-JARGON
> Has anyone ever heard the term "wholihan" applied to a
subtle computer bug, or (even better) have any first-hand
knowledge of its etymology?
The Analytical Engine, Volume 1, Number 2, October 1993 Page 53
I came across the term in a copy of _An Introduction to
Electronic Data Processing_ by Roger Nett and Stanley A.
Hetzler, published in 1959 by The Free Press, Glencoe,
Illinois. The authors provide the following description and
etymology:
Occasionally a more difficult type of error, the
obscure error....sometimes called the "wholihan",
arises. This kind of error is characteristically of no
truly consistent type and is the result of a
combination of unique and unsuspected
circumstances. It may be a very simple error but
nonetheless remote and difficult to expose. The
term _wholihan_ originated among persons
programming for UNIVAC, where a man bearing that
name once inadvertently produced a challenging and
somewhat unforgettable example of the obscure
error. It occurred in a simple enough routine, but in
such a remote combination of circumstances that it
is said to have taken 200 man-hours to discover the
source of the error.
It's an interesting term....but I've never heard it anywhere,
much less the above story behind it, or the reason for its
ultimate demise....I suppose it's too much to hope for the
"first actual wholihan found" to be preserved in some log
book somewhere....
-- from Lee Wittenberg, via Internet
[A member of CHAC recalls that this term was used at the
Honeywell Data Center in San Francisco in the mid-1970's,
not an early citation but one that broadens the use from
the strict context of UNIVAC. Further citations, especially
early ones, will be gratefully received and reproduced. --
Editors ]
***********
PESKY GNAT IN SWEDEN
> Last week I bought a "vintage" computer at the local
charity flea-market. It....is labelled "GNAT Computers, San
Diego, California". "Model 10, SN 231". The front is labelled
"MILLBANK SYSTEM 10"
The box is an all-in-one "console" type....and holds two 5
1/4" diskette drives, a green CRT monitor, and the keyboard.
....The processor board has a Z-80 and a LOT of glue logic
and support IC's; it is labelled "GNAT 1000F level 3" and
appears to be 'fully' equipped with 64Kb of RAM. There
are....I/O ports at the back of the box (RS-232 etc.)
The Analytical Engine, Volume 1, Number 2, October 1993 Page 54
Attached to the back of the CRT is another PCB labelled
"GNAT 1005F Video Processor" [with,] among other things,
an 8085 installed.
It is apparently a CP/M system, but since I have no diskettes,
I have not been able to boot CP/M. I have, however,
succeeded in starting a 'monitor' program by pressing the
reset-button.
-- from Henrik Carling, University of Lund, via Internet
[David McGlone was able to tell us that the GNAT disk
format is DS/DD 48 tpi, but beyond that he draws a blank.
Does anyone know anything about this computer? Further
info much appreciated and will be forwarded. -- Editors ]
***********
FLYING BLIND ON SOL-20 ASSEMBLER
> I've got a SOL-20 sitting in my closet.... My last act with
it was to try and figure out the ALDS (assembly language
development system), contained in ROMs on an S-100 card;
you see, I have no docs. I managed to ....determine that
the previous owner had the ROMs in the wrong sockets,
and straightened that out ....but still couldn't figure out
what I was supposed to do to get it started. Unfortunately
the magazines of the period don't shed much light on
anything beyond the monitor ROM.
-- from "frank", via Internet
[We have purchased a SOL-20 (see above) and haven't
taken delivery of it yet, but it supposedly has manuals. If
they include material pertinent to the ALDS, we would be
glad to forward a copy at cost. -- Editors ]
***********
FIREBOTTLE QUERY
> I have a circuit cage, approx 9" wide, 1" deep, and 5" tall.
The circuit is made of discrete components, including some
semi-conductor diodes (1N480's, 1N119's). On the top of
the cage are 8 electron tubes (dual-triode) with the letters
IBM, and the number 317261 on them. As originally
mounted, the rack had the tubes out, and the length
vertical (9" high, 5" deep, 1" wide). What machine did this
come from?
Extra credit: the circuit is a dual JK, resettable, presettable,
addressable flip-flop. What function did it serve?
-- from Data Rentals and Sales, via Internet
The Analytical Engine, Volume 1, Number 2, October 1993 Page 55
[This is a trick question, since the writer has the answer, but
we'll publish it for the delectation of our audience. --
Editors ]
***********
COMPUTERS IN MILITARY COMMAND AND CONTROL
> I have read numerous reference to SAGE (Semi-
Automatic Ground Environment, I think...) and WWMCCS
(World-Wide Military Command and Control System) in the
literature over the years.
Does anyone have any pointers to literature/books
concerning these systems?
-- from John K. Scoggin, Jr. via Internet
[There's a good survey of SAGE, along with so much else,
in:
_IBM's Early Computers_
Charles J. Bashe _et al_.
MIT Press, Cambridge, Mass. 1986
but nothing in our library mentions WWMCCS. Any ideas
from our readers? -- Editors ]
***********
OLD-IRON SPECS WANTED
> I'd be interested in knowing something about the
workings of some of these early computers (especially the
programmable ones,) e. g., amount of memory, instruction
set, I/O capabilities.
I'm afraid there isn't a lot I can contribute to this, I know
only what I've read in various books. They tend to give
information like the number of valves (tubes) in each
machine, and make some statement about the number of
operations a second it was apparently capable of, but little
more.
-- from David Hembrow, Harlequin Ltd. (UK), via Internet
[David was referring to ENIAC but we've also seen
considerable recent interest in EDSAC, EDVAC, ACE/Pilot
ACE and the IBM 70x series.
We can recommend the TECHNOLOGY volume of Cortada's
_Historical Dictionary of Data Processing_, which gives
meticulous coverage to some of the older big iron, but we
The Analytical Engine, Volume 1, Number 2, October 1993 Page 56
do feel that all possible specifications for these machines
should be collated and published while they're still in the
semi-public record.
As a long-term project, CHAC intends to compile spec
tables of historically important mainframes and make them
available through the ENGINE's request daemon. The first
of these will be for the IBM 701. We'll say more about this
in the January 1994 issue. -- Editors ]
***********
ORIGIN OF "MINICOMPUTER" WANTED
In my search through old issues of _Computers and
Automation_, I've noticed that the term _minicomputer_
didn't show up until 1968. The first use of the term I can
find is in a full-page Interdata ad in May 1968, page 10. By
December 1969, the term must have become fairly
common, because they devoted a full issue to
"Minicomputers (and Their Applications)". Curiously, none
of the articles in that issue are by people from DEC or CDC,
the two companies that are in the best condition to claim
to have originated the minicomputer (either the CDC 112,
the Lincoln Labs LINC or the DEC PDP-5 / PDP-8 family seem
to have earned that title).
So, did Interdata coin the phrase _minicomputer_? Can
someone pin down a citation to the word prior to May
1968?
-- from Doug Jones, via Internet
[We have no idea, but certainly the locution must have
been fairly fluid, given that as late as 1976-77, micros like
the IMSAI and Altair were referred to in the literature as
"mainframes!" Any ideas? -- Editors ]
***********
DOES THE S-100 BUS STOP HERE?
I've recently acquired 3 IMSAI S-100 systems that I am
trying to restore to full usability. (i.e. running CP/M or
MP/M)....it shouldn't be impossible to get a working system
or two. One of the systems has a IMSAI MPU-B processor
board (8085) that I could really use some documentation
for (in particular, how to access the serial port on it, and if
possible, how to set the power-on action.)
....One of the[m] seems to have stopped upgrading around
the era of the Tarbell cassette interface. Anyone happen to
have....old Tarbell cassette operating systems or BASICs that
The Analytical Engine, Volume 1, Number 2, October 1993 Page 57
I have....manuals for? Is Tarbell still in business, by any odd
chance? Are any of the old S-100 companies (California
Computer Systems, IMSAI, ALTAIR, Godbout, Compupro,
etc.) still doing business in any form? Or maybe even still
selling S-100 boards?
-- from Timothy D. Shoppa via Internet
[Well, MITS/Altair was sold to Pertec and Pertec went under,
IMSAI got absorbed into ComputerLand amid a flurry of
lawsuits, and Compupro/Viasyn closed its doors in late
1991, so there's three down. Can anybody help Mr. Shoppa
with docs, used boards, disks or paper tape? -- Editors ]
***********
ONE FROM THE EDITORS
From our last argument around the coffee and doughnuts:
What was the first electronic digital computer in California,
and when, and whose was it?
(We win either way with this one. It'll turn into an article
topic or great mail.)
-------------------------------------------------
PUBLICATIONS RECEIVED
-------------------------------------------------
_Guide to the Oral History Collection of the Charles
Babbage Institute_. Aspray, Bruemmer, Melehy and Traub,
eds. Charles Babbage Institute, Minneapolis, MN, 1986.
110 pp.
_Resources of the History of Computing: A guide to U. S.
and Canadian records_. Bruemmer, Traub and Brosenne,
eds. Charles Babbage Institute, Minneapolis, MN, 1987.
187 pp.
_Charles Babbage Institute Newsletter_, Volume 15,
Number 3, Spring 1993. 10 pp. Oral History Cataloging
Initiative; Supercomputing '92; Tomash fellowships;
Technology museum in Paderborn; Fourth centenary of
Schickard's birth; Bank of America honors Al Zipf; more.
(The three above from Judy E. O'Neill.)
_A CBO Study: Promoting High-Performance Computing
and Communications_. Congressional Budget Office, June
1993. 63 pp. History of the Internet, of supercomputer
technology, and of their markets.
The Analytical Engine, Volume 1, Number 2, October 1993 Page 58
"Builder of First Analog Computer Trying to Recreate
Invention," James McWilliams, _The Huntsville Times,_
Huntsville, AL, June 6, 1993. Helmut Hoelzer and his
construction of the world's first fully electronic analog
computer.
"Preserving Software's History As It Is Written," George
Tibbits, Associated Press, August 9, 1993. A survey of
efforts to preserve historically important software at the
Smithsonian Institution, the National Museum of American
History, and various companies.
(The three above from Philip Webre.)
_The Z-Letter: Newsletter of the CP/M and Z-System
community_. Number 25, May-June 1993; Number 26,
July-August 1993. A forum for the support, preservation,
collection and sale of early microcomputers running the
CP/M and ZCPR3 operating systems. (From David A. J.
McGlone.)
"An Introduction to Bookbinding: Particularly aimed at the
preservation of old DEC handbooks," Douglas Jones, 1992.
Jones, a mainstay of the USENET newsgroup _alt.sys.pdp8_,
has written a lucid and extensive treatise on dissecting,
photocopying, rebinding and restoring old DEC manuals,
with principles generally applicable to any technical
documentation. If you ever rely on docs that are yellowed
and crumbling, read this -- soon.
[This document is an ASCII file of about 35K. To request it
by automagic e-mail, send a message to
engine@win.net
with a _subject_ line of
docfix
Alternatively, contact CHAC at the El Cerrito mail address to
request hard copy. ]
"Microcomputer History and Prehistory -- An Archaeological
Beginning," Harold A. Layer, _Annals of the History of
Computing_, Volume 11, Number 2, 1989. (From the
author.) An illustrated article/listing of a formidable
collection of early micros, calculators, electronic games and
computer-related toys.
The Analytical Engine, Volume 1, Number 2, October 1993 Page 59
-------------------------------------------------
ADDRESSES OF CORRESPONDING ORGANIZATIONS
-------------------------------------------------
The Computer Museum, 300 Congress Street, Boston
MA 02210. Brian C. Wallace, curator of historical
computing.
Charles Babbage Institute, 103 Walter Library, University of
Minnesota, 117 Pleasant Street S. E., Minneapolis MN
55455. Judy E. O'Neill, associate director.
Natural Resources and Commerce Division, Congressional
Budget Office, 410 Ford House Office Building, Washington
DC 20515. Philip Webre, principal analyst.
Intel Museum, P. O. Box 58119, Santa Clara, CA 95052-
8119. Jodelle A. French, curator.
Smithsonian Institution, Air and Space Museum.
Washington, DC 20560. Paul E. Ceruzzi, curator of
historical computing.
Smithsonian Institution, Division of Computers, Information
and Society. Washington DC 20560. David Allison,
director.
Unusual Systems, 220 Samuel Street, Kitchener, Ontario
N2H 1R6, Canada. Kevin Stumpf, president.
_The Z-Letter_, Lambda Software Publishing, 149 West
Hilliard Lane, Eugene OR 97404. David A. J. McGlone,
editor and publisher.
-------------------------------------------------
THANKS TO....
-------------------------------------------------
Scott Callan for insisting that hard work isn't much use
without a big mouth.
Susan deRenne Coerr for hours of invaluable advice on
accession, registration, curatorship, and the key point --
loading docks!
Robert X. Cringely for permission to quote at length from
Accidental Empires.
Hilary Crosby for setting up our accounting and
subscription system, and smoothing the path to our
501(c)3.
The Analytical Engine, Volume 1, Number 2, October 1993 Page 60
Tom Ellis for on-site support at impossible hours.
Michael Tague, Rob Conklin, Jamie Warren and Connie
Rogers at Computer Witchcraft for supplying an Internet
connection with maximum reliability and minimum pain.
All the great people at _news.newusers.answers_,
_alt.folklore.computers_, and _alt.sys.pdp8_ for making
USENET such an interesting place to live.
-------------------------------------------------
NEXT ISSUE * NEXT ISSUE * NEXT ISSUE * NEXT ISSUE
-------------------------------------------------
JANUARY 1994: The REAL first micro. DSP on a Zilog Z-80.
IBM 701, the stuff of legend. Literature. Queries.
Answers. Great mail. More....
Downloadable January first -- 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 1, Number 2, October 1993 Page 61
-------------------------------------------------
GUIDELINES FOR SUBMISSION
-------------------------------------------------
The ANALYTICAL ENGINE solicits manuscripts of 600 to
1500 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 and a one-
year membership, or extension, will be given for each
article published. Article deadlines are the first of each
month prior to publication: June 1 for the July issue,
September 1 for the October issue, December 1 for the
January issue, and March 1 for the April issue.
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 DOS or Mac 3.5" diskettes. Alternatively,
please provide an ASCII file attached to Internet mail.
Please avoid submitting on paper unless absolutely
necessary.
-------------------------------------------------
Can you spare a few minutes a month? The ANALYTICAL
ENGINE urgently needs volunteer help for administration,
subscription fulfillment, proofing and keying. Help keep
the ENGINE spinning -- reply to our Internet or mailing
address today.
-------------------------------------------------
The ANALYTICAL ENGINE, newsletter of the Computer
History Association of California, is published four times a
year -- in January, April, July and October -- at El Cerrito,
California. Subscriptions are available with Association
membership at rates given below. Use the coupon to
subscribe, or contact the Association at:
FAX: 510/528-5138
Internet: cpu@chac.win.net
US Mail: 1001 Elm Court, El Cerrito, CA 94530-2602
The Analytical Engine, Volume 1, Number 2, October 1993 Page 62
-------------------------------------------------
SUBSCRIBE * SUBSCRIBE * SUBSCRIBE * SUBSCRIBE
-------------------------------------------------
and share fascinating insights into the vital story of
computing while you build an organization that safeguards
our unique scientific and technical heritage. Annual
membership will bring you four issues of the ANALYTICAL
ENGINE -- filled with non-partisan, technically and
historically accurate articles -- and the satisfaction of
preserving the history that you work to create.
____ Yes! Please enroll me in the Computer History
Association of California for the next year. I enclose
____ $25 individual membership
____ $75 corporate/institutional membership
____ $15 low-income/student membership
and send four issues of the ANALYTICAL ENGINE to
____ Internet address: ______________________________
____ CompuServe ID#: ________________________________
____ Other gateway: _________________________________
____ I would prefer to receive paper copies of the
ANALYTICAL ENGINE. (The paper edition is available to
paid-up members only.) My mailing address is:
Name: _______________________________________________
Company: ____________________________________________
Suite, Box, Mail stop: ______________________________
Street: _____________________________________________
City: _____________________ Zip/postcode: _________
Country: _______________ Phone: _____________________
____ 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 at:
______________________________________________________
The Analytical Engine, Volume 1, Number 2, October 1993 Page 63
-------------------------------------------------
NINES-CARD
-------------------------------------------------
Here's an authentic chunk of computer history, ERMA's last
words. ERMA was the first computer designed here in the
San Francisco Bay area (later the Silicon Valley), in
development at Stanford Research Institute and at GE from
1950 to 1959. It was a check processing system for Bank of
America, the first of its kind, and among other things it
established an international standard for machine readable
characters on bank checks -- the account and other
numbers printed on your checks.
There were about a dozen ERMA systems in production
use, and when the last one was shut down this was the
final message. You can see this last machine carefully
restored in a good exhibit in the lobby of one of the
buildings at the Bank of America Technology Center in
Concord, across the Bay from San Francisco. The exhibit
includes video testimonies from the original ERMA
developers. Call Ed Hawthorne at Bank of America at
510/675-1303 if you're in the area and want to see the
exhibit.
-- from Peter Nurkse, Sun Microsystems, via Internet
***********
ERMA Says Goodbye
A MESSAGE TO ALL MY CO-WORKERS
FROM ERMA
IN MY ELEVEN YEARS OF SERVICE TO THE BANK OF
AMERICA, I HAVE BEEN PRIVILEGED TO WORK WITH SOME
OF THE BANK'S FINEST EMPLOYEES. FROM PEOPLE LIKE
EMMETT JENKINS, DICK DAVIS, JOHN COOMBS, AND MANY
MORE WHO WERE WITH ME FROM THE BEGINNING, TO
BOB LEE AND ALL OF MY CURRENT CO-WORKERS WHO ARE
ASSISTING ME IN THE PROCESSING OF TRAVELLERS
CHEQUES -- MY FINAL APPLICATION -- I CAN ONLY SAY
THANK YOU. TOGETHER WE HAVE MADE GREAT STRIDES IN
BANKING. AND I CANNOT HELP BUT FEEL, AS THE FIRST
COMPUTER SYSTEM TO BE USED FOR BANKING
APPLICATIONS, THAT MY RETIREMENT BRINGS TO CLOSE AN
HISTORIC ERA. TO BE THE FIRST IN SOMETHING IS A GREAT
ACHIEVEMENT, AND I AM VERY PROUD. BUT MY SUCCESS
COULD NOT HAVE BEEN POSSIBLE WITHOUT THE HELP OF
SO MANY FINE PEOPLE.
The Analytical Engine, Volume 1, Number 2, October 1993 Page 64
ALTHOUGH THE END OF AN ERA IS NEAR, AND WE WILL
SOON PART, I WILL NEVER FORGET MY FRIENDS, AND I
WISH YOU ALL THE GREATEST SUCCESS IN THE FUTURE.
TO MY CURRENT -- AND FINAL -- ASSISTANTS, I BID
FAREWELL --
MY BEST TO ALL,
ERMA
************
[See you in January.... ]