Return to "Visible Storage"

*** Please note: This website (comp-hist) was completed before I found out about Wikipedia in 2002.
Since then I have added material occasionally.
Items are certainly not complete, and may be inaccurate.
Your information, comments, corrections, etc. are eagerly requested.
Send e-mail to Ed Thelen. Please include the URL under discussion. Thank you ***

IBM 1620

Manufacturer IBM
Identification,ID IBM 1620
Date of first manufacture-
Number produced over 1300
Estimated price or cost$90,000 (educational discount)
location in museum -
donor -

Contents of this page:

Photo Photo
IBM 1620

Placard
IBM-1620 - by Ron Mak

Architecture
-

Special features
From R. Tim Coslet
"The memory cycle time of the Model I was 20us and the Model II was 10us."

Historical Notes
Table of contents:
- IBM 1620 Development by Wayne Winger
- Dijkstra comments

E-mail from Dave Babcock Project Lead of the museum's IBM 1620 restoration.
To all,

Last Saturday I received email out-of-the-blue from Wayne Winger. He had seen a mention of the IBM 1620 restoration project in the IEEE Spectrum article (http://www.spectrum.ieee.org/WEBONLY/publicfeature/nov02/gost.html), looked up our website and got my email address.

Wayne was the manager of the IBM 1620 development team in Poughkeepsie!!!

I sent him several pages of questions, his first set of answers is below.

There's a lot of great information here. I'll forward more as it comes in.

...

Thanks,

DaveB


----- Original Message ----- From: "Wayne Winger"
Sent: Tuesday, November 05, 2002 2:51 PM
Subject: IBM 1620 Development

Dave, when I got the assignment to study the "small scientific market for IBM" in 1958 I assembled a small team. Initially there was me, Robert C Jackson, William H Rhodes. Quickly others were added. Anne Deckman (died tragically before project was completed), Kelly B. Day, William Florac and James Brenza. I have contacted Bob Jackson. I think he has some artifacts or documentation. Kelly Day is deceased. I do not know the whereabouts of the others.

The group was small and we all pitched in on most aspects of the program. Competing machines were the LGP 30 by Librascope and the Bendix G-15. We quickly concluded that IBM could offer nothing really new with drum machine so I looked elsewhere. I thought that IBM should be able to take advantage of their bigness and use technologies developed for larger machines in the smaller machine arena. I do not recall being given a set of hard objectives.

Human memories are notoriously unreliable, particularly 40 years later. The laboratory was organized such that a memory group designed memories for various projects. Likewise there was a circuits group which designed standard circuits and cards. The basic packaging design (SMS) was designed in the IBM Endicott Lab. Machine groups were expected to draw on these speciality groups if they could do so and meet their objectives. Projects were assigned by the Laboratory Director (in this case H. Tyler Marcy) according to resources and demands. Of course many of the best projects were the result of engineers working a related area and kind of grew.

The basic objective was to provide a useful machine at the least possible cost. That meant restricting the instruction set (someone can always suggest a nice additionally instruction for just a little more circuirtry.) It meant being clever in design. There were no arithmetic curcuits in the original design and releasee. That was all added by the San Jose group. It meant finding the least expensive Input/Output. You can imagine the flak I received for putting out an IBM machine which did not have a CARD reader and punch.

I cannot tell you the origin of the idea to use table look up. I do recall some general suggestion that we ought to begin thinking about using the logical functions in a machine to replace hardware. We completed the engineering model sometime in the spring followed by a debugging session. Then a model from release drawings. This was submitted to the Product Test Lab (a separate organization) for testing against specs.

At the completion of that test the machine was announced. It was a fully operational machine. It was not a "partially working machine" as you have apparently been lead to believe.

A patent was filed and issued for the Table Lookup Multiplying Computer. We later receied an IBM Patent Award for the content of that patent. Later the San Jose group made improvements and used the machine as a basis for process control functions.

In the fall of 1959 there was a major re organization within th IBM Co. Small machines were asigned to the General Product Division and large scale machines were wssigned to the Data Processing Division. Clearly the 1620 did not belong in the Poughkeepsie area of responsibility. The decision was made to release it to San Jose Manufacturing. A Product Engineering group was formed to support the project in the San Jose Lab. As I recall John Kyffin headed that group and was responsible for the San Jose end of the transfer.I personally do not know the people you have listed in the San Jose group. Perhaps they came along later? I really didn't follow the project closely after release as I was busy with other things. I do know that everyone on the project looks back with fond memories of that project and what we accomplished.

More next time,

Wayne Winger

Dijkstra comments via Cory Heisterkamp

A review of the IBM 1620 Data Processing System

It is a good custom that scientific articles are reviewed and that no publisher ever thinks about starting a lawsuit or any other measures of vengeance against the author of a very unfavourable review of one of his publications.

With this in mind it is somewhat curious that it is not customary to review digital computers. Reviews of these scientific instruments are in some respects much more important: it is a pity if you have bought the wrong book, but it is much, much worse if you have bought the wrong computer.

The idea that computer reviews ought to be written and published is with me for some time already. The final impuls[e] to write such a review has been the discovery of two "Letters to the Editor" of the Communications of the A.C.M., both expressing praise and appreciation for the same computer, viz. the IBM 1620. They are the letter from Fred Gruenberger, C.A.C.M.,Vol 5, April 1962, pg 221 ("Besides being extremely ingenious....") and the letter from Daniel Herrick and Neal Butler, C.A.C.M.,Vol 5, September 1962, pg 496 ("We wish to join Fred Gruenberger of the RAND Corporation in praising the variable word length IBM 1620....."). It is my considered opinion, however, that this machine embodies some very fundamental mistakes and certainly after the publication of the two letters mentioned above I regard it as my duty not to remain silent any longer. Manufacturers should be warned for these mistakes in order not to be tempted to incorporate them in their future designs, also machine users should be warned for these mistakes in order to help them in not chosing the wrong machine and in order to create a climate where machines will be judged more by their fundamental properties.

After the two praising letters I can be short about its virtues; I should like to add that as soon as the troubles of installation are over, it is an extremely reliable machine.

Before going on I should like to explain why I may have objections to "superfluous features". Suppose that a machine contains a certain feature and that I can show, for instance, that it is impossible to use it intelligently or that its use gives rise to undesirable programming conventions; suppose furthermore that the defender of the design agrees to my objections but defends the feature by pointing out that, if I do not like the feature, I do not need to use it, implying that no harm can be done by something "extra". In that stage of the discussion I shall stress that the design would have been better without the feature under discussion. If it is impossible to use it intelligently every effort to do so is spoilt and the programmer would have been better of[f] without it. If its use gives rise to undesirable programming conventions, also in that case the programmer had better ignore the feature completely.

The IBM 1620 contains a beautiful example of such a harmful "superfluous feature". Besides a general mechanism for calling subroutines, it has a special instruction ("Branch and Transmit") to call in subroutines, an instruction by which control is transferred to the subroutine after the return address has been saved: for the benefit of the end of such a subroutine the order code contains a complementary instruction ("Branch Back") which takes care of the return jump. So far, so good, but the blunder is that the return address is saved in a special return address register, the contents of which are accessible only via the instruction "Branch Back" and in no other way! Before I got acquainted with the IBM 1620 I thought that in the mean time everybody knew that the most essential property of a general purpose information processing machine is that it allows you in principle to process any piece of information in whatever way you like. I was most astonished (and appal[l]ed ) when I discovered that the design of the IBM 1620 Data Processing System has not remained faithful to this fundamental requirement: it is just impossible to write a program only inspecting the value of the return address register. As a result, the incorporation of this feature in a program containing many nested subroutine calls requires that the programmer decides, once and for all, on which level the feature will be used. The special feature has two so-called advantages: the calling sequence requires less memory space and the execution time of the call is reduced. Alas, the subroutine which is called in most frequently is, in general, not identical with the subroutine which is called in from the maximum number of different places in the program and the poor programmer who tries to decide intelligently on which level he shall make use of the special feature "Branch and Transmit" is faced with a fairly undecidable problem. Needless to say that, once the use of the feature has been incorporated in the program, program modifications become unnecessarily tricky or even impossible without rewriting major parts of the program.

There are more reasons why the machine is not worthy of the qualification "general purpose machine", in particular as far as its facilities for paper tape input and output are concerned. The tape reader has been equipped with a number of special properties which make it completely useless as soon as one wants to process an arbitrary punched tape, viz. special properties such as:

  1. a built in parity check
  2. automatic skipping of a specific punching (in IBM terminology identified by "TAPE FEED"
  3. continuing to read until a specific punching is encountered (in IBM terminology identified by "END OF LINE"

The tape punch has similar pecularities. As a result the machine cannot be used to process tapes made by some automatic measuring apparatus or to produce tapes for some tape control[l]ed machinery, unless the tape conventions of these pieces of equipment do not violate the restrictions set by the IBM 1620.

Tape reading has another curious property. One can start tape reading and successive characters from the tape are stored on consecutive (pairs of) digit locations in the memory, starting at a known location. The reading process stops as soon as the character "END OF LINE" is met on the tape. This terminal character, however, is not stored in the memory, another character, named "Record Mark" is stored instead. After completion of the tape read operation the number of characters read (or the address of the location of the terminal character) is lost and if the machine wants to detect how many characters have been read from the tape, it must scan the memory. But now a curious problem arises: the terminal Record XXX Mark which has been stored is indistinguishable from previous Record Marks which might have been read from the tape, and therefore the machine is faced with a problem that shows a striking resemblance to the prototype of an improper algorithm: a man asking the way and getting the answer "You go straight on and turn to the right just before the last steel bridge.". As a result one comes to the shocking conclusion that it is impossible to use the IBM 1620 Data Processing System for one of the most trivial jobs: the reproduction of a punched paper tape, impossible even when it is known that the characters on the tape all belong to the restricted set of the IBM 1620.

On the remark in the Reference Manual "The IBM 1620 is a variable field length computer in the complete sense of the term." I should like to give two comments. I agree that variable field length (plus a non-negligible additional burden on the programmer) in principle admits more economic storage utilization. But the design of the IBM 1620 has turned out in such a way that it is very doubtful whether this gain can be attained. The store is divided into locations of five bits, each location requiring six magnetic cores, because every location has its own parity bit. To store numerical data one needs one location, i.e. 6 cores, for every decimal digit, which compares rather unfavourably with the 3.4 cores needed in the case of binary words. It seems to me very doubtful whether cunning exploitation of the variable length feature will be able to compensate this initial loss, in particular because the gain must come from the way in which the data are stored: the program is stored in fixed length two address instructions each requiring the considerable amount of 72 cores! The full waste of core storage is certainly attained in the processing of FORTRAN programs, where fixed and floating point variables have their fixed length of 4 and 10 locations respectively. My second remark on the variable field length pertains to the way chosen to specify the field length, a way which I regard the more objectionable, the more I think about it. One of the bits of each location has the special function of "a flag bit"; a variable field length operation starts by an addressed location and processes consecutive locations from there onward until a location has been processed with its flag bit = 1. An alternative solution (as e.g. in the Philco 1000) would have been to state separately and in advance, somewhere else, the length of the field in question. First of all, the method of the flag bit tends to be rather uneconomic as far as number of cores concerned, because

  1. the field length is effectively given in a "unary number system"
  2. the field length is stored all over again with every field, which is apparently a waste as soon as a great number of fields of known equal length are to be stored.

The next objection to the flag bit, which is of a more fundamental nature, also applies to the special function of the Record Mark, a character which —one level higher— may be used to end the operation "Transmit Record". Information stored in the memory of a machine shows a certain hierarchical structure: on the one hand we have —on a vertain level— "the information proper", on the other hand we have "the addressing information" specifying place and/or extent of the information proper. The flagbits and the Record Marks play with respect to the fields and records the role of "addressing information" In the IBM 1620 (as in some other machines) the correspondence between the information proper and some of the addressing information is established by a fixed convention in terms of relative position. This would be all right if the information proper were only regarded "from one single point of view", but a basic property of a general information processing process is that information can and will be regarded from many different points of view. If addressing information has to be stored in a position uniquely fixed relative to the information proper, such a change of "point of view" will, in general, imply extensive, clumsy manipulations on the addressing information in this case on the flag bits or on the Record Marks. If somebody tries to make a program shifting the arbitrary contents of a given sequence of memory locations to another place in the memory, he will realize the full impact of my objection.

The IBM 1620 is not the only machine on the market, where (part of) the addressing information and the corresponding information proper are positionally dependent. Because such machines can scarcely be used whenever the way in which the information proper is to be addressed changes frequently, their field of application is virtually restricted to rather straightforward jobs; they are, for instance, no longer qualified to take the place of a university computer. I always wonder whether the designers of such machines have been aware of the restrictive consequences of the technique in question; if so, it is hard to respect their conscious decision to stick to it, if not, are they the people that should have been designing machines? I always wonder......

From the letter of F.Gruenberger I quoted "Besides being extremely ingenious...". In contrast to this opinion I should like to state that, in more than one respect, I regard the design as rather crude. I shall give two examples.

Addition of two numbers is performed serially from right to left. If a short number (source) is added to a longer one (destination) the addition needs only to be continued to the left of the most significant digit of the source so long as the carry is unequal to zero. In the IBM 1620, however, the process is always continued to the bitter end of the destination.

The instruction for the punching of a piece of paper tape always ends by punching a character "END OF LINE". To punch a sequence of characters unequal to "END OF LINE" one is therefore forced first to build up the sequence on consecutive locations in the memory and then to punch out this sequence by means of a single punch instruction. But when this punching takes place (at the conservative speed of 7 char./sec!) the machine itself stands idle.

With this last example in mind one must come to the conclusion that the software provided by the manufacturer is just ridiculous. Even the processing of SPS (standing for "Symbolic Programming System", although it is hardly more than just machine code with mnemonic letter combinations for the different instructions) implies the punching out of the "translated" program. One of the SPS-processors punches the translated program in portions of a fixed length of 80 characters, although the last 8 are never used (and sometimes not even one or more preceding multiples of 12).

Concluding remarks

As the reader will understand, my recent study of the IBM 1620 has been a shocking experience: I knew that it was a rather small machine but I had never suspected that it would embody so many basic blunders. Personally, I cannot undergo such an experience without asking myself what its morals are.

One of the facts we have to face is that this machine, despite of its poor qualities, has been bought or rented. Either the customer is incompetent to judge what he is buying, or the contracts are signed by the wrong persons; in both cases the conclusion is that the fact, that other people have chosen a particular machine, is no guarantee whatsoever as far as its quality is concerned. Well, this is hardly surprising. (For this fact one could try the explanation that the machine, although limited gives "value for its money". But this is belied by the machine itself, for even a modest expert can see, that it also give "nuisance for tis money": for instance, without the additional "END OF LINE" character at the end of the punch instruction the machine would have been cheaper and more sound at the same time.)

The next fact that we have to face is that this machine, despite of its poor qualities, has been produced, in this case even by a big firm with a long and considerable experience. The straightforward conclusion is, that nor the size nor the experience is a guarantee as far as the quality of the product is concerned. Well, we can think of various explanations for this apparent inconsistency, but the most obvious explanation predicts still more blunders in the more ambitious and more complicated products of the manufacturer in question.

Januari 1963

E.W.Dijkstra
Technological University
Department of Mathematics
Postbox 513
E I N D H O V E N
The Netherlands

Literature: IBM Reference Manual 1620 Data Processing System, printed in the Netherlands A 26-4500-1.


Transcription by Ken Dyck

This Specimen
from David Wise < David_Wise@Phoenix.com >
You believe correctly, Tim.

The 1620 “S”-level signals are PNP RTL with a -12V supply. Low (“-S”) is a resistive pulldown towards -12V with fan-out degrading it to about -6V; high (“+S”) is a hard pullup to ground.

I used the venerable 1488 and 1489 RS232 chips for level shifting. The 1488 can handle continuous shorts, so you can limit the swing with simple diode clamping. The 1489 has auxiliary inputs that push the threshold around, so it was no problem getting them to switch at -3V. I’m sure there are many purpose-built level-shifter chips, but these were abundant, cheap, and well-understood.

I never saw the kind of trouble that CHM did. It had something to do with power supply transients. I guess my earlier-level machine had different sequencing.

When I started the project, I knew that TI made a 74-series decimal to binary converter chip, but I discovered that converting 17 address lines would require something like 20 of them. It was easier and cheaper to use sparse addressing on 17-line RAM. And yes, they were samples. Mouser stocks nine similar parts at less than $5 each.

Regards,
Dave Wise
Hillsboro, Oregon
World’s last running 1620

-----------------------------

From: R. Tim Coslet [mailto:r.timcoslet@gmail.com]
Sent: Wednesday, September 21, 2016
To: Ed Thelen; David Wise
Cc: Crisp, Lorilee D CIV USARMY (US); Carl Claunch
Subject: Re: CDC 1700

I believe Dave Wise did the original design on that core memory replacement card using two 0.5MB SRAM chips to replace up to 60,000 digits of core (most of the SRAM was not accessible due to the decimal addressing of the 1620 [IIRC I estimated that a little more than 4.25% of the SRAM storage was actually seen by the 1620. As your CDC 1700 uses binary addressing this "wasted memory" space issue would not happen.). He knew some ICs that could be easily used to convert the IBM SDTRL to TTL and TTL to IBM SDTRL voltage levels. However we modified the circuits significantly as we encountered problems.

You would of course have to handle level conversions for CDC voltage levels instead of IBM and I don't know what they are, or what standard chips might work if any.

Using SRAM (as we did) is probably best as DRAM would need to also add refresh circuits and there might be timing conflicts with the CDC timing that you don't have to worry about using SRAM.

As I understand it the SRAMs were actually free engineering "samples", but everything else was purchased.

-----------------------

-------- Original Message -------

Subject: CDC 1700
From: "Crisp, Lorilee D CIV USARMY (US)" < lorilee.d.crisp.civ@mail.mi >
Date: Wed, September 21, 2016 2:52 pm
To: "ed@ed-thelen.org" < ed@ed-thelen.org >

Hi, I am involved with a project to replace the magnetic core memory in a CDC-1700 with current memory technology. Do you have any experience with this or do you know anyone who does? Thanks for your time, Lorilee Crisp

Interesting Web Sites

Other information - Newest near top
  • An IBM 1620 "Jr." project with look and feel of a real 1620. contact info info@ibm1620.org
  • from newsgroup comp.arch Mike Albaugh said
    ... when IBM wanted to make a "process-control" version of the 1620, they added interrupts and called it a 1710.
  • We received almost a ton of IBM 1620 program card decks for from a Purdue professor. These cards have been read by a card reader (rented from a firm in Flordia) and stored on a CD ROM. These are available to the IBM 1620 via a special channel to/from a PC which emulates several I/O devices. [see next below]
  • From David Wise - July 19, 2016
    I designed and built that peripheral emulator, and wrote the PC software that drives it. The Museum’s emulator is the second one built. I debugged the prototype on my own 1620, and still have it, and it still works.
    - Dave Wise
    - Hillsboro, Oregon
  • From Ed Liss Feb 18, 2010
    ... The comment was about a ton of software sent by a Purdue professor.
    I was a student at Purdue in the '70s and there was a lot of 1620 software in the lab, all of it on cards. I worked the Dr, John Maniotes to sort out and organize this software. I remember copies of Monitor I (with and without a 1443), Gotran (card and disk based, 1443 enabled version with SPS source), StatPak (from Goddard), other operating systems, etc.
    There also was a simulator from IBM - SIM20 - that ran stand alone on the S/360 mainframe.
    I have found copies of the manuals on the internet but I was wondering if any of the 1620 software or SIM20 is available for download?


If you have comments or suggestions, Send e-mail to Ed Thelen

Go to Antique Computer home page
Go to Visual Storage page
Go to top

Updated April 27, 2021