10

I was looking at this IBM webpage on the history of floppy disks and it says the original 8-inch floppy disk from 1971 could store 80 KB of data, equivalent to that of 3000 punched cards.

So, based on that information and forgive me if I'm wrong because I'm bad at maths, but:

80000/3000 = 26.6

So the max storage capacity of 1 punched card would be roughly 26 bytes?

  • I think they are referring to the first prototype, before they added the dust jacket and commercialized it. – snips-n-snails Oct 14 at 13:53
  • 1
    That WWW page is misleading, at best, to the point of baloney. IBM actually made the "3000 punched cards" claim about the 256KiB/242KiB IBM 33FD ("Igar") on the 3740 in 1973, not about Noble's 80KiB prototype the IBM 23FD ("Minnow") in 1971. See: Computerworld, June 1999, "The History of the Floppy". ISBN 9780780347090 page 306. ISBN 9780262161237 page 515. – JdeBP Oct 15 at 13:36
  • 3
    Completely tangental, but - back in the day when I was using punch cards in my job, some witty coworker pointed out that the data on a card is represented by holes, and if you burn the card, the holes are still there, so the data's not really gone. ;) – Don Branson Oct 15 at 16:00
  • 1
    @DonBranson Data is represented by the choice of whether to have a hole. If you burn it, there is no choice. There is no figure without ground. – Acccumulation Oct 16 at 5:57
  • 1
    @DonBranson, hmm, but then a fully-punched card could contain more data, since there's more holes, right! – ilkkachu Oct 16 at 7:09
16

it says the original 8inch floppy disk from 1971 could store 80kb of data equivalent to that of 3000 punched cards

Given, the text is a bit misleading, as it mixes up firsts. While it is true that the first Floppy, used in a product, in 1971, had a storage of 80 KiB (exactly 79,75), it was neither used as generic storage media not available for user storage at all. This was the read only 23FD Drive used to load the microcode for certain /360 models. These drives were part of the CPU and not sold separate. Drives able to write this specific 80 KiB format were never sold to customers.

The first drive sold and used as generic storage was the 33FD in 1972, sold starting in 1973 as part of the 3740 data entry system. Here it was literally used to store punch card equivalent, as the 3740 was meant to replace the classic process of data entry via key punch and reading them later via remote entry.

Type 1 stations offered (over time) three sizes after formatting:

  • ~237 KiB (73 tracks with 26 sectors, each 128 bytes)
  • 277,5 KiB (74 tracks with 15 sectors, each 256 bytes)
  • 296 KiB (74 tracks with 8 sectors, each 512 bytes)

237 KiB / 3000 gives about 80, the size of a punch card.

Bottom Line, both numbers are right in being about firsts, but not related.

[...] so the max storage capacity of 1 punched card would be roughly 26bytes

Nope, beside the fact that a punch card does not hold bytes but characters, it's 80 per card.

| improve this answer | |
  • I remember punch cards getting sort of replaced with on disk files called pseudo that still acted like punch cards to the writing and reading batch jobs, but got rid of the physical cards – riffraff169 Oct 15 at 1:05
  • 1
    Pretty common in 1960s operating systems. The dominant design model for programs was "read some cards/paper tape, do some computing, print/punch some output". So operating systems started to support magtape and (later) disk access that looked like basic peripherals to the programs they ran. GEORGE 3 is typical of this style; despite a hierarchical file system familiar enough today, jobs tended to a cards-and-printer orientation. – another-dave Oct 15 at 10:16
  • 1
    The card (stream) is for mainframes about the same basic metaphor as the character stream for Unix/C. Everything is a record vs. everything is a byte. As a side effect all program start at a higher level of data organization. – Raffzahn Oct 15 at 10:21
13

Each hole in a card represents one bit: It either can be punched, or not punched. The holes in a classic card are arranged in 80 columns and 12 rows. 80 x 12 = 960, so the most amount of information that possibly could be stored on one card is 960 bits, which is equivalent to 120 bytes.

In practice, most punched card applications stored one text character per column. If you used one byte to store each character code, then you could store the data from a typical card in an array of no more than 80 bytes.

