BINEX

A conversion program for binary and hexadecimal embedded software data.

Binex

NewLife Software

INTRODUCTION | NEW | INSTALLATION | USAGE | EXAMPLE | FORMATS | MESSAGES | GLOSSARY | COLOPHON

Copyright ® 1990-1999-2009 E.K.H. van der Pols, Zuidland, Nederland


INTRODUCTION

Binex is a symbolic conversion program for binary and hexadecimal encoded absolute-addressed data files, that are regularly encounterd while creating embedded software for EPROM-programming or FLASH-storage. As from version 2.00 on, Binex is a console application only suited for running on a Win32-platform (Windows 9x or Windows NT). If you are still using DOS, you will need an older version of Binex (V1.45).

Binex is a Windows console application, so it runs in a DOS-box under Windows, but not in a DOS-only environment. Binex is controlled via parameters on the command line or from a command file. It is normally used embedded in a script file or a makefile.

The main functions (actions) of Binex are:

During these actions, Binex can perform several operations on the data, like:

Binex can therefore perform most common actions necessary for the production of absolute-addressed embedded software.

This document is the user manual of Binex V2.00. Binex itself contains a concise help-screen with all available options, that is shown when Binex is called with no parameters.

The next sections describe new features of Binex, installation, and de-installation of the program. After that the usage of Binex is explained, with all actions, operations and how to control them, illustrated by an example.

Detailed information is available in the section about the used file formats, and error messages. A glossary and a colophon conclude the document.


WHAT'S NEW in Binex V2.00

If you are upgrading from an older version of Binex, you should take note of the following modifications:


INSTALLATION

The installation of Binex is easy.

  1. Copy the file BINEX.EXE to the utility-directory of your personal computer or server, for example C:\UTL.

  2. For your convenience this directory should be in the search path of your system. If necessary edit the file AUTOEXEC.BAT in the root of your startup disk with the line:
    PATH=%PATH%;C:\UTL

    Reboot your system to make the changes effective.

  3. Ready.

Binex V2.00 can replace any previous version of Binex, however if you still want to use Binex under DOS, you will need this older version, e.g. Binex V1.44 or V1.45.

Binex does not use environment variables or registry settings, nor makes it any changes to the registry or any other system resource. De-installation of Binex is therefore as easy as the installation: just remove BINEX.EXE from your system.


USAGE

parameter | option | actions | operations | switches

Open a console window (e.g. in Windows 95 select Start|Programs|MS-DOS-prompt) and type the command:

    BINEX

Binex shows its help screen:

Binex V2.00 1999.05.06 (c) 1990-1999 by E.K.H. van der Pols, Zuidland.

Usage:	BINEX {option} {inputfile[.HEX]} {;<comment>} {@<cmdfile>}

 /A[<page>]	Encheck ADSP-2101 hex-file [or extract Boot Page]
 /B[V]		Decode hex-file into binary files
 /H[HVS<n>]	Encode binary file(s) into hex-file[s]
 /X[XVS<n>]	Copy hex file(s) to hex-file[s]

 /C[WKEIV][@<addr>][&<sumaddr>]		Check data range
 /F[WLIV]@<addr>[-<addr>][:<data>]	Fill range with data
 /Z[V][@<addr>][-<addr>]		Swap data bytes
 /:[:V][@<addr>][-<addr>]		Discard data [out of] range

 /O[<file>]	Output destination file, directory or device
 /L[ANS:-]	Labels [Alpha,Num,Save,Discard,Disable]
 /@<base>	base address of data			/V	View
 /$<newbase>	new data base address			/![+-]	Backup
 /-<maxaddr>	highest data address			/;[+-]	Comments
 /%[+-][<data>]	empty data byte value [FF]		/?	Help

   [E-Enable, I-Intel, K-CRC16, W-Word, L-Long, V-View, S<n>-Split output]

This help screen gives a concise overview of all available parameters and options. These are all explained in the following sections.

Although you can use Binex by typing in commands, Binex is normally used by calling it from a script or make file. That is why the commands and options are as short as possible. Examples of script files or make files are beyond the scope of this document, since these are more often as cryptic as Binex's commands.

Binex is controlled via parameters that are entered after the program name on the command line:

    BINEX {parameter}

