Well, not really .. If you load up a mod in an editor and look at the pattern data, one thing I have noticed is there is often a lot of empty space and repetitions. So quite a lot of the time there is wasted effort reading in instructions that are essentially the musical equivalent of a nop. If we were to remove all those holes we can save a huge (relitively speaking) amount of space, get rid of the duplicate data and save even more. And that's without compression!
If you were going to look at compressing it I would imagine you would decide on a chunk size to break the data into, say 64bytes of data, then compress that. This way at least you will know that the uncompressed data will always be no more than 64bytes. My (basic) understanding of compression is around the Huffman approach and as such a kind of dictionary will be required, I suppose to remove the need to require one for each 64byte chunk you would produce one for the whole dataset, or at least a larger window to gain as much of an optimisation as possible.
there may be some merrit to compressing the pattern data, however I doubt it will be significant, or give a significant gain to performance. I will bear it in mind and if the mood takes me, I may look into it further. There are however bigger gains to be had from much less work first
Indeed, the 8KB already holds the actual SoundEngine code, it's variables, as well as some small buffers. It may be possible to allocate some of that for pattern data, but as I said earlier the amount of time spent reading pattern data is very minimal, and given the improvements I already have planned this would be reduced further anyway. Restructuring the mod data, working out a compression scheme and then the code needed to work with that is perhaps an interesting challenge but ultimately for small gains.