jimomura@lsuc.uucp (Jim Omura) (12/14/87)
As I said earlier this week, this draft is likely the last in
which the addresses defined to this point will actually change.
Further refinement in the definitions may occur, and other addresses
defined, but unless there's good reason, this much should be
considered stable. If anyone sees a reason to change anything
contained herein, then please notify me within the week. We
should assume everthing defined as frozen, at the very latest,
as of January 1, 1988.
/* GF9 revision 87/12/05
* Public Domain
Changes since last distribution:
The File Length variable has been moved to a
32 bit boundary and all subsequent addresses
shifted down by 2 bytes down to, but not including
0x40 which is the start of the Color Pallette
registers.
Variations in durations are defined as
acceptable up to 10%.
Color register data is defined and described.
Some Screen data formats are described.
************************************************
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 normal header is 128 bytes which are, for the most, to be
thought of as 64 "words" (16 bit), some of which are combined into
32 bit "long words". Byte order is Motorola. The most significant
byte if first, followed by the next most significant byte, and so
on. These 64 words make up the header. There is no "tail" or
trailing information defined at this time.
Offset in Bytes:
0x00 - 1 Header Length. Currently only 128 byte headers
are used, so 0x00 == 0 and 0x01 == 0x80
0x02 - 3 Undefined.
0x04 - 7 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.
0 Length Files
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 as a "long" to be used
as an unsigned integer value. I don't feel that this
format will be 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. Where it looks like an undue amount
of time might be wasted in catering to other machines,
I'll opt to support the CoCo3 and other users will
be best advised to consider using the basic concepts
of this format design, but not to worry about compati-
bility. In particular, using the 16 bit and 32 bit
data sizes exclusively should make it possible for the
programmer to do a mass conversion of byte order, with
some later word-order rearranging where necessary
on Intel byte order machines. This wastes data on
the CoCo3, but isn't unreasonable. However, the
Motorola byte order is maintained to save the CoCo3
users the time needed for the conversion.
0x08 - 9 Screen mode class.
0 Old Color Computer
1 CoCo3 Alphanumerics
2 CoCo3 Graphics modes
0x0a - b 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
0x0c - d 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.
0x0e - f 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". In
general, the acceptable deviation is up to 10%. Maximum
duration is 1024 seconds, or a bit over 17 minutes.
0 Duration Files
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.
NOTE: For more info on 0 Duration files, see below.
0x10 - 0x17 Color Cycling Set 1
0x10 - 1 = first register (0 - 15)
0x12 - 3 = last register (0 - 15)
0x14 - 5 = recursions (0 = infinite)
0x16 - 7 = speed in 1/64 sec. High bit indicates direction
of cycle. If clear, then registers are INC'd.
If set, then registers are DEC'd. By INC'ing,
I mean that if FFB0 is the lowest addressed
register in the set, the value in FFB0 is moved to
FFB1 and so forth until the highest register
is hit. The value is then sent to the lowest
register in the set.
0x18 - 0x1f Color Cycling Set 2
0x18 - 9 = first register (0 - 15)
0x1a - b = last register (0 - 15)
0x1c - d = recursions (0 = infinite)
0x1e - f = speed in 1/64 sec. High bit indicates direction
of cycle. (see above)
0x20 - 0x3f Undefined
0x40 Color Pallette 0 (address FFB0)
0x42 Color Pallette 1 (address FFB1)
0x44 Color Pallette 2 (address FFB2)
0x46 Color Pallette 3 (address FFB3)
0x48 Color Pallette 4 (address FFB4)
0x4a Color Pallette 5 (address FFB5)
0x4c Color Pallette 6 (address FFB6)
0x4e Color Pallette 7 (etc.)
0x50
0x52
0x54
0x56
0x58
0x5a
0x5c
0x5e Color Pallette 15 (address FFBF)
0x60 - 0x7f are reserved for further Color Pallettes
for compatibility with other graphic displays.
Color Computer Register Data
Each color value in the CoCo3 may be either in RGB
format or Composite format. The GF9 standard requires
data to be stored in RGB format. Each value is contained
in the lower 6 bits as follows:
Data Bit 7 6 5 4 3 2 1 0
- - r1 g1 b1 r0 g0 b0
Each pair of color values pair with its corresponding
value to create a level value from 0 to 3
r1 r0 = red value,
g1 g0 = green
b1 b0 = blue.
A bright red is 0b00100100, a dark green is 0b00000010,
white is 0b00111111, black is 0b00000000, etc.
Picture Data
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.
Color Computer 3 Screen Memory Formats:
The screen memory definitions can be found in a number
of publications. The two I'm mainly concerned about are
the 320 * 192 * 16 color and 160 * 192 * 16 color formats.
The information on the original Color Computer formats can
be found in materials describing the MC6847.
The 320 * 192 screen format is Mode 2, Submode 6. In
this format each byte contains information for 2 pixels,
left to right, nibble mapped. The order is from the upper
left corner of the picture across to the right, line by
line from the top of the screen to the bottom in 30,720
bytes. The nibble value is a "pallette address". A 0
value is the color in "Color Pallette 0", a 1 value
is the color in "Color Pallette 1" (etc.) where the
"Color Pallette n" is the register address noted above.
The 160 * 192 is screen format Mode 2, Submode 0. It
is similar to Submode 6, but with 15,360 bytes.
Miscellaneous
The reason for the "undefined" words is for such
things as sprite definition, object motion and such.
It'll be useful for the future.
Duration 0 File Headers:
The contents of these files are defined by *internal*
headers which start *after* the 128th byte.
It is expected that the first bytes of the extended definition
will be used for additional color registers for later computers
able to display more than 16 colors.
A number of special files may be contained inside a single
0 Duration file. For example, if you have 16 bit images of a
girl walking, you may call them 'judy.1' to 'judy.16'. Each
would be contained in a Sprite Definition File by its name
in the form
[Sprite Definition File Header][Sprite definition data]
and all the files may be concatenated into one 0 duration file.
Similarly, Program Files can be intermixed with Sprite
Definition Files. By default, unless another program file
is currently being executed, the first program file will be
executed immediately.
Program files are in a form as follows:
[Program File Header][Program File data]
*/
--
Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880
ihnp4!utzoo!lsuc!jimomura
Byte Information eXchange: jimomura