1srec_intel(5) File Formats Manual srec_intel(5)
2
3
4
6 srec_intel - Intel Hexadecimal object file format specification
7
9 This format is also known as the Intel MCS‐86 Object format.
10
11 This document describes the hexadecimal object file format for the
12 Intel 8‐bit, 16‐bit, and 32‐bit microprocessors. The hexadecimal for‐
13 mat is suitable as input to PROM programmers or hardware emulators.
14
15 Hexadecimal object file format is a way of representing an absolute
16 binary object file in ASCII. Because the file is in ASCII instead of
17 binary, it is possible to store the file is non‐binary medium such as
18 paper‐tape, punch cards, etc.; and the file can also be displayed on
19 CRT terminals, line printers, etc.. The 8‐bit hexadecimal object file
20 format allows for the placement of code and data within the 16‐bit lin‐
21 ear address space of the Intel 8‐bit processors. The 16‐bit hexadeci‐
22 mal format allows for the 20‐bit segmented address space of the Intel
23 16‐bit processors. And the 32‐bit format allows for the 32‐bit linear
24 address space of the Intel 32‐bit processors.
25
26 The hexadecimal representation of binary is coded in ASCII alphanumeric
27 characters. For example, the 8‐bit binary value 0011‐1111 is 3F in
28 hexadecimal. To code this in ASCII, one 8‐bit byte containing the
29 ASCII code for the character '3' (0011‐0011 or 0x33) and one 8‐bit byte
30 containing the) ASCII code for the character 'F' (0100‐0110 or 0x46)
31 are required. For each byte value, the high‐order hexadecimal digit is
32 always the first digit of the pair of hexadecimal digits. This repre‐
33 sentation (ASCII hexadecimal) requires twice as many bytes as the
34 binary representation.
35
36 A hexadecimal object file is blocked into records, each of which con‐
37 tains the record type, length, memory load address and checksum in
38 addition to the data. There are currently six (6) different types of
39 records that are defined, not all combinations of these records are
40 meaningful, however. The record are:
41
42 · Data Record (8‐, 16‐, or 32‐bit formats)
43
44 · End of File Record (8‐, 16‐, or 32‐bit formats)
45
46 · Extended Segment Address Record (16‐ or 32‐bit formats)
47
48 · Start Segment Address Record (16‐ or 32‐bit formats)
49
50 · Extended Linear Address Record (32‐bit format only)
51
52 · Start Linear Address Record (32‐bit format only)
53
54 General Record Format
55 ┌───────┬────────┬────────┬────────┬────────┬────────┐
56 │Record │ Record │ Load │ Record │ Data │ Check │
57 │Mark │ Length │ Offset │ Type │ │ sum │
58 └───────┴────────┴────────┴────────┴────────┴────────┘
59 Record Mark.
60 Each record begins with a Record Mark field containing 0x3A,
61 the ASCII code for the colon (“:”) character.
62
63 Record Length
64 Each record has a Record Length field which specifies the num‐
65 ber of bytes of information or data which follows the Record
66 Type field of the record. This field is one byte, represented
67 as two hexadecimal characters. The maximum value of the Record
68 Length field is hexadecimal 'FF' or 255.
69
70 Load Offset
71 Each record has a Load Offset field which specifies the 16‐bit
72 starting load offset of the data bytes, therefore this field is
73 only used for Data Records. In other records where this field
74 is not used, it should be coded as four ASCII zero characters
75 (“0000” or 0x30303030). This field is two byte, represented as
76 four hexadecimal characters.
77
78 Record Type
79 Each record has a Record Type field which specifies the record
80 type of this record. The Record Type field is used to inter‐
81 pret the remaining information within the record. This field
82 is one byte, represented as two hexadecimal characters. The
83 encoding for all the current record types are:
84
85 0 Data Record
86
87 1 End of File Record
88
89 2 Extended Segment Address Record
90
91 3 Start Segment Address Record
92
93 4 Extended Linear Address Record
94
95 5 Start Linear Address Record
96
97 Data Each record has a variable length Data field, it consists of
98 zero or more bytes encoded as pairs of hexadecimal digits. The
99 interpretation of this field depends on the Record Type field.
100
101 Checksum
102 Each record ends with a Checksum field that contains the ASCII
103 hexadecimal representation of the two's complement of the
104 8‐bit bytes that result from converting each pair of ASCII
105 hexadecimal digits to one byte of binary, from and including
106 the Record Length field to and including the last byte of the
107 Data field. Therefore, the sum of all the ASCII pairs in a
108 record after converting to binary, from the Record Length field
109 to and including the Checksum field, is zero.
110
111 Extended Linear Address Record
112 (32‐bit format only)
113
114 ┌────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
115 │Record │ Record │ Load │ Record │ ULBA (2 │ Check │
116 │Mark │ Length │ Offset │ Type │ bytes) │ sum │
117 │(“:”) │ (2) │ (0) │ (4) │ │ │
118 └────────┴─────────┴─────────┴─────────┴─────────┴─────────┘
119 The 32‐bit Extended Linear Address Record is used to specify bits 16‐31
120 of the Linear Base Address (LBA), where bits 0‐15 of the LBA are zero.
121 Bits 16‐31 of the LBA are referred to as the Upper Linear Base Address
122 (ULBA). The absolute memory address of a content byte in a subsequent
123 Data Record is) obtained by adding the LBA to an offset calculated by
124 adding the Load Offset field of the containing Data Record to the index
125 of the byte in the Data Record (0, 1, 2, ... n). This offset addition
126 is done) modulo 4G (i.e. 32‐bits from 0xFFFFFFFF to 0x00000000) results
127 in wrapping around from the end to the beginning of the 4G linear
128 address defined by the LBA. The linear address at which a particular
129 byte is loaded is calculated as:
130 (LBA + DRLO + DRI) MOD 4G
131 where:
132
133 DRLO is the Load Offset field of a Data Record.
134
135 DRI is the data byte index within the Data Record.
136 When an Extended Linear Address Record defines the value of LBA, it may
137 appear anywhere within a 32‐bit hexadecimal object file. This value
138 remains in effect until another Extended Linear Address Record is
139 encountered. The LBA defaults to zero until an Extended Linear Address
140 Record is encountered. The contents of the individual fields within
141 the record are:
142
143 Record Mark
144 This field contains 0x3A, the hexadecimal encoding of the ASCII
145 colon (“:”) character.
146
147 Record Length
148 The field contains 0x3032, the hexadecimal encoding of the
149 ASCII characters “02”, which is the length, in bytes, of the
150 ULBA data information within this record.
151
152 Load Offset
153 This field contains 0x30303030, the hexadecimal encoding of the
154 ASCII characters “0000”, since this field is not used for this
155 record.
156
157 Record Type
158 This field contains 0x3034, the hexadecimal encoding of the
159 ASCII character “04”, which specifies the record type to be an
160 Extended Linear Address Record.
161
162 ULBA This field contains four ASCII hexadecimal digits that specify
163 the 16‐bit Upper Linear Base Address value. The value is
164 encoded big‐endian (most significant digit first).
165
166 Checksum
167 This field contains the check sum on the Record Length, Load
168 Offset, Record Type, and ULBA fields.
169
170 Extended Segment Address Record
171 (16‐ or 32‐bit formats)
172
173 ┌────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
174 │Record │ Record │ Load │ Record │ USBA (2 │ Check │
175 │Mark │ Length │ Offset │ Type │ bytes) │ sum │
176 │(“:”) │ (2) │ (0) │ (2) │ │ │
177 └────────┴─────────┴─────────┴─────────┴─────────┴─────────┘
178 The 16‐bit Extended Segment Address Record is used to specify bits 4‐19
179 of the Segment Base Address (SBA), where bits 0‐3 of the SBA are zero.
180 Bits 4‐19 of the SBA are referred to as the Upper Segment Base Address
181 (USBA). The absolute memory address of a content byte in a subsequent
182 Data Record is) obtained by adding the SBA to an offset calculated by
183 adding the Load Offset field of the containing Data Record to the index
184 of the byte in the Data Record (0, 1, 2, ... n). This offset addition
185 is done modulo 64K (i.e. 16‐bits from 0xFFFF to 0x0000 results in wrap‐
186 ping around from the end to the beginning of the 64K segment defined by
187 the SBA. The address at which a particular byte is loaded is calcu‐
188 lated as:
189 SBA + ((DRLO + DRI) MOD 64K)
190 where:
191
192 DRLO is the LOAD OFFSET field of a Data Record.
193
194 DRI is the data byte index within the Data Record.
195
196 When an Extended Segment Address Record defines the value of SBA, it
197 may appear anywhere within a 16‐bit hexadecimal object file. This
198 value remains in effect until another Extended Segment Address Record
199 is encountered. The SBA defaults to zero until an Extended Segment
200 Address Record is encountered.
201
202 The contents of the individual fields within the record are:
203
204 Record Mark
205 This field contains 0x3A, the hexadecimal encoding of the ASCII
206 colon (“:”) character.
207
208 Record Length
209 The field contains 0x3032, the hexadecimal encoding of the
210 ASCII characters '02', which is the length, in bytes, of the
211 USBA data information within this record.
212
213 Load Offset
214 This field contains 0x30303030, the hexadecimal encoding of the
215 ASCII characters '0000', since this field is not used for this
216 record.
217
218 Record Type
219 This field contains 0x3032, the hexadecimal encoding of the
220 ASCII character “02”, which specifies the record type to be an
221 Extended Segment Address Record.
222
223 USBA This field contains four ASCII hexadecimal digits that specify
224 the 16‐bit Upper Segment Base Address value. The field is
225 encoded big‐endian (most significant digit first).
226
227 Checksum
228 This field contains the check sum on the Record length, Load
229 Offset, Record Type, and USBA fields.
230
231 Data Record
232 (8‐, 16‐ or 32‐bit formats)
233
234 ┌───────┬────────┬────────┬────────┬────────┬────────┐
235 │Record │ Record │ Load │ Record │ Data │ Check │
236 │Mark │ Length │ Offset │ Type │ │ sum │
237 │(“:”) │ │ │ │ │ │
238 └───────┴────────┴────────┴────────┴────────┴────────┘
239 The Data Record provides a set of hexadecimal digits that represent the
240 ASCII code for data bytes that make up a portion of a memory image.
241 The method for calculating the absolute address (linear in the 8‐bit
242 and 32‐bit case and segmented in the 16‐bit case) for each byte of data
243 is described in the discussions of the Extended Linear Address Record
244 and the Extended Segment Address Record.
245
246 The contents of the individual fields within the record are:
247
248 Record Mark
249 This field contains 0x3A, the hexadecimal encoding of the ASCII
250 colon (“:”) character.
251
252 Record Length
253 The field contains two ASCII hexadecimal digits that specify
254 the number of data bytes in the record. The maximum value is
255 255 decimal.
256
257 Load Offset
258 This field contains four ASCII hexadecimal digits representing
259 the offset from the LBA (see Extended Linear Address Record see
260 Extended Segment Address Record) defining the address which the
261 first byte of the data is to be placed.
262
263 Record Type
264 This field contains 0x3030, the hexadecimal encoding of the
265 ASCII character “00”, which specifies the record type to be a
266 Data Record.
267
268 Data This field contains pairs of ASCII hexadecimal digits, one pair
269 for each data byte.
270
271 Checksum
272 This field contains the check sum on the Record Length, Load
273 Offset, Record Type, and Data fields.
274
275 Note: Care must be taken when the addresses with an record span the end
276 of addressing. The behaviour is different for linear and segmented
277 addressing modes.
278
279 linear If a record starts just short of 2**32, and would finish after
280 2**32, the later part of the record wraps around to address 0.
281 TP 8n segment If a record starts just for of a 2**16 boundary,
282 and would finish after that 2**16 boundary, the later part of
283 the record wraps around to address 0 within the same segment
284 (not the next segment).
285
286 The srec_cat(1) program will never output records such as these, it
287 will always produce separate records on output.
288
289 Start Linear Address Record
290 (32‐bit format only)
291
292 ┌───────┬────────┬────────┬────────┬────────┬────────┐
293 │Record │ Record │ Load. │ Record │ EIP (4 │ Check │
294 │Mark │ Length │ Offset │ Type │ bytes) │ sum │
295 │(“:”) │ (4) │ (0) │ (5) │ │ │
296 └───────┴────────┴────────┴────────┴────────┴────────┘
297 The Start Linear Address Record is used to specify the execution start
298 address for the object file. The value given is the 32‐bit linear
299 address for the EIP register. Note that this record only specifies the
300 code address within the 32‐bit linear address space of the 80386. If
301 the code is to start execution in the real mode of the 80386, then the
302 Start Segment Address Record should be used instead, since that record
303 specifies both the CS and IP register contents necessary for real mode.
304
305 The Start Linear Address Record can appear anywhere in a 32‐bit hexa‐
306 decimal object file. If such a record is not present in a hexadecimal
307 object file, a loader is free to assign a default execution start
308 address.
309
310 The contents of the individual fields within the record are:
311
312 Record mark
313 This field contains 0x3A, the hexadecimal encoding of the ASCII
314 colon (“:”) character.
315
316 Record length
317 The field contains 0x3034, the hexadecimal encoding of the
318 ASCII characters “04”, which is the length, in bytes, of the
319 EIP register content within this record.
320
321 Load Offset
322 This field contains 0x30303030, the hexadecimal encoding of the
323 ASCII characters “0000”, since this field is not used for this
324 record.
325
326 Record Type
327 This field contains 0x3035, the hexadecimal encoding of the
328 ASCII character “05”, which specifies the record type to be a
329 Start Linear Address Record.
330
331 EIP This field contains eight ASCII hexadecimal digits that specify
332 the 32‐bit EIP register contents. The field is encoded big‐
333 endian (most significant digit first).
334
335 Checksum
336 This field contains the check sum on the Record length, Load
337 Offset, Record Type, and EIP fields.
338
339 Start Segment Address Record
340 (16‐ or 32‐bit formats)
341
342 ┌───────┬────────┬────────┬────────┬────────┬────────┬────────┐
343 │Record │ Record │ Load. │ Record │ CS (2 │ IP (2 │ Check │
344 │Mark │ Length │ Offset │ Type │ bytes) │ bytes) │ sum │
345 │(“:”) │ (4) │ (0) │ (3) │ │ │ │
346 └───────┴────────┴────────┴────────┴────────┴────────┴────────┘
347 The Start Segment Address Record is used to specify the execution start
348 address for the object file. The value given is the 20‐bit segment
349 address for the CS and IP registers. Note that this record only speci‐
350 fies the code address within the 20‐bit segmented address space of the
351 8086/80186. The Start Segment Address Record can appear anywhere in a
352 16‐bit hexadecimal object file. If such a record is not present in a
353 hexadecimal object file, a loader is free to assign a default start
354 address.
355
356 The contents of the individual fields within the record are:
357
358 Record Mark
359 This field contains 0x3A, the hexadecimal encoding of the ASCII
360 colon (“:”) character.
361
362 Record Length
363 The field contains 0x3034, the hexadecimal encoding of the
364 ASCII characters “04”, which is the length, in bytes, of the CS
365 and IP register contents within this record.
366
367 Load Offset
368 This field contains 0x30303030, the hexadecimal encoding of the
369 ASCII characters “0000”, since this field is not used for this
370 record.
371
372 Record Type
373 This field contains 0x3033, the hexadecimal encoding of the
374 ASCII character '03', which specifies the record type to be a
375 Start Segment Address Record.
376
377 CS This field contains four ASCII hexadecimal digits that specify
378 the 16‐bit CS register contents. The field is encoded big‐
379 endian (most significant digit first).
380
381 IP This field contains four ASCII hexadecimal digits that specify
382 the 16‐bit IP register contents. The field is encoded big‐
383 endian (most significant digit first).
384
385 Checksum
386 This field contains the check sum on the Record length, Load
387 Offset, Record Type, CS, and IP fields.
388
389 End of File Record
390 (8‐, 16‐, or 32‐bit formats)
391
392 ┌───────┬────────┬────────┬────────┬────────┐
393 │Record │ Record │ Load │ Record │ Check │
394 │Mark │ Length │ Offset │ Type │ sum │
395 │(“:”) │ (0) │ (0) │ (1) │ (0xFF) │
396 └───────┴────────┴────────┴────────┴────────┘
397 The End of File Record specifies the end of the hexadecimal object
398 file.
399
400 The contents of the individual fields within the record are:
401
402 Record mark
403 This field contains 0x3A, the hexadecimal encoding of the ASCII
404 colon (“:”) character.
405
406 Record Length
407 The field contains 0x3030, the hexadecimal encoding of the
408 ASCII characters “00”. Since this record does not contain any
409 Data bytes, the length is zero.
410
411 Load Offset
412 This field contains 0x30303030, the hexadecimal encoding of the
413 ASCII characters “0000”, since this field is not used for this
414 record.
415
416 Record Type
417 This field contains 0x3031, the hexadecimal encoding of the
418 ASCII character “01”, which specifies the record type to be an
419 End of File Record.
420
421 Checksum
422 This field contains the check sum an the Record Length, Load
423 Offset, and Record Type fields. Since all the fields are
424 static, the check sum can also be calculated statically, and
425 the value is 0x4646, the hexadecimal encoding of the ASCII
426 characters “FF”.
427
428 Size Multiplier
429 In general, binary data will expand in sized by approximately 2.3 times
430 when represented with this format.
431
433 Here is an example Intel hex file. It contains the data “Hello, World”
434 to be loaded at address 0.
435 :0D00000048656C6C6F2C20576F726C640AA1
436 :00000001FF
437
439 This information comes (very indirectly) from Microprocessors and Pro‐
440 grammed Logic, Second Edition, Kenneth L. Short, 1987, Prentice‐Hall,
441 ISBN 0‐13‐580606‐2.
442
444 srec_cat version 1.55
445 Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006,
446 2007, 2008, 2009, 2010 Peter Miller
447
448 The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use
449 the 'srec_cat -VERSion License' command. This is free software and you
450 are welcome to redistribute it under certain conditions; for details
451 use the 'srec_cat -VERSion License' command.
452
454 Peter Miller E‐Mail: pmiller@opensource.org.au
455 /\/\* WWW: http://miller.emu.id.au/pmiller/
456
457 Derivation
458 This manual page is derived from a file marked as follows:
459
460 Intel Hexadecimal Object File Format Specification; Revision A, 1/6/88
461
462 Disclaimer: Intel makes no representation or warranties with respect to
463 the contents hereof and specifically disclaims any implied warranties
464 of merchantability or fitness for any particular purpose. Further,
465 Intel reserves the right to revise this publication from time to time
466 in the content hereof without obligation of Intel to notify any person
467 of such revision or changes. The publication of this specification
468 should not be construed as a commitment on Intel's part to implement
469 any product.
470
471
472
473Reference Manual SRecord srec_intel(5)