View source for Format:Advanced OCP Art Studio File Formats

'''''This artikel originally came from Kevin Thackers' archive at [http://www.cpctech.org.uk http://www.cpctech.org.uk].''''' 

= Advanced OCP Art Studio File Formats  =

This document describes the structure of the files used by "OCP Advanced 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: &amp;8809 
*length: 239 
*execution address: &amp;8809

The file has the following structure: 

<br> 

{| border="1"
|-
! Offset (decimal) 
! Count 
! Description&lt;/thead&gt;&lt;tbody&gt;
|-
| 0 
| 1 
| Screen mode (see note 1)
|-
| 1 
| 1 
| Colour animation flag: "FF" = colour animation active, "00" = no colour animation
|-
| 2 
| 1 
| Colour animation delay in frames - 1 (see note 2)
|-
| 3 
| 1*12 
| palette entry 0: colours for 12 frames (see note 3)
|-
| 15 
| 1*12 
| palette entry 1: colours for 12 frames (see note 3)
|-
| 27 
| 1*12 
| palette entry 2: colours for 12 frames (see note 3)
|-
| 39 
| 1*12 
| palette entry 3: colours for 12 frames (see note 3)
|-
| 51 
| 1*12 
| palette entry 4: colours for 12 frames (see note 3)
|-
| 63 
| 1*12 
| palette entry 5: colours for 12 frames (see note 3)
|-
| 75 
| 1*12 
| palette entry 6: colours for 12 frames (see note 3)
|-
| 87 
| 1*12 
| palette entry 7: colours for 12 frames (see note 3)
|-
| 99 
| 1*12 
| palette entry 8: colours for 12 frames (see note 3)
|-
| 111 
| 1*12 
| palette entry 9: colours for 12 frames (see note 3)
|-
| 123 
| 1*12 
| palette entry 10: colours for 12 frames (see note 3)
|-
| 135 
| 1*12 
| palette entry 11: colours for 12 frames (see note 3)
|-
| 147 
| 1*12 
| palette entry 12: colours for 12 frames (see note 3)
|-
| 159 
| 1*12 
| palette entry 13: colours for 12 frames (see note 3)
|-
| 171 
| 1*12 
| palette entry 14: colours for 12 frames (see note 3)
|-
| 183 
| 1*12 
| palette entry 15: colours for 12 frames (see note 3)
|-
| 195 
| 1*12 
| border: colours for 12 frames (see note 3)
|-
| 207 
| 16 
| excluded inks (see note 4)
|-
| 223 
| 16 
| protected inks(see note 5)&lt;/tbody&gt;
|}

Notes: 

#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) 
#The colour animation delay is the number of frames (at 50fps) to wait between updates to the colour palette. 
#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. 
#excluded inks 
#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: &amp;4000 
*length: (variable, depends on dimensions of window and compression) 
*execution address: &amp;4000

The file has the following structure: 

<br> 

{| border="1"
|-
! Offset (decimal) 
! Length 
! Description&lt;/thead&gt;&lt;tbody&gt;
|-
| 0 
| length-5 
| Window pixel data (see note 1)
|-
| length-4 
| 2 
| Width of window in pixels (see note 2)
|-
| length-2 
| 1 
| Height of window in lines/2
|-
| length-1 
| 1 
| &nbsp;?&lt;/tbody&gt;
|}

Notes: 

#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. 
#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. 

#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: &amp;4000 
*length: (16384 if uncompressed, &lt;16384 if compressed) 
*execution address: &amp;4000

Notes: 

#The screen file describes pixel data for a mode 0, mode 1 or mode 2 screen. 
#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. 
#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. 
#If the pixel data is compressed, the file size will be less than 16384 bytes.

The compression method is described here. 

#If the screen is not compressed it will be exactly 16384 bytes. 
#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.

