11

A 1968 Communications of the ACM article describes a proposed USA standard for encoding US ASCII (with a provision to encode all 256 bytes) on punched cards, attempting to keep existing industry standard encodings for capital letters, digits, and common punctuation.

The way control codes are assigned looks surprisingly haphazard. Unlike EBCDIC, it is impossible to tell how specific bytes with the high bit equal to 1 were intended to be punched, for example, where would 0x80 go, or 0xFF?

That said, were there any systems which actually used that encoding on punched cards, or its subset that is specific enough to ascertain its use?

256 hole-pattern table

13
  • That table uses a extreme unusual and unintuitive ordering. At first sight all encodings seem to be the same as used by EBCDIC. Might have to find time to read the cited article.
    – Raffzahn
    Commented May 17 at 23:25
  • @Raffzahn The encoding for NUL is unexplainable. I would have expected it to be 12-11-0 or 12-11-0-9; and the other one for 0x80.
    – Leo B.
    Commented May 18 at 4:26
  • 1
    Huh? 12-11-0 and, 12-11-0-9 are forbidden combinations. A basic rule about punch card codes is to avoid adjacent holes - especially three or more - and never have the upper three (12-11-10). Nicely visible in above chart by having the 12-11-10 columns empty. (And yes, above table adds 9-8-7 combinations, but NUL is older - and those triplets are in the numeric area).
    – Raffzahn
    Commented May 18 at 8:45
  • @Raffzahn Please read the description of the table. There are 256 hole-patterns for 256 8-bit codes. It means that all empty positions in the table are intended to be used.
    – Leo B.
    Commented May 18 at 16:27
  • 1
    @MarkHarrison Not just ancestors, but descendants. Binary cards were commonly used on the IBM 1130 (late 60s-early 70s), both for code and data. See pages 59-62 of media.ibm1130.org/1130-055-ocr.pdf. Bottom-level encoding was straight binary, three 16 bit words every four columns. The "lace card" angst was not present in that corner of the culture.
    – John Doty
    Commented May 20 at 18:37

4 Answers 4

16

Multics came close. Multics used ASCII for its usual text representation, and could punch and read it from cards. There were only six differences between the Multics card code and the ANSI standard. From the linked document:

enter image description here

4
  • 4
    Be sort of interesting to know why there were any differences at all? Why didn't the ASCII standards people just adopt the Multics encoding. Nothing stands out from that table above to indicate why the right column is preferred over the left column ... and the left column was already in use, but there must have been a reason ...
    – davidbak
    Commented May 18 at 20:51
  • @davidbak "Nothing", really? Counting the number of punches comes to mind.
    – Leo B.
    Commented May 20 at 4:55
  • 2
    Why is fewer punches for open/close bracket and vertical line a change worth making? And it doesn't explain the other changes. (FWIW, if I had to pay for card punching I was paying by the card, not by the number of holes in the cards ...)
    – davidbak
    Commented May 20 at 18:17
  • 1
    @davidbak Perhaps, hole-pattern similarities of [ backslash ] mimic their closeness in the ASCII table; similarly for { | }. The question to ask would be, what informed the Multics Standard Card Code, if its designers also wanted to encode ASCII.
    – Leo B.
    Commented May 20 at 20:05
7

This card code is not just proposed, it was actually adopted as a standard in ANSI X3.26-1970 Hollerith Punched Card Code (FIPS PUB 14), and remains in the most recent revision, ANSI X3.26-1980 Hollerith Punched Card Code FIPS PUB 14-1, May 1980.

The standard also includes extended punched-card codes for non-ASCII characters that would occupy byte values 128 through 255 decimal (0x80 through 0xff hexadecimal). I haven't found any specific evidence of vendors using these code definitions. It should be noted that the mapping of EBCDIC to punched card codes did ultimately include 256 codes, so it's possible that there is a full correspondence between them, though the non-card equivalents in ASCII and EBCDIC are obviously different.

However, the X3.26 punched card code for ASCII is not just some standard that was adopted but went unused. DEC used this exact card code in their card processing, at least as early as 1972. It is listed in the DECsystem 10 Operating System Commands manual, order number DEC-10-MRDC-C, 3rd printing, June 1972, in Appendix B, Card Codes, which is also reprinted as chapter 8 of the DECsystem 10 User's Handbook, second edition, 1972.

