Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
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?
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 / 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.
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.
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.
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.
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?
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.
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 '20 at 10:25