Parameters are separated on the command line by white space characters. If a parameter contains one or more white space characters, e.g. in a long file name, the complete parameter should be enclosed in double quotes.

A parameter can be any of the following:

A simple example of a Binex command line is:

    BINEX @cmdfile.txt /xv "My Documents\MyInputfile.hex" /OMyOutputfile.hex ";no backup" /!-

A command file specifier consists of an at-sign "@" preceding a valid text file name. The text file should contain Binex parameters, one parameter per line. The use of a command file circumvents the restrictions on the number and size of parameters by the total length of the command line. The command line and the command file may contain any number of command file specifiers, the nesting level is only limited by available memory. Delimiting of parameters containing white space characters in the command file is not allowed, nor necessary, since they are delimited by the line separators of the file.

A comment parameter starts with a semi-colon ";" and indicates a parameter that is ignored by the program. It is meant for usage in a command file, but can also be used on the command line, as illustrated in the example above.

An input file name may contain a directory path, wildcards, and a file name extension. The default input file name extension is ".HEX". Binex will expand all file names, solve wildcards, and sort input file names alphabetically. Read the section about file formats to learn what kind of input files can be specified.

An option always starts with a forward slash "/" or a minus-sign "-". After this specifier a letter or token follows that specifies the option. More letters or tokens may follow this first character, indicating suboptions. Options are divided into:

If no action is specified but an input file name is present, the file is processed as hex input file and all specified operations are performed, but no output file is generated, unless the /O-switch is specified. This way you can e.g. test the syntax of a hex file, or calculate a checksum without producing an output file.

All operations except the Move-operation can be specified more than once. They are executed in order of presence. The Move-operation is executed before all other operations.

Information about processed files, as well as error messages, is output via the standard output channel of the operating system. This means that you can redirect this output to a (disk) file, using the redirection specifier on the command line ">filename". Progress indication output (record number in progress) is output via the standard error channel of the operating system, so this always ends up on the console screen, since you can not redirect this channel under Windows.


Action /A - Analog Devices ADSP-2101 hex-bootfile processing

/A[<page>]
Encheck ADSP-2101 hex-file [or extract Boot Page].

Action /A lets Binex process the specified input file(s) as a hex-file with bootcode for the ADSP-2101 Digital Signal Processor of Analog Devices. Such a file can contain one or more pages of bootcode of 8 kbyte each. Binex can perform two operations on these files:

/A
checksum calculation and insertion for each of the bootpages;
/A<page>
convert bootpage <page> to a binary file; page=0..7.

These operations can not be combined in one action.

Since the ADSP-2101 normally has no access to its boot memory space during normal operation, normal checksum operations of Binex can not be used for this kind of datafiles. A special kind of checksum is calculated, that is inserted into an empty space in the exception vector table of the bootcode. More information about this checksum can be found in the documentation of the software of the XE-SSF2.

This action always produces an output file. The /A-operation produces a hex-file with the default extension 'CHK'. The /A<page>-operation produces a binary file with the extenson 'BP<page>'.


Action /B - Conversion of hex-file(s) to binary file(s)

/B[V]
Decode hex-file(s) into binary files.

The action /B converts one or more hex-input files into binary output files. Each input file is processed individually. Each consecutive memory area from an input file is output in a separate binary file with a name representing the hexadecimal value of the starting address of the memory area (e.g. "00002000.BIN").

If a single binary image of a hex file with multiple memory areas is desired, then you should first transform the hex-file to a temporary single memory area hex-file, by copying it with the switch /%+ EmptyByte expanding on.

After reading an input file the following operations can be performed:

Switch V (View) makes Binex show internal data on the processed data collection.


Action /H - Conversion of binary file(s) to hex-file(s)

/H[HVS<n>]
Encode binary file(s) into hex-file[s].

The action /H converts one or more binary input files into a hex-output file.

Switch H makes Binex process each input file individually. It should be the first switch to follow the action specifier ("/HH").

If the name of an input file represents a hexadecimal value (e.g. "00002000.BIN"), then this value is taken to be the base address of the corresponding data area in the hex output file. When such address indication is absent, BaseAddress is taken as base address of the data.

Data overlap when merging multiple input files into one hex-file is not allowed and results in an exception.

After reading of the input data the following operations can be performed:

