C64 PICTURE FORMATS
                            ===================

               By Matt Francis (m.p.francis@newcastle.ac.uk)


INTRODUCTION
------------

Several people have asked me to include information on the different picture
formats with this release of ShowVIC.  Well, information wants to be free,
so here are details of all the formats ShowVIC supports.  The following
labels are used:

	Load	- Load address (first two bytes of the file)
	Length	- File length in bytes (including load address bytes)
	Bitmap	- Bitmap offset (8000 bytes)
	Screen	- Screen data offset (1000 bytes)
	Colour	- Colour data offset (1000 bytes)
	ScrCol	- Screen colour offset (1 byte)

The offsets given for the bitmap, screen data etc. do not include the two
load address bytes.

NOTE:  If you don't know anything about how the C64 stores bitmaps, you will
find it very hard to write a conversion program.  If this is the case, I
recommend you read about bitmaps in a good C64 reference book before
attempting to write a conversion routine.


THE FORMATS
-----------

Art Studio (hires):			Load	- $2000
					Length	- 9009
					Bitmap	- 0
					Screen	- 8000


Image System (hires):			Load	- $4000
					Length	- 9194
					Bitmap	- 0
					Screen	- 8192


Blazing Paddles (multicolour):		Load	- $A000
					Length	- 10242
					Bitmap	- 0
					Screen	- 8192
					Colour	- 9216
					ScrCol	- 8064


Koala (multicolour):			Load	- $6000
					Length	- 10003
					Bitmap	- 0
					Screen	- 8000
					Colour	- 9000
					ScrCol	- 10000


Advanced Art Studio (multicolour):	Load	- $2000
					Length	- 10018
					Bitmap	- 0
					Screen	- 8000
					Colour	- 9016
					ScrCol	- 9001


Artist 64 (multicolour):		Load	- $4000
					Length	- 10242
					Bitmap	- 0
					Screen	- 8192
					Colour	- 9216
					ScrCol	- 10239


Vidcom 64 (multicolour):		Load	- $5800
					Length	- 10050
					Bitmap	- 2048
					Screen	- 1024
					Colour	- 0
					ScrCol	- 2024 (see note at end)


Image System (multicolour):		Load	- $3C00
					Length	- 10218
					Bitmap	- 1024
					Screen	- 9216
					Colour	- 0
					ScrCol	- 9215


Doodle (hires):				Load	- $5C00
					Length	- 9218
					Bitmap	- 1024
					Screen	- 0


FLI (see notes at end):			Load	- $3B00
					Length	- 17474 or 17666
					Bitmap	- 9472
					Screen	- 1280 (8000 bytes)
					Colour	- 256
					ScrCol	- 0 (200 bytes)

Hi-Eddi:				Load	- $2000
					Length	- 9218
					Bitmap	- 0
					Screen	- 8192

Amica-Paint:				Compressed Koala pictures


SPECIAL NOTES ON VIDCOM
-----------------------

Unfortunately, Vidcom doesn't seem to store the screen colour in its bitmap
files.  To get round this, ShowVIC takes the screen colour from offset 2024
($7E8), which is usually a zero (so Vidcom pictures will normally be
converted with a black background, even though Vidcom itself uses dark blue
by default).  This can be changed by loading the picture into a binary file
editor like NewZap or DekSid, and changing byte 2026 (2024+2 for load
address bytes) to a value from 0 to 15.  Of course, you could do this on a
C64 before actually transferring the picture.  The best solution is to avoid
using the Vidcom format - Koala or Advanced Art Studio is preferable.

One more thing about Vidcom:  it seems to use exactly the same format for
both hires and multicolour pictures, making it impossible to distinguish
between them.  For this reason, ShowVIC currently assumes all Vidcom
pictures are multicolour.  If many people badger me (can't see it
happening), I might add a switch in a later release, so you can choose which
mode to convert to.



SPECIAL NOTES ON FLI
--------------------

For a full description of FLI, I refer you to Pasi Ojala's article in issue
4 of the "C= Hacking" magazine.  Here are a few notes on implementing the
format.

The only difference between converting this format and converting a normal
multicolour bitmap is that (a) the screen colour ($D021) changes every
scanline, and (b) every byte of every character block in the bitmap has its
own byte of screen data.  The screen data is organised in 8 pages of 1000
bytes each.  When an FLI picture is displayed on a C64, the screen RAM page
is changed every scanline, so the first pixel line of bytes (*not* the first
40 bytes) in the bitmap uses the first 40 bytes from the first page of
screen data.  The second pixel line uses the first 40 bytes from the second
page of screen data, and so on.  Hopefully this example will help clarify
things:


	Byte in		Char.	Screen		Screen
	bitmap		block	data page	data byte
	-------------------------------------------------
	 0		 0	 0		 0
	 1		 0	 1		 0
	...		...	...		...
	 7		 0	 7		 0
	 8		 1	 0		 1
	 9		 1	 1		 1
	...		...	...		...
	 15		 1	 7		 1
	 16		 2	 0		 2
	...		...	...		...