Talk:IBM 1401

Introduction from RTC

Edward G. Nilges 3-25-2005 spinoza1111@yahoo.com: I have added information to this excellent article on 1401 software, notable installations, and in summary as to its human impact based on sources and personal experience. Let me know what you think, oh Collective.

Keep right on going with anything you have. Please register a user name, so we can get to know you. -- RTC 00:23, 25 Mar 2005 (UTC)

I have registered with spinoza1111 and all contributions should appear under this userid.

IBM 1401: fixed I/O memory

From memory (of IBM UK Education Dept, 1961 - 64) the reason op codes 1 - 7 incl. did not need an address was that cards were always read into memory locations 1-80 and were punched from locations 101 - 180, and the line printer printed from locations 201 - 332 (printer line width was fixed at 132 characters). This led to the most noisy instruction being the single op code 7 which read a card, punched a card and printed a line.

I also remember the difference between group marks and word marks, but not how they were coded. A word mark identified the op code. A group mark might have been relevant only with tape I/O, but my memory is not clear on this. Was the character size increased by 1 bit to incorporate the word mark?

Van.snyder (talk) 01:07, 3 April 2011 (UTC) Word mark is an extra bit in each character. Group mark is BA8421. Group mark with word mark stops transmission, either on tape or any other I/O that's not unit record (cards or printer). On the 1440, even unit-record I/O is character serial, so GMWM stops all I/O transfers.

I also have a good memory of SPS, the assembler programming language, and recall writing the manual on the "Sterling Hardware Feature", almost universally installed in the UK, This used the Move Characters and Edit instruction, which was incorporated into the design to allow users of non-decimal currencies and weights and measures to write commercial programmes simply.

David Collins

dscollins@dsl.pipex.com

In the early 1970s, Computer Technology Inc. had a data center in Arlington, TX, that included several large System/360 computers, along with a S/360 Model 30 connected to one of the large machines through a channel as a peripheral device, solely to use its 1401 Emulator. Tom O'Brien

Software

paragraph: "Major software on the 1401 included a simple assembler called the Symbolic Programming System (SPS) and a more advanced form of assembler, Autocoder. The only high-level language in common use was the RPG (Report Program Generator) language, a declarative language primarily for specifying accounting reports still in use on IBM's midrange AS/400."

Actually, a language called FARGO (Fourteen-o-one Automatic Report Generation Operation) was the predecessor of RPG. --YORD-the-unknown 15:50, 19 July 2006 (UTC)

The 1.4K, 2K, and 4K machines could not compile programs ...

The 1.4K, 2K, and 4K machines could not compile programs, and had to be supplied with programs compiled on a more expensive machine. Assuming that "compile" as used here includes "assemble", I deleted this text and added some storage requiremnents to the later text about software. 69.106.254.246 17:42, 17 September 2006 (UTC)

Good, I always felt that needed clarification. However I didn't have any details myself. -- RTC 20:16, 17 September 2006 (UTC)

Thanks for cleaning up the wording; knew that I hadn't done the complete job; my style seems to be collect first, polish later. The details are all from online manuals via one of the external links, not the kind of stuff I would trust memory for. btw, I seem to see your tracks wherever I go. 69.106.254.246 23:07, 17 September 2006 (UTC)

The CADET Name

Internally, the 1401 mainframe was unusual, because it did not use adders -- principally because BCD adder circuits are more complex than binary adders. The 1401 therefore performed addition (and other arithmetic operations) by Table Lookup. In other words, to add (say) 7 and 9, the machine went to a table and looked up the intersection of 7 and 9, finding the answer 16, and brought that back to the data being processed. And so, for larger numbers, where elements were added, e.g., 14 + 32 was processed by looking up the sum of 4 + 2, then the sum of 1 + 3 (multiplying the answer by 10), then adding the results. Seems cumbersome, but less so than a full BCD adder.

For marketing purposes, the 1401 System was called the CADET. Because of the unusual arithmetic processing design, the machine was known among IBM engineers on the project as Can't Add, Doesn't Even Try.

