Oxyd .DAT file format

Written by Jeremy Sawicki (jeremy AT sawicki DOT us)
Last modified: 9-Feb-2003

This document describes the file format of the .DAT files used by the Oxyd
series of games by Dongleware.  It is based on studying the PC versions of
Oxyd 1, Oxyd Magnum, PerOxyd, and Oxyd Extra.  It is still a work in progress.
Most of the reverse engineering work was done with PerOxyd, so some of the
information may not be accurate for the other games.  Documenting the
differences between the games is one area where more work is needed.  The
remaining <specialitem> types also need to be documented, as do <goaldata>
and <marbledata>.  Work is also needed to document how the data in
<infosignal> interacts with each type of piece and object.

A note on byte order: Unless otherwise noted, all multiple-byte quantities
are stored most significant byte first.  For example, the integer 0x01020304
would be represented by the four bytes 0x01, 0x02, 0x03, 0x04 in that order.
This is opposite from the normal order used on IBM PCs.

<datfile> = <credits> <levelskip> <codes> <leveltable> <levels>
            <chunkcount> <chunktable> <chunks>

<credits>: 600 bytes
  Contains programmer names, null bytes, etc.  Probably ignored.

<levelskip>: 4 bytes = sizeof(<levelskip> <codes> <leveltable> <levels>)

<codes>: 4 bytes
  Used in Oxyd 1 to determine (somehow) the level codes.
  First two bytes for one-player levels, next two for two-player levels.

<leveltable>: 400 bytes = sizeof(<level>1) sizeof(<level>2) ...
                          sizeof(<level>200)
  Each size is represented by two bytes

<levels> = <encodedlevel>1 <encodedlevel>2 ... <encodedlevel>200
  Single player levels: 1 to 100.  Two-player levels: 101 to 200.

<encodedlevel> = a <level> with each byte transformed according to a
  16-byte repeating pattern.  Bytes are transformed as follows:

  <encodedlevelbyte>n = (<levelbyte>n + pattern[n % 16]) % 256
  <levelbyte>n = (<encodedlevelbyte>n - pattern[n % 16]) % 256

  For Oxyd 1, Oxyd Magnum, and Oxyd Extra the pattern is
    0x45, 0x23, 0xEA, 0xB9, 0x11, 0xF1, 0x9F, 0x5A,
    0x33, 0x3E, 0x0F, 0xB4, 0x41, 0x56, 0xAF, 0xAA
  For PerOxyd the pattern is
    0xAA, 0xE1, 0x82, 0x34, 0xAF, 0x24, 0x72, 0x42,
    0x37, 0x3E, 0x83, 0x98, 0x22, 0xFF, 0x2F, 0x31

<level> = <info> <info> ... <info>
  Each level contains several distinct types of information.
  One <info> block of each type is included.  <infoend> must be last,
  and <infogeneral> must come before <infosurfaces>, <infopieces>, and
  <infoobjects>.  Otherwise, order is not important.

  If the Oxyd version has fewer than 200 levels, an unused <level> can
  also be zero bytes long.  Oxyd Magnum has 100 levels, and Oxyd Extra
  has 30 levels.  But unused levels are not required to be zero bytes
  long.  In Oxyd Magnum, several of the unused levels are present.

<info> = <infosurfaces> | <infogeneral> | <infosignal> | <infoend> |
         <infopieces> | <infospecial> | <infoobjects>

<infosurfaces> = 0x0000 sizeof(<datasurfaces>) <datasurfaces>
<infogeneral>  = 0x0001 <datageneral>
<infosignal>   = 0x0002 sizeof(<datasignal>) <datasignal>
<infoend>      = 0x0003
<infopieces>   = 0x0004 sizeof(<datapieces>) <datapieces>
<infospecial>  = 0x0005 sizeof(<dataspecial>) <dataspecial>
<infoobjects>  = 0x0006 sizeof(<dataobjects>) <dataobjects>
  All sizes are stored using 2 bytes.

<datasurfaces> = <compressedgrid>
  Represents the "surfaces": brick, ice, abyss, space, etc.

<datapieces> = <compressedgrid>
  Represents the "pieces": walls, puzzle pieces, doors, movable planks,
  etc.

<dataobjects> = <compressedgrid>
  Represents the "objects": coins, hammers, bumps, springboards, etc.

