Graphics Formats and File Extensions

Headless data files are an abomination, IMHO, as there is no way of knowing for certain what they contain and getting that wrong could therefore easily lead to a systems crash. It helps a little if there are recognised file name extensions. After all we all expect to safely be able to LRESPR a _bin or a _rext file. My main beef is with screen dumps as the same-looking data can mean very different things and there havent been any real conventions regarding what to call them.

When the screen was fixed at 512x256 it might just have been acceptable to call the dump of such a screen dump_scr (_scn was reserved by PSION's Archive). The only ambiguity was whether it was a mode 0/4 screen or mode 8. Partial screen dumps were more problematic, and now with GD2 colour screens, not to mention emulators (such as SMSQmulator which can have variable screen sizes and geometries) things are just getting out of hand.

It is far better to use the PIC or SPR file formats. PIC is just a screen dump, after all, except that it has a 10 byte header that contains an identifying (and reassuring) flag (the illegal instruction code $4AFC ) and all the necessary information to display the image correctly. Thus it only requires a single file name extension, namely _pic, to cover all variants of modes and size. Sprites are a little more complex and have other advantages and disadvantages, but that is a chapter on its own.

To enable us to more easily determin the contents of a screen dump (as long as these still seem to be much loved), Id like to suggest the following file name extensions:

sc0screen dump mode 0
sc4synonimous with the above
scr0synonimous with the above
scr4synonimous with the above
dmp0synonimous with the above
dmp4synonimous with the above
sc8screen dump mode 8
scr8synonimous with the above
dmp8synonimous with the above
scrscreen dump mode 0 or mode 8
dmpsynonimous with the above
sc16screen dump mode 16
scr16synonimous with the above
dmp16synonimous with the above
sc32screen dump mode 32
scr32synonimous with the above
dmp32synonimous with the above
sc33screen dump mode 33
scr33synonimous with the above
dmp33synonimous with the above
sc64headless graphic dump mode 64
scr64synonimous with the above
dmp64synonimous with the above

Clearly the scrXX and dmpXX variants are dubious as they are five characters long, but what the hell, one doesnt have to use them.

All the above are mainly to be taken to mean full screen screen dumps in a number of standard sizes. However, they may usefully stretch to cover part-screen dumps as they at least give a clue to the correct mode, leaving only one unknown left to guess.

By standard sizes typically 512x256, 1024x512, 1024x768, etc for modes 0..8 are meant. The file sizes will normally suggest the correct dimensions. Once you throw GD2 modes 16..3X into the mix there are a number of possible "standard" sizes between 512x256 and 1920x1080 (and beyond), based on typical QL/SMSQ platforms. However, file sizes alone cant be relied on as they are not unambiguous. Eg 1024x768 mode 0/8 is 196,608b, but so is 512x384 mode 16, etc, so knowing the mode helps a little.

The PIC file format is the obvious solution. It looks like this:

* Definition of PIC header
pic_flag equ     $00      word     FLAG word
pic.flag equ     $4afc             what you expect to find there
pic_xsiz equ     $02      word     total X SIZe
pic_ysiz equ     $04      word     total Y SIZe
pic_rinc equ     $06      word     Row INCrement
pic_mode equ     $08      byte     MODE of saved data
pic_spar equ     $09      byte     SPARe
pic.hdrl equ     $0a               HeaDeR Length

While simple and versatile PICs have one main problem: File sizes tend to be massive. Therefore I have seen fit to apply a simple, fast compression method on them - the same as used with Wman2/GD2 sprites. To differentiate them from the uncompressed PIC files, Id like to register the following file name extensions:

pacRLE-compressed PIC files (PACked picture)
pccsynonimous with the above (PiCture Compressed)

The PAC file format is very similar to the standard QL PIC file format. The only differences are the "RLEx" long word tag prepended to the header and the fact that the graphics data following the header is RLE-compressed:

* Definition of RLE-compressed PIC header or PACked file
pac_rlex equ     $00      long     "RLEx", x = 1, 2, or 4
pac_flag equ     $04      word     FLAG word
pac.flag equ     $4afc             what you expect to find there
pac_xsiz equ     $06      word     total X SIZe
pac_ysiz equ     $08      word     total Y SIZe
pac_rinc equ     $0a      word     Row INCrement
pac_mode equ     $0c      byte     MODE of saved data
pac_spar equ     $0d      byte     SPARe
pac.hdrl equ     $0e               HeaDeR Length

The decompressed data size is worked out as pac_ysiz x pac_rinc

The RLE format (lifted from the SMSQ/E source documents) goes like this:

* The utility works with three different element sizes: byte, word or long
* The output consists of one byte followed by one or more elements.
* A count byte of 0..127 is followed by count + 1 elements of uncompressed data
* A count byte of 128..255 is followed by a single element, that was found to
* be repeated consecutively in the source data 257 - count times

No man is an island: I should mention that the compression format above was originally implemented for GD2 sprites by Marcel Kilgus, and Bob Spelten Jr's ideas were adopted in defining the PAC format and extension name.

While we're at it we might as well add the original PSA definition here too (This from SMSQ/E's keys/qdos_pt, originally from the QJump team):

psaPartial Save Area
* Definition of partial save area header
ptp_link equ     $00      long     user defined LINK longword
ptp_flag equ     $04      word     FLAG word
ptp.flag equ     $4afc             what you expect to find there
ptp_xsiz equ     $06      word     total X SIZe
ptp_ysiz equ     $08      word     total Y SIZe
ptp_rinc equ     $0a      word     Row INCrement
ptp_mode equ     $0c      word     MODE of saved data (normally ms byte)
ptp_bits equ     $0e
ptp.hdrl equ     $0e               HeaDeR Length

At present only my QV (QuickView) can display these files, but at least one other graphics viewer author has expressed an intention to update his viewer to support PAC files. (I wont mention any names so as not to put undue pressure on the persons involved ;o) I hope the format will be taken up by others as the advantages become apparent..

In the mean time one can use the SBASIC tool, Pac2Pic_bas, found in the GO SUB section of, to unpack PACs. (There are also an SBASIC version of the RLE-compressor, enrle_bas, and a PIC packer, Pic2Pac_bas.)

In the toolkit section, you can find a suit of commands, complete with assembler source code, that does the actual compression/decompression

So thats it, folks. If anyone has better ideas, or knows of well-established variants Im not aware of, now might be a good time to mention them, as Im about to finalise some software for public consumption that will largely rely on these extensions.