1srec_fpc(5)                   File Formats Manual                  srec_fpc(5)
2
3
4

NAME

6       srec_fpc - four packed code file format
7

SYNOPSIS

9       All  ASCII based file formats have one disadvantage in common: they all
10       need more than double the amount of characters as opposed to the number
11       of  bytes  to be sent.  Address fields and checksums will add even more
12       characters.  So the shorter the records, the more characters have to be
13       sent to get the file across.
14
15       The  FPC format helps to reduce the number of characters needed to send
16       a file in ASCII format, although it still needs  more  characters  than
17       the  actual  bytes  it  sends.  FPC stands for "Four Packed Code".  The
18       reduction is accomplished by squeezing 4 real bytes into 5 ASCII  char‐
19       acters.   In  fact every ASCII character will be a digit in the base 85
20       number system.  There aren't enough  letters,  digits  and  punctuation
21       marks  available  to  get  85  different characters, but if we use both
22       upper case and lower case letters we will manage.   This  implies  that
23       the  FPC  is  case  sensitive, as opposed to all other ASCII based file
24       formats.
25
26   Base 85
27       The numbering system is in base 85, and is somewhat hard to  understand
28       for us humans who are usually only familiar with base 10 numbers.  Some
29       of us understand base 2 and base 16 as well, but base 85  is  for  most
30       people  something  new.  Luckily we don't have to do any math with this
31       number system.  We just convert a 32 bit number into a 5  digit  number
32       in  base  85.   A 32 bit number has a range of 4,294,967,296, while a 5
33       digit number in base 85 has a range of 4,437,053,125, which  is  enough
34       to do the trick.  One drawback is that we always have to send multiples
35       of 4 bytes, even if we actually want to send 1, 2 or 3  bytes.   Unused
36       bytes are padded with zeroes, and are discarded at the receiving end.
37
38       The digits of the base 85 numbering system start at %, which represents
39       the value of 0.  The highest value of a digit in base 85 is 84, and  is
40       represented  by  the  character  'z'.  If you want to check this with a
41       normal ASCII table you will notice that we have used one character  too
42       many!   Why?  I don't know, but for some reason we have to skip the '*'
43       character in the row.  This means that after the ')' character  follows
44       the '+' character.
45
46       We can use normal number conversion algorithms to generate the FPC dig‐
47       its, with this tiny difference.  We have to check whether the digit  is
48       going  to  be equal or larger than the ASCII value for '*'.  If this is
49       the case we have to increment the digit once to stay clear of the  '*'.
50       In base 85 MSD digits go first, like in all number systems!
51
52       The  benefit  of this all is hopefully clear. For every 4 bytes we only
53       have to send 5 ASCII characters, as opposed to  8  characters  for  all
54       other formats.
55
56   Records
57       Now  we  take a look at the the formatting of the FPC records.  We look
58       at the record at byte level, not at the actual base 85  encoded  level.
59       Only  after  formatting the FPC record at byte level we convert 4 bytes
60       at a time to a 5 digit base 85 number.  If we don't have  enough  bytes
61       in the record to fill the last group of 5 digits we will add bytes with
62       the value of 0 behind the record.
63
64                     ┌──┬────┬────┬──────┬──────────┬──────────┐
65                     │$ │ ss │ cc │ ffff │ aaaaaaaa │ dddddddd │
66       The field are └d─e─f┴i─n─e─d─┴a─s─:──┴──────┴──────────┴──────────┘
67
68       $       Every line starts with the character $,  all  other  characters
69               are digits of base 85.
70
71       ss      The  checksum.  A one byte 2's‐complement checksum of all bytes
72               of the record.
73
74       cc      The byte‐count.  A one byte value, counting all  the  bytes  in
75               the record minus 4.
76
77       ffff    Format code, a two byte value, defining the record type.
78
79       aaaaaaaa
80               The  address  field.   A  4  byte number representing the first
81               address of this record.
82
83       dddddddd
84               The actual data of this record.
85
86   Record Begin
87       Every record begins with the ASCII character "$".  No  spaces  or  tabs
88       are allowed in a record.  All other characters in the record are formed
89       by groups of 5 digits of base 85.
90
91   Checksum field
92       This field is a one byte 2's‐complement checksum of the entire  record.
93       To  create  the checksum make a one byte sum from all of the bytes from
94       all of the fields of the record:
95
96       Then take the 2's‐complement of this sum to create the final  checksum.
97       The 2's‐complement is simply inverting all bits and then increment by 1
98       (or using  the  negative  operator).   Checking  the  checksum  at  the
99       receivers end is done by adding all bytes together including the check‐
100       sum itself, discarding all carries, and the result must  be  $00.   The
101       padding  bytes at the end of the line, should they exist, should not be
102       included in checksum.  But it doesn't really matter if  they  are,  for
103       their influence will be 0 anyway.
104
105   Byte Count
106       The  byte  count  cc  counts  the number of bytes in the current record
107       minus 4.  So only the number of address bytes and the  data  bytes  are
108       counted  and  not the first 4 bytes of the record (checksum, byte count
109       and format flags).  The byte count can have any value from 0 to 255.
110
111       Usually records have 32 data bytes.  It is not recommended to send  too
112       many data bytes in a record for that may increase the transmission time
113       in case of errors.  Also avoid  sending  only  a  few  data  bytes  per
114       record, because the address overhead will be too heavy in comparison to
115       the payload.
116
117   Format Flags
118       This is a 2 byte number, indicating what format is represented in  this
119       record.   Only a few formats are available, so we actually waste 1 byte
120       in each record for the sake of having multiples of 4 bytes.
121
122       Format code 0 means that the address field in  this  record  is  to  be
123       treated as the absolute address where the first data byte of the record
124       should be stored.
125
126       Format code 1 means that the address field in this record  is  missing.
127       Simply  the  last  known  address  of the previous record +1 is used to
128       store the first data byte.  As if the FPC  format  wasn't  fast  enough
129       already ;‐)
130
131       Format  code  2  means  that  the address field in this record is to be
132       treated as a relative address.  Relative to what is not  really  clear.
133       The relative address will remain in effect until an absolute address is
134       received again.
135
136   Address Field
137       The first data byte of the record is stored in the address specified by
138       the  Address field aaaaaaaa.  After storing that data byte, the address
139       is incremented by 1 to point to the address for the next data  byte  of
140       the record.  And so on, until all data bytes are stored.
141
142       The  length  of  the  address  field  is  always 4 bytes, if present of
143       course.  So the address range for the FPC format is always 2**32.
144
145       If only the address field is given, without any data bytes, the address
146       will be set as starting address for records that have no address field.
147
148       Addresses between records are non sequential.  There may be gaps in the
149       addressing or the address pointer may even point to lower addresses  as
150       before  in  the  same  file.  But every time the sequence of addressing
151       must be changed, a format 0 record must be used.  Addressing within one
152       single record is sequential of course.
153
154   Data Field
155       This  field  contains  0 or more data bytes.  The actual number of data
156       bytes is indicated by the byte count in the  beginning  of  the  record
157       less the number of address bytes.  The first data byte is stored in the
158       location indicated by the address in the address field.  After that the
159       address  is  incremented  by 1 and the next data byte is stored in that
160       new location.  This continues until all bytes are stored.  If there are
161       not  enough data bytes to obtain a multiple of 4 we use 0x00 as padding
162       bytes at the end of the record.  These padding bytes are ignored on the
163       receiving side.
164
165   End of File
166       End  of  file  is  recognized if the first four bytes of the record all
167       contain 0x00.  In base 85 this will be  “$%%%%%”.   This  is  the  only
168       decent way to terminate the file.
169
170   Size Multiplier
171       In general, binary data will expand in sized by approximately 1.7 times
172       when represented with this format.
173