{| border="1"
|-
! Offset 
! Length 
! Description&lt;/thead&gt;&lt;tbody&gt;
|-
| &amp;0000 (line 0 + &amp;0000) 
| 80 
| Line 0 of image
|-
| &amp;0800 (line 0 + &amp;0800) 
| 80 
| Line 1 of image
|-
| &amp;1000 (line 0 + &amp;1000) 
| 80 
| Line 2 of image
|-
| &amp;1800 (line 0 + &amp;1800) 
| 80 
| Line 3 of image
|-
| &amp;2000 (line 0 + &amp;2000) 
| 80 
| Line 4 of image
|-
| &amp;2800 (line 0 + &amp;2800) 
| 80 
| Line 5 of image
|-
| &amp;3800 (line 0 + &amp;3000) 
| 80 
| Line 6 of image
|-
| &amp;3800 (line 0 + &amp;3800) 
| 80 
| Line 7 of image
|-
| &amp;0080 (line 8 + &amp;0000) 
| 80 
| Line 8 of image
|-
| &amp;0880 (line 8 + &amp;0800) 
| 80 
| Line 9 of image
|-
| &amp;1080 (line 8 + &amp;1000) 
| 80 
| Line 10 of image
|-
| &amp;1880 (line 8 + &amp;1800) 
| 80 
| Line 11 of image
|-
| &amp;2080 (line 8 + &amp;2000) 
| 80 
| Line 12 of image
|-
| &amp;2880 (line 8 + &amp;2800) 
| 80 
| Line 13 of image
|-
| &amp;3080 (line 8 + &amp;3000) 
| 80 
| Line 14 of image
|-
| &amp;3880 (line 8 + &amp;3800) 
| 80 
| Line 15 of image
|-
| ... 
| ... 
| ...
|-
| ... 
| ... 
| ...
|-
| ... 
| ... 
| ...
|-
| ... 
| ... 
| ...
|-
| &amp;0780 (line 192 + &amp;0000) 
| 80 
| Line 192 of image
|-
| &amp;0f80 (line 192 + &amp;0800) 
| 80 
| Line 193 of image
|-
| &amp;1780 (line 192 + &amp;1000) 
| 80 
| Line 194 of image
|-
| &amp;1f80 (line 192 + &amp;1800) 
| 80 
| Line 195 of image
|-
| &amp;2780 (line 192 + &amp;2000) 
| 80 
| Line 196 of image
|-
| &amp;2f80 (line 192 + &amp;2800) 
| 80 
| Line 197 of image
|-
| &amp;3780 (line 192 + &amp;3000) 
| 80 
| Line 198 of image
|-
| &amp;3f80 (line 192 + &amp;3800) 
| 80 
| Line 199 of image&lt;/tbody&gt;
|}

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

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

#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: &amp;8300 
*length: &amp;300 
*execution address: &amp;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: 

<br> 

{| border="1"
|-
! Offset 
! Length 
! Description&lt;/thead&gt;&lt;tbody&gt;
|-
| 0 
| 3 
| Identification bytes: "M","J" and "H" in that order
|-
| 3 
| 2 
| Length of uncompressed data in this block (note 1)
|-
| 5 
| ... 
| Compressed data for this block (note 2)&lt;/tbody&gt;
|}

Notes: 

#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. 
#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:

{| border="1"
|-
! Offset 
! Length 
! Description&lt;/thead&gt;&lt;tbody&gt;
|-
| 0 
| 1 
| marker (see note 1)
|-
| 1 
| 1 
| count (see note 2)
|-
| 2 
| 1 
| byte (see note 3)&lt;/tbody&gt;
|}

Notes: 

##The "marker" identifies a run-length packet. The compression method used in OCP Advanced Art Studio files has a marker of "&amp;01". 
##The "count" defines the number of times the data-byte repeats. A count of "&amp;00" means the byte is repeated 256 times. 
##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. &amp;01, 1, &amp;01 for OCP Advanced Art Studio files. 

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