<datageneral>: 68 bytes = <gridwidth> <gridheight> <marblelocation>0
                           <marblelocation>1 ... <marblelocation>7
  Stores the level grid dimensions and the marble starting locations

<gridwidth>: 2 bytes
  Width of the level grid, in blocks
<gridheight>: 2 bytes
  Height of the level grid, in blocks

<marblelocation>n = <marblexcoord> 0x00 0x00 <marbleycoord> 0x00 0x00
<marblexcoord>: 2 bytes
  X coordinate of marble starting location, in pixels
<marbleycoord>: 2 bytes
  Y coordinate of marble starting location, in pixels

<datasignal> = [<signalitem> ...] 0xFFFF
  Determines which items in the grid send signals to which others.
  For instance, signals can be used to create buttons that open and
  close doors, coin slots that operate lasers, etc.  There are also
  less obvious uses of signals.  For instance, when a marble enters
  a hole, the location where it reappears is determined by a signal.

<signalitem> = <signallocation> <recipientcount>
               <signallocation> [<signallocation> ...]
  A <signalitem> represents signal connections between one sender and
  one or more recipients.  The first <signallocation> is the sender.
  The remaining <signallocation>s are the recipients.  The number of
  recipients is specified by <recipientcount>.  <recipientcount> is
  2 bytes.

<signallocation>: 2 bytes
  A <signallocation> represents an item in the grid that sends or receives
  a signal.  Bits 15 and 14 are always 0.  Bit 13 is 0 if the item is a
  piece, and 1 if it is an object.  Bits 12 through 0 represent the block
  number of the item.  (In practice, bit 12 is always 0, so it may not be
  part of the block number.)

<dataspecial> = <specialitem> [(0x20 <specialitem>) ...] 0x00
  Stores such things as what marbles are present in the level,
  the text of any notes, the presence of rubber bands, etc.

<specialitem> = <goal> | <harmlessmeditation> | <marble> |
                <rubberband> | <rubberbandobject> |
                <requiremagicpiece> |
                <scrolling> |
                <reset> |
                <walkthroughpuzzle> |
                <force> |
                <scramble> |
                <laser> |
                <oscillator> | <stilloscillator> |
                <note>
  There are additional types of <specialitem> that I haven't figured out yet.

<goal> = 'G' <goalcode> [<goaldata>]
  Indicates the goal of the level.

<goalcode> = <goalcodeoxyd> | <goalcodemeditation>
<goalcodeoxyd> = 'N'
<goalcodemeditation> = 'M'
  If the <goalcode> is <goalcodeoxyd>, the goal of the level is to open oxyds
  (a normal level).  If it is <goalcodemeditation>, tho goal is to put marbles
  in pits (a meditation level).  If no <goal> item is present in a level, it
  defaults to a normal level.

<goaldata>
  I don't know what this is yet.

<harmlessmeditation> = 'n'
  If present, the black marble can safely come into contact with meditation
  marbles.  If absent, the black marble shatters when it touches a meditation
  marble.  (It seems white marbles can always safely touch meditation marbles.)
  The <harmlessmeditation> item should come immediately before the <marble>
  items.

<marble> = 'F' <marblecode> [<marbledata>]

<marblecode> = <marblecodeblack> | <marblecodewhite> |
               <marblecodemeditation> |
               <marblecodehorse> | <marblecodejack> |
               <marblecodelifespitter> | <marblecodedynamiteholder>
<marblecodeblack> = 'B'
<marblecodewhite> = 'b'
<marblecodemeditation> = 'M'
<marblecodehorse> = 'G'
<marblecodejack> = 'K'
<marblecodelifespitter> = 'C'
<marblecodedynamiteholder> = 'D'
  A "life spitter marble" must be present in levels containing life spitter
  pieces (0x94), and a "dynamite holder marble" must be present in levels
  containing dynamite holder pieces (0x95), otherwise those pieces don't
  function.  Presumably these so-called marbles are used to implement the
  animations associated with those pieces.

<marbledata>
  Still have to figure this stuff out.