Switch S<n> (Split data) makes that the hex output file is split into <n> (decimal number, 2 .. 4096) hex output files, each containing the n-th byte of the original output file. Only the splitted files are output.

Switch V (View) makes Binex show internal data on the processed data collection.


Action /X - Copying and/or merging of hex-files

/X[XVS<n>]
Copy hex-file(s) to hex-file[s].

The action /X copies/merges one or more hex input files to one hex output file.

Switch X makes Binex process each input file individually, so no merging takes place then. It should be the first switch to follow the action specifier ("/XX").

Data overlap when merging multiple input files into one hex-file is not allowed and results in an exception.

After reading of the input data the following operations can be performed:

Switch S<n> (Split data) makes that the hex output file is split into <n> (decimal number, 2 .. 4096) hex output files, each containing the n-th byte of the original output file. Only the splitted files are output.

Switch V (View) makes Binex show internal data on the processed data collection.


Action /? - Help

/?
Help.

Action /? shows the help screen of Binex; after that Binex terminates, all other parameters are ignored. The help screen is also shown if Binex is called without any parameters.


Operation /$ - Move data to a new base address

/$<newbase>
NewBaseAddress-value; hex-number 00000000..7FFFFFFF.

The operation /$<newbase> moves all data from the input files to a new base address. The original base address is BaseAddress, the value of the /@-switch. All addresses of the data are recalculated with the following formula:

Address := Address+(NewBaseAddress-BaseAddress)

After the operation BaseAddress gets the value of NewBaseAddress. Parameter values of other options with address-values, like the /-<maxaddr> switch are not recalculated. You must specify these values with their new (moved) values. Symbols however are recalculated, so symbolic parameter values are automatically adjusted.

The recalculation of adresses always takes place on all input data, right after reading the data and before any other operation is performed. There is no check on overflow of the recalculated addresses.


Operation /F - Fill a data range

/F[WLIV]@<addr>[-<maxaddr>][:<data>]
Fill data range.

The operation /F fills a data range starting at address <addr> and ending with address <maxaddr> with a value <data>. The value <data> can be a 8-bit byte (/F), a 16-bit word (/FW), or a 32-bit longword (/FL).

In case of word or longword filling the byte ordering is important. Normally this is most significant byte first (Big Endian, or Motorola-order), but with the switch I Intel order specified, the byte order is least significant byte first (Little Endian, or Intel-order).

The parameter values <addr>, <maxaddr>, and <data> are all hexadecimal values. The presence of <addr> is compulsory; the default value of <maxaddr> is calculated to insert just one byte, word, or longword, and the default value of <data> is EmpyByte. In case of word or longword filling, the <maxaddr> is silently increased if necessary to include a complete word or longword at the end of the specified range. There is no alignment of words of longwords to specific addresses forced by Binex.

Switch V (View) selects viewing of the filling results.


Operation /C - Checksum calculation and insertion

/C[WKEIV][@<addr>][&<sumaddr>]
Check data range.

The operation /C calculates a checksum over a data range starting at address <addr> and ending just before <sumaddr>. The calculated checksum is inserted at address <sumaddr>.

The default value of <addr> is BaseAddress and the default value of <sumaddr> is calculated in a way that the last byte of the checksum is at MaxAddress.

By calculating a checksum over a data range the integrity of the data can be checked later on by recalculating this checksum and comparing it with the stored checksum. There are many algorithms for checksum calculation and Binex only supports some of them. The checksum is always at the end of the memory area. The suboptions W, K, and E select the specific checksum-method:

/C
the sum of the 8-bit bytes; the checksum itself is a 16-bit word;
/CW
the sum of the 16-bit words; the checksum itself is a 32-bit longword;
/CK
the Cyclic Redundancy Check (CRC-16-IBM, x16+x15+x2+1) of the 8-bit bytes; the checksum itself is a 16-bit word;
/CKW
the Cyclic Redundancy Check (CRC-16-IBM) of the 8-bit bytes; the checksum itself is a 16-bit word, but is written as a 32-bit longword with the most significant word zero.

