Links from this article with broken #section links :
|WikiProject Computing / Early||(Rated Start-class)|
- 1 100,000 digit 1620
- 2 Clock or memory cycle speed
- 3 Inexpensive ???
- 4 Cadet vs. Stretch
- 5 CADET joke
- 6 Multi-level Indirect Addressing
- 7 This is Wikipedia or an instruction manual?
- 8 1620 Compilers -- AFIT FORTRAN, SNOBOL
- 9 Arithmetic in Model II
- 10 Other peripherals
- 11 Invalid character
- 12 Card vs. paper tape
- 13 Character and Op code table
100,000 digit 1620
I was told by a CAI (computer aided instruction) author in 1969 that one 100,000 digit 1620 had been constructed. The primary modification to the machine was the enabling of the 80,000 digit circuit in the memory address registers.
- Well, I wouldn't be entirely surprized if ONE was customized for a specific customer, many even had custom instructions or I/O devices that a customer requested. However IBM destroyed all their customer records on the machine at some point and this is impossible to prove now. It would also require an extra IBM 1623 (Model I), IBM 1625 (Model II) or similar Memory unit to house the additional 40,000 digits and support electronics. The Computer History Museum's IBM 1620 restoration project tried to get copies of any records from the IBM archives.
- If you have any idea where this "extended memory" 1620 was and if it was a Model I or a Model II it would be very helpful. -- RTC 18:13, 29 Oct 2003 (UTC)
- As the standard 1620 MARS Core plane did not have an 80,000 bit (there was no bit to "enable"), this modification would have required a custom MARS Core plane as well as an extra flip-flop in the MAR. -- RTC 00:10, 26 Jan 2004 (UTC)
Clock or memory cycle speed
Hi, great article for the computer history enthusiast! Does someone know the clock or memory cycle speed, or relevant equivalent characteristic, of the 1620? --Wernher 07:28, 22 Nov 2003 (UTC)
- I was on the team that restored a Model I to operation and have full schematics.... read the articles on the individual models as things are different! -- RTC 07:38, 22 Nov 2003 (UTC)
- Oops, sorry, I didn't notice the separate Model I article (misunderstood it to be part of the 1620 main article). Now, however, I am enlightened :-) --Wernher 08:24, 22 Nov 2003 (UTC)
- Good question. My vague recollection is that the clock speed was on the order of about 10 microseconds. Someone should look up the facts and add summary speed info to the main 1620 article. 22.214.171.124 20:35, 16 September 2006 (UTC)
The word "inexpensive" in the opening § should be qualified/explained or else be set in quotes, I think, since I guess we're not exactly talking small change here :-) --Wernher 07:28, 22 Nov 2003 (UTC)
- Inexpensive compared to other IBM scientific computers (e.g. IBM 7090) of the time. Read the Model I article. -- RTC 07:38, 22 Nov 2003 (UTC)
Cost information should be added; it was relatively small and cheap, which was very important in context. 126.96.36.199 20:57, 16 September 2006 (UTC)
Cadet vs. Stretch
As we chatted, I mentioned that the 1620 was the computer I first learned to program. He told me that the 1620 was near and dear to his heart. He said that he had worked in the project office for both the 1620 and the IBM 7030 a.k.a. Stretch.
The budget approach to these two machines was amazingly different. He said that when an engineer on the 7030 approached the project office with the need to add a gate to the machine, it got some scrutiny but was approved. In those days, the term 'gate' on an IBM computer didn't mean a simple logic circuit, it meant a large swinging frame which held multiple circuit cards and represented a sizable cost.
On the 1620 however, the addition of simple and inexpensive components like pull-up resistors had to be rigidly justified and often the engineer was told to redesign and find a cheaper alternative.
That interview was the first time I ever heard the CADET=Can't Add Doesn't Even Try line.
Yes, I got the job, and I'm still with IBM some 30 years later.
- On the 1620 those resistors would most likely have been pull-down resistors, as SDTRL logic used PNP transistors to pull their output to ground and resistors to pull-down to -6V – -12V. -- RTC 09:25, 21 Jan 2005 (UTC)
That C.A.D.E.T. - now I think that acronym ought to be in the article. I also knew and worked with one of the design team in 1964, and was told the "Can't Add Doesn't Even Try' term. --Dumarest 21:22, 4 July 2006 (UTC)
- The internal code name CADET already appears in the article. There are three known interpretations of it:
- "The internal code name CADET was selected for the machine. One of the developers says that this stood for "Computer with ADvanced Economic Technology", however others recall it as simply being one half of "SPACE - CADET", where SPACE was the internal code name of the IBM 1401 machine, also then under development."
- "Following transfer to San Jose, someone there jokingly suggested that the code name CADET actually stood for "Can't Add, Doesn't Even Try", referring to the use of addition tables in memory rather than dedicated addition circuitry. This stuck and became very well known among the user community."
- -- RTC 20:10, 5 July 2006 (UTC)
- As on my page, the point is that the 'joke' is NOT in the actual article - it was, but removed - I think it belongs in the actual article, it is a valid piece of history, and 'encyclopedic'. --Dumarest 20:16, 6 July 2006 (UTC)
- Well, for what it is worth I added a redundant reference to the CADET joke in the introduction. If such duplication is needed, then that is were it belongs, not out of time sequence in the development history section, as it had been added before. It has always been in the development history section, in the appropriate time sequence. -- RTC 02:46, 7 July 2006 (UTC)
- I blush - this time I used a search to find it, and there it was [in the older version that I first looked at]. On beyond where the 'SPACE-CADET' term was, later in the history. I spoke without full knowledge when I started this thread. --Dumarest 12:18, 9 July 2006 (UTC)
- No problem. -- RTC 04:05, 10 July 2006 (UTC)
Multi-level Indirect Addressing
"In the least significant digit of 5-digit addresses it was set for indirect addressing."
My recollection is that this allowed for simple, obvious, n-level indirect addressing. If this is true, I think it is worth mentioning -- a neat feature. 188.8.131.52 21:02, 16 September 2006 (UTC)
- Yes it was multi-level, you could even put it in an infinite indirect addressing loop. But on the Model I indirect addressing was an option, most Model I systems didn't have it. -- RTC 19:57, 17 September 2006 (UTC)
Indirect addressing was an optional, extra cost, special feature on the 1620. If the P6 or Q11 digit of an instruction had the flag bit set, then that address would be interpreted as an indirect address. — Preceding unsigned comment added by Nworth (talk • contribs) 23:17, 3 December 2011 (UTC)
This is Wikipedia or an instruction manual?
Is there any need whatsoever for the huge, HUGE tables here discussing the most intricate details of how this computer operated, and instructing readers precisely how to use this machine? It's astoundingly cumbersome, and most of it isn't even sourced. Legend Saber (talk) 21:09, 11 April 2009 (UTC)
- Well, here's a detail that I certainly recall following many many times, but is not mentioned in the description of the compilation ritual. After phase two of the compiler was loaded, the intermediate deck of cards that had been punched by phase one first had to be re-ordered. The compiler's symbol table at the end of the deck had to be found (no edge printing, but the pattern of holes at its start was easily recognised, though I've forgotten how) and those cards placed at the start of the deck of cards to be fed to phase two. This was needed to handle forward references within the code about to be produced as an executable. Without this reordering, presumably the intermediate deck would have to be read twice so that the required information would be available before the intermediate code was processed, since the first pass of the compiler presumably did not leave this information in memory ready for the second pass to find. I'm not sure how this procedure would be arranged for a paper-tape based system, but I never used that. NickyMcLean (talk) 21:49, 21 April 2009 (UTC)
1620 Compilers -- AFIT FORTRAN, SNOBOL
We used AFIT fortran on our 1620 in the late 60's , it was simpler to use than the IBM product, had a good user group, and compatible with FORGO. I find only a few traces on the web. AFIT is an acronym for Air Force Institute of Technology. Googling finds only " Pratt Wright Patterson AFB" for the author. The compiler was only for the IBM 1620 AFAIK, and less than 2 inches of cards. (Card-inches was one intuitive measure of program size back then, as it translated readily to seconds to prepare for execution.) A classmate built a SNOBOL compiler for the 1620, but it didn't have wide distribution
I too used the 1620 (mod 2) as my first computer, back in '68/69. It only had 20,000 digits of memory, but unless my own memory's wrong, we used a FORTRAN II compiler. If either it or the assembler (SPS) needed multiple passes, I wasn't aware of it because it either kept everything in core or used part of the scratch section of the hard disk.JDZeff (talk) 20:32, 6 October 2011 (UTC)
IBM offered FORTRAN with Format in addition to FORTRAN II. It was a rather abbreviated one pass FORTRAN compiler, but was useful for many student applications.
There was a third party Intercom interpreter available so that Bendix G-15 programs could be executed on the 1620. It was not totally compatible with the most common versions of the Bendix interpreter, however.
One of the first electronic circuit simulation programs, ECAP (really a fourth generation language), was developed on and for the 1620. — Preceding unsigned comment added by Nworth (talk • contribs) 23:25, 3 December 2011 (UTC)
Arithmetic in Model II
I originally learned computer programming on a 1620 Mod 2 in 1968-69, and I assure you that we still had to load the full arithmetic tables into memory as it used table look-up for arithmetic, not hardware. I'm not about to start an edit war over this, but I would like it checked out and, if my memory is verified, corrected.JDZeff (talk) 22:20, 6 October 2011 (UTC)
What is the question? In my case (1970-1) at Auckland University, the Fotrtan compiler was loaded from a deck of cards (there being no disc), followed by your fortran prog; an intermediate deck was punched which was to have its last part (the symbol table) cards placed in front of the main part of the intermediate deck, then after placing the card deck for the second pass of the compiler in the reader, it was followed by the re-ordered intermediate deck, and the card punch rolled out your prog. as a ready-to-load deck. Now discard the intermediate deck (often painfully large!). You then put the loader deck into the reader, followed by your prog., and then your prog. would be loaded and run, probably to read its data deck. It was well-known that arithmetic was performed with the aid of in-memory lookup tables, and I recall amusement being general that boolean arithmetic could be arranged via modifying the table, though so far as I recall, no-one actually did this. It would of course wreck ordinary arithmetic, and anyway, boolean arithmetic is easily simulated with integer arithmetic on values of 0 and 1. I think add and subtract were done in the hardware on later models, possibly prompted by the "Can't add, doesn't even try" humour, as well as performance issues. NickyMcLean (talk) 20:44, 9 October 2011 (UTC)
The lookup tables were really a rather efficient way to do the BCD arithmetic on the 1620. The actual work was done by hardware coded instructions that accessed the tables. Divide was done by a subroutine, however, as were all floating point instructions. Many housekeeping matters associated with arithmetic operations also had to be hand coded. As extra cost options, you could order the automatic divide feature, which eliminated the subroutine and sped things up a lot. You could also order the Move Flag (MF), Transmit Numerical Strip (TNS), and Transmit Numerical Fill (TNF) instructions, which simplified and sped up the housekeeping. Automatic floating point instructions were also available at extra cost, but they were so expensive that they were seldom purchased, despite about an 8 fold speed advantage. The 1620 Model 2 had improved arithmetic instructions, with a hardware adder. — Preceding unsigned comment added by Nworth (talk • contribs) 00:01, 4 December 2011 (UTC)
- That's "Transfer Numerical Strip" and "Transfer Numerical Fill", not "Transmit". My 1620 has the Special Instructions. Also Indirect Addressing. As a minor gaffe, IBM's own One-Pass Assembler was incompatible with this feature. I used one of the spare console switches to turn it off. Vintage Dave (talk) 00:09, 1 July 2016 (UTC)
The 1620 was the first computer to offer an integrated plotter as a peripheral. The 1627 plotter was made by Calcomp and marketed by IBM for the computer. It normally was installed in place of the 1621 paper tape, but both could be installed on special order. — Preceding unsigned comment added by Nworth (talk • contribs) 23:30, 3 December 2011 (UTC)
The PUA character  is used several places in the article. It should be replaced by Unicode, or if that's not possible, substituted as I did here, but forcing the font to be one that displays the character properly. — kwami (talk) 22:36, 17 January 2014 (UTC)
- Found an img for the 1400 series. I assume it's the same symbol? — kwami (talk) 06:46, 18 January 2014 (UTC)
Card vs. paper tape
I added a requested citation for the statement "Most 1620 installations used the more convenient punched card input/output, when it became available, rather than paper tape." But I think if anything that is a misleading understatement. Does anyone know of a 1620 installation that did not punched cards? All the installations I know of certainly did. I know the card reader was not available at the initial announcement, but I don't think a 1620 was usable in any practical way without card I/O. SPS, Fortran and all the other programming languages were based on fixed card formats and to my knowledge, IBM never made a device for keying text into paper tape, much less editing such tape. I used paper tape on a LGP-30 in 1965, with off-line Flexowriters, which was a real pain to edit programs on. But every IBM programming installation I ever used or heard of employed punched cards for program input until well into the 1970s.--agr (talk) 23:51, 16 July 2015 (UTC)
- I took out the potentially misleading "when it became available" --184.108.40.206 (talk) 15:16, 5 November 2015 (UTC)
- The entire first production run (B-Suffix) was paper tape only. The SP-008 SPS Assembler and SP-<mumble> One-Pass SPS Assembler were written for paper tape. The later 1620/1710 SPS came in Card (SP-020) and Paper Tape (SP-021) versions. (No doubt there's a Disk version too.) SP-021 punches 80-column records which I believe are card images. I have all three paper tape versions of SPS. The shop whose 1620 I eventually acquired used Flexowriters for offline tape preparation. Sadly, an unsavory character snitched them before my scheduled pickup. Vintage Dave (talk) 19:04, 11 July 2016 (UTC)
Character and Op code table
The Character and Op code table does not show the two digit op code as a simple decimal number. I realize that a couple of special instructions use the flag bit, but the vast majority of instruction were known by their two decimal digits.--220.127.116.11 (talk) 15:16, 5 November 2015 (UTC)