<rubberband> = 'B' <numberlist>1 [0xF9 <numberlist>2] [0xF8]
  The first number in <numberlist>1 is the natural length of the rubber band
  in pixels.  When it is shorter than the natural length, it supplies no
  force.

  The second number in <numberlist>1 controls the amount of force
  supplied by the rubber band.  A value of 0 means no force; the largest
  observed value is 4000.

  The third number in <numberlist>1 is the block number that one end of the
  rubber band connects to.

  <numberlist>2 contains up to two values, which are marble numbers that
  the rubber band connects to.

  The above values can be combined in different ways to represent different
  kinds of rubber bands.

  To represent a rubber band between two marbles, both marble numbers are
  present the block number is empty.  The natural length and force are also
  present.

  To represent a rubber band between a piece and a marble, the block number
  is present, the first marble number may be present or absent (but not
  empty), and the second marble number is absent.  The natural length and
  force are also present.  The first marble number is only absent in levels
  containing a single marble, in which case it is clear which marble the
  rubber band is attached to.  If the first marble number is absent, the
  0xF9 byte is still present.

  The remaining type of rubber band description does not refer to a rubber
  band that is present when the level begins, but rather it describes the
  properties of rubber bands that appear later.  A level can contain up to
  three rubber band descriptions of this type.  The first describes rubber
  bands created when a black marble touches a rubber band piece.  The
  second describes rubber bands created when a white marble touches a
  rubber band piece.  The third describes rubber bands created when a
  rubber band object is activated.  The rubber band description may contain
  only the letter 'B' with no further information, which is used if the
  level doesn't contain a particular type of rubber band.  Otherwise, the
  natural length and force are present, the block number is absent or
  empty, the 0xF9 byte may or may not be present, and both marble numbers
  are absent.

  The 0xF8 byte is rarely present.  It only occurs once after a rubber
  band between a piece and a marble, and once after a <marblelist>1
  with the third number empty and no 0xF9 byte or <marblelist>2.  The
  meaning of the 0xF8 byte, if any, is not known.

<rubberbandobject> = 'N' <numberlist>
  When a marble activates a rubber band object, the other marble that it
  becomes attached to is determined by the <rubberbandobject> item.  The
  <numberlist> contains two numbers, both always present.  The first number
  is the marble number that a black marble will become attached to, and the
  second is the marble number that a white marble will become attached to.
  If the level contains no <rubberbandobject> item, the default behavior is
  'N(1)(0)' -- in other words, a black marble becomes attached to marble 1
  and a white marble becomes attached to marble 0.

<requiremagicpiece> = '!'
  Magic piece 0x3B is always present when the user restarts the level.
  The magic piece reappears regardless of whether or not the level is
  completely reset, though it does not reappear when the level restarts
  due to the marble being shattered.

<scrolling> = 'f'
  The board scrolls freely (rather than one screen at a time).

<reset> = 's'
  The level completely resets when the marble dies.

<walkthroughpuzzle> = 'j'
  Changes the behavior of piece 0x5C.  If <walkthroughpuzzle> is present,
  the piece is a puzzle piece with connections in all four directions that
  marbles can walk under.  Otherwise, the piece is a stand-alone movable
  piece with no puzzle piece graphics.  Strangely, in every level that
  includes piece 0x5C, <walkthroughpuzzle> is present.

<force> = 'g' <numberlist>
  The number list can contain up to 3 numbers.

  The first number determines the amount of force supplied by certain
  force-supplying surface types, specifically those that don't look sloped.
  The number can be between 0 (no force) and 1000 (very large force).
  If the number is absent, a default amount of force somewhere between
  0 and 45 is used.

  Surface types affected by the first number:
  0x1B, 0x21, 0x22, 0x2F, 0x30, 0x31, 0x32, 0x4F, 0x50, 0x51, 0x52

  The second number determines the amount of friction on certain surface
  types.  The number can be between 0 and 999.  A value of 0 means
  infinite friction.

  Surface types affected by the second number:
  0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x23, 0x24, 0x25, 0x26, 0x27,
  0x28, 0x29, 0x2A, 0x2B, 0x2C, 0x2D, 0x2E, 0x2F, 0x30, 0x31, 0x32, 0x4C,
  0x4D, 0x4E, 0x4F, 0x50, 0x51, 0x52, 0x57, 0x58, 0x59, 0x5A

  The third number determines the amount of force supplied by certain
  force-supplying surface types, specifically those that look sloped.
  The number can be between 0 (no force) and some unknown upper limit.
  The two actual values used are 10 and 70.

  Surface types affected by the third number:
  0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2A, 0x2B, 0x2C, 0x2D, 0x2E

