=============================================================================== INTVPC Resource File Format J. Zbiciak =============================================================================== This description is reverse engineered from the simulator's data files, and as such may not be complete or 100% correct. Some feedback has been provided by Carl Mueller, Jr. himself to provide some corrections, though. Nonetheless, Caveat Hackor. Acknowledgements: The Intellivision simulator code was developed solely by Carl Mueller, Jr. Technical assistance, including providing some hardware and other software support was provided Scott Nudds and William Moeller. Please see De Re Intellivision volume 1 for a more detailed history of the development of the Intellivision for PC and a more complete set of credits for its development. http://2bits.simplenet.com/intv/dri/index.html Resource Archive Format ======================= Archive Header Length: 49 bytes Offset Length Format Description ------ ------ ------ -------------------------------------------- 0 13 String Identification string -- always "Resource" 13 2 Word Status (0000 = Normal, 0001 = Deleted) 15 2 Word Number of resources 17 32 n/a Reserved. 49 xx Record Resource record, length noted in record header Resource Record Header Length: 31 bytes Offset Length Format Description ------ ------ ------ -------------------------------------------- 0 13 String Name of resource 13 2 Word Resource type (see type table below) 15 4 Long Length of resource in bytes 19 4 Long Offset to next resource * 23 4 Long Offset into archive in bytes ** 27 4 n/a Unused (?) -- always zeroes 31 len Data Resource data, length given in header * This is always equal to the length in "packed" archives, but might be larger in "unpacked" archives. I currently only handle "packed" archives. ** This field is supposedly only used internally in Carl Mueller's software, and can be ignored. It is usually not set in most archives. Its value should not be trusted. Image File Format ================= Offset Length Format Description ------ ------ ------ -------------------------------------------- 0 2 Word Width of uncompressed image 2 2 Word Height of uncompressed image 4 2 Word Length of compressed data, (0 == not compr.) 6 2 Word Colors in palette (0 = no palette) 8 len RLE Run-length encoded data Data is encoded as a sequence of runs. Each run is of the form "Run", "Data". The "Run" value is encoded in a single byte like so: 7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ | Run Length |RPT| +---+---+---+---+---+---+---+---+ The "Run Length" is a value in the range 0 - 127. I'm not certain what a run length of 0 does -- it could act as a special code, or as a run of 128. The "RPT" bit determines how this run is treated. If this bit is set, then the next byte is repeated "Run Length" times in the output image. If this bit is cleared, then the next "Run Length" bytes are copied from the compressed data stream directly to the image. I refer to runs with RPT==1 as "Repeat Runs", and runs with RPT==0 as "Escape Runs". The image itself is treated as a linear stream of bytes during decode. This stream of bytes is corresponds to a left-to-right, top-to-bottom scan of the image -- eg. a standard row-major-order raster scan. Notes: -- If the compressed length field is set to 0, then the image file is not compressed. -- No image files currently have palettes attached. Rom File Format =============== The cartridge ROM images store the decles in two portions. The first 4/5ths of the file contains the lower 8 bits of every decle. The last 1/5ths of the file contains the upper 2 bits of each decle, packed four to a byte. Packing order is not yet known. I will refer to this format as the 8+2 format (in the spirit of the Apple ]['s 6+2 and 5+3 disk formats). The packing order appears to be like so, although I need to verify: Bits 7 6 5 4 3 2 1 0 [ 3 | 2 | 1 | 0 ] The last two bytes of the file contain a 2-byte count value. This count appears to be the number of bytes the rom image occupies when unpacked so that each decle occupies a 16-bit word. (eg. a 4Kdecle ROM has a length of 0x2000.) Notes: -- EXEC.CBN in vol1.res doesn't appear to adhere to this format. It was apparently modified to remove some routines related to rotating/flipping bitmaps. Other Information ================= Type numbers for resource records: 0000 -- Binary object (Intellivision objects and other binary resources.) 0001 -- Resource files 0002 -- Compressed image files (custom RLE format) 0003 -- Font character (in same format as image files, it appears) 0004 -- Palette file (only?) (in 6-bit RGB triples.) 0005 -- Sound file, (.SND in Mac .ub format, 11025Hz, AYxxxx files unknown) 0006 -- PCX files (none observed so far) 0007 -- HTML documentation file Data formats: String First byte is length, next 12 bytes are zero-padded (but not necessarily zero-terminated) string. Word 2-byte integer, little-endian format Long 4-byte integer, little-endian format Data Raw data, in one of the noted type formats (see type-table above). RLE Run-length encoded image data. =============================================================================== $Id: res_file.txt,v 1.2 1998/12/28 07:17:45 im14u2c Exp $ ===============================================================================