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