Timeline – Richard Cabot

Options

Copy Download Link

Options

Copy Download Link

Options

Copy Download Link

Options

Copy Download Link

Options

Copy Download Link

Options

Copy Download Link

<table border="0" cellpadding="0" cellspacing="0">
 <tr>
 <td width="600"> 
 <h3 align="center">"EA IFF 85" Standard
 for Interchange Format Files </h3>
 <table>
 <tr>
 <th align="left">Document Date: 
 From: 
 Status of Standard: 
   </th>
 <td>  January 14, 1985 
   Jerry Morrison, Electronic Arts 
   Released and in use 
   </td>
 </tr>
 </table>
 <h3>1. Introduction</h3>
 Standards are Good for Software Developers
 As home computer hardware evolves to better and better media machines, the demand
 increases for higher quality, more detailed data. Data development gets more expensive,
 requires more expertise and better tools, and has to be shared across projects. Think
 about several ports of a product on one CD-ROM with 500M Bytes of common data! 
 Development tools need standard interchange file formats. Imagine scanning in images of
 "player" shapes, moving them to a paint program for editing, then incorporating
 them into a game. Or writing a theme song with a Macintosh score editor and incorporating
 it into an Amiga game. The data must at times be transformed, clipped, filled out, and
 moved across machine kinds. Media projects will depend on data transfer from graphic,
 music, sound effect, animation, and script tools. 
 Standards are Good for Software Users
 Customers should be able to move their own data between independently developed
 software products. And they should be able to buy data libraries usable across many such
 products. The types of data objects to exchange are open-ended and include plain and
 formatted text, raster and structured graphics, fonts, music, sound effects, musical
 instrument descriptions, and animation. 
 The problem with expedient file formats typically memory dumps is that they're too
 provincial. By designing data for one particular use (e.g. a screen snapshot), they
 preclude future expansion (would you like a full page picture? a multi-page document?). In
 neglecting the possibility that other programs might read their data, they fail to save
 contextual information (how many bit planes? what resolution?). Ignoring that other
 programs might create such files, they're intolerant of extra data (texture palette for a
 picture editor), missing data (no color map), or minor variations (smaller image). In
 practice, a filed representation should rarely mirror an in-memory representation. The
 former should be designed for longevity; the latter to optimize the manipulations of a
 particular program. The same filed data will be read into different memory formats by
 different programs. 
 The IFF philosophy: "A little behind-the-scenes conversion when programs
 read and write files is far better than NxM explicit conversion utilities for highly
 specialized formats." 
 So we need some standardization for data interchange among development tools and
 products. The more developers that adopt a standard, the better for all of us and our
 customers. 
 Here is "EA IFF 1985"
 Here is our offering: Electronic Arts' IFF standard for Interchange File Format. The
 full name is "EA IFF 1985". Alternatives and justifications are included for
 certain choices. Public domain subroutine packages and utility programs are available to
 make it easy to write and use IFF-compatible programs. 
 Part 1 introduces the standard. Part 2 presents its requirements and background. Parts
 3, 4, and 5 define the primitive data types, <tt>FORM</tt>s, and <tt>LIST</tt>s,
 respectively, and how to define new high level types. Part 6 specifies the top level file
 structure. Appendix A is included for quick reference and Appendix B names the committee
 responsible for this standard. 
 References
 <cite>American National Standard Additional Control Codes for Use with ASCII, ANSI
 standard 3.64-1979 for an 8-bit character set.</cite> See also ISO standard 2022 and
 ISO/DIS standard 6429.2. 
 Amiga™ is a trademark of Commodore-Amiga, Inc. 
 <cite>C, A Reference Manual,</cite> Samuel P. Harbison and Guy L. Steele Jr., Tartan
 Laboratories. Prentice-Hall, Englewood Cliffs, NJ, 1984. 
 <cite>Compiler Construction, An Advanced Course,</cite> edited by F. L. Bauer and J.
 Eickel (Springer-Verlag, 1976). This book is one of many sources for information on
 recursive descent parsing. 
 <cite>DIF Technical Specification</cite> � 1981 by Software Arts, Inc. DIF™ is
 the format for spreadsheet data interchange developed by Software Arts, Inc. 
 DIF™ is a trademark of Software Arts, Inc. 
 Electronic Arts™ is a trademark of Electronic Arts. 
 <cite>"<tt>FTXT</tt>" IFF Formatted Text,</cite> from Electronic Arts. IFF
 supplement document for a text format. 
 <cite>Inside Macintosh</cite> � 1982, 1983, 1984, 1985 Apple Computer, Inc., a
 programmer's reference manual. 
 Apple� is a trademark of Apple Computer, Inc. 
 Macintosh™ is a trademark licensed to Apple Computer, Inc. 
 <a href="ilbm.html"><cite>"ILBM" IFF Interleaved Bitmap</cite></a>, from
 Electronic Arts. IFF supplement document for a raster image format. 
 <cite>M68000 16/32-Bit Microprocessor Programmer's Reference Manual</cite> � 1984,
 1982, 1980, 1979 by Motorola, Inc. 
 <cite>PostScript Language Manual</cite> � 1984 Adobe Systems Incorporated. 
 PostScript™ is a trademark of Adobe Systems, Inc. 
 Times and Helvetica� are trademarks of Allied Corporation. 
 <cite>InterScript: A Proposal for a Standard for the Interchange of Editable Documents</cite>
 � 1984 Xerox Corporation. 
 <cite>Introduction to InterScript</cite> � 1985 Xerox Corporation. 
 <hr class="PAGE-BREAK">
 <h3>2. Background for Designers</h3>
 Part 2 is about the background, requirements, and goals for the standard. It's geared
 for people who want to design new types of IFF objects. People just interested in using
 the standard may wish to skip this part. 
 What Do We Need?
 A standard should be long on prescription and short on overhead. It should give lots of
 rules for designing programs and data files for synergy. But neither the programs nor the
 files should cost too much more than the expedient variety. While we're looking to a
 future with CD-ROMs and perpendicular recording, the standard must work well on floppy
 disks. 
 For program portability, simplicity, and efficiency, formats should be designed with
 more than one implementation style in mind. (In practice, pure stream I/O is adequate
 although random access makes it easier to write files.) It ought to be possible to read
 one of many objects in a file without scanning all the preceding data. Some programs need
 to read and play out their data in real time, so we need good compromises between
 generality and efficiency. 
 As much as we need standards, they can't hold up product schedules. So we also need a
 kind of decentralized extensibility where any software developer can define and refine new
 object types without some "standards authority" in the loop. Developers must be
 able to extend existing formats in a forward- and backward-compatible way. A central
 repository for design information and example programs can help us take full advantage of
 the standard. 
 For convenience, data formats should heed the restrictions of various processors and
 environments. E.g. word-alignment greatly helps 68000 access at insignificant cost to 8088
 programs. 
 Other goals include the ability to share common elements over a list of objects and the
 ability to construct composite objects containing other data objects with structural
 information like directories. 
 And finally, "Simple things should be simple and complex things should be
 possible." --Alan Kay. 
 Think Ahead
 Let's think ahead and build programs that read and write files for each other and for
 programs yet to be designed. Build data formats to last for future computers so long as
 the overhead is acceptable. This extends the usefulness and life of today's programs and
 data. 
 To maximize interconnectivity, the standard file structure and the specific object
...