@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: jimomurasampson@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 */