For DEC, this represented a change compared to their earlier practice, as documented in the (PDP-10 System Reference Manual, DEC-10-HGAA-D, April 1968, a slightly more recent version of which was reprinted in the 1970 PDP-10 Reference Handbook. These include, in Appendix B, Input-Output Codes, a table of card codes, whcih includes "DEC 029" and "DEC 026" codes. These cover the the DEC "SIXBIT" subset of ASCII 1963 (ASA X3.4-1963), which only includes the characters in columns 2 through 5 (hexadecimal codes 0x20 through 0x5f), no controls, no lower case. The DEC 029 code is quite similar to, but not quite identical to, the same characters in the adopted standard.

It's quite possible that DEC was represented in the standards committee, and in any case, the committee looked at existing practices as a basis for developing the code.

I had only minimal use of punched cards on a DECsystem-10, and at the time did not consider the details of the code that was used.

5
  • Were you typing all that from memory, or is there a reference material online?
    – Leo B.
    Commented May 23 at 2:43
  • I was referring to the specific documents I named. FIPS-14-1 can be found online by a search, and the DEC manuals can be found in the Bitsavers archive.
    – Eric Smith
    Commented May 23 at 4:28
  • 1
    @EricSmith It would help if you (or another editor) added hyperlinks to your answer, to make it easier to look up the references. (Reference-style Markdown links seem appropriate.)
    – wizzwizz4
    Commented May 23 at 7:16
  • Added some links.
    – Eric Smith
    Commented May 26 at 9:05
  • Did anyone really use punched cards in 1980? I worked at the Census Bureau where punched cards were invented, and they went key-to-disk in 1976. Commented Jun 5 at 15:56
4

Additional notes about Multics:
"The Multics standard card punch codes described in this section are DQ1 identical to the currently proposed ASCII punched card code. The ASCII standard code is not supported by any currently [03/30/67] available punched card equipment; until such support exists it is not a practical standard for Multics work. The Multics standard card punch code described here is based on widely available card handling equipment used with IBM System/360 computers."
http://people.csail.mit.edu/saltzer/Multics/MHP-Saltzer-060508/bookcases/MSPM/bb-3-02.670330.punch-card-codes.pdf

1
  • 1
    In two out of 5 characters mentioned in John Doty's answer (! and |) Multics diverged from IBM, while the proposed standard follows IBM (as per the document I refer to in the question). It appears that IBM was not internally consistent.
    – Leo B.
    Commented May 22 at 3:59
3

I think the coding represents a means of mapping a combination of punches in the bottom 8 columns to 4 bits and combining that with the pattern of punches in the top 4, so as to recognize 256 distinct punch patterns. The mapping of 8-bit patterns to characters, however, was chosen to be consistent with existing punch patterns. For example, digits 0-9 are each represented by a single punch in one of the bottom ten rows, and uppercase letters are mapped to a combination of one of the top three rows plus one of the bottom 9. Row 9 is repurposed to represent one of the top four bits directly, rather than representing bit pattern 1001 in the bottom four bits, but the bit patterns otherwise resemble EBCDIC more than anything else.

8
  • 1
    Still, it is unclear how, for example, 0x80 would be represented. Looking at the shape of the available space, there will be no consistent algorithm to convert "ASCII with high bit" to punch patterns.
    – Leo B.
    Commented May 17 at 22:55
  • 2
    0x80 would be eight columns from the left, zero from the top. Character code 0x80 is assigned to the glyph "9". I think the intention isn't so much that people use this as a code for character data, so much as something analogous to base64 encoding, but for punched cards, and using only one column per encoded byte. I'm not sure what advantage this would have over a more "binary" oriented approach like having odd columns represent the bits of a byte using rows 1245780- and even columns use 235689+-, an arrangement which would avoid any 2x2 region of punched holes.
    – supercat
    Commented May 18 at 4:30
  • 1
    Vertically adjacent holes do not matter as much as "lacing" due to horizontally adjacent holes. I know of an encoding that would fill 4 columns with 6 bytes, then left a column unused. Accounting for identifying information and a checksum, there were up to 84 payload bytes per card.
    – Leo B.
    Commented May 18 at 4:53
  • 3
    @LeoB. "Vertically adjacent holes do not matter as much" Sorry, but it's the other way around. Vertical holes are most influential to stability. Transport subjects cards to lengthwise shockwaves when handed over between between rolls/conveyors. Note that this may be not an issue for those tiny 200 or even 600 cpm readers, but it definitely is for serious machinery in the 1000..2000 cpm range - even more if those are reader/sorter devices with several meters of multiple transport and point sections. vertical hole combinations waken the lengthwise stability let them wiggle ad get stuck.
    – Raffzahn
    Commented May 18 at 10:14
  • 1
    @LeoB. (for reference, I got basic training as FSE in 1980 on those and similar OCR devices)
    – Raffzahn
    Commented May 18 at 10:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .