[Coco] vef spec was Re: CoCo3 graphic file formats

[John Strong]

Willard,

Thanks.

VEF was one of the "etc" I was interested in.

ISTR that MGE also use a RLE format.

 

Know were to get a few VEF files for testing?


> Here's the official word on .vef, from the MVCanvas docs, by Mike
> Haaland of Hyper-Tech Software, 1989, updated 03/22/90.
> 
> He says:
> 
> FILE FORMAT
> ----------------
> 
> NOTE: "char" below refers to a Byte.
> 
> VEF picture format:
> 
> A two byte VEF Header. Header Values are in Hexadecimal
> 
> Standard Squashed Screen Type Screen size Colors
> -------------------------------------------------------
> 0000 8000 08 320x200 16
> 0001 8001 07 640x200 4
> 0003 8003 06 320x200 4
> 0004 8004 05 640x200 2
> 
> 16 bytes palette information
> 
> Picture Data:
> ----------------
> 
> If picture is a Standard (UnCompressed) VEF
> 
> Raw Data -- just put it on the screen
> 
> If picture is compressed (Squashed)
> 
> char len; Number of bytes to read and decode to restore 1/2 scan
> line of screen data. 1/2 scan line is 80 bytes on a
> type 7 or 8 screen, 40 bytes on types 5 or 6 screen.
> (40 and 80 are Decimal values)
> char count; compressed/uncompressed byte count
> 
> if data is compressed:
> 
> char data;
> 
> if data is uncompressed:
> 
> char data[count];
> 
> The header data will only be found once at the beginning of the file.
> 
> Now to decode the Compressed Data. Read the first byte and call it
> len. It's the length of the compressed 1/2 scan line. Now read 'len'
> bytes into an array. All we have to do now is to decode the data we
> just read into the buffer. Get the first byte in the buffer and see
> if the high bit is set. It's our 'count' byte. If the high bit is
> set it's compressed. Now subtract 128 from our 'count' (clear the
> high bit) and put the next byte in the buffer 'count' times.
> 
> If the high bit is not set, get the next 'count' bytes from the buffer
> and put them on the screen.
> 
> This continues until you've used 'len' bytes that are in the buffer.
> When the buffer has been decoded, read the next 'len' byte from the
> file and do it again. This will be repeated 400 times in the file.
> 
> For compressed data:
> --------------------------
> (In Decimal)
> char count, 1 to 127 - High bit set - means its compressed
> data; this will be the screen data, put it on the screen
> 'count' times.
> 
> For uncompressed data:
> --------------------------
> (In Decimal)
> char count, 1 to 127 - Uncompressed number of bytes to follow.
> data[count];
> 
> 
> Willard says: That's it! I've only dealt with uncompressed VEFs
> myself. 
> 
> -- 
> Willard Goosey goosey at sdc.org
> Socorro, New Mexico, USA
> I search my heart and find Cimmeria, land of Darkness and the Night.
> -- R.E. Howard



> I got a rare one for you! .hr0 .hr1 .hr2 .hr3
Surprisingly I remember seeing this one in Rainbow:)

> 
> I only know of one other person who ever used this... :-)
> 
> HR files are bitmap graphic files of the CoCo 3 type 8 screen 
> (320x200x16) produced by a simple routine, shown in the included 
> hisave.bas & hiload.bas files. 
> 
> Since the CoCo 3 hi-res graphics screens aren't in BASIC's
> memory, these routines work by using the GIME's MMU functions to
> map the consecutive 8K blocks of the screen into BASIC memory,
> then savem's the individual block. The result is 4 8K files,
> each in the usual CoCo .bin file format. The loader works the
> same way, mapping in one of the 8K blocks of graphics RAM and
> loadm-ing the appropriate file into that block.
> 
> The result is 4 files, each 10 bytes longer than 8K (the size of
> the .bin header & footer). If the file is named TANK, the
> results are TANK.HR0, TANK.HR1, TANK.HR2, & TANK.HR3.

 

John Strong

StrongWare