Sometimes it is necessary to be able to recognize the presence of a valid checksum, e.g. when you are debugging code that expects a valid checksum but it has not been inserted yet. The presence of the checksum could be signalled by filling a specific memory location with a specific value. This could be done with the Fill-operation. The checksum operation however has a special switch E (Enable checksum) that makes that the inserted checksum is preceded by a 16-bit Enable word (or 32-bit longword in the presence of suboption W). Binex fills the Enable-word or -longword with Empty Bytes, before calculating the checksum. By specifying in the source code a different value, the presence of the checksum can be recognized. Note: the Enable-(long)word starts at <sumaddr> and the checksum follows right behind it. The default value of <sumaddr> is calculated taking the Enable word into account.

Switch I (Intel order) sets the byte ordering of read and written word- and longword-data to least significant byte first.

Switch V (View) selects viewing of the checksum calculation results. You can compare the original value (Old data) with the calculated value (New data).


Operation /Z - Byte order swapping

/Z[V][@<addr>][-<maxaddr>]
Swap bytes in range.

The operation /Z swaps the data bytes of the 16-bit words in the range <addr> - <maxaddr>.

The parameter values <addr>, and <maxaddr> are hexadecimal values. The default value of <addr> is BaseAddress; and the default value of <maxaddr> is MaxAddress. Switch V (View) selects viewing of the swapping operation.

If the range does not start or end on a word-boundary (a even address), then the range is expanded with one or two bytes to make the boundaries of the range even. If one of the bytes of a word is missing in the input data, the EmptyByte value is inserted instead. Note that no word swapping takes place of 32-bit longwords.


Operation /: - Discard data

/:[:V][@<addr>][-<maxaddr>]
Discard data inside or outside the specified range.

The operation /Z swaps the data bytes of the 16-bit words in the range <addr> - <maxaddr>.

The operation /: removes all data inside the data range <addr> - <maxaddr>. The operation /:: removes alls data outside the data range <addr> - <maxaddr>.

The parameter values <addr>, and <maxaddr> are hexadecimal values. The default value of <addr> is BaseAddress; and the default value of <maxaddr> is MaxAddress. Switch V (View) selects viewing of the discarding operation.


Switch [/]V - View

/V
View.
V
View.

The /V View switch makes Binex show an overview of the internal data record collection after processing the operations. The overview includes start address, end address, the number of data bytes, the number of empty bytes, totals of those values and the entry point value.

The V View switch added to some operations specifier makes Binex to output some data about these operations. When added to the action specifier, both the record collection overview and operation data view are enabled.


Switch S<n> - Split data

S<n>
Split data; default value: no splitting.

The switch S<n> makes that the hex output file is split into <n> (decimal number, 2 .. 4096) splitted hex output files, each containing the n-th byte of the original output file. Only the splitted files are output.

With switch S2 e.g. two files are created with the file extensions ".000" en ".001", that contain the even addressed and odd addressed bytes respectively.

The Split switch can e.g. be used to create image files for 8-bit EPROM devices. Note: Binex has no way to merge splitted files into one image again.


Switch I - Intel order

I
Intel order; default value: Motorola order.

In case of reading or writing 16-bit words or 32-bit longwords the byte and word ordering is important. Normally Binex works with most significant byte/word first (Big Endian, or Motorola-order). With global switch I Intel order specified, Binex works with least significant byte/word first (Little Endian, or Intel-order).


Switch /L - Symbolic label processing

/L[ANS:-]
Label processing; default value: /L- (disabled).

A hex data file might contain a symbol table that Binex processes and uses for solving symbolic parameter values.

Switch /LA (Alpha) prints the symbol table alphabetically sorted on module.label-name in a file "<filename>.LBA".

Switch /LN (Numerical) prints the symbol table numerically sorted in a file "<filename>.LBN".

Switch /LS (Save) prints the symbol table in the original format in a file "<filename>.LBX".

Switch /L: (Discard) prevents output of the symbol table in the hex output file(s).

Switch /L- (Disable) disables reading and processing of a symbol table; symbolic parameter values cannot be solved.

Both /LA and /LN produce files with the label-name preceded with its module-name and with a preceding underscore ("_") removed.

If a symbol table is present and processing is enabled, you can make use of it when specifying parameter values. Every hexadecimal parameter value (address, data, empty byte value, etc.) can be replaced with a valid symbolic label name, preceded with a "$"-sign. The label name may be preceded with a module name, separated with a period ("."). An underscore ("_") at the beginning of the label name can be omitted. A label name may optionally be followed by a plus sign "+", followed by a hexadecimal offset value. The resulting value is calculated as the sum of the label value and the offset:

    $LabelName+3ac4

