164 lines
6.0 KiB
Plaintext
164 lines
6.0 KiB
Plaintext
|
|
PGC Portfolio Graphics Compressed File Specification
|
|
----------------------------------------------------
|
|
by Don Messerli, Software Vineyard
|
|
Revision 01 1/4/91
|
|
|
|
Introduction
|
|
------------
|
|
|
|
The PGC spec allows graphic files on the Portfolio (formerly called
|
|
PGF files) to be compressed to save disk (RAM Card) space. We
|
|
all know how much RAM cards cost!
|
|
|
|
A little background
|
|
-------------------
|
|
|
|
The Portfolio's screen is 240 x 64 pixels when in graphics mode.
|
|
Being monochome, it only takes 1 bit to represent a single pixel.
|
|
Therefore, 8 pixels per byte. A PGF ends up being 64 rows of
|
|
30 bytes each for a total of 1920 bytes. PGF files could simply
|
|
be copied from video ram to disk and vice-versa.
|
|
|
|
This was pretty simple. All PGF files were 1920 bytes no matter
|
|
how complex the picture. A real space waster in most cases.
|
|
Compression became a logical next step.
|
|
|
|
What will compression do?
|
|
-------------------------
|
|
|
|
Compression can save quite a bit of space. Typically from 20
|
|
to 80% depending on the file. However, because of the compression
|
|
algorithm I have chosen, it is also possible for a file to become
|
|
larger. This happens with files that have a lot of random dots
|
|
on the screen with little repetition. Digitized photos are the
|
|
culprits. Fortunately, because of the small size of the Portfolio
|
|
screen, we probably won't be seeing too many of them.
|
|
|
|
PGC File Format
|
|
---------------
|
|
|
|
Header - The first 3 bytes of the file are the PGC header. This
|
|
is the only way to tell if the file is a PGC file or
|
|
not. This should always be checked when reading PGC
|
|
files. Your decoder routines could take a quick trip
|
|
into never-never land if you try to decode a spreadsheet
|
|
file.
|
|
|
|
The three bytes that make up the header are the ASCII
|
|
codes for 'P' and 'G' followed by the revision number
|
|
in hex. These three bytes should be:
|
|
|
|
"\x50\x47\x01"
|
|
P G 01
|
|
|
|
Data - The picture data is made up of repeating sets of single
|
|
index bytes followed by data bytes. The index byte
|
|
tells the decoder how to handle the data that follows.
|
|
The key is whether the high bit (\x80) is set or not.
|
|
The maximum number of data bytes following an index
|
|
byte is 127.
|
|
|
|
High Bit Set
|
|
------------
|
|
If the high bit is set, it indicates that the data is
|
|
a string of identical bytes. The low 7 bits indicate
|
|
how many times to repeat the following byte (maximum is
|
|
127).
|
|
|
|
Example: 86 FF
|
|
index data byte
|
|
|
|
High bit of index byte is set, low 7 bits = 6.
|
|
Repeat data byte (FF) 6 times.
|
|
|
|
High Bit Not Set
|
|
----------------
|
|
If the high bit is NOT set, it indicates that the data
|
|
following is a string of unique bytes and should be copied
|
|
as is. The low 7 bits indicate how many bytes to copy (max
|
|
is 127).
|
|
|
|
Example: 0A FF 01 10 09 1A BB CE D0 FF 1A
|
|
index data bytes
|
|
|
|
High bit of index byte is NOT set, low 7 bits = 10.
|
|
Copy next 10 bytes as is.
|
|
|
|
|
|
Where do we go from here?
|
|
-------------------------
|
|
|
|
Writing a decoder is fairly straightforward. The following is
|
|
the general algorithm:
|
|
|
|
do {
|
|
get a byte from PGC image
|
|
if high bit is set
|
|
index = byte - 128
|
|
get data byte
|
|
write data byte, index times
|
|
else
|
|
index = byte
|
|
copy next index # of bytes
|
|
} while less than 1920 bytes written
|
|
|
|
Writing an efficient compressor is a little more difficult. I
|
|
plan to upload a library of functions in the near future. If
|
|
you encounter difficulty writing a compressor, please contact
|
|
me via electronic mail.
|
|
|
|
|
|
What are these other files?
|
|
---------------------------
|
|
I have included a few PGF files to give your compressors and
|
|
decoders a real workout.
|
|
|
|
BEST.PGF - This is a pure black image. It should compress down
|
|
to 35 bytes.
|
|
|
|
WORST.PGF - This image is made up of runs of 2 identical bytes
|
|
alternated with single unique bytes. It should end
|
|
up being larger as a PGC file (2524 bytes) than as
|
|
a PGF file (1920 bytes). All decoders should be able
|
|
to handle this file.
|
|
|
|
|
|
In Closing
|
|
----------
|
|
|
|
I hope this information is helpful for those writing graphics
|
|
applications for the Portfolio. It is my sincere wish that the
|
|
PGC format is widely supported in the Portfolio arena and that
|
|
it promotes compatibility between graphics applications on the
|
|
Portfolio. My sincere thanks to BJ Gleason for including PGC
|
|
support in PBASIC. That is a major step in making my wish come
|
|
true.
|
|
|
|
Please support the PGC format whenever possible. If your application
|
|
must output PGF files, because you're trying to write the world's
|
|
smallest TSR (or something) and you can't commit to the overhead
|
|
required by a compressor, that is unavoidable. The PGF files can
|
|
later be compressed with PGCOMP (my compressor). It is still preferable
|
|
to store files that end up larger as PGC files as PGC files anyway.
|
|
This means software only has to worry about reading the PGC
|
|
format.
|
|
|
|
Versions of PGEDIT greater than 1.10 will read either PGF or PGC files.
|
|
However, they will only save in PGC format. BJ Gleason has indicated
|
|
that PBASIC 3.1 will only read and write PGC files.
|
|
|
|
If you have any questions, comments, or kind words, please send
|
|
me electronic mail:
|
|
|
|
Don Messerli
|
|
Compuserve 72500,1671
|
|
GEnie DMESS
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|