But, using eight bits to store each character is wasteful if the character set that you're using has fewer than 256 characters. Many applications used not much more than just upper-case roman letters, digits, and maybe a handful of punctuation. If you start looking at it from the viewpoint of information theory, you could compress the information on most cards into 50 bytes or less. For some applications, maybe a lot less.

| improve this answer | |
  • 4
    Furthermore, although a card could store 80 characters, in most cases they didn't. Take program source, for example - Fortran was one statement/card. How long is an average Fortran statement? 26 chars (per the OP) seems plausible. – another-dave Oct 14 at 16:43
  • I was thinking about the FORTRAN case as well, but from a slightly different POV: eight characters were usually lost to the sequence number at the end of each card and six to the label at the start which I suspect is not strictly part of a statement, so in no case is a statement on a single card more than 68 characters. – Mark Morgan Lloyd Oct 16 at 8:48
  • Arguing this way you also have to argue that it is possible to store much more than a megabyte of data on the first floppy disks - using special disk drives, of course. I don't know about the S/360, but the standard 140x system (1401+1402) could write 63 different symbols, which is ~5.98 bits per row (or ~59.8 bytes per card); using a hardware modification a 64th symbol was possible, what allowed storing exactly 6 bits per row (60 bytes per card). – Martin Rosenau Oct 16 at 17:58
5

3000 might be a slight exaggeration (standard IBM punch card had 80 columns with 12 rows) but there are some factors that make it so that you can't just treat a punch card as 80 or 120 bytes.

One is that you generally didn't treat the holes on a punch card as binary, doing that would weaken it too much and it would fall apart in the machine. IBM punch cards were designed around only having 1-3 holes per column representing numbers, letters and symbols. While there were several different character sets depending on the machine or programming language you were normally limited to 64 symbols (6 bits) per column, meaning a maximum of 60 bytes per punch card.

At 60 bytes per card we'd still need less than 1400 to store 80k.

However a stack of punch cards was not normally treated as a single continuous stream of data. Rather for purposes of practicality each card was treated like a seperate record. Imagine if every time you wanted to insert a character you had to repunch the the entire deck of cards (or at least those past the insertion point) in order to shift them all by one.

So instead punch cards tended to have empty space on them. If your punch cards stored employee data then each card would be just one employee or if they stored programming code then each card would store a single line of code. This makes the idea of a punch card only averaging 26 bytes or 26 characters far more believable and thus IBM's estimate of 3000 punch cards equal to 80KB of magnetic binary storage is a boastful but not entirely inaccurate number.

| improve this answer | |
  • 3
    Re, "...binary...would weaken [the cards] too much." That idea was beat to death in this forum just a few weeks back. retrocomputing.stackexchange.com/q/16112/588 Binary punched cards were a real thing, but they practically never were used in applications. They mainly were used for systems-level things (e.g., booting an OS.) – Solomon Slow Oct 14 at 13:57
  • @SolomonSlow: Binary bunched cards were also used in Allen brand electronic organs to encode sounds. I'm not sure of the format, but many columns had a lot more than three holes punched in them. – supercat Oct 14 at 20:58
  • 2
    @supercat, Interesting. I bet the organ's card reader wasn't designed to handle hundreds of cards per minute though ;-) – Solomon Slow Oct 14 at 21:07
  • 3
    @SolomonSlow: Just as important, it wasn't designed to have cards slide against each other. One of the problems with lace cards is that if two adjacent lace cards have "bridges" which are bent slightly toward each other and they catch slightly, they may not jam immediately but will get bent slightly more toward each other. Cards which are designed to be unstacked by hand and manually inserted wouldn't have that problem. – supercat Oct 15 at 14:42
1

To find out the information capacity of a punched card, we need to consider the main limitation: the overall percentage of holes on a card must be substantially less than 50% for it to maintain rigidity and not to jam. Let's be generous and say that a card maintains enough rigidity with up to 5 holes per column (encodings existed allowing up to 6 holes for some characters, for example, the double quote in modified EBCDIC, which was represented by punches in rows BA8421, but they were rare).

