Punch cards were a standard form of program and data storage for decades, but you’d never know it by looking around today. Card punches and even readers are becoming rare and expensive. Sometimes it takes a bit of hacking [YouTube link] to get that old iron running again!
[Antiquekid3] managed to score an old punch card reader on Ebay, but didn’t have a way to interface with it. The reader turned out to be a Documation M-1000-L. After a bit of searching, [Antiquekid3] managed to find the manual [PDF link] on BitSavers. It turns out that the Documation reader used a discrete output for each row of data. One would think the Documation reader would be a perfect fit for the PDP-8 lurking in the background of [Antiquekid3’s] video, but unfortunately the ‘8 lacks the necessary OMNIBUS card to interface with a reader.
Undaunted, [Antiquekid3] threw some modern hardware into the mix, and used an Arduino Uno as a Documation to Serial interface. The Arduino had plenty of I/O to wire up with the card reader’s interface. It also had a serial interface which made outputting data a snap. The ATmega328 even had enough power to translate each card from one of IBM’s many keypunch formats to serial.
[Antiquekid3’s] test deck of cards turned out to be a floating point data set. Plotting the data with a spreadsheet results in a nice linear set of data points. Of course, no one knows what the data is supposed to mean! Want more punch card goodness? Check out this tweeting punch card reader, or this Arduino based reader which uses LEGO and a digital camera to coax the data from the paper.
Wrote some of my first programs on punchcards… those were the days!
Let’s see an Arduino recreate the joy of pitching handfuls of the little punches into the breeze at a football game!
Coming in, handing over a heavy drawer full of colored cards, let them run throu some mighty blue rattling machines, going to lunch, having some coffee, coming back, getting a big pile of green lined fanfolded paper only to read that there is another typo in some FORTRAN line somewhere.
Next day, next try. Those were the real days!
Program for the Android environment using Googles emulator using only an i3 and a 5400 RPM Toshiba HDD. About the same experience…
Do the cards make any sense if the data is read as http://en.wikipedia.org/wiki/EBCDIC ? I understand it was a common format for punched cards.
Not only a common format for cards, but IBM 9 track tape was written as EBCDIC.
The code that was punched into the cards was NOT EBCDIC it was Hollerith code. EBCDIC was the memory code used on all IBM. Mainframes from the Series 360 onwards. Main memory, tape drives and disk drives contained bytes encoded in EBCDIC which was an 8 bit code. Mini computers such as the DEC PDP11 used ASCII code which existed as either 7 or 8 bit code.
Before the IBM Series 360 there was the 1400 Series which used BCD code which stands for Binary Coded Decimal and was a 6 bit code. EDCDIC incidentally stands for Extended Binary Coded Decimal Interchange Code.
You remap from EBCDIC to ASCII, it’s pretty easy. There are some non-translate able symbols, but it’s even handled automatically by modern platforms like .NET (tell it that an input stream is 8 bit EBCEDIC and it will quite happily convert it to UTF8 for you).
Solving the worlds problems 100bytes (or less) at a time – of course the answer was sent via RFC 1149 (IPoAC)
100? The cards were 80 column, and the first two columns were reserved so you only really got 78 to work with. IBM mainframes today still expect 80 column data by default.
IBM did make a 96 colum card for the System/3, but as history has shown it never caught on. As you say 80(78) columns still rules the roost.
To say that 96 column crds never caught on is a little disingenuous as tens of thousands of System 3 and series 34 36 and 38 machines were sold and installed in thousands of customer sites.
80 column cards were a late development. See http://www.adafruit.com/blog/2014/12/19/ibm-001-manual-keypunch/
Yes, those were the days– When products came with a manual that included schematics, timing diagrams, and theory of operation. You could repair your own equipment with the schematics and an oscilloscope, replacing a DIP chip you found as faulty.
Interesting the holes were off. Do cards shrink with age? With an arduino instead of just nand dates and D flip flops, it wouldn’t be hard to recalibrate the offset from timing disk pulses to recenter the holes detected. You might even be able to detect dangling chads on a Florida ballot.