1srec_signetics(5) File Formats Manual srec_signetics(5)
2
6 srec_signetics - Signetics file format
7
9 The Signetics file format is not often used. The major disadvantage in
10 modern applications is that the addressing range is limited to only
11 64kb.
12 Records
14 All data lines are called records, and each record contains the follow‐
15 ing 5 fields:
16 ┌──┬──────┬────┬────┬────┬────┐
18 │: │ aaaa │ cc │ as │ dd │ ss │
19 The field are define└d──a┴s──f─o─l─l─o┴w─s─:──┴────┴────┴────┘
20 : Every record starts with this identifier.
22 aaaa The address field. A four digit (2 byte) number representing
24 the first address to be used by this record.
25 cc The byte‐count. A two digit value (1 byte), counting the
27 actual data bytes in the record.
28 as Address checksum. Covers 2 address bytes and the byte count.
30 dd The actual data of this record. There can be 1 to 255 data
32 bytes per record (see cc)
33 ss Data Checksum. Covers only all the data bytes of this record.
35 Record Begin
37 Every record begins with a colon “:[rq] character. Records contain
38 only ASCII characters. No spaces or tabs are allowed in a record. In
39 fact, apart from the 1st colon, no other characters than 0..9 and A..F
40 are allowed in a record. Interpretation of a record should be case
41 less, it does not matter if you use a..f or A..F.
42 Unfortunately the colon was chosen for the Signetics file format, simi‐
44 lar to the Intel format (see srec_intel(5) for more information). How‐
45 ever, SRecord is able to automatically detect the dofference between
46 the two format, when you use the -Guess format specifier.
47 Address Field
49 This is the address where the first data byte of the record should be
50 stored. After storing that data byte, the address is incremented by 1
51 to point to the address for the next data byte of the record. And so
52 on, until all data bytes are stored. The address is represented by a 4
53 digit hex number (2 bytes), with the MSD first. The order of addresses
54 in the records of a file is not important. The file may also contain
55 address gaps, to skip a portion of unused memory.
56 Byte Count
58 The byte count cc counts the actual data bytes in the current record.
59 Usually records have 32 data bytes, but any number between 1 and 255 is
60 possible.
61 A value of 0x00 for cc indicates the end of the file. In this case not
63 even the address checksum will follow! The record (and file) are ter‐
64 minated immediately.
65 It is not recommended to send too many data bytes in a record for that
67 may increase the transmission time in case of errors. Also avoid send‐
68 ing only a few data bytes per record, because the address overhead will
69 be too heavy in comparison to the payload.
70 Address Checksum
72 This is not really a checksum anymore, it looks more like a CRC. The
73 checksum can not only detect errors in the values of the bytes, but
74 also bytes out of order can be detected.
75 The checksum is calculated by this algorithm:
77 checksum = 0
78 for i = 1 to 3
79 checksum = checkum XOR byte
80 ROL checksum
81 next i
82 For the Address Checksum we only need 2 Address bytes and 1 Byte Count
83 byte to be added. That's why we count to 3 in the loop. Every byte is
84 XORed with the previous result. Then the intermediate result is rolled
85 left (carry rolls back into b0).
86 This results in a very reliable checksum, and that for only 3 bytes!
88 The last record of the file does not contain any checksums! So the
90 file ends right after the Byte Count of 0.
91 Data Field
93 The payload of the record is formed by the Data field. The number of
94 data bytes expected is given by the Byte Count field. The last record
95 of the file may not contain a Data field.
96 Data Checksum
98 This checksum uses the same algorithm as used for the Address Checksum.
99 This time we calculate the checksum with only the data bytes of this
100 record.
101 checksum = 0
102 for i = 1 to cc
103 checksum = checksum XOR byte
104 ROL checksum
105 next i
106 Note that we count to the Byte Count cc this time.
107 Size Multiplier
109 In general, binary data will expand in sized by approximately 2.4 times
110 when represented with this format.
111
113 Here is an example Signetics file
114 :B00010A5576F77212044696420796F75207265617B
115 :B01010E56C6C7920676F207468726F756768206136
116 :B02010256C6C20746861742074726F75626C652068
117 :B0300D5F746F207265616420746869733FD1
118 :B03D00
119 In the example above you can see a piece of code in Signetics format.
120 The first 3 lines have 16 bytes of data each, which can be seen by the
121 byte count. The 4th line has only 13 bytes, because the program is at
122 it's end there.
123 Notice that the last record of the file contains no data bytes, and not
125 even an Address Checksum.
126
128 http://sbprojects.fol.nl/knowledge/fileformats/signetics.htm
129
131 This man page was taken from the above Web page. It was written by San
132 Bergmans <sanmail@bigfoot.com>
133Reference Manual SRecord srec_signetics(5)