Provided by: srecord_1.56-1build1_amd64 bug

NAME

       srec_fpc - four packed code file format

SYNOPSIS

       All  ASCII  based  file  formats  have one disadvantage in common: they all need more than
       double the amount of characters as opposed to the number of bytes  to  be  sent.   Address
       fields  and checksums will add even more characters.  So the shorter the records, the more
       characters have to be sent to get the file across.

       The FPC format helps to reduce the number of characters needed to send  a  file  in  ASCII
       format,  although  it  still  needs  more  characters than the actual bytes it sends.  FPC
       stands for "Four Packed Code".  The reduction is accomplished by squeezing  4  real  bytes
       into  5  ASCII  characters.   In fact every ASCII character will be a digit in the base 85
       number system.  There aren't enough letters, digits and punctuation marks available to get
       85  different  characters,  but  if  we use both upper case and lower case letters we will
       manage.  This implies that the FPC is case sensitive, as opposed to all other ASCII  based
       file formats.

   Base 85
       The  numbering  system is in base 85, and is somewhat hard to understand for us humans who
       are usually only familiar with base 10 numbers.  Some of us understand base 2 and base  16
       as  well,  but  base 85 is for most people something new.  Luckily we don't have to do any
       math with this number system.  We just convert a 32 bit number into a 5  digit  number  in
       base  85.  A 32 bit number has a range of 4,294,967,296, while a 5 digit number in base 85
       has a range of 4,437,053,125, which is enough to do the trick.  One drawback  is  that  we
       always  have  to  send  multiples  of  4 bytes, even if we actually want to send 1, 2 or 3
       bytes.  Unused bytes are padded with zeroes, and are discarded at the receiving end.

       The digits of the base 85 numbering system start at %, which represents the  value  of  0.
       The  highest  value  of a digit in base 85 is 84, and is represented by the character 'z'.
       If you want to check this with a normal ASCII table you will notice that we have used  one
       character  too  many!   Why?   I  don't  know, but for some reason we have to skip the '*'
       character in the row.  This means that after the ')' character follows the '+' character.

       We can use normal number conversion algorithms to generate the FPC digits, with this  tiny
       difference.   We  have  to check whether the digit is going to be equal or larger than the
       ASCII value for '*'.  If this is the case we have to increment  the  digit  once  to  stay
       clear of the '*'.  In base 85 MSD digits go first, like in all number systems!

       The benefit of this all is hopefully clear. For every 4 bytes we only have to send 5 ASCII
       characters, as opposed to 8 characters for all other formats.

   Records
       Now we take a look at the the formatting of the FPC records.  We look  at  the  record  at
       byte level, not at the actual base 85 encoded level.  Only after formatting the FPC record
       at byte level we convert 4 bytes at a time to a 5 digit base 85 number.  If we don't  have
       enough  bytes  in the record to fill the last group of 5 digits we will add bytes with the
       value of 0 behind the record.

                               ┌──┬────┬────┬──────┬──────────┬──────────┐
                               │$ │ ss │ cc │ ffff │ aaaaaaaa │ dddddddd │
Binary file (standard input) matches