At 15:48 -0400 on 07/23/2008, Tony Harminc wrote about Re: IBM 029
keypunch -- 0-8-2 overpunch -- what hex code re:
The 2540 was quite happy to read so-called column binary cards, that
is cards with any 12-bit combination of holes punched. (Well, happy
may be the wrong word, but the problems were mechanical rather than
logical, and it was mostly the punching rather than the reading that
gave trouble.) Later readers also had an optional column binary
feature, and the mark sense and later OMR features used the same
scheme. The S/360 interface (implemented in the 2821 control unit
rather than the reader itself) could deliver the 2x6 bits embedded in
two 8-bit bytes. I imagine a 2540 connected to a pre S/360 machine,
would deliver 6-bit characters across the interface.
I once worked in a shop with one of those 2540s which was used to
read an odd-ball card whose Cols 1-40 were in EBCDIC and Cols 41-80
was Column Binary (ie: 120 characters of data per card) - Don't ask
why the card was formatted this way. The cards were read in real-time
(spooling would not work) by reading the card in EBCDIC with no
feed/pocket selection and DATA-BLOCKING (so it would not error on the
CB Columns). The card was then read again (from the Reader's Buffer)
in CB mode and and Feed/Pocket Select to eject the card. All was good
until the bean counters replaced the 2540 with a 2501 Reader (you get
one crack at the card image). So I write a program that read the card
in CB mode and internally converted the EBCDIC columns from CB to
Internal EBCDIC.
Once I got the card-image punch code mappings the program was simple.
It moved a mask string of the even numbers from 0-78 followed by the
odds from 1-79 into a work area. Doing a TR of the work area using
the CB input as the TR Table separated the 12-3 rows from the 4-9
rows. Two TRs then converted the punches into the form
12-11-0-8-9-xxx (where xxx was the binary value of the assumed single
punch in the 1-7 row). Doing a OC onto the first 40 bytes with the
2nd 40 bytes gave a card image of the punches. A TR of the first 40
bytes of the work area then did the conversion. Repeating the
sequence with the last TR as a TRT did a sanity check to see that
only one punch in a 1-7 row existed in each column (the first two TRs
used x1234567 (x not used) mappings and the TRT looked for any byte
with more than one 1 bit set (ie: any code from 00-7F other than
00/01/02/04/08/10/20/40). The program was so efficient that the 2501
ran at almost full speed. I still look back at this utility/Q&D-Hack
as one of my better coding efforts since I wrote it in about an hour
after the original programmer took over 2 weeks to write his program
and had it taking 30-60 seconds per card. It turned out that he was
straight out of programming school and was doing a binary search one
column at a time until he got his match (at least the 256 possible
matches were ordered so that only 8 needed to be done per column - I
gave him an "A" for effort and implementation of his design and an
"F" for the poor choice of design). He had never had the use of the
TR as a data movement instruction taught him in school.
If it was written now, I could of course use the TR version that
Translates a 2byte string into a single byte (although the sanity
check would still be needed via a table that did the TR to a non-zero
value for all but the 256 valid punch combinations and then the TRT
to spot a non-zero result).
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
