Electronic Arts is a company that deserves credit for helping make life easier for the Amiga programmer and end user. The company has promoted the Amiga since the computer's introduction more so than CBM (although very few organizations have promoted the Amiga less than its manufacturer). By esta- blishing IFF standards on behalf of CBM and releasing source code for reading and writing IFF files, Electronic Arts has helped make the Amiga the success that it is in the video/graphics market. Unfortunately, the people who wrote the documents describing the IFF file formats have an appalling lack of respect for the English language. No effort was made to be concise and clear. Sentences seem to have been constructed by heaving several, long phrases together, and subsequently inserting a verb or two. Then, if the text didn't sound "technical" or "serious" enough, adjectives were invented, and brazenly thrust into any sentence of less than 40 words. This mish-mash of technical newspeak is typical of computer programmers who never learned to write in any language other than Pascal. In fact, if the trend toward inventing technical jargon continues, we may see the day when technical literature will have the words BEGIN and END surrounding each "standard written language module" (i.e. paragraph). Many misguided programmers (and others engaged in scientific disciplines) are also taught that any use of the first person (i.e. I or we) is too conversational, and therefore unprofessional. Apparently, the function of technical literature is not to converse, but to bore. Because the original IFF documents exhibit all of these flaws, I will attempt to paraphrase those documents. I do not guarantee that I will have correctly ascertained the intentions of the lifeform that wrote those documents, so you should consult the original text. BEGIN IFF stands for "InterChange Format Files". This is some of that technical jargon that I was alluding to earlier. Basically, an IFF file is a set of data that is in a form that many, unrelated programs can read. An IFF file should not have anything in it that was intended specifically for just one, particular program. If a program must save some "personal" data in an IFF file, it must be saved in a manner which allows another program to "skip over" this data. There are several different types of IFF files. ILBM files store picture data. SMUS files store musical scores. 8SVX store sampled sounds. Each of these files must start with an ID which indicates that it is indeed an IFF file, followed by an ID that indicates which type of file. So what is an ID? An ID is four, printable ascii characters. If you use the CLI Type command (opt h) to print out an IFF file to the CLI window, you will notice that every so often you will see 4 letters in a row. These 4 letters are an ID. Every IFF file must start with one of the following 3 IDs. 'FORM' 'LIST' 'CAT ' If the first 4 chars (bytes) in a file are not one of these, then it is not an IFF file. These IDs are referred to as group IDs in EA literature. END After this group ID, there is a ULONG that indicates how many bytes are in the entire file. This count does not include the 4 byte group ID, nor this LONG. This LONG is useful if you wish to load the rest of the file into mem- ory to examine it. After this LONG, there is an ID that indicates which type of IFF file this is. As mentioned earlier, "ILBM", "SMUS", and "8SVX" are 3 types of IFF files. There are many more, and programmers are always inventing new types for lack of better things to do. What you find after the type ID depends on which type it is (i.e. From here on, an ILBM will be different than an 8SVX). Here is the beginning of a typical ILBM file. 'FORM' <- OK. This really is an IFF file. 13000 <- There are 13000 more bytes after this ULONG 'ILBM' <- It is an ILBM (picture) file One thing that all IFF files do have in common after the group ID, byte count, and type ID, is that data is organized into chunks. OK, more jargon. What's a chunk? A chunk consists of an ID, a ULONG that tells how many bytes of data are in the chunk, and then all those data bytes. For example, here is a CMAP chunk (which would be found in an ILBM file). 'CMAP' <- This is the 4 byte chunk ID 6 <- This tells how many data bytes are in the chunk (chunkSize) 0,0,0,1,1,4 <- Here are the 6 data bytes Notice that the chunk size doesn't include the 4 byte ID or the ULONG for the chunk Size. So, all IFF files are made up of several chunks. There are a few other details to note. A chunk cannot have an odd number of data bytes (such as 3). If necessary, an extra zero byte must be written to make an even number of data bytes. The chunk Size doesn't include this extra byte. So for example, if you want to write 3 bytes in a CMAP chunk, it would look like this: 'CMAP' 3 <- Note that chunk Size is 3 0,1,33,0 <- Note that there is an extra zero byte In the preceding example, the group ID was 'FORM'. There are other group IDs as well. A 'CAT ' is a collection of many different FORMs all stuck together consecutively in 1 IFF file. For example, if you had an animation with 6 sound effects, you would want to save the animation frames in an ANIM FORM, and you would want to save the sound effects in several 8SVX FORMs (one per sound effect). Note: a better way to store sound samples would be the SAMP format. See Fish Disc #203. You could save the animation and sound in 7 separate files. The ANIM file would start this way: FORM 120000 <- Whatever the size happens to be (this is expressed in 32 bits) ANIM Each 8SVX file would start this way: FORM 8000 <- whatever size 8SVX If the user wanted to copy the data to another disc, he would have to copy 7 files. On the other hand, you could save all the data in one CAT file. CAT 4+120008+8008+2028+... <- The total size of the ANIM and the 6 8SVX files ' ' <- Type of CAT. 4 spaces for the type ID means "a grab bag" of IFF FORMs are going to be inside of this CAT FORM 120000 ANIM ...all the chunks in the ANIM file placed here (note: ANIMs have imbedded ILBM FORMs) FORM 8000 8SVX ...all the chunks in the first sound effect here FORM 2020 8SVX ...all the chunks in the second sound effect here ...etc. for the other 4 sound effects To further complicate matters, there are LISTs. LISTs are a lot like CATs except that there is an additional group ID associated with LISTs. That ID is a PROP. LISTs can have imbedded PROPS just like an ILBM can have an im- bedded CMAP chunk. A PROP header looks very much like a FORM header in that you must follow it with a type ID. For example, here is an ILBM PROP with a CMAP in it. PROP <- Here's a PROP 4+14 <- Here's how many bytes follow in the PROP ILBM <- It's an ILBM PROP CMAP <- Here's a CMAP chunk inside this ILBM PROP 6 <- There are 6 bytes following in this CMAP chunk 0,0,0,1,1,4 LISTs are meant to encompass similiar FORMs (i.e. several 8SVX files stuck together). Often, when you have similiar FORMs stuck together, some of the chunks in the individual FORMs are the same. For example, assume that we have 2 8SVX sound effects. 8SVX FORMs can have a NAME chunk which contains the ascii string that is the name of the sound effect. Also assume that both sounds are called "car crash". Wouldn't it be nice if we didn't have to have the same NAME chunk in each 8SVX FORM like so: CAT <- We put the 2 files into 1 CAT 4+1004+504 8SVX <- It's an CAT of several 8SVX FORMs FORM <- here's the start of the first sound effect file 1000 8SVX ...some chunks NAME <- here's the name chunk for the 1st sound effect 9 'car crash',0 ...more chunks FORM <- here's the start of the second sound effect file 500 8SVX ...some chunks NAME <- here's the name chunk for the 2nd sound effect. Look 9 familiar? 'car crash',0 ...more chunks With a LIST, we can have PROPs. A PROP is group ID that allows us to place chunks that pertain to all the FORMs in the LIST. So, we can rip out the NAME chunks inside both 8SVX FORMs and replace it with one NAME chunk inside of a PROP. LIST <- Notice that we use a LIST instead of a CAT 4+30+990+490+... 8SVX PROP <- Here's where we put chunks intended for ALL the 22 subsequent FORMS; inside a PROP. 8SVX <- type of PROP NAME <- here's the name chunk inside of the PROP 9 'car crash',0 FORM <- here's the start of the first sound effect file 982 <- size is 18 bytes less because no NAME chunk here 8SVX ...some chunks, but no NAME chunk FORM <- here's the start of the second sound effect file 482 8SVX ...some chunks, but no NAME for this guy either Notice that the PROP group ID is followed by a type ID (in this case 8SVX). This means that the PROP only affects any 8SVX FORMs. If you were to sneak in an SMUS FORM at the end, the NAME chunk would not apply to it. Also, if you included a NAME chunk in one of the 8SVX FORMs, it would override the PROP. For example, assume that you have a LIST containing 10 8SVX FORMs. All but 1 of them is named "CBM needs an advertising budget". You can store a NAME chunk in a PROP 8SVX for "CBM needs an advertising budget". Then, in the one 8SVX FORM whose name is not "CBM needs an advertising budget", you can include a NAME chunk to override the PROP. It should be noted that you can take several LISTs and squash them toge- ther inside of a CAT or another LIST.² Personally, I have never seen a data file with this level of nesting, and doubt that it would be of much use. If you need this level of complexity, forget IFF and make your own proprietary data format, then give info to anyone who wants to access your data. No doubt, somewhere, there is a moron devising a plot to inflict a CAT of LISTs upon an unsuspecting public now that VirusX has defeated his more devious aspirations.