Revision as of 14:05, 16 April 2010

Advanced OCP Art Studio File Formats

This document describes the structure of the files used by The Advanced OCP Art Studio, a art utility for the Amstrad CPC, published by "Rainbird".

The files covered are:

• The palette file with filename extension ".PAL".
• The window file with filename extension ".WIN".
• The screen file with filename extension ".SCR".
• The font file with filename extension ".FNT".

Note:

• All multi-byte values are stored in little endian format.

The palette ".PAL" file structure

The palette file has an extension of ".PAL". This file contains the display mode, palette and colour animation for a Advanced Art Studio window or screen.

The palette file has the same name as the window or screen it was saved with. (e.g. The screen file "raytrace.scr" will have a palette file named "raytrace.pal").

The file is binary and has the following properties:

• load address: &8809
• length: 239
• execution address: &8809

The file has the following structure:

Notes:

1. screen mode is:
   • "0" for low resolution (160x200 in 16 colours) OR
   • "1" for medium resolution (320x200 in 4 colours) OR
   • "2" for high resolution (640x200 in 2 colours)
2. The colour animation delay is the number of frames (at 50fps) to wait between updates to the colour palette.
3. There are 12 bytes for each colour palette entry. Each byte is a hardware colour number in the format that can be written directly to the Gate-Array (e.g. bit 7="0", bit 6="1", bit 5="0" and bit 4..0 define the hardware colour index). See the document on the Gate Array for the hardware colour numbers and their associated colour. Each byte is the colour for a frame, and therefore there are 12 frames for colour animation effects.
4. excluded inks
5. protected inks

The window (".WIN") file format

The window file has an extension of ".WIN".

A window is a rectangular area of bitmapped graphics that has been cut from a bitmapped screen. The pixel data in the file can be compressed or uncompressed.

The mode and palette information for the window file is stored in a seperate palette file.

The file is binary and has the following properties:

• load address: &4000
• length: (variable, depends on dimensions of window and compression)
• execution address: &4000

The file has the following structure:

Notes:

1. Window pixel data:
   • If the file is compressed, after decompression, each byte of the pixel data is in the format that the hardware uses. If the file is not compressed, each byte of the pixel data will already be in the format that the hardware uses. Each byte describes:
     • 2 mode 0 pixels OR
     • 4 mode 1 pixels OR
     • 8 mode 2 pixels.
   • The pixel data can be compressed. The compression method is described here.
   • The pixel data is stored in complete lines from top to bottom.
   • The length of a line in the pixel data is a integral number of bytes. Therefore there may be unused pixels in the last byte of each line.
2. The width of the window is defined in mode 2 sized pixels regardless of the actual display mode.

To calculate the width of the window in mode 1 sized pixels, divide the width of the window by 2. To calculate the width of the window in mode 0 sized pixels, divide the width of the window by 4.

1. With bitmapped screens, each byte of pixel data describes one or more pixels directly.

The screen (".SCR") file structure

The screen file contains the pixel data for a entire bitmapped screen.

The file is binary and has the following properties:

• load address: &4000
• length: (16384 if uncompressed, <16384 if compressed)
• execution address: &4000

Notes:

1. The screen file describes pixel data for a mode 0, mode 1 or mode 2 screen.
2. The screen is always 200 lines tall, and 80 bytes wide. This corresponds to a resolution of:
   • 160x200 in mode 0 OR
   • 320x200 in mode 1 OR
   • 640x200 in mode 2.
3. If the file is compressed, after decompression, each byte of the pixel data is in the format that the hardware uses.

If the file is not compressed, each byte of the pixel data will already be in the format that the hardware uses. Each byte describes:

1. • 2 mode 0 pixels OR
   • 4 mode 1 pixels OR
   • 8 mode 2 pixels.
2. If the pixel data is compressed, the file size will be less than 16384 bytes.

The compression method is described here.

1. If the screen is not compressed it will be exactly 16384 bytes.
2. The entire pixel data is in the format that the hardware uses: The following table shows the start offset of each line in the screen file.

The following equation can be used to calculate the offset of any line:

offset = ((line AND 7)*&800) + ((line/8)*&80)

1. With bitmapped screens, each byte of pixel data describes one or more pixels directly.

The font ".FNT" file format

The font file format describes the characters in a monochrome bitmapped font.

The file is binary and has the following properties:

• load address: &8300
• length: &300
• execution address: &8300

Notes:

• The font stores the printable characters with ASCII codes 32-127 inclusive.
• The font is monochrome, i.e. only two colours are used by the font; foreground and background.
• The dimensions for all characters is the same.
• The dimension of a single character is 8 pixels wide and 8 pixels tall (8x8)
• Pixel data:
  • The pixel data for each character takes 8 bytes.
  • Each byte contains the pixel data for a line of the character. Bit 7 is the left-most pixel, bit 0 is the rightmost pixel. Therefore if a bit is "1" this pixel will be displayed using the foreground colour, if a bit is "0" this pixel will be displayed using the background colour.
  • The lines are stored from top to bottom:
    • Byte 0 is the data for line 0,
    • Byte 1 is the data for line 1,
    • Byte 2 is the data for line 2,
    • Byte 3 is the data for line 3,
    • Byte 4 is the data for line 4,
    • Byte 5 is the data for line 5,
    • Byte 6 is the data for line 6,
    • Byte 7 is the data for line 7.

The following equation can be used to calculate the start of the character

offset = (ascii_code - 32)*8

Compression algorithm used by pixel data in window and screen files

If data is compressed using this algorithm, there will be one or more "compressed blocks".

A "compressed block" has the following structure:

Notes:

1. The decompression algorithm used by OCP Advanced Art Studio does not allow more than "length of uncompressed data in this block" bytes to be written, even if the data describes more bytes. The surplus bytes are ignored.
2. The compression method is based on "run length encoding". "run length encoding" is a simple compression algorithm which can compress groups of repeated bytes. The compressed data in each block will contain single data bytes and run-length packets. A "marker" byte is used to identify a run-length packet. Each packet has the following structure:

Notes:

1. 1. The "marker" identifies a run-length packet. The compression method used in OCP Advanced Art Studio files has a marker of "&01".
   2. The "count" defines the number of times the data-byte repeats. A count of "&00" means the byte is repeated 256 times.
   3. The "byte" is the actual data byte to output when decompressing.

If the marker exists in the data before compression, it will be encoded as the following run-length packet:

marker, 1, marker

i.e. &01, 1, &01 for OCP Advanced Art Studio files.

1. The uncompressed data is written forwards. (i.e. the pointer to the destination uncompressed data is incremented after each uncompressed byte is written)
2. The uncompressed data is written in a continuous block, there is NO re-arrangement of the data.