Binex will solve each symbolic parameter value at the moment it is needed for processing. If a symbolic value can not be solved, an exception takes place. Module and label names are processed case sensitive.


Switch /;[+-] - Comments

/;[+-]
Preserve comment lines in hex files ; default value: disabled.

Hex files may contain lines that are treated as comment by Binex that could be preserved during processing. These lines start with a semicolon. Use the /;+ switch to enable comment preservation, and use the /;- switch to disable comment preservation.


Switch /O[<file>] - Output

/O[<file>]
Output destination file, directory or device.

The switch /O makes Binex to write the output file(s) to the specified file name, directory path or device name.

If no file name is specified, it is taken from the input file, except for binary output files that have their base address as file name. If no file name extension is specified, it is determined by the action performed (e.g. ".HEX" of ".BIN"). Device names (like LPT1, NUL) are obviously not changed.

Existing files will be backed up, if this is enabled.


Switch /![+-] - Back Up

/![+-]
Back-up output files; enable/disable generation of back up output files; default value: enabled.

If the output file generated by Binex has a name of a file that already exists, that file will be overwritten, unless it is backed up. With backup enabled the existing file is renamed with extension ".!xx", with xx being a hexadecimal number ranging 00 .. FF. Therefore Binex creates 256 back-ups before a file is discarded (switch /!+). The creation of back up files is disabled using the /!- switch.


Switch /%[+-][<empty>] - EmptyByte-value

/%[+-][<empty>]
EmtpyByte-value/compression/expansion; hexadecimal number 00..FF, default value FF.

All bytes in the data range that has not been read from the input files are (virtually) filled in some operations with the EmptyByte-value, e.g. when calculating checksums. An empty, erased EPROM normally contains FF-values, so this is the default value of EmptyByte.

The switch /%+ (empty byte expansion) makes that all virtual Empty Bytes in the data range are actually written when writing a hex output file; it is said that expansion of the data takes place, since these EmptyBytes are no longer virtual.

The switch /%- (empty byte compression) makes that Empty Bytes (bytes with the EmptyByte-value) at the end of S-records are not written to the hex output file; now it is said that compression takes place, since Empty Bytes are virtualized.


Switch /@<base> - BaseAddress-value

/@<base>
BaseAddress-value; 32-bit hexadecimal number 00000000..7FFFFFFF, default value is lowest address in databuffer (auto ranging).

The switch /@<base> specifies for certain operations the lower boundary of the memory range to be processed.


Switch /-<maxaddr> - MaxAddress-value

/-<maxaddr>
MaxAddress-value; 32-bit hexadecimal number 00000000..7FFFFFFF, default value highest address in databuffer (auto ranging).

The switch /-<maxaddr> specifies for certain operations the higher boundary of the memory range to be processed.


EXAMPLE

Modern embedded controller boards often contain multiple processors of various kind, booted from a single EPROM or FLASH memory source by a central microcontroller. Apart from the software for de microcontroller, the hex image file of the EPROM should also contain the software for the other processors, all properly guarded with checksums to make sure that all components receive valid software at initialization. Each processor might have its own development environment producing the output software in some hex or binary format. Binex takes care of putting the pieces together.

In this example we look at a controller board with a Motorola MC68332 microcontroller, containing two processors itself (CPU and TPU), accompanied by a digital signal processor (DSP), and an Altera FLEX-EPLD, a programmable logic device that needs configuration at power-up. The CPU is in charge of configuring the TPU, DSP, and the EPLD at power-up with data from its own FLASH-memory. We will demonstrate in this example the combination and processing of the CPU and EPLD software.

The CPU software development system produces an output file MICRO1.HEX with the CPU code in Motorola S-format. We like to add a 32-bit word-wise checksum over this code from address 0 (start of CPU code) to a label called EPROMSum, defined in the source code of the CPU. It should also contain an Enable longword, to indicate the insertion of the checksum. Byte-ordering is big-endian.

The FLEX-EPLD-development system produces a file FLEX.HEX containing the configuration data in Intel-hex format, starting at address 0. These data should reside at address 00010000 (hex) of the CPU address space.