<scramble> = 'P' <numberlist>
  This describes the scrambling that should be applied to puzzle pieces in
  the level.  The number list is grouped into pairs of numbers.  The first
  number in each pair is a block number, and the second number is a value
  between 0 and 3 (inclusive), representing one of the four directions on
  the screen (0 = up, 1 = down, 2 = left, 3 = right).  Each pair determines
  a row or column of puzzle pieces that will be rotated during the
  scrambling.  The row or column begins at the specified block number and
  extends in the specified direction.  The scrambling process basically
  consists of rotating the various rows and columns of puzzle pieces by
  random amounts.  The exact details of the process are not known.

<laser> = 'L' <numberlist> [0xF9 | 0xF8]
  The <numberlist> contains two numbers.  The first is a laser type number,
  from 1 to 3.  The three laser types correspond to the bytes 0x3E, 0x3F,
  and 0x40 in the piece grid.  The second number is a direction number
  (0 = up, 1 = down, 2 = left, 3 = right) that indicates which direction
  lasers of the specified type point.  If the final optional byte is 0xF9,
  lasers of the specified type are initially on.  If it is 0xF8 or not
  present, they are initially off.  At most one <laser> item is present for
  each laser type.  If no <laser> item is present for a given laser type,
  lasers of that type are initially off, and they point in a default
  direction based on type (type 1 = up, type 2 = down, type 3 = right).

<oscillator> = '~' <numberlist>
  The <numberlist> contains two numbers.  The first is the block number
  of an oscillator piece.  The second is a value between 1 and 15 that
  indicates the period of the oscillator.  The period p is approximately
  (n + 1) * 0.678 seconds, where n is the second number in the number list.
  The oscillator sends an "on" signal and an "off" signal every period,
  evenly spaced.  If a level contains an oscillator piece with no
  corresponding <oscillator> item, the oscillator behaves as though the
  second number is 0.  If a level contains more than one <oscillator>
  item for a given oscillator piece, the last one takes precedence.

<stilloscillator> = 'O' <numberlist>
  The number list contains a single number, the block number of an
  oscillator piece.  If a <stilloscillator> item is present for an
  oscillator, the oscillator is initially inactive, otherwise it is
  initially active.

<note> = <notecode> <langagecode> '"' <notetext> '"'

<notecode> = <notecode1> | <notecode2>
<notecode1> = 'Z'
<notecode2> = 'z'

<languagecode> = <languagecodegerman> | <languagecodeenglish> |
                 <languagecodefrench>
<languagecodegerman> = 'g'
<languagecodeenglish> = 'e'
<languagecodefrench> = 'f'

<notetext>
  The note text may contain space characters (0x20).

<numberlist> = [<parenthesizednumber> ...]
<parenthesizednumber> = '(' [<number>] ')'
<number>
  A <number> is a non-negative integer represented in base 10 using the
  ASCII characters '0' through '9'.

<compressedgrid> = <griditem> ...
  A <compressedgrid> is a compressed representation of a two-dimensional
  grid of <gridbyte>s.  Each <griditem> represents a sequence of one or
  more <gridbyte>s.  The concatenation of the sequences forms one long
  sequence that represents the contents of the grid from top to bottom,
  left to right.  (It seems to be necessary to parse a <compressedgrid>
  by starting at the end and working backwards.  That could explain why
  a few things are stored least significant byte first in a
  <compressedgrid>.)

<gridbyte>: 1 byte
  Each <gridbyte> in interpreted as a particular type of surface, piece,
  or object, depending on what type of grid it appears in.  The various
  <gridbyte> values are documented in grid-bytes.txt.

<griditem> = <griduncompressed> | <gridrepeatlong> |
             <gridrepeatshort> | <gridpattern>

<griduncompressed> = <gridbyte>
  The <gridbyte> represents itself literally.  Just about any byte can
  be represented this way, but definitely not 0xFD, 0xFE, or 0xFF, since
  they will be interpreted as a compressed <griditem> during parsing.

<gridrepeatlong> = <count> <gridbyte> 0xFF
  This is equivalent to repeating <gridbyte> <count>+1 times.
  <count> is 2 bytes.  It is stored LEAST significant byte first.

