1srec_fpc(5) File Formats Manual srec_fpc(5)
2
6 srec_fpc - four packed code file format
7
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 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 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 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 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 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 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 ┌──┬────┬────┬──────┬──────────┬──────────┐
65 │$ │ ss │ cc │ ffff │ aaaaaaaa │ dddddddd │
66 The field are └d─e─f┴i─n─e─d─┴a─s─:──┴──────┴──────────┴──────────┘
67 $ Every line starts with the character $, all other characters
69 are digits of base 85.
70 ss The checksum. A one byte 2's-complement checksum of all bytes
72 of the record.
73 cc The byte-count. A one byte value, counting all the bytes in
75 the record minus 4.
76 ffff Format code, a two byte value, defining the record type.
78 aaaaaaaa
80 The address field. A 4 byte number representing the first
81 address of this record.
82 dddddddd
84 The actual data of this record.
85 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 Size Multiplier
171 In general, binary data will expand in sized by approximately 1.7 times
172 when represented with this format.
173
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
198 http://sbprojects.fol.nl/knowledge/fileformats/pfc.htm
199
201 This man page was taken from the above Web page. It was written by San
202 Bergmans <sanmail@bigfoot.com>
203 For extra points: Who invented this format? Where is it used?
205Reference Manual SRecord srec_fpc(5)