The connection of magnetic-card readers to PC-compatible computers is usually made through a serial port or a keyboard interface. In this configuration, the computer merely receives ASCII strings, but the decoding process must be supported by a microcontroller embedded into the rather expensive “intelligent” card reader. Another design option is to use a much cheaper “TTL” reader and write some PC software to process the raw binary data from the card.
Common single-track magcard readers come with just five wires, two for the 5-V power supply and three for the logic outputs: “card present,” “data” and “clock.” The “games port” or “joystick connector” of most PCs is seldom used for “serious” tasks, but lends itself very well to the present application because it offers a good +5-V supply and four logic input lines. The necessary connections are shown, including an optional “PolySwitch” resettable fuse inserted into the +5-V line to protect the motherboard tracks against accidental overcurrent conditions (see the figure).
The software program was written in Turbo-Pascal and proved to work satisfactorily, under MS-DOS, on CPUs running at 25 MHz or faster (see the listing). Operation under Windows isn’t recommended, at least on CPUs slower than 200 MHz, since the main routine is time-critical.
Once run, the program waits for a card being swept into the reader, then it displays the decoded contents of its ISO-2 track (the most commonly used one, carrying a maximum of 40 numeric characters). The ISO-3 (max. 107 numeric characters) and ISO-1 (max. 79 alphanumeric characters) tracks could be treated very similarly with appropriate readers.
The program assumes that the card is encoded in accordance with the 5-bit ANSI code, but it’s written in such a way that it could easily be adapted, on a bit-by-bit basis, to any proprietary code or to the 7-bit alphanumeric ANSI code.
It should also be noted that the parity of the data (the last bit of each character) isn’t checked directly, but that the occurrence of any bit pattern other than the 16 ones listed here could easily be detected as a parity error. In addition, the last character of the track is usually an LRC, and could be used, at a later stage, to control the integrity of the data string.