Example

175       Now it's time for an example.  In the first table you can see the  byte
176       representation  of the file to be transferred.  The 4th row of bytes is
177       not a multiple of 4 bytes.  But that does not matter, for we append $00
178       bytes at the end until we do have a multiple of 4 bytes.  These padding
179       bytes are not counted in the byte count however!
180              D81400000000B000576F77212044696420796F7520726561
181              431400000000B0106C6C7920676F207468726F7567682061
182              361400000000B0206C6C20746861742074726F75626C6520
183              591100000000B030746F207265616420746869733F000000
184              00000000
185       Only after converting the bytes to base 85 we get the  records  of  the
186       FPC  type  file format presented in the next table.  Note that there is
187       always a multiple of 5 characters to represent a multiple of 4 bytes in
188       each record.
189              $kL&@h%%,:,B.\?00EPuX0K3rO0JI))
190              $;UPR'%%,:<Hn&FCG:at<GVF(;G9wIw
191              $7FD1p%%,:LHmy:>GTV%/KJ7@GE[kYz
192              $B[6\;%%,:\KIn?GFWY/qKI1G5:;-_e
193              $%%%%%
194       As  you  can  see  the  length of the lines is clearly shorter than the
195       original ASCII lines.
196

SEE ALSO

198       http://sbprojects.fol.nl/knowledge/fileformats/fpc.htm
199

AUTHOR

201       This man page was taken from the above Web page.  It was written by San
202       Bergmans <sanmail@bigfoot.com>
203
204       For extra points: Who invented this format?  Where is it used?
205
206
207
208Reference Manual                    SRecord                        srec_fpc(5)
Impressum