The 1401 was never known as "CADET." That was the 1620, which never had arithmetic circuits. Arithmetic was done by table lookup. We used this to write programs that worked in octal instead of decimal, for telemetry processing. Van.snyder (talk) 01:03, 3 April 2011 (UTC)

1402 Reliability Check

The 1402 Card Reader-Punch was innovative in that it read card holes optically, not by brushes as in earlier card readers. In previous machines, a row of 80 brushes was provided, one brush per column. Punched cards would pass under the brushes, so when there was an open hole the brush tip would make contact with the underlying metal surface, completing a circuit and creating an electrical pulse. Because the pulse timing corresponded with the position of the on-the-fly card, the row was identified in the corresponding column. This system worked fairly well with low-speed card movement, but at higher speeds the brushes sometimes would not make contact; and in any case, the signals were not "clean", i.e., staticky. (By the way, that is why IBM cards had rectangular holes, rather than round holes which were of course easier to make.)

Optical hole readers allowed an order of magnitude (or more) greater speed in reading cards. This was very important, as reading data (or instructions) from cards was the limiting factor in how fast the machines could process data. Reading cards electronically, rather than electrically, helped move data input speeds closer to the processing speeds of the machine's electronics. That is why 1401 systems were often used as the data I/O interfaces for larger systems, such as the 700 and 7000 series machines.

The optical system featured a row of 80 photocells, positioned below an illuminating light, with the card passing between them. When the card had a hole, the photocell would be energized, and the signal would indicate that the card was puinched in that position. However, there was great concern that if one of the photocells (or the illuminating light above them) would fail, then the data input would be erroneous -- and possibly many cards, perhaps thousands, would be read incorrectly.

I was the engineer who designed circuitry such that all 80 photocells were checked before the card arrived at the read station (all ON), then checked again between the card edge and the first row (all OFF), then checked again between each row (all OFF), then checked after the final row (all OFF), then checked again after the trailing edge of the card passed (all ON) but before arrival of the subsequent card.

With this system, any photocell (or light source) which failed would be detected immediately. The machine would be brought to an immediate stop, so that the failure could be repaired and the operation re-started with the card in process when the failure occurred. In this manner, the reader could be operated as fast as the cards could be pushed through, without encountering problems of vibration, tearing, folding, etc.

On The Topic of Punched Cards

One might wonder why IBM punch cards were made in the size that was chosen. Certainly they could have been much smaller, still with plenty of space for 80 columns and 14 rows. In fact, competitors did utilize much smaller cards in their equipment.

IBM chose its card size to be identical with the size of US currency, in the 1920s and earlier, prior to its being changed during the Great Depression. That was so customers could store their punched cards in the drawers of cash registers, and other containers for currency. Thus small merchants could record their sales, inventory, and payroll data on cards, store them in available compartments, and not risk having the cards slide around into a jumbled mass or even perhaps slide our of sequence. This actually was a big selling point for the IBM sales force.

Because of these oversized cards, IBM became the largest purchaser of the particular cardboard stock, which was used by all manufacturers who made punched-card equipment. Wehn the US Government changed the size of currency, IBM retained the original card size because there was so much equipment in existence using the original card size. Changing card size would have meant either replacing all of the equipment in being (much of which was being rented to customers by IBM), or else requiring customers to have two sizes of data processing equipment. So the original card size persists to the present day -- though of course, punched cards are little used presently for data storage.

The use of punched cards became so vast, that the sale of (blank) cards became one of IBM's main revenue sources, and one of its most profitable businesses.

Comments from Kent L. Aldershof; Aldershof-MSII@Prodigy.net —Preceding unsigned comment added by 70.111.225.17 (talk) 20:32, 27 November 2010 (UTC)

Thanks for the interesting comments. What competitor had smaller cards? Remington Rand had more data (90 characters) on its cards, but they were the same size. I suspect the card size was appropriate in the electromechanical era, the rectangular holes produced nice clean pulses to relays when brushes made contact through them as the cards passed through the read station. Making all the mechanical equipment much smaller was probably not feasible in the 1920s and 30s. IBM introduced a much smaller format with the System/3, but that was late in the game and didn't last long. Also, I heard the CADET story about the IBM 1620, which used a lookup table for addition. The 1401 did have an add instruction, op code A.--agr (talk) 20:46, 28 November 2010 (UTC)

