On 07/27/2012 03:07 PM, Paul Gilmartin wrote:
On Fri, 27 Jul 2012 07:21:26 -0500, McKown, John wrote:
For the truly strange hardware hackers among us.
Hardware:
http://codeincluded.blogspot.co.nz/2012/07/punch-card-reader-hardware.html
software:
http://codeincluded.blogspot.co.nz/2012/07/punchcard-reader-software.html
Ummm... USB interface. For Herc on Raspberry Pi? Driver? What code
page? For that matter, what was the code page for IBM card readers?
I doubt that it was selectable.
Almost as easy to put 3 at a time on a scanner with black construction paper
backing.
-- gil
If not lost in the last move, I may still have one box of card decks
stashed somewhere, just in case someone ever came up with a cheap and
trivial way to read them that wouldn't take a ridiculous amount of time
and effort. Getting a full image of the card either by camera or
scanner and then processing the image seems like such a complicated
method compared to the sensing used in the old days by actual card
readers, which either used light or wire brushes for a 0/1 sensing of
each hole. The more complicated hardware part always seemed to be the
close tolerances required by the mechanical card transport, both to
maintain card alignment and to get the timing right to correctly sense
rows (or columns).
If I were trying to build a cheap card reader and willing to expend as
much time as this reader project must have taken, I would be tempted to
try combining simple optical sensing concepts with the inexpensive clock
timing solutions of a Bendix G-15: something along the lines of:
(1)a rectangular "card carrier", maybe just a thin wood frame that would
support the card all around only by the edges, and which contained a
series of 80 "timing holes" next to the 12-edge or the 9-edge of the
card, positioned to be aligned with the 80 column positions of a card
positioned in the carrier.
(2)an assembly with 13 light sensors connected to guide rails that would
allow the carrier with card to be passed under the sensors by column
with a light source on the opposite side while keeping the sensors
parallel with the card columns, with one sensor aligned for the timing
hole in the carrier and the other 12 for each of the 12 rows in the card.
(3)Electronics connected to the sensors to "read" the bits from the 12
card-column sensors each time the timing hole sensor senses a timing
hole, and make each set of 12-bits available over a USB interface as
each column of the card passes, which could easily be done in as few as
160 bytes per card. I'm not into digital hardware design, so this part
is way outside my current skill set. My eldest son would have no
problem with this if he had the time -- but he's not into mainframe
retro-computing like some of us.
I would think the speed of such a reader would only be limited by how
fast an operator could position a new card in the carrier and move the
carrier under the sensor array. Variations in carrier velocity or
actual velocity of the card carrier should not affect accuracy, as read
timing is directly driven by the actual card movement. Alignment issues
would be resolved by the "operator" properly positioning the card in the
carrier and by the guides for the card carrier, and the card holes are
large enough that the mechanical tolerances for sensor and guide
alignment should be achievable.
I find thinking about a solution entertaining, but based on two decades
of inaction, may never progress beyond that. Michael Hamilton deserves
a mainframe-geek gold star for rising to the level of implementation!
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
