Software tile decompression

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
mic_
Posts: 917
Joined: Thu Oct 05, 2006 6:29 am

Software tile decompression

Post by mic_ » Wed Nov 25, 2009 10:05 am

I've added a decoder for the SNES to my tile compression package: http://jiggawatt.org/badc0de/sixpack/.

The algorithm used is LZSS so it's not exactly optimal, but it can achieve decent compression. The decoder is currently not as flexible as the Master System version I wrote earlier - it lacks the ability to decode tiles where unused bitplanes have been removed for example.

The decoder uses about 4kB of RAM starting at $7F0000 + 16 bytes of DP RAM starting at $80 (the addresses can be modified with some defines in the decoder).

There's a test ROM with source code included.

mic_
Posts: 917
Joined: Thu Oct 05, 2006 6:29 am

Post by mic_ » Mon Nov 30, 2009 11:05 am

I've updated some of the SNES-related parts of sixpack recently. The converter can now output 8-bit planar data (for mode 3/4) in addition to the formats it already supported. I've also rewritten parts of the 65816 LZSS decoder so hopefully it's a bit faster now; I haven't tried doing any measurements.

I'm planning on adding an option to the converter that would convert tiles from planar to linear mode before encoding them, and then back to planar during decoding. This would probably improve compression a little bit, but we'll see.

tepples
Posts: 21710
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Mon Nov 30, 2009 12:09 pm

mic_ wrote:I'm planning on adding an option to the converter that would convert tiles from planar to linear mode before encoding them, and then back to planar during decoding.

By "linear mode" do you mean in the sense of the packed pixel formats used on Genesis and GBA? If so, you can probably repurpose some GBA tile converters in your early experiments.

mic_
Posts: 917
Joined: Thu Oct 05, 2006 6:29 am

Post by mic_ » Mon Nov 30, 2009 2:12 pm

I mean that each pixel would be stored in one nibble/byte/whatever instead of being broken up in separate bitplanes.
Modifying the converter to do this is no big deal - just a few lines of code. Modifying the decoder takes a bit more work. It's not a huge task, but I have a lot of active projects and a finite amount of time to work on them, so..

mic_
Posts: 917
Joined: Thu Oct 05, 2006 6:29 am

Post by mic_ » Wed Jun 23, 2010 10:35 am

I've written an aPLib decruncher for the SNES which now is included in the package: http://jiggawatt.org/badc0de/sixpack/

mic_
Posts: 917
Joined: Thu Oct 05, 2006 6:29 am

Post by mic_ » Sat Jun 26, 2010 12:35 pm

I've written a 65816 version of the PackFire tiny mode depacker. The code can be found here.

Depacking large amounts of data (like a full-screen 256-color image) using this algorithm is very slow on the SNES, but the compression ratios are pretty good.

psycopathicteen
Posts: 2901
Joined: Wed May 19, 2010 6:12 pm

Post by psycopathicteen » Sat Jun 26, 2010 12:54 pm

mic_ wrote:I've written a 65816 version of the PackFire tiny mode depacker. The code can be found here.

Depacking large amounts of data (like a full-screen 256-color image) using this algorithm is very slow on the SNES, but the compression ratios are pretty good.


Even with Mode-7 packed pixel format?

mic_
Posts: 917
Joined: Thu Oct 05, 2006 6:29 am

Post by mic_ » Sat Jun 26, 2010 1:09 pm

It depends on the amount of data. The test I made was to unpack 29120 bytes of data (packed size: 18158 bytes), and this took several seconds.

The same data unpacks much much faster with the LZSS (packed size: 21283) and aPLib (packed size: 18774) depackers.

Post Reply