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

NAME

6       srec_signetics - Signetics file format
7

DESCRIPTION

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
13   Records
14       All data lines are called records, and each record contains the follow‐
15       ing 5 fields:
16
17                           ┌──┬──────┬────┬────┬────┬────┐
18                           │: │ aaaa │ cc │ as │ dd │ ss │
19       The field are define└d──a┴s──f─o─l─l─o┴w─s─:──┴────┴────┴────┘
20
21       :       Every record starts with this identifier.
22
23       aaaa    The address field.  A four digit (2 byte)  number  representing
24               the first address to be used by this record.
25
26       cc      The  byte‐count.   A  two  digit  value  (1 byte), counting the
27               actual data bytes in the record.
28
29       as      Address checksum.  Covers 2 address bytes and the byte count.
30
31       dd      The actual data of this record.  There can be  1  to  255  data
32               bytes per record (see cc)
33
34       ss      Data Checksum.  Covers only all the data bytes of this record.
35
36   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
43       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
48   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
57   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
62       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
66       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
71   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
76       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
87       This results in a very reliable checksum, and that for only 3 bytes!
88
89       The last record of the file does not contain  any  checksums!   So  the
90       file ends right after the Byte Count of 0.
91
92   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
97   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
108   Size Multiplier
109       In general, binary data will expand in sized by approximately 2.4 times
110       when represented with this format.
111

EXAMPLE

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
124       Notice that the last record of the file contains no data bytes, and not
125       even an Address Checksum.
126

SEE ALSO

128       http://sbprojects.fol.nl/knowledge/fileformats/signetics.htm
129

AUTHOR

131       This man page was taken from the above Web page.  It was written by San
132       Bergmans <sanmail@bigfoot.com>
133
134
135
136Reference Manual                    SRecord                  srec_signetics(5)
Impressum