I'm having a bad time with the stupid web design / scripts on here so I have some difficulty in responding to the PM you sent about this, so I'll reply here.
I sort of see what you're trying to understand about BCD and packing it (string encoding); I hadn't recalled the specifics of that ANSI/ISO form of BCD used in the context you're talking about, thanks for the link/information. It has been a long time since I've had much use for BCD.
Uh I think one of the main things you're possibly missing is that BCD = a string of *bits*.
So if I write "1011" that's 4 digits of ASCII, yes, composed of 4 numeric decimal digits strung together, yes, but I'm just showing that as a text representation of something that is REALLY just 4 bits in size in the physical encoding.
So when you say:
but my writer only takes 104 numeric characters (which is the limit for track 2).
ANSI/ISO BCD has many more characters per digit ie. 1=00001 etc etc..
How can I take numeric characters and have it end up in ansi on the card?
what seems to be the case is that it's taking 104 digit characters as input, but what you must realize is that each of those digit characters that you'd feed in (in ASCII I guess) is actually expanding to *5* bits (one 4-bit-BCD + 1-bit parity) on the medium.
So according to the table you sent input characters 0-9 should be directly converted to the appropriate 5 bit BCD sequence.
Apparently ';' = 0xB and '?' = 0xF in 4-bit BCD code ignoring the parity bit that's calculated from the rest of the bits in the code.
So it seems impossible to me that you could have your software/system's input be characters of 104 decimal digits since there would be no way to represent these BCD characters which are also in the table you linked: ": ; < = > ?".
However if your software/hardware takes hex characters then for each 4 bit hex character there would be written a 5-bit sequence on the media (if it adds the parity automatically), and you could encode all 16 character set characters: "01234567890:;<=>?".
Though that does conflict with the link you mentioned:
Track 2
75BPI
5 bits per character
40 Numeric characters
So since you say your setup can take in 104 characters, that's much more than the 40 (excluding the LRC) that your link says actually can possibly be used if each input specified character is generating one BCD 5-bit tuple worth of data.
Let's see.. 37 characters * 4 bits / character (ignoring parity bits and ignoring SS FS and ES and the LRC) = 148 bits of actual user specifiable data.
So if you can specify 104 characters, that can't possibly be 1 bit per character (e.g. "0" or "1" only) since you wouldn't have enough bit-characters to generate the 37 or more BCD characters that your link says are available on T2.
Maybe I'm mixing up two unrelated problems. Maybe you sent the link only as an example of ANSI/ISO BCD encoding and it has nothing to do with the track formatting stuff elsewhere on the page.
You said:
I need to encode ;xxxxxxx=xxxx? the x's represent ascii digits. the semi colon and ? both have corresponding BCD values but I don't know how to string it all together properly.
Let's see
";0123456=0123?"
"123456789ABCD" = 0xD total characters = 13 (decimal); 13x4=52 4-BCD bit sequences;
13 x 5 = 65 (4-BCD + 1-parity) bit sequences.
So being able to specify 104 'characters' whether those characters were 'bits {0|1}' or hex-digits is certainly enough for your stated application, ignoring all the track formatting stuff in the link.
So what is the 'character' format of your input software/hardware? Is an single input 'character' defined as being among one of the following possibilities of alphabets:
01
0123456789
0123456789ABCDEF
0123456789:;<=>?
The answer to that will more or less imply what the encoding process is likely to be, though if you wanted to be fully explicit you could check the documents as to what the formatting of the output is and what if anything is done automatically by your devide (parity, framing characters, et. al.).
Also unknown is whether the thing is encoding from left to right or right to left or whatever, and what the order of 'bits' within each input specified character is.
I assume the bit ordering is likely pretty much sensible for an equivalence of ASCII to BCD (i.e. not backwards other than relative to the whole right-to-left / left-to-right stringing of the data stream physically).
So if each character is ASCII alphanumeric:
";0123456=0123?" = ";0123456=0123?"
If each character is ASCII HEX-BCD and the machine does the parity for you implicitly:
";0123456=0123?" = B0123456D0123F
If each character is ASCII binary then (ignoring the spaces added for clarity):
";0123456=0123?" = 11010 00001 10000 01000 11001 00100 10101 01101 10110 00001 10000 01000 10011
If each character is decimal-BCD then: well that'd be silly of them, so I assume it isn't this way unless the system can't generate things other than 0-9 or whatever.
...or they could be the right-to-left mirrored version of those depending on the ordering.