@lsuc.uucp (11/27/87)
/* GF9 revision 87/11/16 * Public Domain Changes since last distribution: Compression key value 10000000 (binary) redefined. (This is a correction.) 0 duration files are defined. 0 length files are defined. Color Cycling data is allocated. TITLE: Proposal for Graphics File Format Standard For OS-9 / Color Computer Users I've been waiting for a while now for some sort of standard to arise, but nothing has happened. As such, this is what I'm going to use for now. If something better comes along, I state right now that I intend to abandon this format. But I'll only do so if there is an alternative which looks to be better than this. I don't like the idea of wasting my efforts, but I believe more strongly in establishing standards which are useful in the industry generally. So if I drop this without "a fight" that's why. Proposed Name : I've arbitrarily called it 'GF9' for Graphics Format 9. Files need not use this as an extension, but it wouldn't hurt if you did. The Header Format: The key is 64 bytes which are, for the most, to be thought of as 32 "words". Where a word is 16 bits. These 32 words make up the header. There is no "tail" information defined at this time. Offset in Bytes: 0x00 The first byte defines screen mode class. 0 Old Color Computer 1 CoCo3 Alphanumerics 2 CoCo3 Graphics modes 0x01 The 2nd byte is a submode. For mode 0 they are: 0 Alphanumerics 1 Inverted Alphanumerics 2 SemiGraphics - 4 3 64 * 64 Color Graphics 4 128 * 64 Graphics 5 128 * 64 Color Graphics 6 128 * 96 Graphics 7 128 * 96 Color Graphics 8 128 * 192 Graphics 9 128 * 192 Color Graphics 0x0a 128 * 256 Graphics For mode 1 they are: 0 32 char. 1 40 char. 2 80 char. For mode 2 they are: 0 160 * 16 1 256 * 2 3 256 * 4 4 256 * 16 5 320 * 4 6 320 * 16 7 512 * 2 8 512 * 4 9 640 * 2 0x0a 640 * 4 0x02 Compression style: Up to 255 forms of compression may be defined. 0 is uncompressed. 1 is run length encoding. Run length encoding will work as follows: The picture file will consist of a series of variable length "packets" in the form [key value] [data bytes]. The Key Value is a single byte. If the high bit is set, then the following byte is repeated the number of times specified by the unsigned value of the rest of the byte. I.e. if the byte is 10010000 binary, then the first bit specifies that the "packet" is compressed and the next byte is to be repeated 0010000 (16) times. The key value 10000000 is a special case where the next byte repeated 128 times. If the Key Value high bit is unset, then the rest of the byte specifies the number of bytes are to be considered "literal". I.e., if the byte is 01000000, then the next 64 bytes are not compressed, and the next byte after the last "literal" byte is the next Key Value byte. 2 is delta compression. Delta compression really isn't compression on its own at all. Each byte in a frame is subtracted from the corresponding byte in the previous frame and the difference is stored. A delta frame is useful because the delta file can be compressed by other means with a separate compression utility. If you want to show animation, the uncompressed file requires less alteration than a compressed deltafile for display. Furthermore, with a multi-tasking OS, it is conceivable that one might have uncompression of files occuring as a background task separate from the display function, so there may be some value in this separation of functions. 3 is delta and run length encoding combined. In storing the file, the original frame is "delta"d from the previous frame, and then the result is run length encoded using the method described in compression #1. 0x03 - 0x05 File length. This is the number of bytes of actual picture data, not including the header. If the file is 5000 bytes of picture data and 64 bytes of header, the total file will be 5064 bytes. A frame file which is delta'd and having no data changes from the previous frame may be stored as a header with 0 data. This may occasionally prove useful. With the variability of display duration, it is not likely to be *very* useful. However, it might be valuable during development and also for special usage of the color pallette. For the sake of portability with other computers the file length is specified in 24 bits (3 bytes) to be used as an unsigned integer value. I don't feel that this will make a truly *universal* format because such universality is very inefficent, but there might be some value in using this file format with some relatively similar machines. 0x06 - 0x07 Display Duration in 1/64 sec. increments. The 16 bit value is treated as an unsigned integer. Although it is formally a 1/64 sec., it should be presumed that due to the multi-tasking nature of the OS, some delay may occur between frames. As such, specific frame synch might require "something more". Display based on 1/60 sec. tickrates would not be considered "wrong". Maximum duration is 1024 seconds, or a bit over 17 minutes. Duration 0 is a special case. A 0 duration file is not intended to be displayed at all. Such files are used for holding sprite definitions, or even programming code to define sprite movement or other special features. 0x08 - 0x0b Color Cycling 0x08 = first register (0 - 15) 0x09 = last register (0 - 15) 0x0a = recursions (0 = infinite) 0x0b = speed in 1/8 sec. 0x0c - 0x1f Undefined 0x30 Color Pallette 0 (address FFB0) 0x32 Color Pallette 1 (address FFB1) 0x34 Color Pallette 2 (address FFB2) 0x36 Color Pallette 3 (address FFB3) 0x38 Color Pallette 4 (address FFB4) 0x3a Color Pallette 5 (etc.) 0x3c 0x3e 0x40 0x42 0x44 0x46 0x48 0x4a 0x4c 0x4e Color Pallette 15 (address FFBF) The bytes of the file follow as a straight memory dump if there is no defined compression. There are no special delimiter characters in the uncompressed formats. File length should *always* be provided, even in uncompressed files. The reason for the "undefined" words is for such things as color cycling, object motion (sprites?) and such. It'll be useful for the future. */ -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura
sampson@killer.UUCP (12/01/87)
> TITLE: Proposal for Graphics File Format Standard > For OS-9 / Color Computer Users > > I've been waiting for a while now for some sort of standard > to arise, but nothing has happened. As such, this is what I'm Change to: , but nothing has happened except the Compuserve GIF protocol, which has no animation facilities. > The Header Format: > > The key is 64 bytes which are, for the most, to be thought > of as 32 "words". Where a word is 16 bits. These 32 words make > up the header. There is no "tail" information defined at this > time. Problems: 1. Byte swapping allowed? (e.g. Intel, ATT) or is Motorolla the format. 2. 32 "words"? How about the three byte length and 1 byte modes, etc. Would a C structure look like this: typedef unsigned short word; typedef char byte; struct header { byte Mode; byte SubMode; byte CompType; byte Length[3]; /* Length[0] = Msb, Length[2] = Lsb */ word Duration; byte ColorCycle[4]; byte Extra[20]; word Palette[16]; /* Actually pointers but hardcoded */ }; /* to 16 bit addresses */ Wouldn't it be easier to code if Length[3] is just made a 'long': long Length; byte Extra[19]; /* EOF */