The data should be programmed into two 8-bit wide FLASH-memory components of 512 kbyte each, using a programmer with a one byte socket. One device should contain the even bytes and the other the odd bytes. The sector protection bits of both memory devices should be disabled (set to 0). This can be done via the programmer, by adding a 0-byte to the data of each component at the first address after the address space of the component (80000 hex).

All operations can be done in two Binex actions. First the data in file FLEX.HEX is moved to the correct address:

        BINEX /X /@0 /$10000 FLEX

Binex will move all data from base address 0 to the new base address 10000 hex. Output is written to the file FLEX.HEX, whilst the input file is backed up under the name FLEX.!00.

Next a second Binex action combines the MICRO1.HEX data and the FLEX.HEX data in one data set, calculates and inserts the checksum over the CPU data, fills the data for the sector protection bits with 0, and finally writes the output data to two splitted hex files:

        BINEX /XS2 /CWE&$EPROMSum /FW@100000:0 FLEX MICRO1 /OMICRO

The last action is processed by Binex as follows: first the two files FLEX.HEX and MICRO1.HEX are read in alphabetical order. Then on address 00100000 hex a word with value 0 is added to the data (option /F). Next, after filling of the Enable-longword on address $EPROMSum (symbolic label value is solved with the symbol table data in MICRO1.HEX) with FFFFFFFF hex (default value of Empty Byte), the sum of the words from address 0 up and including $EPROMSum+3 is calculated and written as longword at address $EPROMSum+4 (option /C). Finally two files are produced (switches S2 en /O): MICRO.000 with all even bytes and MICRO.001 with all odd bytes. With these files the FLASH memories can be programmed. Note that, due to the splitting, the sector protection bit-bytes are now on the correct address (100000 / 2).


FILE FORMATS

Binex processes files in several data formats. Output files are either in simple binary format, or in Motorola S-format. Input files can be in simple binary format, Motorola S-format, Intel hex-format, or Linear hex-format.

Binex autodetects hex input files as being in Linear hex-format, Motorola S-format, or Intel-hex format. Hex files may contain a symbol table and comment. All these formats are recognized on a per line basis, which means that you can have all formats intermixed in one file.

Binary files are not autodetected; processing of binary or hex files depends on the specified action.

Simple binary format

A file in the simple binary format contains just binary data. There are no delimiters, addresses, or checksums in the file. Binex normally assumes the filename to contain the hexadecimal starting address of the data, but this need not be the case.

Linear hex-format

A hex file in the linear hex-format is a text file containing hexadecimal encoded data whithout any address specification, checksum, or record organisation. Data bytes can be grouped in any number of bytes, separated with any number of non-hex character(s). Each line however should start with the hex-character of the first data byte, and should contain no more than 256 data bytes. A file could look like this:

        01 23 45 67 89 AB CD EF 01 23 45 67 89 AB CD EF 01 23 45 67 89 AB CD EF
        01,23,45,67,89,AB,CD;EF;01;23;45,67,89,AB,CD,EF,01,23,45,67,89,AB,CD,EF

or like this:

        012345
	6789AB
	CDEF01

Data of linear hex files are appended to the data collection of Binex. This means that you normally will have to move the data to a new base address before further processing is possible.

Motorola S-format

A file in the Motorola S-format is a text file containing hexadecimal encoded data, organised in so-called records: a text line in the following format:

        S<recordtype><recordlength><address><data><checksum>

In which is:

'S'
identifying character of the record (therefore called S-record);
<recordtype>
a character specifying the type of the record:
'0':
header record with 2 bytes address (value 0); contains usually not much interesting data, e.g. with the hex encoded text "HEADER". Binex starts its output files with an S0 record containing the hex encoded text "Binex V2.00".
'1', '2', '3':
data record with 2, 3, respectively 4-byte address that represents the absolute starting address of the first data byte of the record.
'5':
data record count record with a 2-byte address that represents the preceding number of data records; this record contains no data bytes; Binex checks the S5-records in input files and produces an exception if the number of data records is not ok, but Binex itself produces no S5-records in its output files.
'7', '8', '9':
termination record with a 4, 3, respectively 2-byte address that represents the Entry Point in the terminated data block, so e.g. the initial value of the program counter of a processor. Binex retains per action the last read entry point from its input files and writes it to its output file.
<recordlength>
 hex-encoded byte representing the number of address, data, and checksum bytes.