The number of 12-bit codes with up to 5 bits set is 1586 out of 4096 (for comparison, the number of 12-bit codes with up to 4 bits set is 794).

Therefore, each column can carry the amount of information equal to log2(1586) = 10.6 bit (or, for up to 4 punches, log2(794) = 9.6 bit).

The total information-theoretic practical capacity of a card will be, depending on the quality of the card stock, about 768-848 bit; maybe a little less if we have to adjust the encoding to prevent long sequences of consecutive punches in one row.

In more understandable terms, that would be about 100 bytes, give or take a few bytes.

| improve this answer | |
  • The limitation would not be the number of holes, but rather the presence of sufficient material to prevent excessive flexing. A card which had all holes in rows 4-9 of columns 21-60 punched, for example, would be much more likely to cause jams than one which had a checkerboard pattern punched, even though the latter would have twice as many holes, since the latter wouldn't have any thin "bridges" between poorly-supported areas, while the former would have a bunch. – supercat Oct 17 at 18:04
  • @supercat I've accounted for that in the remark "maybe a little less if we have to adjust the encoding to prevent long sequences of consecutive punches in one row". – Leo B. Oct 18 at 8:33
1

That "3000 punched cards" statement was what I'd call "advertising language", mixing in a lot of usage assumptions, and effectively comparing apples with pears.

A standard punched card could hold 80 columns of data, with each column typically representing 1 possible character of a text line. Each column consisted of 12 places, so you might call it 12 bits, but the encoding didn't use all possible combinations.

On a floppy disk, with a different encoding, you typically have 1 byte per character, and represent lines by inserting carriage return and/or line feed characters in between the lines, so you typically get the text in a packed form.

Probably they based their calculation on an assumed average text line length around 25 characters plus line separator, giving roughly 80000 bytes.

If you were to squeeze the maximum out of the punched card medium, you`d get a raw 12*80 bits = 120 bytes. But punching too many holes into the card hurts its mechanical stability, so I guess you'd have to limit yourself to 10 bits per column (with a clever encoding avoiding too many holes), resulting in 100 bytes. Based on that calculation, one floppy equals 800 punched cards, but when advertising the shiny new technology called "floppy", 3000 is much more impressive, isn't it?

| improve this answer | |
0

The answer by Raffzhan to the Question, What did code on punch cards do with the other six bits per column? gives a good example of how information was expressed on punched cards, as does this article about computer cards for ICL (International Computers Limited) computers from Britain.

As others have stated in other answers to this your question, each column on a computer card represented one character, or one byte. Most cards that I am aware of contained 80 columns, so the limit for a single card was 80 bytes.

However, how much a stack of cards contained depended on what was stored on the cards and the format in which it was stored.

During the era of computer cards, the cards either contained computer programs or data, where each card represented on line of a program or one line of data.

A card with the program instruction,

C := C + 1

only contained six characters, so it only stored 6 bytes.

How much data was stored a single card depended on whether the data was integer numbers, floating point numbers, or characters and whether delimiters where used and whether spaces were used.

I have seen data cards where all 80 columns were used as if an 80 digit long integer was stored on them. It was a method of maximizing data storage. The program reading the data, usually a FORTRAN program would parse the data as required, so, for example, the first four digits may have been one number and the next six digits another number. This required numbers to have leading zeros to fill out the fixed format of the data storage. If the number read needed to be in floating point format is was converted by the program after having been read and parsed.

| improve this answer | |
  • Nit C := C + 1 is 10 bytes, the spaces should count, even if represented by "no holes" -- they'd be explicitly stored on magnetic media. Also, surely you forgot the semicolon? ;-) – another-dave Oct 15 at 10:25
  • Further to the "continuous data" concept, many customers used bespoke cards with their own field names and delineators pre-printed on them, for each specific application. And of course, each language (assembler, COBOL, ForTran, RPG2) would have its own card layouts pre-printed. Commonly, a deck of cards would be passed through an off-line "interpreter" which printed the contents along the top edge of the card. Because the mainframe was remote and operator-only access, people pften eyeballed card data directly. I can still hand-punch ICL cards in my sleep. – Paul_Pedant Oct 15 at 15:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.