CD Actual 14/CDACTUAL.iso/cdactual/demobin/share/program/Basic/SDA30.ZIP/IMAGE.DOC

Text File | 1985-01-25 | 5.4 KB | 111 lines

                   SDA Compressed Image Format


    The binary "image" file produced by the Screen Design Aid
(SDA) is actually a quite primitive format.  It is easiest to
think of the image as being composed of two parts:  The field
definitions, and the screen body.  The following paragraphs
defined the precise format of these two parts, which are actually
concatenated to form one contiguous, variable length file.

Field Definition Part:

    The first word (normal LSB, MSB sequence in memory), contains
a count of the number of fields defined in this image.  The
remainder of this part is composed of four bytes entries, one per
defined field, where the four bytes contain the following
information:

    Byte 1:  Contains the binary screen row (top = 0).
    Byte 2:  Contains the binary screen column (left most = 0).
    Byte 3:  Contains the length of the field in binary.
    Byte 4:  Contains the display attribute of the field.

These four bytes repeat as many times as necessary to define each
of the fields specified for the screen.

Screen Body:

    Immediately following the field table part, the next word of
the image contains the binary length of the screen body part,
including this word itself.  The remaining bytes of the body
should be considered a "stream" of bytes.  When the compressed
image is formed, a "scan ahead" function is used.  If more than
three screen positions are found to contain identical characters
AND attributes, then these duplicate characters are discarded and
a special code is inserted in the image.  Similarly, when a
change of attribute is noted, a code is inserted in the image.

    To decode the image is straight forward.  Simply load the
"next" byte of the image.  If this byte is a hex 0FFH, the
following byte is the new attribute, and will remain in effect
until another 0FFH flag is encountered.  If this byte is zero,
then the following byte is a "repeat count" (number of
repetitions of the next data character and attribute to be
output).  If the byte loaded is any other value, it is a "data"
byte, and should be output using the current repeat count and the
current attribute.  By setting the "repeat count" to one
initially, and by re-setting it to one after each output
operation, the image will be correctly expanded and displayed.

    When all of the "stream" bytes have been processed, you will
have filled the full display screen, and the expand operation is
complete.


    To further clarify this expansion process, the following
series of steps are provided.

    1.  Load the count of fields.
    2.  Multiply the count by four, and then add two.
    3.  Use the value computed as an offset into the image and
load the word at this offset.  This word is the length of the
body of the image INCLUDING THIS WORD.  
    4.  Subtract two from this length, giving the number of bytes
in the compressed image.  This value should be saved, and
decremented each time a byte is loaded from the image.  The
completion test is therefore a simple check to see if this count
is zero.  Set the repeat count equal to one.
    5.  If complete, go to end.
    6.  Load the "next" byte, decrementing the count
    7.  If the byte is 0FFH then load the next byte, decrementing
the count.  Save the loaded byte as the "current attribute".  Go
to step 5.
    8.  If the byte is zero, then load the next byte,
decrementing the count, and save this byte as the "repeat count".
Go to step 5.
    9.  For any other value, save the loaded byte as the "data"
byte, and output this byte using the current attribute, as many
times as the required by the "repeat count".
    10. Set the repeat count = 1.
    11. Go to step 5.

    It should be obvious that the first byte encountered in the
compressed image is always a 0FFH, since the first function
required is that of loading a "current attribute". 

    It is probably equally obvious that any character can be
displayed, except 0 and 255.  These two characters are reserved
to act as flags.  Neither character can be generated by SDA
during screen design.  Since only one byte is available for the
"repeat count", no repeat count greater than 255 is allowed.
Since this value will always follow a zero byte when used as a
repeat count, no confusion with the attribute flag exists.  If a
character and attribute repeats more than 255 times (this is not
uncommon in screens that are primarily blank), then the maximum
count is set, and the character to be duplicated is inserted.
This sequence is immediately followed by another "repeat count"
flag, another repeat count, and the character to be duplicated.
This repetitive pattern is repeated until a change of character
or attribute is finally encountered, or until the "end of screen"
is found.  It is slightly interesting to note that an all blank
image requires approximately 26 bytes in compressed form.  This
represents 4000 bytes in expanded form.  It is easy to see how
compression can pay signficant storage dividends.

    The use of the "repeat count" has a hidden advantage.  BIOS
does provide a call that permits outputing a character and
attribute, "count times".  The form used for this compression
exactly parallels this BIOS call, providing considerably greater
speed than 2000 single character output calls to BIOS.