About File Types

Raw 1802 Binary Format - .cos

The simplest file format supported by TinyELF is a raw binary format. These files have a .cos or .COS file extension.

Bytes in these files have a 1-to-1 correspondence with bytes in TinyELF's memory. For example, suppose you had a small 4 byte program at address 0000 that continuously flashed the Q LED:

The 7B is the opcode for the SEQ (set Q) instruction; 7A is the REQ (reset Q) instruction; 30 is a BR (short branch) instruction; and 00 is the address that we branch back to, making the program run in an infinite loop.

If this program were saved to disk in the raw binary format, the file would be 4 bytes long, and would contain the 4 bytes of the program.

The advantages of the raw binary format are simplicity and small file size. The main drawback to this format is that it contains no other information, such as the address the program should be loaded at. When opening these files through either Open on the File menu, double-clicking a file, or dragging a file onto TinyELF's icon, TinyELF loads them at address 0000. When importing a raw binary file, though, you can specify the address the program should be loaded at. The Import option is also on TinyELF's File menu.

Intel Hex File Format - .hex

Intel hex files have been around for a long time and are often used with devices such as EPROM programmers. These consist of ASCII characters and may therefore be viewed in any text editor. Intel hex files have a .hex or .HEX extension.

Each line in a hex file is a record consisting of:

1. a header character, always a colon (":");
2. a two character count of data bytes in hexadecimal;
3. a four character address in hexadecimal;
4. a two character record type code in hexadecimal;
5. the actual data bytes in hexadecimal, two characters per byte;
6. a checksum, the two's complement of all the record's bytes added together: the data byte count, the address, the record type code, and the data bytes themselves.

If the four byte program described in the raw binary section above were saved in an Intel hex file and viewed in a text editor, this is what you'd see:

:040000007b7a3000d7
:00000001FF

The first line is the data record. Following the colon, the 04 tells us that the record contains 4 data bytes. The next four characters are the address of the first byte in the record. In this case, the address is 0000. The 00 following the address is the record type. A record type of 0 is a normal data record. This is followed by the four bytes of our program, 7b7a3000, and the checksum, d7.

The second line contains no bytes of data; the first byte after the colon is 00. Ignoring the address, you'll note that the record type is 01. Record type 1 is an end record placed at the end of the file. Because the data byte count and address are always 0 for this record type, the checksum is always FF, so the end record always looks exactly as shown above.

Some other record types are defined for Intel hex files, mostly to support addressing beyond 64k. These record types are not currently supported by TinyELF. More information on Intel hex format, including other record types, may be found on the internet.

The primary advantages of Intel hex files is that they are widely supported by other products, and they embed addressing information along with the data. When opening or importing Intel hex files, this address information is always used, making this format a good choice for loading code that should be placed somewhere other than address 0000. The drawbacks of the format are that it is somewhat more complicated than a raw binary, and produces files more than twice the size. Of course, with a maximum program size of "only" 64K, file size probably isn't a big problem for a Macintosh hard drive!