• Decimal oriented, (digits 0-9), variable field length machine used optional word mark bit in each character to identify end of field.
• Address pointed to lowest significant character, added in serial fashion.
• 2 address logic, the A address was the from address, the B address was the destination.
• Highest numeric address was 999, next address over 999 is using "A" and "B" bits
• op codes
  • L = load
  • A = add ie, A 419768 - and get following instruction for word mark 8 times to get instruction. a single add instruction could take 100 microseconds to get instruction and 3 memory cycle times per character, A + B -> B
  • B = branch
  • E = edit instruction, signs, CR - credit,
  • logenge - clear word mark.
• optional multiply and divide
• Address pointed to lowest significant character, added in serial fashion.
• The highest address was the least signifiacnt digit.
• bits 1,2,4,8 shown on console vertically
• above the 8 bit was the "A" bit then the "B" bit
• on IBM cards, numeric punches 0-9, zone punches "X" or "12", and "Y" or "11"
• "A" was a "12" and a "1" punch, through "I"
• "J" was a "11" and a "1" punch, through "R"
• "S" was a "0" and a "2" punch, through "Z"
• special characters were $,comma, period, logence a square with caved in sides

• minimum size machine had 1400 characters of memory
• Memory cycle time = 11.5 microseconds per character
• each character had 6 data bits, a word mark, and a parity bit.
• 1403 printer (a great machine) had a switch to permit 6 lines/inch (normal) or 8 lines per inch (a bit compressed). Printed 600 lines per minute (15 lines per second) which was typical in those days, but had the advantage that the print placement dispursion was mostly horizontal, not vertical, much more appealing to the eye. Could print up to about 5 carbon copies (common in those days) or also use carbonless "NCR" paper from National Cash Register.
• RAMAC - was a 1405 (physically similar to RAMAC 305) active, independent arms with read/write heads.

from Mike Cheponis

I asked one of my friends about the Sense Switch A needing to be up when reading cards to get an End of Card indication - and he did remind me that we always kept SS A up, but he didn't remember exactly why. And yes I do remember keeping SS A up, too. (But, it's been 28 years since I last used a 1401, so my memory is ever-so-slightly fuzzy about the details (!)) Also, as I recall, there was an option for the 1402 that let it read cards in "column binary".

from CKB Raju May 10, 2001

I read with much interest your web page on the IBM 1401. I have used that computer from 1964 to 1977 and had many interesting experiences with it. The reason for keeping the sense switch A up is to mark the last read card as the last record in that file. If there are more cards coming in you have to keep SS A down to prevent the software from assuming that the cards are all read.

• A Century of Smart: The IBM 1401 (1959) - YouTube
• IBM 1401, a User's Manual Part I - IBM 1401 Processing Unit (computer 'music')

• What makes the 1401 so interesting? OffSite, by LaFarr
• 1401 system restoration since July 2004 :-))
• "Computer Structures: Readings and Examples", (1971 edition) by C. Gordon Bell & Allen Newell Part 3, Section 3, Chapter 18
• Welcome to the IBM 1401 "Data Center"
• IBM 1401 Stuff and Links
• 1401s I have known by Tom Van Vleck

• IBM 1401 Data Processing System Reference Card, side 1, side 2.

• From Mike Albaugh
  [re: Fortran Compilier for a 4 K character 1401]
  I still have the "Internals" reference manual... :-) IIRC, it was derived from the 1401 compiler discussed in J.A.N. Lee's "Anatomy of a Compiler" book. That one had 63 phases. Note the terminology. A "pass" was used to refer to reading in (and writing out) the source code or a modified form of it. As used in the 1401 and 1130 compilers, a _phase_ was essentially an overlay of code. The first phase read the entire source into memory and built a partially tokenised form. Each successive phase "recognized" some particular construct and replaced it with some derivation. This might be, e.g. "recognize array references and convert to offset calculation", or "transform expressions to canonical form", or "emit object code for canonical-form expression".

  The major "win" is that one is only reading (code overlays), not reading-writing, so file allocation issues don't arise. One could even do this technique from sequential storage (tape, or even cards). The major "lose" is that an entire source file must fit in core, along with the largest "phase", modulo a little wriggling about being able to use larger phases when the source is in a more "dense" form. In practice, with sane-sized modules, it worked.

• from LaFarr Stuart FORTRAN Compilier (for 4K memory, card machines)
  • The cards were stacked in the card reader hopper as follows:
    - 30 to 50 cards (first pass?)
    - your FORTRAN source deck
    - about 3000 cards (more than a box) of maybe 60 passes of the FORTRAN compilier
    - maybe 3 inches of utilities, including variable precision math functions

    You pushed the LOAD button and stood back and watched

    - the card reader would read cards at mostly 800 cards/minute

    - there would be moments where the reader would miss a few cycles

    - at the end of the reading of the big deck,

    - the 1401 optionally would be running the compiled FORTRAN

    - and usually the printer would start printing the results of the program.

    ----

    1st phase took out the spaces, and stored it in the top of memory, first card highest

    2nd phase ?, looking for a "DO" loop, replacing with token, ...

    ....

    last phase picked up required subroutines, then go into execution - usually punching object included copying subroutines
  An interesting verification routine,
  • one coding sheet. Hilbert matrix, say 8x8 generate, invers, multiply invert by original, giving identy matrix.
  • Required at least 12 digits to do reasonably, better than 360 and many other machines.
  • Demo that worked on 1401 failed on most other machines. slick eh?
    (Required double precission on other machines.)

  LaFarr has a web page What makes the 1401 so interesting?

  and from LaFarr - Feb 2007 -

  Hi: It is only academic, but I thought the clear word mark switch could be used following any 7 character instruction such as Move, Load, Add, Subtract, etc. I am 99% certain we allowed it in the RCA emulators, and simulators. Of course I am biased, but I believe RCA had better emulators/simulators than anyone else, we even made sure that non numeric characters added produced true "1401" results. Unfortunately RCA's peripherals didn't produce true "1401" results. Even when they worked right! :-( We had no way to "stacker select" such as merge "in the middle pocket" cards from the punch and reader. Hence we made no effort to make stacker select work correct based on the time it was issued after a read/punch. (Essentially; on a real 1401, a multiply or divide instruction before a stacker select would take enough time to cause the stacker select to be ignored. But we all know timing dependent coding rarely works on simulators. I wish I knew more about IBM's emulators on the Model 30's and 40's worked on some of these questionable techniques. I know in the early days a lot of 30's spent a lot of time running 1401 programs.)

• In comp.lang.asm370, Clark F. Morris, Jr. wrote
  The names "Symbolic Programming System" and "Autocoder" were given to IBM assemblers for a number of unrelated pre-360 machines. These were assemblers in the modern sense, in that they allowed symbolic reference to program locations and data areas. On machines like the 1401 in which there were both SPS and Autocoder assemblers, Autocoder was the more elaborate one.

  1401 SPS was very simple, requiring symbolic operands to be in fixed-format fields of its input records and explicit coding of d-modifier characters, but these limitations allowed it to run in a minimal, 1400-character 1401.

  1401 Autocoder was a little more programmer-friendly, with comma-delimited operands, extended branch mnemonics with assembler-generated d-modifiers, and a simple macro facility, but it required a 4000-character 1401.