What did code on punch cards do with the other six bits per column?

Question

In the fifties and sixties, program source code was typically stored on punch cards, one card per line.

The most common card format was the IBM 80 column by 12 row. For source code, this was commonly used as one character position per column, the first 72 columns used for actual code, the last 8 for a sequence number. (Practical application: if you dropped a deck of cards all over the floor, after you picked them up, you could get them automatically sorted by the sequence number into correct order again.)

In those days, computers didn't really do lowercase. Uppercase text only needs six bits per character.

That means six bits per character were left over. What were they used for, if anything?

Answer 1

TL;DR;

Punch card code is not binary but a collection of n out of m encodings.

---

Long Story

Yes, really a long story, so I'll only cover the main line from Hollerith to EBCDIC. There are many sidelines for special equipment, situations and as used by different manufacturers. Some covering up to 7 holes but all mostly compatible in the basic Numeric/Alpha region ... a bit like the various ISO 646 encodings :)

Punch card encoding is essentially combinatoric and based upon decimal - with one hole per number - as it did grow out of numerical only - and based on the way cards were seen:

Example:

  COL 1234...
ROW  ,-------~
  12 |
  11 |
(1)0 |0000...  (Row zero is called 10 when it's about Alpha)
   1 |1111...
   2 |2222...
   3 |3333...
   4 |4444...
   5 |5555...
   6 |6666...
   7 |7777...
   8 |8888...
   9 |9999...
     '-------~

Notation: Punched characters are described as their row numbers connected by hyphens, like 12-1 marks an A.

Numbers

Numbers use a one out of ten encoding. A number gets only one hole within a column. Rows 11 and 12 were used for - and + as sign.

(Upper Case) Letters

To add alpha, a two out of twelve encoding was used (or more precisely, one out of three plus one out of nine) Each of the 26 basic (English) characters got one 'group' hole in row 10..12, called 'Zone', and a 'number' hole in 1..9. 3 x 9 = 27 combinations, a pleasant fit to hold 26 character, isn't it?

• A..I got a hole in 12 plus one in 1..9
• J..R one in 11 plus another in 1..9, while
• S..Z had it in 10 (0) and 2..9.

The surplus combination (27 positions minus 26 letters) was assigned to 10-1 to avoid having two adjacent holes (*1).

      RETRO
     ,-------~
  12 | X
  11 |X XXX
  10 | 
   1 | 
   2 | 
   3 | 
   4 | 
   5 | X
   6 |    X
   7 | 
   8 |  X
   9 |X  X
     '-------~

Punctuation

To add punctuation, the scheme was repeated using a three hole encoding. This time a hole in row 8 marks all punctuation, with characters as none or one out of three (10..12) plus one out of six in row 2 to 7, allowing up to 24 symbols.

      *C+=1
     ,-------~
  12 | XX
  11 |X   
  10 | 
   1 |    X
   2 | 
   3 | X
   4 |X
   5 |  
   6 |  XX  
   7 | 
   8 |X XX
   9 | 
     '-------~

Lower Case Letters

EBCDIC finally added lower case letters by again using 3 holes, but this time two in the group section (10..12), making it a two out of three plus one out of nine (1..9). Except for the added group hole, the encoding was exactly like the uppercase, so

• a..i like A..I plus 10 (0)
• j..r like J..R plus 12
• s..z like S..Z plus 11

      Retro
     ,-------~
  12 | XXXX
  11 |X XXX
  10 | X
   1 | 
   2 | 
   3 | 
   4 | 
   5 | X
   6 |    X
   7 | 
   8 |  X
   9 |X  X
     '-------~

Control Characters

Control characters were filled in with EBCDIC as well, much like punctuation, but this time with an additional hole in row 9 and using a one out of three (10..12) plus one out of seven (1..7) producing 28 possible control codes.

Oddities

Two control characters (NUL and DS) use a five hole combination, while SPACE means no hole at all (and differs form BLANK). 12 alone has been redefined to & as + wandered over to 12-8-6

          S
          P
          AN
          CUD
      &-/+ELS
     ,--------~
  12 |X  X X
  11 | X    X
  10 |  X  XX
   1 |  X  XX
   2 | 
   3 | 
   4 | 
   5 | 
   6 |   X
   7 | 
   8 |   X XX
   9 |     XX
     '-------~

Bottom line

Although a hole might be seen as a binary values, punch card holes are not, but represent their row.

---

*1 - It was later used for the slash (/).

Answer 2

Uppercase text only needs six bits per character.

The fundamental mistake that you are making is assuming that punch codes were binary numbers. They were not.

The encodings were patterns, combinations of of zero, one, two, or three holes. This is a reference card in IBM 5081 format:

The row numbering was somewhat odd, for historical reasons: 12, 11, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9. Notice that the IBM 5081 here doesn't number rows 12 and 11.

A complete explanation would be complex and long, and probably obscure the point. But briefly:

• Space was zero holes.
• The 12 one-hole patterns, through all rows, represented a couple of punctuation characters and then the digits 0 to 9.
• The remaining patterns were a combination of a range selection code, in the "zone" rows 12, 11, and 0, and an ordinal encoded in the "digit" rows 1 to 9. The "zone" rows effectively bank-switched the meanings of the "digit" rows.
• The 27 major two-hole patterns all had exactly one hole in the "zone" rows and another hole in the 1 to 9 "digit" rows. 3 × 9 was enough for all uppercase letters of the English alphabet plus slash.
• Things got complex with the further patterns, which were punctuation but whose exact meanings varied over the years, and from manufacturer to manufacturer. In these patterns, "digit" row 8 was always punched, and the rest of the pattern was one hole in the "digit" rows 1 to 7 combined with zero (making two-hole patterns) or exactly one (making three-hole patterns) hole in the "zone" rows. This made for 4 × 7 combinations.

In the IBM 5081 picture, the two one-hole patterns with holes in rows 12 and 11, representing two punctuation characters, are in fact there, but presented in the middle of the three-hole patterns. The two-hole pattern for slash, with holes in rows 0 and 1, is similarly presented out of place. This makes it less obvious that there are in fact one unassigned two-hole and three unassigned three-hole patterns with row 8 punched, here.

EBCDIC looks odd to eyes used to character codes in binary. It makes a lot more sense when viewed as punch codes. There is a direct correspondence between the upper nybble of the EBCDIC code and the "zone" row pattern, and between the lower nybble of the EBCDIC code and the "digit" row pattern. There are tables showing this in detail in all three further reading items.

Further reading

• Douglas W. Jones. Punched Card Codes. The Punched Card Collection. University of Iowa.
• John J. G. Savard. The Punched Card. quadibloc.com.
• W. Wayne Black (1971). "Appendix 4: Punch Card Codes". An Introduction to On-line Computers. CRC Press. ISBN 9780677029306.

Answer 3

Although you have many correct answers describing the nature of the coding used in punched cards, no one has touched on the mechanical properties of the cards. Regular users of punched cards in the past would be familiar with this issue, as getting cards through the mechanics of a fast card reader regularly and repeatedly was a major issue at the time.

If a card used all the holes in a vertical column (used to represent a character) then it would be much weakened and flimsy. It would not handle like a card and would very likely shred and thus jam the card reader. The design of the pattern of holes took issues like this into account, using just enough holes to convey information, but not so many holes as to remove any stiffness properties of the card.

Cards lost their stiffness due to environmental issues, such as humidity, dampness and so on. This also caused them to jam up readers. Card reader jams was a regular daily occurrence in the day.

That is a very strong reason why not all 12 x 80 holes were used in the coding.

However it was possible to do this, and some IBM machines had this capability, and created what were known as lace cards. More details are shown in Wikipedia.

Answer 4

The code punched into a 12-row card is not a binary code, but actually a form of extended decimal coding. Rows 0-9 are used to directly encode decimal digits, while letters and symbols are encoded as one decimal row plus one "zone row" which could be the A, B or 0 rows.

Within the IBM 1401 series, this was re-encoded as an extended-BCD code in six bits. Two of the bits record the zone row used (if any), while the other four encode the decimal rows. This encoding propagated to the tape format.

Each machine word on the 1401 had two additional bits for a total of eight; a "word mark" bit which was used to delimit instructions and data, and a parity bit for error detection. These bits could not be encoded on a punch card.

Answer 5

More historical folklore...

As late as 1978, I worked on META-4 systems at Digital Scientific Corporation that still supported punched card readers, and even had to write microcode to allow the systems to be bootstrap loaded from a single punched card. These systems emulated IBM 1130 and 1800 computers, which were typically booted from a single punched card.

The card only contained 12 "bits" per column, but during the special "initial program load" (IPL) or "boot load", the 12 bits were mapped into the 16-bit "words" of the main memory at addresses 0-79, then the computer began executing the code starting at address 0. This code then read the "boot sector" - sector 0 of the primary disk drive, which contained the next sequence to load the operating system. The mapping of the 12 bits to 16 bits was pretty cute, as the instructions that could be used had to only use those "bits" that were mapped and had to have zero value bits for the 4 instruction bits not provided on the card.

Answer 6

For completeness, here is an example of a punch card in the row-order byte-based Soviet GOST encoding.

     ,--------------------------------------------------------------------------------.
  12 |  X     X   XXXX X   XX  X  X  XXX    X   XX   X  X X X X   XXXXX X   X XX   XXX|
  11 |X X XXX XX  X XX X   X XX   XXXX X      X X XXX X XX X XX   XXXX X    XX X  X  X|
  10 |  X XX  X XX    XX  X   X   XXXXX X XXX  X  X X   X  X XXX   XXXX   XXXX  XX  X |
   1 |X X XX X  X  X XX   XXXXXX   X    X      X  XX  X XX  XXX   XXXXX XXXXXXX X XXX |
   2 |XX     X    XXX X   XXXXX   XXXXX XX    X X XXX XX   XXX  XX  X   X  X X X  XX  |
   3 |X   XXXX  XX   X  X  X XX   XXXX X  X X XX    X   X  X X X  X  XX XX X XX   XXXX|
   4 |XX  X XXX X XX XXX    X XX  X     X X X X XX  XXX   XXXX  X      X  X  XX   XXXX|
   5 | X    XX X  X  XXX     X  X  X XX   XXXXX X   X XX   X  X X XXX  X   X XX XXXXXX|
   6 |X   XXXX X   XX  X  X  XXX    X X   XXXX X       X  X  X  X XX    X  X X    XXX |
   7 |                                                                                |
   8 |                                                                                |
   9 |                                                                                |
     '--------------------------------------------------------------------------------'            

It contains the text "A QUICK BROWN FOX JUMPS OVER THE LAZY DOG. PORTEZ CE VIEUX WHISKY AU JUGE BLOND QUI FUME."

Answer 7

It's been mentioned already that cards were also used to hold binary data (and programs), specifically, using 2-columns representing 3-bytes. This must have been relatively modern, as prior to the introduction of System-360, IBM's mainframes (IBM 7090 et al) used 6-bit characters, packed 6 to a 36-bit word. I used a (then very old) IBM 7094-II back in the early 1970s and I remember encountering boxes of cards holding binary data. I don't know whether the data was directly encoded (3x12 columns - 36-bits) or whether the data was encoded to ensure some anti-holes were present, ensuring the structural integrity of the card.

Answer 8

One or two things not mentioned on this trip down memory lane.

Columns 73-80 were used for sequence numbers on fortran (and probably other) source code cards because the IBM card readers on the 7090 series computers did not read those columns; they read the card as 24 36 bit words.

We did use binary cards on CDC 3600 computers to store compiled programs and I remember patching such decks sometimes actually replacing a hole with a chad from the scrap bin in the key punch

I saw but did not use cards with circular holes; I think these were used on early Sperry Univac systems.

Answer 9

When I worked with keypunches and card readers, the most common issue I faced was a jammed keypunch. You could often clear a keypunch with a card saw, but sometimes one of the punches stuck down, and then you needed a service call to IBM for a repair.

One of the things I most dreaded was dropping someone's card deck. It happened to all of us, and there was really nothing to do but collect and rubber band the cards and attach a note of apology. Most user's didn't mark or number the cards, so it wasn't easy to correctly order the deck.