1402 LOAD button

I like completeness and left to myself, will add all kinds of stuff. But I think details of the 1402 LOAD button do not belong in the article. Memory, Addressing, Instructions are necessary to understand the 1401. The function of the LOAD button is a operational nit. Can we delete it?

I'd also delete the existing text about errors, just more operational nits. 69.106.254.246 07:56, 18 September 2006 (UTC)

Character and Op codes table is wrong

The BCD column includes "C", for check bit I assume, but the checkbit also includes any wordmark and so cannot be determined just from the 6 bit character.69.106.254.246 08:14, 18 September 2006 (UTC)

You are correct. Nevertheless, that's what's in the IBM manuals. Jeh (talk) 14:33, 17 March 2010 (UTC)

Announced as marginal...

Announced as marginal, and for the simple accounting of midrange companies and as a sort of slave print server to the IBM 7090, the 1401 (like many other platforms before it and since) attracted its own hard core of devoted followers, who could see that although marketed as limited in function, the 1401 was in logical terms a real computer, whose secrets could be unlocked by people sufficiently patient to understand its arcane addressing scheme, and to devise ways around its limitations.

I was there, programming 1401's for the US Army, IBM, ... from 1959 to about 1967 and disagree with almost everything in that sentence. So I am a "hard core ... devoted follower", but am I wrong? Did IBM really sell 20,000 marginal machines? 69.106.254.246 06:01, 18 September 2006 (UTC)

Found IBM announcemet day material. Inserted some text from that and deleted the "marginal" paragraph as unsupported!69.106.254.246 20:16, 18 September 2006 (UTC)

An optional "Advanced Programming Option" allowed for additional flags for 3 bytes within the first 100.

I used to program the 1401 - lots - and I have no idea what that sentence means.69.106.254.246 05:41, 18 September 2006 (UTC)

Funny - I was just going to say the same thing! It may have something to do with the optional index registers... I suggest we delete this sentence unless someone clarifies it.Jpaulm (talk) 14:22, 3 November 2008 (UTC)

Deleted. Only took 18 months. :) The index register scheme is covered in the next graf. Jeh (talk) 18:24, 18 May 2010 (UTC)

Deleted "...1969 ... Red concertgoers"

"An IBM 1401 installation located on Michigan Avenue and Congress Parkway was attacked in 1969 by Red concertgoers to a Sly and the Family Stone concert but the crowd did little damage.-ref-Chicago Tribune, 2 August 1970, Page A1-/ref-"

As best I can find the concert was July 27, 1970 (not 1969 - note the Tribune 1970 date) and the concertgoers were disappointed at the no-show Sly & Family. If they were "Red" (with a capital "R"!) it would have been because of summer weather in Chicago. Too many mistakes, too little contribution - deleted. 69.106.237.145 (talk) 08:32, 19 April 2011 (UTC)

Link to Bit slicing deleted

I deleted it because I don't think it applies. A bit-slice microprocessor, as the term is normally used, is a complete MPU and can be used as such in its own native bit width; or it can be combined with others to implement wider MPUs. The fact that IBM implemented one bit of, say, a BCD adder on a card and then used multiple cards to handle the entire BCD digit isn't really the same thing. Those cards were never intended to be used independently, nor could you have combined eight of them instead of four to implement a wider-bit-width adder. Anyway, a tremendous number of discrete transistor machines, to say nothing of tube machines, did something similar with a card or module implementing some basic function for a single bit. If this means the 1401 is a bit-sliced implementation, then so are they all, and the term loses most of its meaning. I'll leave the references to the 1401 on the Bit slicing page alone pending consensus here. Jeh (talk) 18:33, 29 April 2011 (UTC)

I'll "consent" either way, it's out of my field -- just so that both articles agree. (it's nice to know someone is reading this) 69.106.237.145 (talk) 21:48, 29 April 2011 (UTC)