I'm here to pick up my pallet of Modern Warfare 2 punch cards.

January 13, 2010 7:22 AM

How much data, in bytes, does an old fashioned FORTRAN punch card hold?

I was talking with a coworker today who did programming on FORTRAN punch cards, and we got to wondering how much data a single punch card holds. Just for kicks: how many punch cards would it take to put Half-Life 2 onto a computer?

posted by codacorolla to Computers & Internet (16 answers total)

Here's the Wikipedia article on punch cards. Most seem to have been 80 columns by 12 rows; thus the maximum capacity of a punch card would be 960 bits, or 120 bytes. But this was apparently unusual. It seems like usually each column indicated a single character.
posted by madcaptenor at 7:35 AM on January 13, 2010

There were different types of cards, but let's assume that you were using an IBM card with 80 columns and 12 punch locations. At a maximum, this could correspond to 960 bits of information (or 120 bytes). In practice, it was doesn't quite work that way, though, because you couldn't punch every hole in every column, and different combos meant different things. Here's an example from that Wikipedia page:

     ______________________________________________
    /&-0123456789ABCDEFGHIJKLMNOPQR/STUVWXYZ
 Y / x           xxxxxxxxx                 
 X|   x                   xxxxxxxxx         
 0|    x                           xxxxxxxxx
 1|     x        x        x        x
 2|      x        x        x        x       
 3|       x        x        x        x      
 4|        x        x        x        x     
 5|         x        x        x        x    
 6|          x        x        x        x   
 7|           x        x        x        x  
 8|            x        x        x        x 
 9|             x        x        x        x
  |________________________________________________