<gridrepeatshort> = <count> <gridbyte> 0xFD
  This is equivalent to repeating <gridbyte> <count>+1 times.
  <count> is 1 byte.

<gridpattern> = <bitpattern> <count> <gridbyte>1 <gridbyte>0 0xFE
  This is equivalent to a sequence of <count>+1 <gridbyte>s, each
  of which is either <gridbyte>1 or <gridbyte>0 as determined by
  <bitpattern>.  <bitpattern> contains ceil[(<count>+1) / 8] bytes.
  These bytes can be interpreted as a single integer, LEAST significant
  byte first.  When it contains more than <count>+1 bits, the most
  significant extra bits are ignored.  Of the remaining bits, the most
  significant corresponds to the first <gridbyte> and the least
  significant corresponds to the last <gridbyte>.  <count> is 1 byte.

<chunkcount>: 2 bytes = the number of chunks
  The remainder of the .DAT file after the levels is made up of a
  series of "chunks."  A chunk can contain audio, graphics, or
  perhaps other things.

<chunktable> = <encodedchunktableentry>1 ... <encodedchunktableentry>n
  There is one <encodedchunktableentry> for every <chunk> in the .DAT file.

<encodedchunktableentry>: 24 bytes
  An <encodedchunktableentry> is a <chunktableentry> with all of the bits
  inverted, and with a transformation applied to each group of four bytes.
  The transformation is a rotation by three bits.  To encode, the value is
  shifted right by three bits, with the three least significant bits becoming
  the new most significant bits.  To decode, reverse the process.

<chunktableentry>: 24 bytes = <compressedsize> <uncompressedsize> <offset>
                              <chunkname>

<compressedsize>: 4 bytes
  The number of bytes occupied by the chunk in the file.

<uncompressedsize>: 4 bytes
  Some chunks use a type of compression.  For compressed chunks, this
  is the size of the chunk when uncompressed.  For chunks that are stored
  uncompressed, <uncompressedsize> is the same as <compressedsize>.

<offset>: 4 bytes
  The offset from <chunkcount> to the beginning of the chunk.

<chunkname>: 12 bytes
  This is the name of the chunk.  It is a string of up to 12 characters.
  Any unused bytes past the end of the string are nulls (0x00).  The names
  appear to be DOS filenames with a base name of up to 8 characters followed
  by a dot and a 3 character extension.  The extension is .PIB for bitmaps,
  .SDD for audio, and .SIB for some other type of information (font data?).

<chunks> = <chunk>1 ... <chunk>n

<chunk> = <compressedchunk> | <uncompressedchunk>
  If the chunk's <compressedsize> and <uncompressedsize> differ, the chunk
  is a <compressedchunk>, otherwise it is an <uncompressedchunk>.

<compressedchunk> = <compressionentry> ...
  A <compressedchunk> is a stream of bytes which stands for another longer
  stream of bytes, an <uncompressedchunk>.

<compressionentry> = <compressionkey> <compressiondata>0 ... <compressiondata>7
  The <compressionkey> is 1 byte, where bit n determines the interpretation of
  <compressiondata>n.  The last <compressionentry> may contain anywhere between
  1 and 8 <compressiondata> items.  Unused <compressionkey> bits in the last
  <compressionentry> are 0.

<compressiondata> = <compressionliteral> | <compressioncopy>
  If the corresponding <compressionkey> bit is 1, <compressiondata> is a
  <compressionliteral>, otherwise it is a <compressioncopy>.

<compressionliteral>: 1 byte
  This byte is interpreted as the same byte uncompressed.

<compressioncopy>: 2 bytes
  This is made up of a 4-bit <count> and a 12-bit <offset>.  Bits 3 to 0
  of the second byte are the <count>.  Bits 7 to 4 of the second byte are
  bits 11 to 8 of the <offset>, and bits 7 to 0 of the first byte are bits
  7 to 0 of the <offset>.

  The interpretation of <compressioncopy> is that <count>+3 bytes should
  be copied to the uncompressed stream from somewhere earlier in the
  uncompressed stream.  The location to start copying from is the largest
  location before the current location that is congruent to <offset> + 0x12
  (modulo 0x1000).

  If the copy starts before the beginning of the stream, any bytes before
  the beginning of the stream are assumed to be 0x20.  The copy never starts
  more than <count>+3 bytes before the beginning of the stream.  (The byte
  value 0x20 seems a strange choice.  Perhaps this compression method was
  originally used for text, since 0x20 is the space character in ASCII.)

  If the copy starts fewer than <count>+3 bytes before the current stream
  location, the bytes should be copied from lowest to highest location, so
  that by the time a byte needs to be copied from after the current stream
  location, it will have already been written by copying an earlier byte.

