A practical introduction to the IFF standard

This section provides a brief overview of the IFF standard. For more detail refer to the "Interchange File Format Specification" published by the Commodore Applications and Technical Support group.

Perhaps the greatest stength of IFF is that it was well-defined and adopted very early in the Amiga's history.

An IFF data structure has two levels. The first level is a wrapper or envelope structure which is, technically, the syntax. It's easy to describe: the IFF wrapper is just a header containing an identifier and the file size. The identifier is four letters and the file size is a number taking up 32 bits of space. The whole IFF wrapper weighs in at eight bytes of disk space. That's it.

There are only three possible identifiers for the wrapper part of IFF files: FORM, CAT (a space after the T) and LIST.

It is possible to build some fairly complex files using just these three types since a FORM may contain FORMs within it; a LIST can contain other FORMs, CATs or LISTs and so forth. (To help with the possible complexity of IFF syntax, Release 2 of the operating system now contains a function library named iffparse.library.) In practice, however, the most common IFF file is the simple FORM containing a single set of data. There may be any type of data within the FORM wrapper.

The second layer of an IFF file, underneath the wrapper, defines the particular file types. The file types consist of a four-letter identifier followed by a series of data chunks which contain the data natural to the type. Some examples are:

Type IDData Stored in this Type
ILBMGraphics data in interleaved bitmap format. This is very widely used on the Amiga.
8SVXAudio data in 8-bit sample bytes. The most widely used audio file format on the Amiga.
FTXTFormatted text. Recommended for sharing text data.
ANIMA common way to store interchangeable animation files.

Each IFF file type contains a number of data chunks specific to the type. These data chunks are the basic building blocks of IFF files and they come in a wide variety. They can be structured in any number of ways, but a chunk always starts with a four-letter ID followed by the chunk size which, as in the wrapper, is given as a 32-bit number.

For example the 8SVX file type consists of two chunks: a VHDR chunk which contains information like the sampling speed, and the BODY chunk which contains the sample bytes.

Here is a listing of typical 8SVX file to give you a better idea of how IFF files are structured:

FORM                               IFF wrapper ID
10120                              IFF file size as
                                   a 32-bit value

8SVX                               type ID          -+
VHDR                               chunk ID          |
20                                 chunk size        |
00 02 3D 90 00 00 00 00 00 00    \\ 20 bytes of VHDR  |
00 00 21 4A 01 00 00 01 00 00    / chunk data        +- 10120 bytes
BODY                               chunk ID          |
10080                              chunk size        |
12 00 10 55 00 90 13 FF 12 00    \\ 10080 bytes of    |
10 55 00 90 13 FF...             / BODY chunk data  -+

The IFF Philosophy

The goals of IFF are lofty but obviously within reach. IFF is intended to make data abstract enough to be stored independent of a particular program, compiler, device or machine architecture. With that achieved, IFF files could be shared not only between applications but also on and between platforms other than the Amiga.

The key to this is making the data abstract. The IFF standard accomplishes this by building the files through chunks each with an ID and size. The ID is a reference by name to a given implementation of an access procedure. The access procedures can evolve and change independently of the software which uses them.And the size count enables applications to support object operations like "copy" and "skip to next" regardless of the object type or contents.

IFF is meant to be easily extensible. The CAT and LIST wrappers make it easy to combine existing types to form new composite types. And if all else fails the IFF specification provides rules for creating new file types for special storage needs that are not handled by the existing IFF types.

IFF and Your Application

If an IFF format exists for your program's genre, you only need to provide two features:

You should support IFF two ways: provide a way for users to save files in IFF format; and provide a way for users to import IFF files.

In some cases the IFF format is also the best format for everyday file storage. Many applications have opted to use ILBM for those purposes. In other cases, the IFF format is not great as a normal storage format. In these cases, you can provide your own internal storage format, but you should also provide the means to save and import IFF.

Note, however, that revisions to your application could mean changes in your internal data format. If you have been using your internal data format as your storage format as well, any files saved in the old format may not be readable by the new format. If you don't use IFF as the default storage format, at least try to provide for backwards compatibility in your own program.

If No IFF Format Exists

If no IFF format exists for your program's genre, it would be a good idea to develop an IFF format and use that.

If you need to create a new IFF format or expand upon an existing one, then you must register the change with Commodore. Commodore's Applications and Technical Support group serves as a central clearinghouse to keep track of new developments in the IFF standard. A registry of IFF form and chunk types is available from Commodore on the IFF disk. This specification is required reading for all developers who want to conform to the Amiga's user interface standards.