With this kind of set up (one character or int per column, you'd actually only get 80 characters (80 bytes) per card.


(If there's anyone who's actually used these cards, feel free to come in and give more info or correct me.)
posted by chrisamiller at 7:36 AM on January 13, 2010

It doesn't look to me like you actually get a full byte out of each column. That is, there weren't 256 different combinations of holes in a column that would have been "legal" in the standard encodings. (Yeah, I know, bytes weren't always eight bits...)
posted by madcaptenor at 7:38 AM on January 13, 2010

A quick search on 'half life 2 source code' at the local torrent sites yields a 360MB archive. Let's assume it unpacks to double that; about 720MB.

There was a 72-character limit to the punchcards we used back in the day. That included the newline character, but ignoring that and assuming you could code each line with continuation codes and have no waste, you'd need just over ten million punched cards (10,485,760).

Side note: The repairmen for the Hollerith punch card machines billed $120 an hour back in 1982.
posted by Hardcore Poser at 7:51 AM on January 13, 2010 [2 favorites]

Response by poster: Doing a bit more googling I found that a card could hold 120 bytes (although probably not, since according to the answers so far you're not getting exactly that much, plus there would be stuff like header info and metadata). Just going with that it shakes out to:

9 cards to a Kilobyte (8.3333, but I'll round up to 9 because of what I mentioned before)

8,533 cards to a meg

8,737,792 cards to a gig

If a modern game install is 4 gigs then you're looking at 34,951,168 cards. I figured that each card has about the same height as a playing card (.01 inches). Which means a stack one on top of the other would be 5.5 miles high (!!!).

That's probably pretty shitty math though.
posted by codacorolla at 7:54 AM on January 13, 2010

Best answer: Oh, and as for the second part of your question, I see somewhere that Half-Life two came on 5 CDs. We'll assume that they were all full, so that's 3.41 GB, which means you're looking at about 45 million punch cards.

Assume the card stock is 0.081 mm thick, that's a stack of cards 3715 m high (or about 2.3 miles).

One of the readers could read 150 cards per minute, so that's about 212 days to read Half-life 2 off of punch cards, assuming you had the memory to store and run it (which you didn't).
posted by chrisamiller at 7:58 AM on January 13, 2010 [1 favorite]

Should have previewed. The 72-byte limit was a limitation of the Fortran compiler we worked on. Punched cards were indeed 80 characters; we just couldn't use them all.

72 bytes was also the limit of the pencil-based MAPO cards that replaced our card punch when it got too expensive for the school to maintain. Yes kids, at one time we had to write code the same way we now fill in lottery tickets.

One advantage of MAPO was that you could write an entire command with two penciled-in bubbles instead of coding each letter. A primitive form of 'keyboard macro,' if you will.
posted by Hardcore Poser at 8:02 AM on January 13, 2010

Since Cardamation still sells punch cards, and they charge $20/1000 for 8051s, your approximately 40 million cards would cost $800K, plus shipping.
posted by scruss at 8:08 AM on January 13, 2010

Best answer: One more correction, for those commenters above unsure of the whole 'card character vs. stored byte' thing. First, set aside the fancy codes you could punch or pencil in to represent an entire command keyword in one card character. Even then the characters used on the card didn't translate directly into the 8-bit bytes we like to think in these days. The number of bits used to store it in the mainframe would vary depending on the compiler being used, what kind of data it was, etc. A lot of possible answers; to be definitive you'd have to be more specific about what programs would handle your input.

Also note, mainframes don't have the same hardware history as micros. The size of their 'words' was always large (32-bit and 64-bit words being the most common.) So that adds another variable to the mix.

Just say 10 million cards and be done with it.
posted by Hardcore Poser at 8:15 AM on January 13, 2010

A chart in our lab here says one punch card holds 800 bits.

But I agree with Hardcore Poser, we only used up to column 72.
posted by Rash at 9:18 AM on January 13, 2010

Response by poster: Thanks for the replies. I guess there's a technical possibility, and a real limit. Regardless you're looking at tens of millions of cards for a modern program. Can anyone recommend some recent casual reading books about the early stages of computing?
posted by codacorolla at 9:41 AM on January 13, 2010

Ifrah's The Universal History of Computing: From the Abacus to the Quantum Computer (which I hope is the US publication of Volume 3 of his delightfully obsessive Universal History of Numbers) is pretty good on the computer history front.
posted by scruss at 11:52 AM on January 13, 2010

Columns past 72 were usually used to number the cards. If you dropped a stack, you could run them through the card sorter. You would typically thus get 72 bytes per card.

In FORTRAN, you'd normally code a single statement per card, there was a continuation column (in which you'd punch a 'c') if your statement was too long for a card. For IBM machines, your characters would be internally coded in EBCDIC: Extended binary coded decimal interchange code. I never heard of ASCII before the DEC PDP11 came out.
(though it existed and was used somewhere).

Bonus computer history joke:
How does a DEC repairman fix a flat tire?

ans. He changes the tires one at a time until he finds the one that was flat.
posted by Obscure Reference at 5:24 PM on January 13, 2010

(Un)Punched cards are a near-optimal size for bookmarks and to-do lists. Code was written by hand, then transcribed to punched cards (sometimes with an intermediate step of transcribing to a 80 columned coding sheet, to be entered by a card punch operator (essentially, a typist)).

One striking thing about the punched card days was how much a simple extra piece of information (eg. the use of columns 72-80), or skill, (eg. typing, or programming a drum card), or minor trick (say, marking the edge of newly inserted cards with felt tip) increased relative productivity. Related to this would also be the influence of computing geography, leading to a culture of the dedicated (or desperate) who hung out in the graveyard shift to do their programming work (here, too, a simple change in scheduling work time could yield a large increase in productivity). One could think of the computing resources as a sort of watering hole, where everyone needed access, and the optimal time for access would depend on which fauna member one was.

I'd approach this from a socio-cultural viewpoint, and look to biographies and anecdotes, starting with someone I found interesting, such as Grace Hopper, co-inventor of COBOL, and credited with the term "debugging" (she had a great story of how the term came into being). Here's a couple clips of her on the talkshow circuit; Morley Safer piece here, and Letterman's show here. She was very accessible, and gave a lot of TED-like talks to university & professional events.
posted by Tuesday After Lunch at 2:32 PM on January 14, 2010

Back in the day, when I took a FORTRAN class in high school, we used optical-mark cards, so that we could code at home without needing access to the single card punch machine available for the class. The optical cards took only 17 characters per card, and an even modestly ambitious program would use up a box and a half of cards, at maybe 20 inches a box. Good times!
posted by Jasper Fnorde at 8:17 AM on January 16, 2010

Well, 10 months later I stumble onto this question. I used to work on card machines, and I believe I have the largest current punch card inventory in Vermont.
There are some variables to answering the question. With reference to FORTRAN, yes, you had 72 bytes of code on a card, due to the 73-80 columns being used for identification, but I think the question is about the card, not about FORTRAN.
I also assume the question is about the standard 80-column punch card. The IBM System 3 used a 96-column card that AFAIK just held 96 bytes of data.
So the standard card has 12 rows and 80 columns, but that didn't translate into 960 bits. There were certain combinations of punches that were not valid. I think you were only allowed to have 1 punch per column in rows 2-7. The most you could punch was 6 holes per column- $FF was 12-11-0-7-8-9.
There were also two formats for cards. The uncommon one allowed for for 2 characters per column, and I think they were just allowed to be numbers. So 160 bytes, if you're just using numbers. (But you wouldn't use that for coding a program) This was called 2 column binary.
The normal format was 80 columns, 1 byte per column, and yes, there were 256 combinations (See the green card (11MB PDF) p11-14), at least in 360/370 EBCDIC. Before that there were fewer combinations. So 80 bytes per card, and in 360/370 there were 8 bits (plus parity) per byte, so 640 bits per card.

Now I realize I just know IBM, but I don't know of any other systems that actually used 120 bytes. So I'd say 12.8 cards per KB. It seems to me that if you compiled a program to card, it punched in some kind of sequence (like col73-80 in FORTRAN) so maybe you didn't get 80 bytes of machine language per card. Lets say you do. That works out to 53 1/2 million cards, and cards were .0065" thick (unless they got wet and swollen), so a card rack 5.5 miles long. And the IBM 3505 could read 1200 cards per minute, so it would only take 31 days to read it (plus maintenance time!)
posted by MtDewd at 3:22 PM on October 8, 2010 [1 favorite]