<uncompressedchunk> = <audio> | <bitmap> | something else?

<audio>
  This is raw audio data.  It is 6289 samples per second, 8-bit, mono,
  PCM, signed.

<bitmap> = <bitdepth> <bitplanesize>0 ... <bitplanesize>n-1 <blocksize>
           <palette> <bitplane>0 ... <bitplane>n-1
  This represents a 640x400 bitmap, with either 2 or 16 colors.  The bitmap
  is divided into 16x16 pixel blocks.  It is stored compressed.

<bitdepth>: 2 bytes
  The number of bits used to represent each pixel, stored LEAST significant
  byte first.  In practice the value is always 0x0001 or 0x0004.  The bitmap
  contains this many <bitplane>s.

<bitplanesize>n: 2 bytes = sizeof(<bitplane>n)
  Stored LEAST significant byte first.

<blocksize>: 2 bytes
  This value is always 0x0010, stored LEAST significant byte first.  I don't
  really know what the value means, but it may be the block size.

<palette> = <color>0 <color>1 ... <color>15
  Determines the palette of RGB color values corresponding to the color
  index values used in the bitmap.  The <palette> always contains space for
  16 colors, even in a 2-color bitmap.  Sometimes all colors are black (all
  bytes in the <palette> are 0x00).  In that case, the software must be
  using the palette from a different bitmap (which makes sense because
  multiple bitmaps can be on the screen at once).

<color> = <component> <component> <component>
  The three <component>s represent red, green, and blue, in that order.

<component>: 2 bytes
  The value from 0x0000 to 0xFFFF determines the amount of red, green, or
  blue in the color.  Stored LEAST significant byte first.

<bitplane> = 'IBM16COL' <bitplanedata> [<blockcopies>]
  A <bitplane> represents 1-bit graphics data.  Specifically,
  it is a 640x400 grid of 0's and 1's.  The grid is broken into
  16x16 pixel blocks for compression purposes.

<bitplanedata> = <bitplanedatasize> <pixelwidth> <pixelheight>
                 <blockwidth> <blockheight> <bitstreamsize> <bytestreamsize>
                 <invert>0 <invert>1 <blockcopyflag> <bitplaneunused>
                 <bitstream> <bytestream>

<bitplanedatasize>: 4 bytes = sizeof(<bitplanedata>)

<pixelwidth>: 2 bytes
  Width of the bitmap in pixels.  Always 640 (0x0280).

<pixelheight>: 2 bytes
  Height of the bitmap in pixels.  Always 400 (0x0190).

<blockwidth>: 2 bytes
  Width of the bitmap in 16x16 blocks.  Always 40 (0x0028).

<blockheight>: 2 bytes
  Height of the bitmap in 16x16 blocks.  Always 25 (0x0019).

<bitstreamsize>: 4 bytes = sizeof(<bitstream>)

<bytestreamsize>: 4 bytes = sizeof(<bytestream>)

<invert>n: 1 byte
  The bits in a bit plane are sometimes stored inverted.  <invert>0
  and <invert>1 determine the status of the bits in the even-numbered
  and odd-numbered rows, respectively.  A value of 0x00 indicates that
  the bits are not inverted, and a value of 0xFF indicates that they
  are.  Inverting means that after decoding, all 0s should be replaced
  by 1s and vice versa.

<blockcopyflag>: 2 bytes
  In Oxyd Magnum, PerOxyd, and Oxyd Extra, the value is either 0x0000 or
  0xDEAD.  If it is 0xDEAD, the bitmap has a <blockcopies> section.
  In Oxyd 1, <blockcopyflag> is filled with various values, similar to
  <bitplaneunused>.  Oxyd 1 does not support <blockcopies>.

<bitplaneunused>: 8 bytes
  These bytes seem to be ignored.  In Oxyd 1 they are filled with various
  values.  In Oxyd Magnum they are all 0x00.  In PerOxyd and Oxyd Extra
  they are all 0x00 except for the last two bytes.

