title: srec_atmel_generic(5)

summary: Atmel Generic file format

text:
# srec_atmel_generic(5)

## NAME
srec_atmel_generic - Atmel Generic file format

## DESCRIPTION
This format is the output of the Atmel AVR assembler. The file contains two columns of hexadecimal coded values. The first column is the 24‐bit word address, the second column is the 16‐bit word data. The columns are separated by a colon (`:') character.

By default, SRecord treats this is little‐endian data (the least significant byte first). If you want big endian order, use the -atmel‐generic‐be argument instead.

### Size Multiplier
In general, binary data will expand in sized by approximately 6.0 times when represented with this format (6.5 times in Windows).

## EXAMPLE
Here is an example Atmel Generic file. It contains the data “Hello, World[rq] to be loaded at bytes address 0x0100 (but remember, the file contents are word addressed).

```
000080:4865
000081:6C6C
000082:6F2C
000083:2057
000084:6F72
000085:6C64
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


package: srecord

title: srec_binary(5)

summary: binary file format

text:
# srec_binary(5)

## NAME
srec_binary - binary file format

## DESCRIPTION
It is possible to read and write binary files using srec_cat(1).

### File Holes
A file hole is a portion of a regular file that contains NUL characters and is not stored in any data block on disk. Holes are a long‐standing feature of Unix files. For instance, the following Unix command creates a file in which the first bytes are a hole:

```
$ echo -n "X" | dd of=/tmp/hole bs=1024 seek=6
$
```

Now /tmp/hole has 6,145 characters (6,144 NUL characters plus an X character), yet the file occupies just one data block on disk.

File holes were introduced to avoid wasting disk space. They are used extensively by database applications and, more generally, by all applications that perform hashing on files.

See http://www.oreilly.com/catalog/linuxkernel2/chapter/ch17.pdf for more information.

### Reading
The size of binary files is taken from the size of the file on the file system. If the file has holes these will read as blocks of NUL (zero) data, as there is no elegant way to detect Unix file holes. In general, you probably want to use the -unfill filter to find and remove large swathes of zero bytes.

### Writing
In producing a binary file, srec_cat(1) honours the address information and places the data into the binary file at the addresses specified in the hex file. This usually results on holes in the file. Sometimes alarmingly large file sizes are reported as a result.

If you are on a brain‐dead operating system without file holes then there are going to be real data blocks containing real zero bytes, and consuming real amounts of disk space. Upgrade - I suggest Linux.

To make a file of the size you expect, use

srec_info foo.s19

to find the lowest address, then use

srec_cat foo.s19 -intel -offset -n -o foo.bin -binary

where n is the lowest address present in the foo.s19 file, as reported by srec_info(1). The negative offset serves to move the data down to have an origin of zero.

## SEE ALSO
srec_input(1)

for a description of the -unfill filter

srec_examples(1)

has a section about binary files, and ways of automagically offseting the data back to zero in a single command.

## COPYRIGHT
SRrecord version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The SRrecord program comes with ABSOLUTELY NO WARRANTY; for details use the 'SRrecord -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'SRrecord -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_brecord(5)

text:
# srec_brecord(5)

## NAME
srec_brecord - Freescale MC68EZ328 Dragonball bootstrap record format

## DESCRIPTION
This data format is understood by Freescale MC68EZ328 Dragonball series processors on their internal UART.

### Lines
Each line contains hexadecimal data, each byte represented by two hexadecimal nybbles in upper case. Characters not in this set, but larger than 0x30 (e.g. lower case) will be ignored, less than 0x30 (e.g. CR or LF) are considered record terminators. Comments are problematic; don't try this at home.

### Fields
Each line contains a 4‐byte address (big endian), a 1‐byte length‐and‐mode, and then data bytes as dictated by the length. There is no checksum. A zero length record is an execution start address record, non‐zero length records are data.

1

2

3

4

5

6

7

8

9

10

...

n

Address

Length

Data

The length‐and‐mode byte is formatted as follows:

7

6

5

4

3

2

1

0

Mode

R

Length

Mode

These bits are ignored by SRecord in input (00 = bytes, 01 = half words, 10 is reserved, 11 = long words). These bits are always zero on output by SRecord.

R

This bit indicates a data read rather than a data write; SRecord does not accept input files with this bit set, and will not set it on output.

Length

The length of the records data bytes. It does not include the address or length bytes. The maximum payload of a record is 31 bytes of data.

### Size Multiplier
In general, binary data will expand in sized by at least 2.35 times when represented with this format.

## EXAMPLE
Here is an example b‐record format file. It contains the data “Hello, World” to be loaded at address 0.

```
000000000D48656C6C6F2C20576F726C640A
```

## SEE ALSO
http://www.freescale.com/files/32bit/doc/ref_manual/MC68VZ328UM.pdf

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_coe(5)

summary: Xilinx Coefficient File Format

text:
# srec_coe(5)

## NAME
srec_coe - Xilinx Coefficient File Format

## DESCRIPTION
The Xilinx Coefficient File Format has a general syntax of the form:

keyword

=

value

;

optional comment

radix‐keyword

=

value

;

optional comment

data‐keyword

=

value, ..., value;

There are numerous keywords, only the “memory_initialization_radix” and “memory_initialization_vector” keywords are used. The semicolons are mandatory.

### Size Multiplier
Binary data stored in this format expand approximately 4 times (5 time on Windows).

### See Also
http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/cgn_r_coe_file_syntax.htm

## COPYRIGHT
srec_coe.5 version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_coe.5 program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_coe.5 -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_coe.5 -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_cosmac(5)

summary: RCA Cosmac Elf file format

text:
# srec_cosmac(5)

## NAME
srec_cosmac - RCA Cosmac Elf file format

## DESCRIPTION
This file takes the form of one or more RCA Cosmac Elf monitor commands, also known as the IDIOT/4 monitor. Only the change memory command (!M) is allowed.

The general form of the !M command takes the form

!Maaaa dd ... dd

The !M command writes data byte bytes (represented by character pairs dd) into successive memory locations, started at address aaaa. Spaces between data bytes are ignored. Using the comma (,) line continuation character resumes from the next address in sequence.

!Maaaa dd ... dd, dd ... dd

Using the semicolon (;) line continuation character takes an address on the next line

!Maaaa dd ... dd; aaaa dd ... dd

It is also possible to have the semicolon immediately after the command.

!M; aaaa dd ... dd

All of these forms may be used in combination.

### Size Multiplier
In general, binary data will expand in size by approximately 2.0 times when represented with this format.

## EXAMPLE
Here is an example Cosmac file. It contains the data “Hello, World[rq] to be loaded at address 0x1000.

```
!M1000 48656C6C6F2C20576F726C640A
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_dec_binary(5)

summary: DEC Binary (XXDP) file format

text:
# srec_dec_binary(5)

## NAME
srec_dec_binary - DEC Binary (XXDP) file format

## DESCRIPTION
The DEC Binary (XXDP) format was used on the PDP 11 series machines. This is a binary format, and is not readable or editable with a text editor. The file consists of records of the form

type

length

address

...data...

checksum

The field are defined as follows:

type

Two byte little‐endian value. Must always be 1.

length

Two byte little‐endian value. This is the number of bytes in the data, plus six.

address

Two byte little‐endian value. This is the load address of the data.

data

The data is simple raw bytes. There are (length‐6) of them.

checksum

The checcksum is a single byte. It is the negative of the simple summ of all the header and data bytes.

If the record length is exactly 6 (i.e. no data), this is the execution start address record, indicating the transfer address.

In addition there may be NUL padding characters between records. It is common for records to be padded so that they start on even byte boundaries. In the days of paper tape, it was common for the file to have many leading NULs, to generate blank leader on the tape.

### Size Multiplier
In general, raw binary data will expand in sized by approximately 1.03 times when represented with this format.

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_emon52(5)

summary: Elektor Monitor (EMON52) file format

text:
# srec_emon52(5)

## NAME
srec_emon52 - Elektor Monitor (EMON52) file format

## DESCRIPTION
This format is used by the monitor EMON52, developed by the European electronics magazine Elektor (Elektuur in Holland). Elektor wouldn't be Elektor if they didn't try to reinvent the wheel. It's a mystery why they didn't use an existing format for the project. Only the Elektor Assembler will produce this file format, reducing the choice of development tools dramatically.

### Records
All data lines are called records, and each record contains the following four fields:

cc

aaaa

:

dd ... dd

ssss

The field are defined as follows:

cc

The byte count. A two digit hex value (1 byte), counting the actual data bytes in the record. The byte count is separated from the next field by a space.

aaaa

The address field. A four hex digit (2 byte) number representing the first address to be used by this record.

:

The address field and the data field are separated by a colon.

dd

The actual data of this record. There can be 1 to 255 data bytes per record (see cc) All bytes in the record are separated from each other (and the checksum) by a space.

ssss

Data Checksum, adding all bytes of the data line together, forming a 16 bit checksum. Covers only all the data bytes of this record.

Please note that there is no End Of File record defined.

### Byte Count
The byte count cc counts the actual data bytes in the current record. Usually records have 16 data bytes. I don't know what the maximum number of data bytes is. It depends on the size of the data buffer in the EMON52.

### Address Field
This is the address where the first data byte of the record should be stored. After storing that data byte, the address is incremented by 1 to point to the address for the next data byte of the record. And so on, until all data bytes are stored.

The address is represented by a 4 digit hex number (2 bytes), with the MSD first.

### Data Field
The payload of the record is formed by the Data field. The number of data bytes expected is given by the Byte Count field.

### Checksum
The checksum is a 16 bit result from adding all data bytes of the record together.

### Size Multiplier
In general, binary data will expand in sized by approximately 3.8 times when represented with this format.

## EXAMPLE
Here is an example of an EMON52 file:

```
10 0000:57 6F 77 21 20 44 69 64 20 79 6F 75 20 72 65 61 0564
10 0010:6C 6C 79 20 67 6F 20 74 68 72 6F 75 67 68 20 61 05E9
10 0020:6C 6C 20 74 68 69 73 20 74 72 6F 75 62 6C 65 20 05ED
10 0030:74 6F 20 72 65 61 64 20 74 68 69 73 20 73 74 72 05F0
04 0040:69 6E 67 21 015F
```

## SEE ALSO
http://sbprojects.fol.nl/knowledge/fileformats/emon52.htm

## AUTHOR
This man page was taken from the above Web page. It was written by San Bergmans <sanmail@bigfoot.com>


title: srec_fairchild(5)

summary: Fairchild Fairbug file format

text:
# srec_fairchild(5)

## NAME
srec_fairchild - Fairchild Fairbug file format

## DESCRIPTION
The Fairchild Fairbug format has 8‐byte records. A file begins with an address record and ends with an end‐of‐file record.

There are three record types in this file format.

Address records are of the form

S

nnnn

indicating the address for the following data records. Data records are of the form

X

ffffffffffffffff

c

Each data record begins with an X and always contains 8 data bytes. The ff characters are hexadecimal byte values (8 bytes). Each data byte is represented by 2 hexadecimal characters. The c character is a hex digit being the the nibble‐sum of the data bytes. A 1‐digit hexadecimal checksum follows the data in each data record. The checksum represents, in hexadecimal notation, the sum of the binary equivalents of the 16 digits in the record; the half carry from the fourth bit is ignored. The programmer ignores any character (except for address characters and the asterisk character, which terminates the data transfer) between a checksum and the start character of the next data record. This space can be used for comments. The end‐of‐file record has the form

*

The last record consists of an asterisk only, which indicates the end of file.

### Size Multiplier
In general, binary data will expand in sized by approximately 2.4 times when represented with this format.

## EXAMPLE
Here is an example Fairchild Fairbug file. It contains the data “Hello, World[rq] to be loaded at address 0x1000. Notice how the last record is padded with 0xFF bytes.

```
S1000
X48656C6C6F2C2057C
X6F726C64210AFFFF3
*
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_fastload(5)

summary: LSI Logic Fast Load file format

text:
# srec_fastload(5)

## NAME
srec_fastload - LSI Logic Fast Load file format

## DESCRIPTION
The FastLoad Format uses a compressed ASCII format that permits files to be downloaded in less than half the time taken for Motorola S‐records.

The base‐64 encoding used is "A‐Za‐z0−9,.". The data is encoded in groups of 4 characters (3 bytes, 24 bits).

The character '/' is used to introduce a special function. Special functions are:

Annnnnn

Defines an address.

Bnn

Define a single byte.

Cnnnn

Compare the checksums. The checksum is a simple positive 16‐bit sum, of the data bytes only.

EAA

Define the program's entry point. The address will be the current address as defined by the A command. (The AA number in this command is ignored.) This must be the last entry in the file.

KAA

Clear the checksum. (The AA number in this command is ignored.)

Sname,X

Define a symbol. The address of the symbol will be the current address as defined by the A command.

Znn

Clear a number of bytes.

### Size Multiplier
In general, binary data will expand in sized by approximately 1.4 times when represented with this format.

## EXAMPLE
Here is an example LSI Logic Fast Load format file. It contains the data “Hello, World[rq] to be loaded at address 0.

```
/AAAA
SGVsbG8sIFdvcmxk/BAK/CARS/AAAA/EAA
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_formatted_binary(5)

summary: Formatted Binary file format

text:
# srec_formatted_binary(5)

## NAME
srec_formatted_binary - Formatted Binary file format

## DESCRIPTION
This is the PDP‐11 paper tape format, described in the DEC‐11‐GGPC‐D PDP‐11 "Paper Tape Software Programming Handbook" 1972.

The file starts with a character sequence which appears as an arrow when punched on 8‐hole paper tape.

0x08, 0x1C, 0x2A, 0x49, 0x08, 0x00

Then follows a byte count, encoded big‐endian in the low 4 bits of the next 4 bytes. The high bits should be zero.

Then follows a 0xFF byte.

The data follows, as many bytes as specified in the header.

The trailer consists of the following bytes:

0x00, 0x00,

and then a 2‐byte checksum (big‐endian). The alternate header sequence

0x08, 0x1C, 0x3E, 0x6B, 0x08, 0x00

is followed by an 8‐nibble big‐endian byte count.

### Size Multiplier
In general, binary data will expand in sized very little when represented with this format.

## EXAMPLE
Here is a hex dump of a formatted binary file containing the data "Hello, World!".

```
0000: 08 1C 2A 49 08 00 00 00  ..*I....
0008: 00 0E FF 48 65 6C 6C 6F  ...Hello
0010: 2C 20 57 6F 72 6C 64 21  , World!
0018: 0A 00 00 04 73           ....s
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_forth(5)

summary: FORTH file format

text:
# srec_forth(5)

## NAME
srec_forth - FORTH file format

## DESCRIPTION
This format can be read by FORTH interpreters

The file starts with HEX to set the number base.

Each line contains the address, the byte and a store command, either C! for RAM or EEC! for EEPROM

## EXAMPLE
Here is an example srec[hy]forth file. It contains the data “Hello, World” to be loaded at address 0x1000.

```
HEX
48 1000 C!
65 1001 C!
6C 1002 C!
6C 1003 C!
6F 1004 C!
2C 1005 C!
20 1006 C!
57 1007 C!
6F 1008 C!
72 1009 C!
6C 100A C!
64 100B C!
0A 100C C!
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_fpc(5)

summary: four packed code file format

text:
# srec_fpc(5)

## NAME
srec_fpc - four packed code file format

## SYNOPSIS
All ASCII based file formats have one disadvantage in common: they all need more than double the amount of characters as opposed to the number of bytes to be sent. Address fields and checksums will add even more characters. So the shorter the records, the more characters have to be sent to get the file across.

The FPC format may be used to reduce the number of characters needed to send a file in ASCII format, although it still needs more characters than the actual bytes it sends. FPC stands for "Four Packed Code". The reduction is accomplished by squeezing 4 real bytes into 5 ASCII characters. In fact every ASCII character will be a digit in the base 85 number system. There aren't enough letters, digits and punctuation marks available to get 85 different characters, but if we use both upper case and lower case letters we will manage. This implies that the FPC is case sensitive, as opposed to all other ASCII based file formats.

### Base 85
The numbering system is in base 85, and is somewhat hard to understand for us humans who are usually only familiar with base 10 numbers. Some of us understand base 2 and base 16 as well, but base 85 is for most people something new. Luckily we don't have to do any math with this number system. We just convert a 32 bit number into a 5 digit number in base 85. A 32 bit number has a range of 4,294,967,296, while a 5 digit number in base 85 has a range of 4,437,053,125, which is enough to do the trick. One drawback is that we always have to send multiples of 4 bytes, even if we actually want to send 1, 2 or 3 bytes. Unused bytes are padded with zeroes, and are discarded at the receiving end.

The digits of the base 85 numbering system start at %, which represents the value of 0. The highest value of a digit in base 85 is 84, and is represented by the character 'z'. If you want to check this with a normal ASCII table you will notice that we have used one character too many! Why? I don't know, but for some reason we have to skip the '*' character in the row. This means that after the ')' character follows the '+' character.

We can use normal number conversion algorithms to generate the FPC digits, with this tiny difference. We have to check whether the digit is going to be equal or larger than the ASCII value for '*'. If this is the case we have to increment the digit once to stay clear of the '*'. In base 85 MSD digits go first, like in all number systems!

The benefit of this all is hopefully clear. For every 4 bytes we only have to send 5 ASCII characters, as opposed to 8 characters for all other formats.

### Records
Now we take a look at the the formatting of the FPC records. We look at the record at byte level, not at the actual base 85 encoded level. Only after formatting the FPC record at byte level we convert 4 bytes at a time to a 5 digit base 85 number. If we don't have enough bytes in the record to fill the last group of 5 digits we will add bytes with the value of 0 behind the record.

$

ss

cc

ffff

aaaaaaaa

dddddddd

The field are defined as:

$

Every line starts with the character $, all other characters are digits of base 85.

ss

The checksum. A one byte 2's‐complement checksum of all bytes of the record.

cc

The byte‐count. A one byte value, counting all the bytes in the record minus 4.

ffff

Format code, a two byte value, defining the record type.

aaaaaaaa

The address field. A 4 byte number representing the first address of this record.

dddddddd

The actual data of this record.

### Record Begin
Every record begins with the ASCII character "$". No spaces or tabs are allowed in a record. All other characters in the record are formed by groups of 5 digits of base 85.

### Checksum field
This field is a one byte 2's‐complement checksum of the entire record. To create the checksum make a one byte sum from all of the bytes from all of the fields of the record:

Then take the 2's‐complement of this sum to create the final checksum. The 2's‐complement is simply inverting all bits and then increment by 1 (or using the negative operator). Checking the checksum at the receivers end is done by adding all bytes together including the checksum itself, discarding all carries, and the result must be $00. The padding bytes at the end of the line, should they exist, should not be included in checksum. But it doesn't really matter if they are, for their influence will be 0 anyway.

### Byte Count
The byte count cc counts the number of bytes in the current record minus 4. So only the number of address bytes and the data bytes are counted and not the first 4 bytes of the record (checksum, byte count and format flags). The byte count can have any value from 0 to 255.

Usually records have 32 data bytes. It is not recommended to send too many data bytes in a record for that may increase the transmission time in case of errors. Also avoid sending only a few data bytes per record, because the address overhead will be too heavy in comparison to the payload.

### Format Flags
This is a 2 byte number, indicating what format is represented in this record. Only a few formats are available, so we actually waste 1 byte in each record for the sake of having multiples of 4 bytes.

Format code 0 means that the address field in this record is to be treated as the absolute address where the first data byte of the record should be stored.

Format code 1 means that the address field in this record is missing. Simply the last known address of the previous record +1 is used to store the first data byte. As if the FPC format wasn't fast enough already ;‐)

Format code 2 means that the address field in this record is to be treated as a relative address. Relative to what is not really clear. The relative address will remain in effect until an absolute address is received again.

### Address Field
The first data byte of the record is stored in the address specified by the Address field aaaaaaaa. After storing that data byte, the address is incremented by 1 to point to the address for the next data byte of the record. And so on, until all data bytes are stored.

The length of the address field is always 4 bytes, if present of course. So the address range for the FPC format is always 2**32.

If only the address field is given, without any data bytes, the address will be set as starting address for records that have no address field.

Addresses between records are non sequential. There may be gaps in the addressing or the address pointer may even point to lower addresses as before in the same file. But every time the sequence of addressing must be changed, a format 0 record must be used. Addressing within one single record is sequential of course.

### Data Field
This field contains 0 or more data bytes. The actual number of data bytes is indicated by the byte count in the beginning of the record less the number of address bytes. The first data byte is stored in the location indicated by the address in the address field. After that the address is incremented by 1 and the next data byte is stored in that new location. This continues until all bytes are stored. If there are not enough data bytes to obtain a multiple of 4 we use 0x00 as padding bytes at the end of the record. These padding bytes are ignored on the receiving side.

### End of File
End of file is recognized if the first four bytes of the record all contain 0x00. In base 85 this will be “$%%%%%”. This is the only decent way to terminate the file.

### Size Multiplier
In general, binary data will expand in sized by approximately 1.7 times when represented with this format.

## Example
Now it's time for an example. In the first table you can see the byte representation of the file to be transferred. The 4th row of bytes is not a multiple of 4 bytes. But that does not matter, for we append $00 bytes at the end until we do have a multiple of 4 bytes. These padding bytes are not counted in the byte count however!

```
D81400000000B000576F77212044696420796F7520726561
431400000000B0106C6C7920676F207468726F7567682061
361400000000B0206C6C20746861742074726F75626C6520
591100000000B030746F207265616420746869733F000000
00000000
```

Only after converting the bytes to base 85 we get the records of the FPC type file format presented in the next table. Note that there is always a multiple of 5 characters to represent a multiple of 4 bytes in each record.

```
$kL&@h%%,:,B.\?00EPuX0K3rO0JI))
$;UPR'%%,:<Hn&FCG:at<GVF(;G9wIw
$7FD1p%%,:LHmy:>GTV%/KJ7@GE[kYz
$B[6\;%%,:\KIn?GFWY/qKI1G5:;-_e
$%%%%%
```

As you can see the length of the lines is clearly shorter than the original ASCII lines.

## SEE ALSO
http://sbprojects.fol.nl/knowledge/fileformats/fpc.htm

## AUTHOR
This man page was taken from the above Web page. It was written by San Bergmans <sanmail@bigfoot.com>

For extra points: Who invented this format? Where is it used?


title: srec_idt(5)

summary: IDT/sim binary file format

text:
# srec_idt(5)

## NAME
srec_idt - IDT/sim binary file format

## DESCRIPTION
This format comes from Integrated Device Technology (IDT) System Integration Manager (IDT/sim).

It is almost identical to the Motorola S‐Record format, except that most of each record is in binary, and there is no line termination character. The 'S' and tag characters are the same (ascii), however all other bytes are emitted as binary, rather than as a 2‐byte hexadecimal ascii encoding.

## SEE ALSO
srec_motorola(5)

The orginal Motorola S‐Record format.

srec_wilson(5)

For a different spin on making S‐Record into a more densely packed binary file.

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_intel(5)

text:
# srec_intel(5)

## NAME
srec_intel - Intel Hexadecimal object file format specification

## DESCRIPTION
This format is also known as the Intel MCS‐86 Object format.

This document describes the hexadecimal object file format for the Intel 8‐bit, 16‐bit, and 32‐bit microprocessors. The hexadecimal format is suitable as input to PROM programmers or hardware emulators.

Hexadecimal object file format is a way of representing an absolute binary object file in ASCII. Because the file is in ASCII instead of binary, it is possible to store the file is non‐binary medium such as paper‐tape, punch cards, etc.; and the file can also be displayed on CRT terminals, line printers, etc.. The 8‐bit hexadecimal object file format allows for the placement of code and data within the 16‐bit linear address space of the Intel 8‐bit processors. The 16‐bit hexadecimal format allows for the 20‐bit segmented address space of the Intel 16‐bit processors. And the 32‐bit format allows for the 32‐bit linear address space of the Intel 32‐bit processors.

--address-length=2

“i8hex”

16‐bit

--address-length=3

“i16hex”

20‐bit

segmented

--address-length=4

“i32hex”

32‐bit

linear

The hexadecimal representation of binary is coded in ASCII alphanumeric characters. For example, the 8‐bit binary value 0011‐1111 is 3F in hexadecimal. To code this in ASCII, one 8‐bit byte containing the ASCII code for the character '3' (0011‐0011 or 0x33) and one 8‐bit byte containing the) ASCII code for the character 'F' (0100‐0110 or 0x46) are required. For each byte value, the high‐order hexadecimal digit is always the first digit of the pair of hexadecimal digits. This representation (ASCII hexadecimal) requires twice as many bytes as the binary representation.

A hexadecimal object file is blocked into records, each of which contains the record type, length, memory load address and checksum in addition to the data. There are currently six (6) different types of records that are defined, not all combinations of these records are meaningful, however. The record are:

•

Data Record (8‐, 16‐, or 32‐bit formats)

•

End of File Record (8‐, 16‐, or 32‐bit formats)

•

Extended Segment Address Record (16‐ or 32‐bit formats)

•

Start Segment Address Record (16‐ or 32‐bit formats)

•

Extended Linear Address Record (32‐bit format only)

•

Start Linear Address Record (32‐bit format only)

### General Record Format
Record Mark

Record Length

Load Offset

Record Type

Data

Check sum

Record Mark.

Each record begins with a Record Mark field containing 0x3A, the ASCII code for the colon (“:”) character.

Record Length

Each record has a Record Length field which specifies the number of bytes of information or data which follows the Record Type field of the record. This field is one byte, represented as two hexadecimal characters. The maximum value of the Record Length field is hexadecimal 'FF' or 255.

Load Offset

Each record has a Load Offset field which specifies the 16‐bit starting load offset of the data bytes, therefore this field is only used for Data Records. In other records where this field is not used, it should be coded as four ASCII zero characters (“0000” or 0x30303030). This field is two byte, represented as four hexadecimal characters.

Record Type

Each record has a Record Type field which specifies the record type of this record. The Record Type field is used to interpret the remaining information within the record. This field is one byte, represented as two hexadecimal characters. The encoding for all the current record types are: 0

Data Record

1

End of File Record

2

Extended Segment Address Record

3

Start Segment Address Record

4

Extended Linear Address Record

5

Start Linear Address Record

Data

Each record has a variable length Data field, it consists of zero or more bytes encoded as pairs of hexadecimal digits. The interpretation of this field depends on the Record Type field.

Checksum

Each record ends with a Checksum field that contains the ASCII hexadecimal representation of the two's complement of the 8‐bit bytes that result from converting each pair of ASCII hexadecimal digits to one byte of binary, from and including the Record Length field to and including the last byte of the Data field. Therefore, the sum of all the ASCII pairs in a record after converting to binary, from the Record Length field to and including the Checksum field, is zero.

### Extended Linear Address Record
(32‐bit format only)

Record Mark (“:”)

Record Length (2)

Load Offset (0)

Record Type (4)

ULBA (2 bytes)

Check sum

The 32‐bit Extended Linear Address Record is used to specify bits 16‐31 of the Linear Base Address (LBA), where bits 0‐15 of the LBA are zero. Bits 16‐31 of the LBA are referred to as the Upper Linear Base Address (ULBA). The absolute memory address of a content byte in a subsequent Data Record is) obtained by adding the LBA to an offset calculated by adding the Load Offset field of the containing Data Record to the index of the byte in the Data Record (0, 1, 2, ... n). This offset addition is done) modulo 4G (i.e. 32‐bits from 0xFFFFFFFF to 0x00000000) results in wrapping around from the end to the beginning of the 4G linear address defined by the LBA. The linear address at which a particular byte is loaded is calculated as:

(LBA + DRLO + DRI) MOD 4G

where: DRLO

is the Load Offset field of a Data Record.

DRI

is the data byte index within the Data Record.

When an Extended Linear Address Record defines the value of LBA, it may appear anywhere within a 32‐bit hexadecimal object file. This value remains in effect until another Extended Linear Address Record is encountered. The LBA defaults to zero until an Extended Linear Address Record is encountered. The contents of the individual fields within the record are: Record Mark

This field contains 0x3A, the hexadecimal encoding of the ASCII colon (“:”) character.

Record Length

The field contains 0x3032, the hexadecimal encoding of the ASCII characters “02”, which is the length, in bytes, of the ULBA data information within this record.

Load Offset

This field contains 0x30303030, the hexadecimal encoding of the ASCII characters “0000”, since this field is not used for this record.

Record Type

This field contains 0x3034, the hexadecimal encoding of the ASCII character “04”, which specifies the record type to be an Extended Linear Address Record.

ULBA

This field contains four ASCII hexadecimal digits that specify the 16‐bit Upper Linear Base Address value. The value is encoded big‐endian (most significant digit first).

Checksum

This field contains the check sum on the Record Length, Load Offset, Record Type, and ULBA fields.

### Extended Segment Address Record
(16‐ or 32‐bit formats)

Record Mark (“:”)

Record Length (2)

Load Offset (0)

Record Type (2)

USBA (2 bytes)

Check sum

The 16‐bit Extended Segment Address Record is used to specify bits 4‐19 of the Segment Base Address (SBA), where bits 0‐3 of the SBA are zero. Bits 4‐19 of the SBA are referred to as the Upper Segment Base Address (USBA). The absolute memory address of a content byte in a subsequent Data Record is) obtained by adding the SBA to an offset calculated by adding the Load Offset field of the containing Data Record to the index of the byte in the Data Record (0, 1, 2, ... n). This offset addition is done modulo 64K (i.e. 16‐bits from 0xFFFF to 0x0000 results in wrapping around from the end to the beginning of the 64K segment defined by the SBA. The address at which a particular byte is loaded is calculated as:

SBA + ((DRLO + DRI) MOD 64K)

where: DRLO

is the LOAD OFFSET field of a Data Record.

DRI

is the data byte index within the Data Record.

When an Extended Segment Address Record defines the value of SBA, it may appear anywhere within a 16‐bit hexadecimal object file. This value remains in effect until another Extended Segment Address Record is encountered. The SBA defaults to zero until an Extended Segment Address Record is encountered.

The contents of the individual fields within the record are:

Record Mark

This field contains 0x3A, the hexadecimal encoding of the ASCII colon (“:”) character.

Record Length

The field contains 0x3032, the hexadecimal encoding of the ASCII characters '02', which is the length, in bytes, of the USBA data information within this record.

Load Offset

This field contains 0x30303030, the hexadecimal encoding of the ASCII characters '0000', since this field is not used for this record.

Record Type

This field contains 0x3032, the hexadecimal encoding of the ASCII character “02”, which specifies the record type to be an Extended Segment Address Record.

USBA

This field contains four ASCII hexadecimal digits that specify the 16‐bit Upper Segment Base Address value. The field is encoded big‐endian (most significant digit first).

Checksum

This field contains the check sum on the Record length, Load Offset, Record Type, and USBA fields.

### Data Record
(8‐, 16‐ or 32‐bit formats)

Record Mark (“:”)

Record Length

Load Offset

Record Type

Data

Check sum

The Data Record provides a set of hexadecimal digits that represent the ASCII code for data bytes that make up a portion of a memory image. The method for calculating the absolute address (linear in the 8‐bit and 32‐bit case and segmented in the 16‐bit case) for each byte of data is described in the discussions of the Extended Linear Address Record and the Extended Segment Address Record.

The contents of the individual fields within the record are:

Record Mark

This field contains 0x3A, the hexadecimal encoding of the ASCII colon (“:”) character.

Record Length

The field contains two ASCII hexadecimal digits that specify the number of data bytes in the record. The maximum value is 255 decimal.

Load Offset

This field contains four ASCII hexadecimal digits representing the offset from the LBA (see Extended Linear Address Record see Extended Segment Address Record) defining the address which the first byte of the data is to be placed.

Record Type

This field contains 0x3030, the hexadecimal encoding of the ASCII character “00”, which specifies the record type to be a Data Record.

Data

This field contains pairs of ASCII hexadecimal digits, one pair for each data byte.

Checksum

This field contains the check sum on the Record Length, Load Offset, Record Type, and Data fields.

Note: Care must be taken when the addresses with an record span the end of addressing. The behaviour is different for linear and segmented addressing modes.

linear

If a record starts just short of 2**32, and would finish after 2**32, the later part of the record wraps around to address 0. TP 8n segment If a record starts just for of a 2**16 boundary, and would finish after that 2**16 boundary, the later part of the record wraps around to address 0 within the same segment (not the next segment).

The srec_cat(1) program will never output records such as these, it will always produce separate records on output.

### Start Linear Address Record
(32‐bit format only)

Record Mark (“:”)

Record Length (4)

Load. Offset (0)

Record Type (5)

EIP (4 bytes)

Check sum

The Start Linear Address Record is used to specify the execution start address for the object file. The value given is the 32‐bit linear address for the EIP register. Note that this record only specifies the code address within the 32‐bit linear address space of the 80386. If the code is to start execution in the real mode of the 80386, then the Start Segment Address Record should be used instead, since that record specifies both the CS and IP register contents necessary for real mode.

The Start Linear Address Record can appear anywhere in a 32‐bit hexadecimal object file. If such a record is not present in a hexadecimal object file, a loader is free to assign a default execution start address.

The contents of the individual fields within the record are:

Record mark

This field contains 0x3A, the hexadecimal encoding of the ASCII colon (“:”) character.

Record length

The field contains 0x3034, the hexadecimal encoding of the ASCII characters “04”, which is the length, in bytes, of the EIP register content within this record.

Load Offset

This field contains 0x30303030, the hexadecimal encoding of the ASCII characters “0000”, since this field is not used for this record.

Record Type

This field contains 0x3035, the hexadecimal encoding of the ASCII character “05”, which specifies the record type to be a Start Linear Address Record.

EIP

This field contains eight ASCII hexadecimal digits that specify the 32‐bit EIP register contents. The field is encoded big‐endian (most significant digit first).

Checksum

This field contains the check sum on the Record length, Load Offset, Record Type, and EIP fields.

### Start Segment Address Record
(16‐ or 32‐bit formats)

Record Mark (“:”)

Record Length (4)

Load. Offset (0)

Record Type (3)

CS (2 bytes)

IP (2 bytes)

Check sum

The Start Segment Address Record is used to specify the execution start address for the object file. The value given is the 20‐bit segment address for the CS and IP registers. Note that this record only specifies the code address within the 20‐bit segmented address space of the 8086/80186. The Start Segment Address Record can appear anywhere in a 16‐bit hexadecimal object file. If such a record is not present in a hexadecimal object file, a loader is free to assign a default start address.

The contents of the individual fields within the record are:

Record Mark

This field contains 0x3A, the hexadecimal encoding of the ASCII colon (“:”) character.

Record Length

The field contains 0x3034, the hexadecimal encoding of the ASCII characters “04”, which is the length, in bytes, of the CS and IP register contents within this record.

Load Offset

This field contains 0x30303030, the hexadecimal encoding of the ASCII characters “0000”, since this field is not used for this record.

Record Type

This field contains 0x3033, the hexadecimal encoding of the ASCII character '03', which specifies the record type to be a Start Segment Address Record.

CS

This field contains four ASCII hexadecimal digits that specify the 16‐bit CS register contents. The field is encoded big‐endian (most significant digit first).

IP

This field contains four ASCII hexadecimal digits that specify the 16‐bit IP register contents. The field is encoded big‐endian (most significant digit first).

Checksum

This field contains the check sum on the Record length, Load Offset, Record Type, CS, and IP fields.

### End of File Record
(8‐, 16‐, or 32‐bit formats)

Record Mark (“:”)

Record Length (0)

Load Offset (0)

Record Type (1)

Check sum (0xFF)

The End of File Record specifies the end of the hexadecimal object file.

The contents of the individual fields within the record are:

Record mark

This field contains 0x3A, the hexadecimal encoding of the ASCII colon (“:”) character.

Record Length

The field contains 0x3030, the hexadecimal encoding of the ASCII characters “00”. Since this record does not contain any Data bytes, the length is zero.

Load Offset

This field contains 0x30303030, the hexadecimal encoding of the ASCII characters “0000”, since this field is not used for this record. In ancient times, i8hex used this for the start address record.

Record Type

This field contains 0x3031, the hexadecimal encoding of the ASCII character “01”, which specifies the record type to be an End of File Record.

Checksum

This field contains the check sum an the Record Length, Load Offset, and Record Type fields. Since all the fields are static, the check sum can also be calculated statically, and the value is 0x4646, the hexadecimal encoding of the ASCII characters “FF”.

### Size Multiplier
In general, binary data will expand in sized by approximately 2.3 times when represented with this format.

## EXAMPLE
Here is an example Intel hex file. It contains the data “Hello, World” to be loaded at address 0.

```
:0D00000048656C6C6F2C20576F726C640AA1
:00000001FF
```

## REFERENCE
This information comes (very indirectly) from Microprocessors and Programmed Logic, Second Edition, Kenneth L. Short, 1987, Prentice‐Hall, ISBN 0‐13‐580606‐2.

http://en.wikipedia.org/wiki/Intel_HEX

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au

### Derivation
This manual page is derived from a file marked as follows:

Intel Hexadecimal Object File Format Specification; Revision A, 1/6/88

Disclaimer: Intel makes no representation or warranties with respect to the contents hereof and specifically disclaims any implied warranties of merchantability or fitness for any particular purpose. Further, Intel reserves the right to revise this publication from time to time in the content hereof without obligation of Intel to notify any person of such revision or changes. The publication of this specification should not be construed as a commitment on Intel's part to implement any product.


title: srec_intel16(5)

summary: Intel Hexadecimal 16\[hy]bit file format specification

text:
# srec_intel16(5)

## NAME
srec_intel16 - Intel Hexadecimal 16‐bit file format specification

## DESCRIPTION
This format is also known as the INHX16 format.

This document describes the hexadecimal object file format for 16‐bit microprocessors.

This format is very similar to the srec_intel(5) format, except that the addresses are word addresses. The count field is a word count.

The hexadecimal representation of binary is coded in ASCII alphanumeric characters. For example, the 8‐bit binary value 0011‐1111 is 3F in hexadecimal. To code this in ASCII, one 8‐bit byte containing the ASCII code for the character '3' (0011‐0011 or 0x33) and one 8‐bit byte containing the) ASCII code for the character 'F' (0100‐0110 or 0x46) are required. For each byte value, the high‐order hexadecimal digit is always the first digit of the pair of hexadecimal digits. This representation (ASCII hexadecimal) requires twice as many bytes as the binary representation.

A hexadecimal object file is blocked into records, each of which contains the record type, length, memory load address and checksum in addition to the data. There are currently six (6) different types of records that are defined, not all combinations of these records are meaningful, however. The record are:

•

Data Record

•

End of File Record

•

Extended Segment Address Record

•

Start Segment Address Record

•

Extended Linear Address Record

•

Start Linear Address Record

### General Record Format
Record Mark

Record Length

Load Offset

Record Type

Data

Check sum

Record Mark.

Each record begins with a Record Mark field containing 0x3A, the ASCII code for the colon (“:”) character.

Record Length

Each record has a Record Length field which specifies the number of 16‐bit words of information or data which follows the Record Type field of the record. This field is one byte, represented as two hexadecimal characters. The maximum value of the Record Length field is hexadecimal 'FF' or 255.

Load Offset

Each record has a Load Offset field which specifies the 16‐bit starting load offset of the data words, therefore this field is only used for Data Records (if the words are loaded as bytes, the address needs to be doubled). In other records where this field is not used, it should be coded as four ASCII zero characters (“0000” or 0x30303030). This field one 16‐bit word, represented as four hexadecimal characters.

Record Type

Each record has a Record Type field which specifies the record type of this record. The Record Type field is used to interpret the remaining information within the record. This field is one byte, represented as two hexadecimal characters. The encoding for all the current record types are: 0

Data Record

1

End of File Record

5

Execution Start Address Record

Data

Each record has a variable length Data field, it consists of zero or more 16‐bit words encoded as set of 4 hexadecimal digits, most significant digit first. The interpretation of this field depends on the Record Type field.

Checksum

Each record ends with a Checksum field that contains the ASCII hexadecimal representation of the two's complement of the 8‐bit bytes that result from converting each pair of ASCII hexadecimal digits to one byte of binary, from and including the Record Length field to and including the last byte of the Data field. Therefore, the sum of all the ASCII pairs in a record after converting to binary, from the Record Length field to and including the Checksum field, is zero.

### Data Record
(8‐, 16‐ or 32‐bit formats)

Record Mark (“:”)

Record Length

Load Offset

Record Type

Data

Check sum

The Data Record provides a set of hexadecimal digits that represent the ASCII code for data bytes that make up a portion of a memory image.

The contents of the individual fields within the record are:

Record Mark

This field contains 0x3A, the hexadecimal encoding of the ASCII colon (“:”) character.

Record Length

The field contains two ASCII hexadecimal digits that specify the number of 16‐bit data words in the record. The maximum value is 255 decimal.

Load Offset

This field contains four ASCII hexadecimal digits representing the word address at which the first word of the data is to be placed. (For an exquivalent bytes address, double it.)

Record Type

This field contains 0x3030, the hexadecimal encoding of the ASCII character “00”, which specifies the record type to be a Data Record.

Data

This field contains sets of four ASCII hexadecimal digits, one set for each 16‐bit data word, most significant digit first.

Checksum

This field contains the check sum on the Record Length, Load Offset, Record Type, and Data fields.

### Execution Start Address Record
Record Mark (“:”)

Record Length (4)

Load Offset (0)

Record Type (5)

EIP (4 bytes)

Check sum

The Execution Start Address Record is used to specify the execution start address for the object file. This is where the loader is to jump to begin execution once the hex load is complete.

The Execution Start Address Record can appear anywhere in a hexadecimal object file. If such a record is not present in a hexadecimal object file, a loader is free to assign a default execution start address.

The contents of the individual fields within the record are:

Record mark

This field contains 0x3A, the hexadecimal encoding of the ASCII colon (“:”) character.

Record length

The field contains 0x3032, the hexadecimal encoding of the ASCII characters “02”, which is the length, in bytes, of the EIP register content within this record.

Load Offset

This field contains 0x30303030, the hexadecimal encoding of the ASCII characters “0000”, since this field is not used for this record.

Record Type

This field contains 0x3035, the hexadecimal encoding of the ASCII character “05”, which specifies the record type to be a Start Address Record.

EIP

This field contains eight ASCII hexadecimal digits that specify the address. The field is encoded big‐endian (most significant digit first).

Checksum

This field contains the check sum on the Record length, Load Offset, Record Type, and EIP fields.

### End of File Record
This shall be the last record in the file.

Record Mark (“:”)

Record Length (0)

Load Offset (0)

Record Type (1)

Check sum (0xFF)

The End of File Record specifies the end of the hexadecimal object file.

The contents of the individual fields within the record are:

Record mark

This field contains 0x3A, the hexadecimal encoding of the ASCII colon (“:”) character.

Record Length

The field contains 0x3030, the hexadecimal encoding of the ASCII characters “00”. Since this record does not contain any Data bytes, the length is zero.

Load Offset

This field contains 0x30303030, the hexadecimal encoding of the ASCII characters “0000”, since this field is not used for this record.

Record Type

This field contains 0x3031, the hexadecimal encoding of the ASCII character “01”, which specifies the record type to be an End of File Record.

Checksum

This field contains the check sum an the Record Length, Load Offset, and Record Type fields. Since all the fields are static, the check sum can also be calculated statically, and the value is 0x4646, the hexadecimal encoding of the ASCII characters “FF”.

### Size Multiplier
In general, binary data will expand in sized by approximately 2.3 times when represented with this format.

## EXAMPLE
Here is an example INHX16 file. It contains the data “Hello, World” to be loaded at address 0.

```
:0700000065486C6C2C6F5720726F646CFF0AA8
:00000001FF
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_logisim(5)

summary: format Logisim EPROM load files

text:
# srec_logisim(5)

## NAME
srec_logisim - format Logisim EPROM load files

## DESCRIPTION
The file format used for image files is intentionally simple; this permits you to write a program, such as an assembler, that generates memory images that can then be loaded into memory. As an example of this file format, if we had a 256‐byte memory whose first five bytes were 2, 3, 0, 20, and -1, and all subsequent values were 0, then the image would be the following text file.

v2.0 raw 02 03 00 14 ff

The first line identifies the file format used (currently, there is only one file format recognized). Subsequent values list the values in hexadecimal, starting from address 0; you can place several such values on the same line. Logisim will assume that any values unlisted in the file are zero. The image file can use run‐length encoding; for example, rather than list the value 00 sixteen times in a row, the file can include 16*00 rather than repeat 00 sixteen times. Notice than the number of repetitions is written in base 10. Files produced by Logisim will use run‐length encoding for runs of at least four values

### Size Multiplier
In general, binary data will expand in sized by approximately 2.95 times when represented with this format.

### Commentary
This format is particularly deficient.

•

The is no way for changing address in‐flight. And therefore the format can't have holes in the data.

•

There are no checksums, or any other error checking.

•

There is no provision for a comment header, as distinct to the “v2.0 raw” magic number.

•

There is no provision for an execution start adddress.

## SEE ALSO
http://ozark.hendrix.edu/~burch/logisim/docs/2.3.0/guide/mem/menu.html

## COPYRIGHT
srec_logisim.5 version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_logisim.5 program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_logisim.5 -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_logisim.5 -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_mem(5)

summary: Lattice Memory Initialization format

text:
# srec_mem(5)

## NAME
srec_mem - Lattice Memory Initialization format

## DESCRIPTION
A Lattice Memory Initialization format (.mem), by Lattice Semiconductor, file is an ASCII text file that consists of a header followed by lines of memory data.

### Syntax
The data must be in one of the following formats: Bin (binary), Hex (hexadecimal), or Address‐Hex (described below).

For hexadecimal values, both upper and lower case can be used. If the data has fewer bits than the specified data width, the most significant bits are filled with 0. Any address not specified will be filled with 0.

Comments can be added at any point after the header (defined below) by starting the comment with a pound sign (#) or two slashes (//). The comment then includes everything to the end of the line. Comments may be added to any of the data, but never add comments to the header.

### Header
A .mem file starts with a header, which declares the file format, memory size, and address and data display radix for Memory Generator. The syntax of the header is:

```
#Format=Bin | Hex | AddrHex
#Depth=1 to 65536
#Width=1 to 256
#AddrRadix=index‐number
#DataRadix=index‐number
#Data
```

The index‐number can be one of the following numbers. AddrRadix and DataRadix can have different values.

```
Binary: 0
Octal: 1
Decimal: 2
Hexadecimal: 3
```

For example, the following header says the .mem file is using the binary format for a 32x8 memory. When displayed in Memory Generator, the address will be shown in hexadecimal and the data will be shown in binary.

```
#Format=Bin
#Depth=32
#Width=8
#AddrRadix=3
#DataRadix=0
#Data
```

### Bin and Hex Formats
The data is represented in binary or hexadecimal format. Each line of data specifies the contents for one memory location, starting with address 0. That is, the first line is for address 0, the second line is for address 1, and so on. For each line, the data is interpreted as least significant bit on the right.

For example, in the Bin format, the following lines will initialize address 0 to “00011011”, address 1 to “11111010” (assuming it is a 32x8 memory).

```
# for a 32x8 memory
11011
11111010
```

In the Hex format, the following lines will initialize address 0 to “003B”, address 1 to “FB0A” (assuming it is a 32x16 memory).

```
# for a 32x16 memory
3B
FB0A
```

### AddrHex
The data is represented in hexadecimal format. Each line consists of an address followed by a colon and then any number of data words, separated by spaces:

address: data data> data...

The data will be applied starting at <address> and filling in sequentially from there. For example:

```
A0:03 F3 3E 4F
B2:3B 9F
```

will initialize A0 with 03, A1 with F3, A2 with 3E, A3 with 4F, B2 with 3B, and B3 with 9F. The other addresses will be initialized to 0. So A4 through B1 will be set to 0.

### See Also

```
http://help.latticesemi.com/docs/webhelp/eng/wwhelp/wwhimpl/common/html/wwhelp.htm#href=Design%20Entry/memory_initialization_file.htm#1371843&single=true
```

### Size Multiplier
The size multiplier depends on the width selected. As files grow larger, their size multipliers will approach those in the table, from above.

Width

Linux

Windows

8

2.96

3.0

16

2.47

2.5

32

2.25

2.28

64

2.13

2.15

### Byte Order
This format is implicitly big‐endian. Use a -byte‐swap filter if you need something different.

## COPYRIGHT
srec_mem version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_mem program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_mem -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_mem -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_mif(5)

summary: Memory Initialization File (MIF) format

text:
# srec_mif(5)

## NAME
srec_mif - Memory Initialization File (MIF) format

## DESCRIPTION
This format was invented by Altera.

An ASCII text file (with the extension .mif) that specifies the initial content of a memory block (CAM, RAM, or ROM), that is, the initial values for each address. This file is used during project compilation and/or simulation. You can create a Memory Initialization File in the Memory Editor, the In‐System Memory Content Editor, or the Quartus II Text Editor.

A Memory Initialization File serves as an input file for memory initialization in the Compiler and Simulator. You can also use a Hexadecimal (Intel‐Format) File (.hex) to provide memory initialization data.

A Memory Initialization File contains the initial values for each address in the memory. A separate file is required for each memory block. In a Memory Initialization File, you must specify the memory depth and width values. In addition, you can specify data radixes as binary (BIN), hexadecimal (HEX), octal (OCT), signed decimal (DEC), or unsigned decimal (UNS) to display and interpret addresses and data values. Data values must match the specified data radix.

When creating a Memory Initialization File in the Quartus II Text Editor, you must start with the DEPTH, WIDTH, ADDRESS_RADIX and DATA_RADIX keywords. You can use Tab "" and Space " " characters as separators, and insert multiple lines of comments with the percent "%" character, or a single comment with double dash "--" characters. Address:data pairs represent data contained inside certain memory addresses and you must place them between the CONTENT BEGIN and END keywords, as shown in the following examples.

```
%  multiple‐line comment
multiple‐line comment  %
-- single‐line comment
DEPTH = 8;                    -- The size of data in bits
WIDTH = 32;                   -- The size of memory in words
ADDRESS_RADIX = HEX;          -- The radix for address values
DATA_RADIX = BIN;             -- The radix for data values
CONTENT                       -- start of (address : data pairs)
BEGIN
00 : 00000000;                -- memory address : data
01 : 00000001;
02 : 00000010;
03 : 00000011;
04 : 00000100;
05 : 00000101;
06 : 00000110;
07 : 00000111;
08 : 00001000;
09 : 00001001;
0A : 00001010;
0B : 00001011;
0C : 00001100;
END;
```

There are several ways to specify the address and data, as seen in the following table:

Notation

Interpretation

Example

A : D;

Addr[A] = D

2 : 4 Address: 01234567 Data: 00400000

[A0..A1] : D; (See note below.)

Addr[A0] to [A1] contain data D

[0..7] : 6 Address: 01234567 Data: 66666666

[A0..A1] : D0 D1; (See note below.)

Addr[A0] = D0, Addr[A0+1] = D1, Addr[A0+2] = D0, Addr[A0+3] = D1, until A0+n = A1

[0..7] : 5 6 Address: 01234567 Data: 56565656

A : D0 D1 D2;

Addr[A] = D0, Addr[A+1] = D1, Addr[A+2] = D2

2 : 4 5 6 Address: 01234567 Data: 00456000

Note: The address range forms are limited in SRecord, the range must be less than 255 bytes. SRecord will never write an address range.

Note: When reading MIF file, SRecord will round up the number of bits in the WIDTH to be a multiple of 8. Multi‐byte values will be laid down in memory as big‐endian.

An ASCII text file (with the extension .mif) that specifies the initial content of a memory block (CAM, RAM, or ROM), that is, the initial values for each address. This file is used during project compilation and/or simulation. A MIF contains the initial values for each address in the memory. In a MIF, you are also required to specify the memory depth and width values. In addition, you can specify the radixes used to display and interpret addresses and data values.

## SIZE MULTIPLIER
In general, binary data will expand in sized by approximately 3.29 times when 8‐bit data is represented with this format (16 bit = 2.75, 32 bit = 2.47, 64 bit = 2.34).

## EXAMPLE
Following is a sample MIF:

```
DEPTH = 32; % Memory depth and width are required %
% DEPTH is the number of addresses %
WIDTH = 14; % WIDTH is the number of bits of data per word %
% DEPTH and WIDTH should be entered as decimal numbers %
ADDRESS_RADIX = HEX; % Address and value radixes are required %
DATA_RADIX = HEX; % Enter BIN, DEC, HEX, OCT, or UNS; unless %

                  % otherwise specified, radixes = HEX %

 --Specify values for addresses, which can be single address or range
CONTENT
BEGIN
[0..F]: 3FFF;     % Range: Every address from 0 to F = 3FFF %
6     :    F;     % Single address: Address 6 = F %
8     :    F E 5; % Range starting from specific address %
--                % Addr[8] = F, Addr[9] = E, Addr[A] = 5 %
END;
```

## REFERENCE
The above information was gleaned from the following sources:

```
http://www.altera.com/support/software/nativelink/quartus2/glossary/def_mif.html
http://www.mil.ufl.edu/4712/docs/mif_help.pdf
```

## COPYRIGHT
srec_mif version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_mif program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_mif -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_mif -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_mips_flash(5)

summary: MIPS\[hy]Flash file format

text:
# srec_mips_flash(5)

## NAME
srec_mips_flash - MIPS‐Flash file format

## DESCRIPTION
The MIPS SDE tool chain has a convert program that is able to output this format. I have no idea what reads it, some kind of flash programmer I suppose.

### Format
The file must start with '!R' to reset the state machine. White space appears to be ignored, except as it serves to separate tokens.

Data is presented as 32‐bit hexadecimal numbers, in the normal big‐endian text number format. To write them to memory, you have to know if the target is big‐endian or little‐endian. for little endian targets, reverse the order of the bytes in this number.

The eight bytes following a '>' are a sort of comment. The SDE code reads like they are displayed in the flash programmer as a kind of progress indicator.

The number following '@' is a new address for the following data.

Each segment must be erased before it can be written, this is done with the '!E' command. Each segment is assumed to be 128kB in size.

Special segments must unlocked (with the '!C' command) and locked again (with the '!S' command).

This file format contains no checksum mechanism.

### Command Line Options
This format is specified using one of the -Mips‐Flash‐Big_Endian or -Mips‐Flash‐Little_Endian options. The endian‐ness must be specified on the command line, because there is nothing in the file contents to indicate the endian‐ness of the data it contains.

### Size Multiplier
In general, binary data will expand in sized by approximately 2.3 times when represented with this format (worse if you use shorter lines).

## EXAMPLE
Here is an example MIPS‐Flash file. It contains the data “Hello, World” to be loaded at bytes address 0x0000 (but remember, the file contents are always multiples of four bytes).

```
!R
>00000xxx @00000000 !E
@00000000
>00000000
48656C6C 6F2C2057 6F726C64 210A0000
>#DL_DONE
>FINISHED
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_mos_tech(5)

summary: MOS Technology file format

text:
# srec_mos_tech(5)

## NAME
srec_mos_tech - MOS Technology file format

## DESCRIPTION
The MOS Technology format allows binary files to be uploaded and downloaded between between a computer system (such as a PC, Macintosh, or workstation) and an emulator or evaluation board for microcontrollers and microprocessors.

### The Lines
Each line consists of 5 fields. These are the length field, address field, data field, and the checksum. The lines always start with a semicolon (;) character.

### The Fields
;

Length

Address

Data

Checksum

CRLF

Length

The record length field is a 2 character (1 byte) field that specifies the number of data bytes in the record. Typically this is 24 or less.

Address

This is a 2‐byte address that specifies where the data in the record is to be loaded into memory, big‐endian.

Data

The data field contains the executable code, memory‐loadable data or descriptive information to be transferred.

Checksum

The checksum is an 2‐byte field that represents the least significant two bytes of the the sum of the values represented by the pairs of characters making up the record's length, address, and data fields, big‐endian.

### End of File
The final line should have a data length of zero, and the data line count in the address field. The checksum is not the usual checksum, it is instead a repeat of the data line count.

### Size Multiplier
In general, binary data will expand in sized by approximately 2.54 times when represented with this format.

## EXAMPLE
Here is an example MOS Technology format file. It contains the data “Hello, World” to be loaded at address 0.

```
;0C000048656C6C6F2C20576F726C640454
;0000010001
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au

## KIM‐1 User Manual - Appendix F - Paper Tape Format
(The following information is reproduced from http://users.telenet.be/kim1‐6502/6502/usrman.html#F just in case it vanishes from the Web.)

The paper tape LOAD and DUMP routines store and retrieve data in a specific format designed to insure error free recovery. Each byte of data to be stored is converted to two half bytes. The half bytes (whose possible values are 0 to F HEX) are translated into their ASCII equivalents and written out onto paper tape in this form.

Each record outputted begins with a “;” character (ASCII 3B) to mark the start of a valid record. The next byte transmitted (18HEX) or (24 decimal) is the number of data bytes contained in the record. The record's starting address High (1 byte, 2 characters), starting address Lo (1 byte, 2 characters), and data (24 bytes, 48 characters) follow. Each record is terminated by the record's check‐sum (2 bytes, 4 characters), a carriage return (ASCII 0D), line feed (ASCII 0A), and six “NULL” characters (ASCII 00). (NULL characters cause a blank area on the paper tape.)

The last record transmitted has zero data bytes (indicated by ;00) The starting address field is replaced by a four digit Hex number representing the total number of data records contained in the transmission, followed by the records usual check‐sum digits. An “XOFF” character ends the transmission.

;180000FFEEDDCCBBAA0099887766554433221122334455667788990AFC

;0000010001

During a “LOAD” all incoming data is ignored until a “;” character is received. The receipt of non ASCII data or a mismatch between a records calculated check‐sum and the check‐sum read from tape will cause an error condition to be recognized by KIM. The check‐sum is calculated by adding all data in the record except the “;” character. The paper tape format described is compatible with all other MOS Technology, Inc. software support programs.


title: srec_motorola(5)

summary: Motorola S\[hy]Record hexadecimal file format

text:
# srec_motorola(5)

## NAME
srec_motorola - Motorola S‐Record hexadecimal file format

## DESCRIPTION
This format is also known as the Exorciser, Exormacs or Exormax format.

Motorola's S‐record format allows binary files to be uploaded and downloaded between two computer systems. This type of format is widely used when transferring programs and data between a computer system (such as a PC, Macintosh, or workstation) and an emulator or evaluation board for Motorola microcontrollers and microprocessors.

### The Lines
Most S‐Record file contain only S‐Record lines (see the next section), which always start with a capital S character. Some systems generate various “extensions[rq] which usually manifest as lines which start with something else. These “extension[rq] lines may or may not break other systems made by other vendors. Caveat emptor.

### The Fields
The S‐Record format consists of 5 fields. These are the type field, length field, address field, data field, and the checksum. The lines always start with a capital S character.

S

Type

Record Length

Address

Data

Checksum

Type

The type field is a 1 character field that specifies whether the record is an S0, S1, S2, S3, S5, S6, S7, S8 or S9 field.

Record Length

The record length field is a 2 character (1 byte) field that specifies the number of character pairs (bytes) in the record, excluding the type and record length fields.

Address

This is a 2‐, 3‐ or 4‐byte address that specifies where the data in the S‐Record is to be loaded into memory.

Data

The data field contains the executable code, memory‐loadable data or descriptive information to be transferred.

Checksum

The checksum is an 8‐bit field that represents the least significant byte of the one's complement of the sum of the values represented by the pairs of characters making up the record's length, address, and data fields.

### Record Types
S0

This type of record is the header record for each block of S‐Records. The data field may contain any descriptive information identifying the following block of S‐Records. (It is commonly “HDR[rq] on many systems.) The address field is normally zero.

S1

A record containing data and the 2‐byte address at which the data is to reside.

S2

A record containing data and the 3‐byte address at which the data is to reside.

S3

A record containing data and the 4‐byte address at which the data is to reside.

S5

An optional record containing the number of S1, S2 and S3 records transmitted in a particular block. The count appears in the two‐byte address field. There is no data field. This record is optional, you do not have to use it. Nobody knows if you can have more than one in a file; and if you do, nobody knows whether or not the line count resets after each one.

The srec_cat command will only ever use one, provided the number of lines fits in 16 bits, otherwise it will use S6.

S6

An optional record containing the number of S1, S2 and S3 records transmitted in a particular block. The count appears in the three‐byte address field. There is no data field. This record is optional, you do not have to use it. Nobody knows if you can have more than one in a file; and if you do, nobody knows whether or not the line count resets after each one.

Nobody knows what happens if you mix S5 and S6 records in a file.

The srec_cat command will only ever use one, provided the number of lines fits in 24 bits.

S7

A termination record for a block of S3 records. The address field may contain the 4‐byte address of the instruction to which control is passed. There is no data field.

S8

A termination record for a block of S2 records. The address field may optionally contain the 3‐byte address of the instruction to which control is passed. There is no data field.

S9

A termination record for a block of S1 records. The address field may optionally contain the 2‐byte address of the instruction to which control is passed. If not specified, the first entry point specification encountered in the object module input will be used. There is no data field.

### Size Multiplier
In general, binary data will expand in sized by approximately 2.4 times when represented with this format.

## EXAMPLE
Here is an example S‐Record file. It contains the data “Hello, World[rq] to be loaded at address 0.

```
S00600004844521B
S110000048656C6C6F2C20576F726C640A9D
S5030001FB
S9030000FC
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_msbin(5)

summary: Windows CE Binary Image Data Format

text:
# srec_msbin(5)

## NAME
srec_msbin - Windows CE Binary Image Data Format

## DESCRIPTION
This format is the output of the Microsoft WinCE Platform Builder. This is a binary (non‐text) file format. File names in this format typically (ambiguously) use the .bin suffix.

### File Format
Files in this format start with a header record.

Then comes the data itself, organized into records.

The file finishes with an execution start address record. This is mandatory.

### File Header Record
Data in this format start with an optional header containing the magic “B000FF\n”, followed by the image start (four bytes, little endian) address and the span of the image (highest address - lowest address + 1) (four bytes, little endian). The file header does not have a checksum; it is therefore possible that a corrupt file header will go undetected.

Magic “B000FF\n” (7 bytes)

Least Address (4 bytes)

Greatest Address (4 bytes)

There is no provision for a file comment of any kind.

### Data Record
Each record consists of a record start address (four bytes, little endian), a record length (four bytes, little endian), a record checksum (four bytes, little endian), followed by the record data. The data part of each record is raw byte values, no encoding.

Start address (4 bytes)

Length (4 bytes)

Checksum (4 bytes)

Data

The checksum is calculated by a simple sum of unsigned bytes into a 32‐bit accumulator.

The 12 record header bytes are not included in the record checksums; it is therefore possible that a corrupt record header will go undetected.

It is not possible to place data at address zero with this format. Address zero is reserved for use by the execution start address record.

There is effectively no limit on the length of a record (2^32-1). It is not uncommon for a MsBin file to contain records with sizes in the tens of megabytes.

### Execution Start Address Record
Last comes a special record with the record address set to zero and record length set to the image execution start address. According to specification the record describing the execution start address must be always present, and must always be the last record in the file.

Zero (4 bytes)

Start Address (4 bytes)

Checksum = 0 (4 bytes)

### Commentary
The MsBin files produced by SRecord are valid and can be successfully parsed by the command line utilities viewbin and cvrtbin (part of Windows CE platform).

For a MsBin file to be usable in Microsoft WinCE Platform Builder it has to contain a TOC meta‐structure. This is data embedded in the file by Microsoft WinCE Platform Builder itself.

The opposite conversion - from MsBin - comes in handy when analyzing a MsBin file (i.e. a WinCE image).

### Size Multiplier
In general, binary data will expand in sized by approximately 1.0 times (approaching asymptotically from above) when represented with this format, as the 15‐byte file header is averaged over the data content. Holes in the data will also increase the size.

## SOURCE
http://msdn.microsoft.com/en-us/library/ms924510.aspx

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_needham(5)

summary: Needham EMP\[hy]series programmer ASCII file format

text:
# srec_needham(5)

## NAME
srec_needham - Needham EMP‐series programmer ASCII file format

## DESCRIPTION
This format is understood by Needham Electronics' EMP‐series programmers. See www.needhams.com/winman.pdf for more information. (This format is very similar to the ASCII‐Hex format, but without the ^B and ^C guard characters.)

Each data byte is represented as 2 hexadecimal characters, and is separated by white space from all other data bytes.

The address for data bytes is set by using a sequence of $Annnn, characters, where nnnn is the 8‐character ascii representation of the address. The comma is required. There is no need for an address record unless there are gaps. Implicitly, the file starts a address 0 if no address is set before the first data byte.

### Size Multiplier
In general, binary data will expand in sized by approximately 3.0 times when represented with this format.

## EXAMPLE
Here is an example ascii‐hex file. It contains the data “Hello, World[rq] to be loaded at address 0x1000.

```
$A1000,
48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 0A
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_os65v(5)

summary: OS65V Loader file format

text:
# srec_os65v(5)

## NAME
srec_os65v - OS65V Loader file format

## DESCRIPTION
This format is used by Ohio Scientific OS65V‐compatible loaders. This family of machines includes the OSI C1P, Superboard II, C2, C4, C8, and Challenger III, as well as the UK101, and Elektor Junior.

The file startes with a period '.' (0x2E), to ensure address entry mode. then a 4‐digit hex address, followed by a slash '/' (0X2F) to enter the data entry mode. The initial address is always present. There is no need for an additional address record unless there are gaps.

Each data byte is represented as 2 hexadecimal characters, and is separated by a carriage return character (0x0D) (advance address). The final return character may be omitted.

The data is concluded with a period '.' (0x2E) to re‐enter address mode. If an address to start execution is specified, then the last 5 bytes are nnnnG where nnnn is the 4‐digit execution address, and G is the 'Go' command.

### Size Multiplier
In general, binary data will expand in sized by approximately 3.0 times when represented with this format.

## EXAMPLE
Here is an example ascii‐hex file. It contains the data “Hello, World[rq] to be loaded at address 0x1000, with execution at 0x1003. (On a 6502, this is the opcode for indirect jump to 0x2C6F.)

1000/48^M65^M6C^M6C^M6F^M2C^M20^M57^M6F^M72^M6C^M64^M0A^M.1010G

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_ppb(5)

summary: Stag Prom Programmer binary format

text:
# srec_ppb(5)

## NAME
srec_ppb - Stag Prom Programmer binary format

## DESCRIPTION
This is the native binary format of the Stag Prom Programmer.

### Format
The format is packet based. The packet is somposed of an 0x01 byte, the packet payload size (4 bytes, big‐endian), the packet address size (4 bytes, big‐endian), the packet data, and a one‐byte simple sum of the payload data.

If the packet payload is more than 1024 bytes, there is an intermediate checksum after each 1024th payload pyte.

The end of file is indicated by a packet with a zero‐length payload.

### Command Line Option
This format is specified using the -PPB command line option.

### Size Multiplier
In general, binary data will expand in sized by approximately 1.002 times when represented with this format (worse if there are many short data regions).

## SEE ALSO
http://www.stag.co.uk/

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_ppx(5)

summary: Stag Prom Programmer hexadecimal format

text:
# srec_ppx(5)

## NAME
srec_ppx - Stag Prom Programmer hexadecimal format

## DESCRIPTION
This is the native hexadecimal format of the Stag Prom Programmer.

### Format
The file must start with an asterisk '*' on a line by itself.

Each line has a 16‐bit address, followed by 8‐bit bytes.

The end is indicated by '$S' folloowed by a 16‐bit checksum of the data bytes as 4 hex digits.

### Command Line Option
This format is specified using the -PPX command line option.

### Size Multiplier
In general, binary data will expand in sized by approximately 3 times when represented with this format (worse if you use shorter lines).

## EXAMPLE
Here is an example PPX file. It contains the data “Hello, World” to be loaded at bytes address 0x0000 (but remember, the file contents are always multiples of four bytes).

```
*
0000 48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 21 0A $S0473
```

## SEE ALSO
http://matthieu.benoit.free.fr/pdf/pp39.pdf http://www.stag.co.uk/

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_signetics(5)

summary: Signetics file format

text:
# srec_signetics(5)

## NAME
srec_signetics - Signetics file format

## DESCRIPTION
The Signetics file format is not often used. The major disadvantage in modern applications is that the addressing range is limited to only 64kb.

### Records
All data lines are called records, and each record contains the following 5 fields:

:

aaaa

cc

as

dd

ss

The field are defined as follows:

:

Every record starts with this identifier.

aaaa

The address field. A four digit (2 byte) number representing the first address to be used by this record.

cc

The byte‐count. A two digit value (1 byte), counting the actual data bytes in the record.

as

Address checksum. Covers 2 address bytes and the byte count.

dd

The actual data of this record. There can be 1 to 255 data bytes per record (see cc)

ss

Data Checksum. Covers only all the data bytes of this record.

### Record Begin
Every record begins with a colon “:[rq] character. Records contain only ASCII characters. No spaces or tabs are allowed in a record. In fact, apart from the 1st colon, no other characters than 0..9 and A..F are allowed in a record. Interpretation of a record should be case less, it does not matter if you use a..f or A..F.

Unfortunately the colon was chosen for the Signetics file format, similar to the Intel format (see srec_intel(5) for more information). However, SRecord is able to automatically detect the dofference between the two format, when you use the -Guess format specifier.

### Address Field
This is the address where the first data byte of the record should be stored. After storing that data byte, the address is incremented by 1 to point to the address for the next data byte of the record. And so on, until all data bytes are stored. The address is represented by a 4 digit hex number (2 bytes), with the MSD first. The order of addresses in the records of a file is not important. The file may also contain address gaps, to skip a portion of unused memory.

### Byte Count
The byte count cc counts the actual data bytes in the current record. Usually records have 32 data bytes, but any number between 1 and 255 is possible.

A value of 0x00 for cc indicates the end of the file. In this case not even the address checksum will follow! The record (and file) are terminated immediately.

It is not recommended to send too many data bytes in a record for that may increase the transmission time in case of errors. Also avoid sending only a few data bytes per record, because the address overhead will be too heavy in comparison to the payload.

### Address Checksum
This is not really a checksum anymore, it looks more like a CRC. The checksum can not only detect errors in the values of the bytes, but also bytes out of order can be detected.

The checksum is calculated by this algorithm:

```
checksum = 0
for i = 1 to 3

  checksum = checkum XOR byte

  ROL checksum
next i
```

For the Address Checksum we only need 2 Address bytes and 1 Byte Count byte to be added. That's why we count to 3 in the loop. Every byte is XORed with the previous result. Then the intermediate result is rolled left (carry rolls back into b0). This results in a very reliable checksum, and that for only 3 bytes!

The last record of the file does not contain any checksums! So the file ends right after the Byte Count of 0.

### Data Field
The payload of the record is formed by the Data field. The number of data bytes expected is given by the Byte Count field. The last record of the file may not contain a Data field.

### Data Checksum
This checksum uses the same algorithm as used for the Address Checksum. This time we calculate the checksum with only the data bytes of this record.

```
checksum = 0
for i = 1 to cc

  checksum = checksum XOR byte

  ROL checksum
next i
```

Note that we count to the Byte Count cc this time.

### Size Multiplier
In general, binary data will expand in sized by approximately 2.4 times when represented with this format.

## EXAMPLE
Here is an example Signetics file

```
:B00010A5576F77212044696420796F75207265617B
:B01010E56C6C7920676F207468726F756768206136
:B02010256C6C20746861742074726F75626C652068
:B0300D5F746F207265616420746869733FD1
:B03D00
```

In the example above you can see a piece of code in Signetics format. The first 3 lines have 16 bytes of data each, which can be seen by the byte count. The 4th line has only 13 bytes, because the program is at it's end there. Notice that the last record of the file contains no data bytes, and not even an Address Checksum.

## SEE ALSO
http://sbprojects.fol.nl/knowledge/fileformats/signetics.htm

## AUTHOR
This man page was taken from the above Web page. It was written by San Bergmans <sanmail@bigfoot.com>


title: srec_spasm(5)

summary: SPASM file format

text:
# srec_spasm(5)

## NAME
srec_spasm - SPASM file format

## DESCRIPTION
This format is the output of the Paralax SPASM assembler (now defunct, I'm told). The file contains two columns of 16‐bit hexadecimal coded values. The first column is the word address, the second column is the word data.

By default, SRecord treats this is big‐endian data (the most significant byte first). If you want little endian order, use the -spasm‐le argument instead.

### Size Multiplier
In general, binary data will expand in sized by approximately 5.0 times when represented with this format (5.5 times in Windows).

## EXAMPLE
Here is an example SPASM file. It contains the data “Hello, World[rq] to be loaded at bytes address 0x0100 (but remember, the file contents are word addressed).

```
0080 6548
0081 6C6C
0082 2C6F
0083 5720
0084 726F
0085 646C
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_spectrum(5)

summary: Spectrum file format

text:
# srec_spectrum(5)

## NAME
srec_spectrum - Spectrum file format

## DESCRIPTION
In this format, bytes are recorded as ASCII code with binary digits represented by 1s and 0s. Each byte is preceded by a decimal address.

The file ends with a Control‐C character (0x03).

### Size Multiplier
In general, binary data will expand in sized by approximately 14 times when represented with this format (or 15 times on DOS or Windows).

## EXAMPLE
Here is an example Spectrum file. It contains the data “Hello, World[rq] to be loaded at address 0x0.

```
^B
0000 01001000
0001 01100101
0002 01101100
0003 01101100
0004 01101111
0005 00101100
0006 00100000
0007 01010111
0008 01101111
0009 01110010
0010 01101100
0011 01100100
0012 00100001
0013 00001010
^C
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au