Kosinski compression

Kosinski compression is the name given by the Sonic Community to a format used in Sonic games for the Sega Genesis/Megadrive. It is named after the person who cracked it, Brett Kosinski. It appears to be an extension/variation of the LZSS algorithm.

Kosinski compression is used to compress the following data types:

Sonic the Hedgehog - 256x256 block mappings.
Sonic the Hedgehog 2 - level graphics, block mappings and level layouts.

I will call the A field the 'description' field. This is always 2 bytes in length, starting at the beginning of the compression, and is followed by the B field, which i'll call the 'data' field. This goes on for as long as necessary to cover all the data described in the 'description' section. After that, the pattern repeats until the 'end of compression' sequence is given, which i'll explain at the end.

Description Field

The 'description' field is made up of 16 bits in little endian bit (not byte) order, which means that the second byte actually comes first and they are read backward. So for example, if the description field is:

FF FE

then the description field, in bits, in the order we care about, will be:

[1111 1111] [0111 1111]

Now, starting left to right, we interpret each of the bits in the following way:

If the bit is a 1, The corresponding data object in the data field is uncompressed. This only uses 1 bit to denote.
If the bit is a 0, followed by a 1, the corresponding data object uses backreferencing. This only uses 2 bits to denote.
If the bit is a 0, followed by a 0, the corresponding data object is run-length encoded. The two bits immediately after the '00' are also used to denote how many times the RLE is copied. This uses 4 bits to denote.
If the end of compression sequence been found in a data object, ignore the rest of the description field.

Uncompressed Data

Bytes with a corresponding description of '1' indicate that the corresponding byte in the data field is already uncompressed. This only refers to a single byte. So for example, the following block of kosinski compression:

FF FF 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

simply produces the following output:

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

because all bits in the description field are 1, indicating that each byte in the data field (00 through 0F) are already uncompressed.

Run Length Encoding

Run length encoding works when '00 XX' is found in the description field. There are two parameters to the encode, the first is the number of times the data is repeated, which is encoded in the 'XX' found in the description field. This number (possible values are 0 through 3) is increased by 2 to get the number of bytes used to repeat the pattern. Therefore:

00 00 - RLE repeated for 2 bytes
00 01 - RLE repeated for 3 bytes
00 10 - RLE repeated for 4 bytes
00 11 - RLE repeated for 5 bytes

The other parameter is the data object, which is only a single byte. Rather than this byte describing the data to be repeated, it actually describes the 'previous number of bytes' to repeat, encoded as a negative number. Therefore:

Data byte FF (-1) - Repeat the last 1 byte
Data byte FE (-2) - Repeat the last 2 bytes
Data byte FD (-3) - Repeat the last 3 bytes
Data byte FC (-4) - Repeat the last 4 bytes
Data byte FB (-5) - Repeat the last 5 bytes

So for example (including the description field):

F1 FF 25 FF 01 02 03 04 05 06 07 08 09 0A 0B 0C

outputs to:

25 25 25 25 01 02 03 04 05 06 07 08 09 0A 0B 0C

because the description field

F1 FF = [1000 1111] [1111 1111]

starts with an uncompressed [1] value (25), then a RLE value repeated for 3 bytes [00 01] of FF, which means the 1 previous byte(s) .. which is 25 repeated 3 times, followed by 11 more uncompressed [1] bytes (01 through 0C).

Note: Keep in mind that the bitfield after 01 in the description field is NOT how many times the pattern is repeated, but for how many bytes the pattern is repeated. Using 11 (repeat for 5 bytes) and a value of FB (copy the last 5 bytes) only repeats the pattern once. Note that anything farther back than the last 5 bytes cannot be repeated entirely using this method because the largest number of bytes you can repeat is 5. Anything that needs to be repeated that is larger than 5 bytes should use backreferencing.

Relative Backreferencing

Backreferencing is marked with in the description field with a '01' and refers to a data object 2 or 3 bytes wide, depending on the second byte. The format of this data object is:

[LLLL LLLL] [HHHH HCCC]

or

[LLLL LLLL] [HHHH H000] [CCCC CCCC]

the second format is used when the C bits of the second byte are all unset. The values of L and H are negative.

What this type of data object means is that the output should be copied from a location x bytes back, and copied for c + 2 bytes. 9 bytes of data can be copied using the 2 byte format, and 257 bytes using the 3 byte format.

The offset to the data to be copied, x is calculated using:

x = L - (256 * (H + 1))

So for example, in:

F0 F8 40 = [1111 0000] [1111 1000] [0100 0000]

x would be -15, or 15 bytes backward since -15 - (256 * (-1 + 1)) = -15. Also in this example, the data at that offset would be repeated for 66 bytes (c+2 where c is 64 [40]).

End of Compression Sequence

The end of compression sequence is a 3-byte format backreference where L is 0, H is -1 (all bits set), and C is 0:

00 F8 00

Obviously this sequence would not come up elsewhere in the compressed data because it is literally a backreference to itself.

One Final Example


Compressed Data:

  FF 3F 54 3B C4 44 54 33 33 5B 2D 5C 44 5C C4 C5
  FC 15 FE C3 44 78 88 98 44 30 FF FF 00 F8 00

Decompression process:

  FF 3F translates to [1111 1111] [1111 1100]
  First 14 data bytes are uncompressed (1111 1111 1111 11)

      Output: 3B C4 44 54 33 33 5B 2D 5C 44 5C C4 C5

  The next object is RLE (00) but we need more description data, so we start the next chunk:
  FC 15 translates to [0011 1111] [1010 1000]

  The RLE goes for 2 bytes (00) and is copied from the previous 2 bytes (FE from data):

      Output: 3B C4 44 54 33 33 5B 2D 5C 44 5C C4 C5 C4 C5

  The next 7 data bytes are uncompressed (11 1111 1)

      Output: 3B C4 44 54 33 33 5B 2D 5C 44 5C C4 C5 C4 C5 C3 44 78 88 98 44 30

  The next data bytes are a backreference (01).  These bytes (FF FF) translate to a backreference
  of ''x = -1'' for ''c+2 = 9'' (the last 1 output byte repeated for 9 output bytes).

      Output: 3B C4 44 54 33 33 5B 2D 5C 44 5C C4 C5 C4 C5 C3 44 78 88 98 44 30
              30 30 30 30 30 30 30 30 30

  The next data bytes are also a backreference (01).  These bytes (00 F8 00) translate to an end
  of compression sequence.  The rest of the description field is ignored and the compression is
  complete.
  
      Output: 3B C4 44 54 33 33 5B 2D 5C 44 5C C4 C5 C4 C5 C3 44 78 88 98 44 30
              30 30 30 30 30 30 30 30 30

Kosinski Moduled compression

Kosinski Moduled compression (KosM compression) is a variant of standard Kosinski compression, used by Sonic 3 & Knuckles. KosM compressed data starts off with a 2-byte header. The upper nibble is the total number of modules minus 1, and the lower three nibbles are the uncompressed size of the last module in bytes (all other modules have a fixed uncompressed size of $1000 bytes). As a result, the entire header word can be read as the total uncompressed size of the data. The only special case occurs when the header is $A000, in which case the game reads it as $8000. After the header are the actual modules. Each module can be read as standard Kosinski-compressed data, and is padded out to a size which is a multiple of $10 bytes.