<bitstream> = <row> <row> ... <row>
  This is interpreted as a sequence of bits, with the most significant bit
  in each byte coming first.  The <bitstream> describes how to decompress
  the bitmap, one row of blocks at a time, and within each row, one block
  at a time.  Certain items in the <bitstream> require extra bytes of data,
  which are taken from the <bytestream> in order.

<bytestream>
  These bytes are interpreted according to the <bitstream>.

<row> = <rowskip> | <normalrow>
  Each <row> describes the contents of a single row of blocks in the bitmap.

<rowskip> = 0
  No data is stored for the row.  All pixel locations have a value of 0
  by default, though individual blocks might be overridden by information
  in <blockcopies>.  (In practice I don't think blocks in a <rowskip>
  row are ever replaced by <blockcopies>, so that may or may not be legal.)

<normalrow> = 1 <block> <block> ... <block>
  This indicates that information is stored about each block in the row,
  from left to right.

<block> = <blockskip> | <blockuncompressed> | <blockcompressed>
  A <block> is a representation of a 16x16 block of pixels.  The block
  is conceptually divided into four 8x8 quadrants.  The order of the
  quadrants is upper left, upper right, lower left, lower right.  The
  block is also conceptually divided into 32 horizontal rows of eight
  pixels.  Eight rows fall in each quadrant.

<blockskip> = 0
  No data is stored about the block.  All pixel locations in the block have a
  value of 0 by default, though this may be overridden by information in
  <blockcopies>.

<blockuncompressed> = 1 1 1
  The block is stored uncompressed.  The next 32 bytes in the <bytestream>
  determine the bits of the 32 horizontal rows of eight pixels.  The rows
  are in the following order: first the upper left row, then the upper
  right row, then the row immediately below the upper left row, then the
  row immediately below the upper right row, etc.  The bits from most to
  least significant determine the pixels from left to right.

<blockcompressed> = 1 <compressiontype> <quadrantskip>
  The block is stored compressed.  The compressed data stands for an
  intermediate 16x16 block of bits.  The translation from those intermediate
  bits to the real 16x16 block of pixels depends on the <compressiontype>.

  For each quadrant in order, the corresponding <quadrantskip> bit
  determines whether any information is stored for the quadrant.  If the
  bit is 0, the entire quadrant is made up of 0 bits.  If the bit is 1,
  the next <bytestream> byte is a quadrant header byte.  The bits in the
  quadrant header byte from most to least significant determine whether
  any information is stored for the rows of eight bits in the quadrant,
  from top to bottom.  If a bit is 0, all eight bits are 0.  Otherwise,
  another byte in the <bytestream> determines the bits.  The bits from
  most to least significant determine the pixels from left to right.

<quadrantskip>: 4 bits
  The four bits correspond to the four 8x8 quadrants of the block in the
  following order: upper left, upper right, lower left, lower right.

<compressiontype> = <exact> | <xor1> | <xor2>

<exact> = 0 0
  The pixels in the intermediate 16x16 block are the same as those in the
  real 16x16 block.

<xor1> = 0 1
  Each bit in the real 16x16 block is the exclusive or of the same bit
  in the intermediate 16x16 block and the bit one pixel above it in the
  real 16x16 block.  Bits above the top of the block are assumed to be 0.

<xor2> = 1 0
  Each bit in the real 16x16 block is the exclusive or of the same bit
  in the intermediate 16x16 block and the bit two pixels above it in the
  real 16x16 block.  Bits above the top of the block are assumed to be 0.

<blockcopies> = [<blockcopy> ...] 0xFF 0xFF
  If present (as determined by <blockcopyflag>), <blockcopies> indicates
  that certain source blocks should be copied to one or more destination
  blocks (that were skipped with <blockskip> or possibly <rowskip>), as
  an efficient way of encoding blocks that occur more than once.

<blockcopy> = <blockcopysource> <blockcopydest> [<blockcopydest> ...]
              0xFF 0xFF

<blockcopysource> = <blockcopycoord>
  The source block.
<blockcopydest> = <blockcopycoord>
  One of the destination blocks.

<blockcopycoord> = <blockcopyx> <blockcopyy>

<blockcopyx>: 1 byte
<blockcopyy>: 1 byte
  These represent the X and Y coordinates, respectively, of a source or
  destination block.