TIFILES (ǬP( ╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩S╩SPIX FORMAT SPECIFICATION /Copyright 1989 by Jim Reiss and Asgard Software 3Pix is a trademark of Asgard Software and Jim Reiss HISTORY: OThe Pix format was researched and developed by Jim Reiss under sponsorship fromAsgard Software. JThis format was developed in response to a need for a graphics file formatLthat: (a) was portable between all systems with 9918a or compatible graphicsOprocessors, (b) provided significant compaction of picture data without complex Asgard Software. Ndecoding and encoding software, (c) was able to be decoded and encoded quicklyKwith a minimum amount of memory needed for buffering, (d) could serve as anLinterim format between different graphics standards native to and foreign of x Asgard Software. K9918a systems, (e) was designed more towards the needs of desktop publishngNsoftware than existing formats, and finally (f) one which was fully documented(and could be used freely by all parties. ards native to and foreign of x Asgard Software. LVirtually all file formats in widespread use today were designed to suit theIspecific needs of a particular application. As a result, data interchangeKbetween graphics applications on the TI-99/4A is fragmented at best. Widely n of x Asgard Software. Gused graphics formats for the TI-99/4A include GRAPHX, TI-Artist, CSGD,NJoyPaint, Picasso, Instance, TIPS, RLE, Page Pro, Calendar Maker, GIF, My-Art,OMacPaint, and many other lesser ones. Currently, users are faced with (at best) x Asgard Software. Igreat difficulty in moving artwork between applications. Porting graphicsNbetween file formats can sometimes take 3 or more different programs and quite a bit of time and manual labor. rrently, users are faced with (at best) x Asgard Software. ITI-99/4A programmers face their own problem in that no format is properlyIdesigned for use in emerging new fields of graphics applications, such asNanimation and desktop publishing. As a result, file formats can be expected to st) x Asgard Software. Nproliferate further, with commensurately less interchange of data. In order toLmaintain compatibility with existing libraries of pictures, programmers willLhave to produce more and more converters to handle conversions between other Asgard Software. Mfile formats and their own. It is plain that users and developers of graphics1files and applications need a "universal" format. GThis format is proposed not as the native format of all existing or new conversions between other Asgard Software. Japplications (since at a minimum that would require thousands of man-hoursNworth of rewriting), but as a format that facilitates data interchange betweenLgraphics applications. Pix was designed to be flexible enough to handle both r Asgard Software. Mcolor and monochrome pictures, and picture of every size from small "clipart"Oto full-page works many times the size of the actual screen. Pix is also usefulLas an archival format since it typically provides significant compression of sgard Software. Lpictures over their native formats (for instance a monochrome GRAPHX pictureOmay be reduced from 13,568 bytes to 5,376 bytes in size). Converters supportingNthis format can even decode a file from Pix to their format typically twice as gard Software. 8fast as they could decode RLE (a popular simple format). LApplication writers are encouraged to write converters from the file formatsMused in their programs to this format. In this way, an application author can ypically twice as gard Software. Oproduce a file format more appropriate to his or her application while ensuringNaccess to a large quantity of existing artwork for users of their application.FPix is copyrighted in an attempt to control the format and prevent the ce as gard Software. Lemergence of nonstandard versions, as happens all too easily. The author isKopen to suggestions for format extensions, but requests the right to decideLwhat is added to the official Pix definition. Authors who create derivative ce as gard Software. Eformats are asked to provide a converter to the Pix standard in theirapplications. TECHNICAL SPECIFICATIONS: OPix pictures are stored in 32 byte fixed length records. The first record is a s who create derivative ce as gard Software. Nheader which contains important information about the picture. The key to theOcompaction which Pix provides is that no character pattern is defined twice. AIcharacter is an 8 pixel wide by 8 pixel high block. On the TMS9918a, the as gard Software. Nscreen will have no more than 768 distinct patterns. In many cases, there are<as few as 200, or even less, unique patterns out of the 768. NWithin the Pix file, there are either two or four data tables. Pictures which 8a, the as gard Software. Ohave only two colors throughout will only have two. Pictures with more complexGcolors will have four tables. These tables are stored in the order of: 1) Virtual Screen 2) Pattern Table 3) Virtual Color Screen 4) Color Table gard Software. OAll tables start in brand new records, even if the previous table does not fillits last record. KThe Virtual Screen table is a list of character numbers whose length is the ttern Table 3) Virtual Color Screen 4) Color Table gard Software. Nwidth of the picture times the height, in 8x8 pixel characters. The width andNheight can be greater than what is displayed on the screen, and are defined inOthe picture header. Until character 255 has been encoded and its number output rd Software. Kto the Screen table, character numbers are stored in 8-bit bytes. Once 255Ohas been written, the pointer for writing to the screen is incremented if it isNcurrently pointing to an odd numbered address. 16-bit words are then used for ut rd Software. Gcharacter numbers. This can save a lot of bytes when pattern 255 isn'tLneeded. Aside from the varying word length, the programmer can think of theJVirtual Screen and Pattern Table in the same way as the screen and pattern n used for ut rd Software. Ntables of the 9918a's Graphics 1 mode, but with 768 allowable patterns insteadof 256. OThe Pattern Table is the set of character patterns which the decoder will referKto based on the Virtual Screen. Character numbering starts at zero, so the . Hfirst record of the pattern table holds the patterns for characters zerothrough three. HThe Virtual Color Screen is just like the Virtual Screen, but instead ofJcharacter patterns it points to 8 byte groups of color codes. These color so the . Mcodes are as they would be in the 9918a's color table, so the group refers toOthe colors of a particular pixel row of eight contiguous characters. The Color/Table is otherwise just like the Pattern Table. of color codes. These color so the . FThe 32 byte header record is as follows (byte zero is the first byte): -Byte 0 Reserved - must be ascii value of 'P' 8Byte 1 Picture type flag. Allows extensions to format. A If byte is zero, there is no Color Screen or Color Table. 3 If byte is 01, there is a color definition. ?Byte 2 High byte of picture width in characters (usually zero) >Byte 3 Low byte of picture width (usually 32 decimal, 20 hex) EByte 4 High byte of picture height in characters (also usually zero) :Byte 5 Low byte of picture height (usually 24, or 18 hex) AByte 6 High byte of the number of records for the Virtual Screen 8Byte 7 Low byte of number of records for Virtual Screen 7Byte 8 High byte of number of records in Pattern Table zero) 6Byte 9 Low byte of number of records in Pattern Table -Byte 10 through byte 13 vary based on byte 1. If byte 1 is 00: IByte 10 The two colors in the picture. The high nybble is the foreground/ color, the low is the background color. 2Bytes 11 through 13 are reserved and must be zero. If byte 1 is 01: 7Byte 10 High byte of number of records for Color Screen 6Byte 11 Low byte of number of records for Color Screen 6Byte 12 High byte of number of records for Color Table 5Byte 13 Low byte of number of records for Color Table NIn either case, bytes 14 through 31 are reserved for future expansion and mustMbe zero. For now, decoders should abort if byte 1 is anything other than oneor zero. rds for Color Table KNote that a simple encoder for a 32x24 two color screen could merely outputNzero through 255 as bytes, then 256 through 767 as words, and then the patternOtable could be identical to how it is stored in the video RAM of the 9918a, and for Color Table Jall Pix decoders could view it. However, this gives no compaction at all.*Encoders should not allow repeat patterns. CONTACTS: IJim Reiss has a BSS in Computer Science from Cornell College. He has been f the 9918a, and for Color Table Ninvolved in programming the TI-99/4A commercially for almost 2 years, and on aNmore casual basis for many years prior to that. He is the author of TypewriterKand Tris, both available in module and disk form for the TI-99/4A and Myarc Geneve 9640. OAsgard Software is a leader in the TI-99/4A software industry with well over 70Jdifferent titles and 100 packages available for the 99/4A and Geneve 9640.NThis firm has been developing new applications since 1984, and now distributes Geneve 9640. Lsoftware in disk, cassette and module form, and through a subsidiary (AsgardCPublishing) publishes several books and a highly-regarded magazine. /Any questions can be directed to the following:
Jim Reiss: CIS TI Forum, ID # 75116,2373 People Link, user name JIM REISS Delphi, user name JIMREISS OBT BBS (201) 679-0549 or by US Mail at: 216 First Street West Mount Vernon, IA 52314 Asgard Software: CIS TI Forum, ID # 72561,3241 GEnie, C.BOBBITT Delphi, ASGARD By Telephone, (703)255-3085 or by US Mail at: P.O. Box 10306 Rockville, MD 20850 HSome telecommunications services aren't checked as frequently as others. oftware: CIS TI Forum, ID # 72561,3241 GEnie, C.BOBBITT Delphi, ASGARD
