2

I thought that punched cards already represent the code in binary since a hole means 0 and rest positions mean 1 on a punched card. But then I read that you could use punched cards to present the Cobol or Fortran codes. I also noticed that there are always 2 holes per column on a punched card. Such things have confused me.

enter image description here

Were the punched cards really binaries, or some sort of assemblers were needed to convert the input provided by punched cards to machine code?

I am particularly interested in knowing the oldest way of providing input to computers using punched-cards.

Improve this question
8
  • Are you asking how characters are encoded on punch cards, or how they were used for, e.g., Fortran programs?
    – Jon Custer
    Mar 10, 2020 at 13:48
  • For Fortran, the cards held the program - human readable characters at the top, the encoding in the holes. Those got read in, compiled, and run. (I was one of the last users of punch cards at my university. Terminals to the IBM mainframe were all the rage, making them hard to get, and slow once everyone was on. Yet, every 5 minutes the punch card reader ran at top priority, so my edit/compile/run cycle was faster than anyone else's.)
    – Jon Custer
    Mar 10, 2020 at 13:54
  • 1
    Some systems used punched cards for binaries directly encoded in holes, see retrocomputing.stackexchange.com/q/2080/4025
    – Leo B.
    Mar 10, 2020 at 14:53
  • 1
    It might be worth pointing out in the answers that punched cards predates the computers. So early computers using punched cards adapted the use of cards as data storage first, then redefined how to use the cards.
    – UncleBod
    Mar 10, 2020 at 16:40
  • 1
    I think it is at most related, but not dupe.
    – peterh
    Mar 11, 2020 at 15:08

5 Answers 5

Reset to default
6

Punched cards generally contained human-readable source code or data. In combination with computers, they were pretty much exclusively used as a data entry (as opposed to data storage) medium. You can find an example of the encoding used in the section "IBM 80-column punched card format and character codes" of the Wikipedia article, https://en.wikipedia.org/wiki/Punched_card.

Binaries were typically stored on magnetic tape or paper tape, towards the end of the punch card era also on hard disks and (at the very end) floppy disks.

Improve this answer
2
  • 3
    Cards sometimes stored binary data. I worked a year or two as a teen in a data center that had an automatic card punch. It was by far the loudest machine in a very loud environment -- and you could easily tell when it was producing a binary deck, because its noise, normally a rhythmic chatter, turned to more of a bellowing snarl. (It punched every hole for a card in a single cycle, about four cards per second.)
    – jeffB
    Mar 10, 2020 at 14:53
  • I think your 'typically' depends on year and usage. For example, I used an IBM 7094 under IBSYS in the early 1970s (it was probably obsolete then, so schoolkids could use it). The OS and system library were on magtape; the only long-term storage available to us was cards. The dominant mode was "program and data on cards ==> output printed on paper".
    – another-dave
    Mar 10, 2020 at 23:19
5

Preamble

We tend to use the word 'binary' in an odd way when talking about the content of computer storage. Fundamentally, storage is always binary: zeroes and ones. But we talk about 'text files' when we mean files in which the zeroes and ones are supposed to be interpreted as making up characters which have meaning to humans (can be printed, etc.), and then files that are not text files get called 'binary' files, even though they're all binary really.

Likewise, the holes in cards can mean 'binary' or 'text', though again it's all fundamentally hole or not-hole. But the way the information is arranged is somewhat different between the two modes of operation.

Binary data on punch cards

How binaries are generated using Punched cards?

From the 30,000 foot level, the principle is pretty much the same regardless of input device. There are some 'marks' on a storage medium. A special device (and its controller) knows how to convert those marks -- whether they're patterns of magnetization on a rotating disc, or charges in very small capacitors, or holes in paper -- into signal levels which represent ones and zeroes to a computer, and then to use those signal levels to write the ones and zeroes into memory.

For a card, you typically end up with 80 columns x 12 rows of ones and zeroes stored in memory. What those ones and zeroes "mean" is system-dependent. There are probably two "modes" in which cards may be interpreted: "text" mode in which each column is considered to be a character in some arbitrary encoding (usually one, two, or three holes per column), and "binary" mode, in which there's some defined more-or-less direct mapping between the holes in the card and words in memory.

Consider the case of a 36-bit computer. One possible arrangement for binary card files is to say that one card row, from columns 1 to 72, will hold two words of memory. Thus one card (12 columns) can hold 24 machine words, and there will be a convention that the controller and/or computer implements for transferring those words to memory. Maybe top row, cols 1 to 36 to word N, top row cols 37 to 72 to word N+1, next row, cols 1 to 36 to word N+2, ...

The IBM 709/7090/7094 systems used this sort of arrangement. Binary decks would be punched by compilers and loaders, and read in for exexcution.

This Wikipedia article on the IBM 711 card reader describes the read-by-rows arrangement, two words per row. 'Row 9' is the bottom row of the card (from the top to the bottom, the rows are numbered 11, 12, 0, 1, … 9).

Can I feed the binaries to the computer directly?

Yes in general, though the details depend on what you're exactly arguing.

You may be able to boot the computer from cards, as part of the general mechanism of selecting an input device and executing the computer-specific boot procedure.

The IBM 701 (~1950s era) allowed this. See for example this article about the 701, on the page numbered 1273 -- it's a journal extract, not that big!

A boot deck would have to be punched precisely according to the hardware requirements. One card might well be enough for the bootstrap.

Could you run a binary program from cards under an operating system?

Depends on the OS, of course. In general, yes. It's just bits, and it likely doesn't matter where the bits came from. The only requirement is that the loader can handle sequential file input, since there's no going backwards and forwards on a card reader. Offhand, I can't think I've ever tried this -- but I have known (now forgotten) of systems that supported punching out a program image, which is pretty pointless if you can't then run them.

Text data on punch cards

I also noticed that there are always 2 holes per column on a punched card. Such things have confused me.

Cards with 'fewer' holes are likely cards that are to be considered as text. There is one character punched per column, with each character encoded as 0 to 3 holes. No holes is a space. Roughly speaking, the code space is laid out like this: the digits are encoded as one hole, in rows 0 to 9 with the obvious meaning. Letters are encoded as two holes, one of which is in row 11, 12, or 0, and the other in 1 through 9. Other 'special' characters need 3 holes. You can see the encoding on this page a little way down.

Improve this answer
3
  • Could cards with binary data be fed reliably at the same speed as text cards? An IBM card where large contiguous rectangular groups of holes are punched (generally possible with binary data) would seem like it would be mechanically far less robust than one with at most two consecutive columns punched, and prone to tearing in high-speed feeders.
    – supercat
    Mar 11, 2020 at 18:36
  • I don't know what controlled feed speed; the user did not. But yes. risk of jam increased with punching density. Wikipedia refers to lace cards being intentionally used to cause a jam. They say 'prank', I say 'denial of service attack'. FWIW, my only experience with reading cards in 'binary mode' was in a program than needed to understand foreign card codes on a DEC PDP-11, i.e., it was text but not text that the driver could interpret as text.
    – another-dave
    Mar 11, 2020 at 18:57
  • The speed of feeders may not have generally been under user control, but if one can avoid the need to use very many lacy cards in a boot process, it may be practical to manually feed those.
    – supercat
    Mar 11, 2020 at 19:05
4

I thought that punched cards already represent the code in binary since a hole means 0 and rest positions mean 1 on a punched card.

Virtually all computer data is stored or transmitted in "binary" at some level. In order to interpret most data, you have to delve through multiple layers of meaning... multiple layers of codes.

When you get to the lowest layers, you practically always find binary data---patterns of high and low voltages, punched holes or not-holes on a card, magnetic domains on a disk platter---that can be understood as "1s" and "0s."

But then I read that you could use punched cards to present the Cobol or Fortran codes

The patterns of holes and not-holes on a card can be interpreted as character code points--one code point in each column of the card. Sub-strings can be interpreted as "tokens" (words, numbers, special symbols). Strings of tokens can be interpreted as statements in Fortran or Cobol. It's all layers upon layers.

One program--a compiler--could read a stack of cards, and expect to interpret the data as a Fortran program. Another program--maybe an accounts payable system--could read a stack of cards, and expect them to represent rows in a database. Another program--the computer's boot loader--could read a stack of cards and expect to interpret the data as machine instructions to be loaded directly into RAM and then executed.

Were the punched cards really binaries, or...?

Were floppy disks really binaries? CD-ROMs? Thumb drives? Punched cards, like all of the above, are just a means of delivering data to a computer. What the computer does with the data depends on what program reads the data, and on the layers of meaning that the program ascribes to the data.

I am particularly interested in knowing the oldest way of providing input to computers using punched-cards

I don't know how to find that for you, but I'm pretty sure that all you have to do is find the oldest computer that could read punched cards, and ask how it read them.

Improve this answer
1
  • The IBM 701 is probably a good contender for 'oldest'.
    – another-dave
    Mar 10, 2020 at 23:28
1

Punched cards are not a "binary" or "text" format; like files in a Unix system they are simply streams of codes (albeit much smaller streams—80 codes per card if you read each column as a code). These can be interpreted as character codes as in a "text file," as binary codes to be loaded and executed as in an "executable file," as a sequence of decimal numbers, as some other kind of binary data, or anything else.

If they are intended to be interpreted as text (e.g., lines of a program) typically the characters represented by the punched codes will be printed along the top. For cards not containing data intended to be interpreted as text, anything (or nothing) might be printed along the top; what is printed need not bear any relation to the codes. (Some, perhaps many, keypunch machines, however, would print only the characters for codes they punched.)

Even within a deck, interpretations of particular cards might be different, and done by different programs. Decks typically started with "job control" cards that used a job control language (JCL being a famous one) to give instructions to the machine about what to do with subsequent cards, such as run an assembler or FORTRAN compiler on the data they contain, and where to send the output of that subsequent program.

Improve this answer
1
  • @another-dave Yes, good idea! And thanks for helping me clarify my answer.
    – cjs
    Mar 11, 2020 at 3:21
0

The earliest use of punched cards for computing was not in what you'd nowadays call a computer, but in Hollerith tabulators and similar machines, which were the 1930s state of the art for business and scientific calculation. They would be set to perform a particular operation, such as summing all the cards that were fed into them, or multiplying the values on one deck of card by those on another; then you had to set them up again for a different operation. Some other early machines used punched paper tape, then primarily used in the telegraph industry.

The first computers did not have an assembly language. Instead you got an operator's manual which informed you about how to punch the card or tape to produce a given operation from the machine. So you entered machine code directly, after perhaps working it out using mnemonic code on paper, by hand. Assembly language was eventually developed so that you could just enter the mnemonics, and let the machine itself take care of the translation to machine code. Of course the machine code would vary between machines, often by a lot.

The particular cards shown in the question have rows numbered from 0 to 9. This indicates they contain decimal numeric data. One of the two punches in each column is a numeric, and the other is probably a parity bit. This suggests to me that they are cards for a Hollerith machine, not a computer.

Improve this answer
4
  • 1
    While the cards don't have the zone punch rows 11 and 12 (at the top) marked, they are punched, which suggests to me that they're likely not just decimal data. I've never heard of cards using a parity bit for each column.
    – cjs
    Mar 10, 2020 at 16:06
  • @cjs, "marked?" Ink on the card means nothing to the computer. The computer (or other data processing equipment) only cares whether or not there's a hole that light can shine through (high-speed reader) or metal fingers can feel through (old-school tech.) But, if you're talking about the cards in the photograph, then yes, those look like they represent text. If you were willing to spend a little time, you probably could decipher the one on the top of the pile.
    – Solomon Slow
    Mar 11, 2020 at 19:56
  • @SolomonSlow Yes, exactly my point! (Read my comment in light of the last paragraph of the answer.)
    – cjs
    Mar 12, 2020 at 5:12
  • @cjs. Mmm, Yes, I see. FBO Chromatix: If you look at it from a business applications point of view instead of a computer science point of view, then the progression from Hollerith's first tabulating machine to IBM's System 370 was a long sequence of many small improvements. There never was any bright dividing line between the computer age and what was before. [B.T.W., That picture of cards on a desktop almost could have been my desk, back in the 1970s. Only difference being, the cards on my desk probably would have been interpreted (i.e., row of human-readable print across the top edge.)]
    – Solomon Slow
    Mar 12, 2020 at 13:52

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