<address>
 hex-encoded 2, 3, or 4-byte address, depending on the record type;
<data>
 hex-encoded data bytes (usually not more than 64 per record, maximum 255);
<checksum>
 one's complement of the sum of all bytes in the record after the recordtype. Apart from the correct hex-encoding Binex checks this checksum in input files.

Files with only S0, S1 and S9 records are also called to be in Motorola Exorcisor format. If also S2 and S8 records appear, the format is also called Motorola Exormax.

Intel hex-format

A file in the Intel hex-format is a text file containing hexadecimal encoded data, organised in so-called records: a text line in the following format:

        :<datacount><address><recordtype><data><checksum>

In which is:

':'
identifying character of the record;
<datacount>
hex-encoded byte representing the number of data bytes in the record;
<address>
hex-encoded 2-byte address;
<recordtype>
hex-encoded byte representing the record type:
'00':
data record (like the Motorola record type "S1");
'01':
termination record (like the Motorola record type "S9");
'02':
segment base address record, the first word of data of this record used as Segment Base Address of the addresses of the next data records; actual addresses are calculated as:
start address := (SegmentBaseAddress*16) + record start address;
'04':
unknown record-type, the first word of data of this record is interpreted by Binex as Segment Address, the most significant word of the addresses of the next data records; actual addresses are calculated as:
start address := (SegmentAddress*65536) + record start address;
<data>
hex-encoded data bytes (maximum 255);
<checksum>
two's complement of the sum of all bytes in the record after the identifying character. Apart from the correct hex-encoding Binex checks this checksum in input files.

Files with only 00, and 01 records are called to be in Intel "Intellec" 8/MDS format. The Intel MCS86 (Intellec 86) format adds the 02 type records to that.

Symbol table

A hex file may contain a modular symbol table. The format of this table is:

        $$ <module>
          <label> <address> <label> <address> ...
          <label> <address> <label> <address> ...
        $$

A line starting with two '$'-signs contains the name of the module. This line precedes one or more lines starting with two spaces and containing pairs of label names followed by the corresponding address. Address values are hexadecimal encoded and are preceded by a '$'-sign. Lines are normally no longer than 80 characters. Each table may contain several modules. Every label is always inside a module block. The table ends with an empty module name specifier (just two '$'-signs).

Comment

Apart from the hex records and a symbol table, a hex file may contain any kind of text lines. These are just skipped by Binex when read in, exept for lines that start with a semicolon ";". These are taken to be comment to the accompanying data and they are preserved while copying hex files. All comment lines are output at the beginning of the hex file. (Not in this version of Binex yet.)


ERROR MESSAGES AND EXCEPTIONS

The error messages that notify the various exceptions that might occur during the execution of Binex are supposed to speak for themselves.

The first line of a message states the class of the exception, the name of the module (Binex), and the program address it occurred. This information is a bit detailed and not very useful to the ordinary user, but you get it anyway.

The second line of the message actually describes the nature of the exception and many times includes some data that clarifies the error, e.g. the name of a file that could not be opened.

Oddly enough, the error message is not output via the standard error channel, but via the standard output channel. That means, the message is written to a file instead of the console, if you redirect standard output to a file.

Whenever Binex does not normally terminate, it's exit code is non-zero. This normally signals an enclosing makefile to abort further processing. In a DOS batch file this can be used via an errorlevel test:

	binex %1 %2 %3 %4 %5
	if errorlevel 1 goto errorhandling

To alert the user to the anomaly, a message beep might sound if your system has any audio equipment enabled.


GLOSSARY

ASCII American Standard Code for Information Interchange
DOS Disk Operating System (originally QDOS: Quick and Dirty Operating System)
[E]EPROM [Electrical] Erasable Programmable Read Only Memory
EPLD Erasable Programmable Logic Device
PC Personal Computer
Windows Windows Operating System, some more sophisticated looking DOS
   
   

COLOPHON

program: Binex V2.00
operating system: Microsoft Windows 95, Windows 98, or Windows NT
application: console application
memory requirements: 200 kbyte for installation
author: Ernst van der Pols, Zuidland, Nederland
development platform: Borland Delphi 2.0

Binex Manual / 2009.01.30 / Copyright NewLife Software, E.K.H. van der Pols, Zuidland, Holland