Compression of AMOS Pro compiler's "squash" function?

[ant512]

I'm trying to unpack a data file that was originally compressed using the AMOS Pro compiler's "Squash" function. Without using AMOS.

Does anyone have any idea what compression algorithm this used? I was hoping it was PowerPacker but it doesn't look like it.

[ant512]

Progress so far! Not much.

The last 4 bytes of the packed file contain the unpacked size. All of the rest of the file is a bitstream, in which the bits are all backwards (so the bits 1000000b represent the hex value 0x01).

Here's an example file. Hex on the left; binary on the right. T final 4 bytes are stripped as I already know what those mean.

800BC704: 10000000000010111100011100000100
00001010: 00000000000000000001000000010000
800BD714: 10000000000010111111110100010100

The original file contains the character 'A' 64 times.

Here's another:

800BC684: 10000000000010111100011010000100
00001010: 00000000000000000001000000010000
800BD694: 10000000000010111101011010010100

This contains the character 'B' 64 times.

And another:

4003C685: 01000000000000111100011010000101
00104848: 00000000000100000100100001001000
40138ECD: 01000000000100111000111011001101

This is a 64 byte file containing the repeated character sequence 'AB'.

...and this:

C00DC704: 11000000000011011100011100000100
18584018: 00011000010110000100000000011000
D855871C: 11011000010101011000011100011100

This is a 64-byte file containing the repeated sequence 'ABC'.

There are a few interesting things I can see. The first few files obviously have the bit sequence for 'A' and 'B' at the end of the first row. The first byte of each file changes depending on how many different characters the file contains: '10000000' for 1 character, '01000000' for 2 characters, and '11000000' for 3 characters (mirror them and you get 1, 2 and 3 in decimal).

Here's another file:

900AC701: 10010000000010101100011100000001
41020242: 01000001000000100000001001000010
04058401: 00000100000001011000010000000001
00000010: 00000000000000000000000000010000
D50D4152: 11010101000011010100000101010010

This contains the repeated sequence 'AAABBBCCC'. The first byte is 0x09, which suggests that it is tracking sequence length rather than the number of distinct characters.

Here's another packed file:

D802C6B5
05048584
4544C5C4
2524A5A4
6564E5E4
15149594
5554D5D4
3534B591
00000007
AD763363
00000051

This one includes the final 4 bytes. This is the original file:

AABCDEFGHIJKLMNOPQRSTUVWXYZAABCDEFGHIJKLMNOPQRSTUVWXYZAABCDEFGHIJKLMNOPQRSTUVWXYZ

...so it looks like the first byte is the sequence length (the sequence is 27 characters, and that's what the first byte stores).

[Lonewolf10]

Originally Posted by ant512

I'm trying to unpack a data file that was originally compressed using the AMOS Pro compiler's "Squash" function. Without using AMOS.

You might be at it for a while if you don't use AMOS, for 2 reasons:

1) I believe the Squash function in the compiler was buggy

2) The source to AMOS 1.3 and AMOS Pro are currently available on the internet. Some of us (mainly bruceuncle right now) over at the AMOS Factory are working on fixing and improving AMOS Pro.

[ant512]

Originally Posted by Lonewolf10

You might be at it for a while if you don't use AMOS, for 2 reasons:

1) I believe the Squash function in the compiler was buggy

2) The source to AMOS 1.3 and AMOS Pro are currently available on the internet. Some of us (mainly bruceuncle right now) over at the AMOS Factory are working on fixing and improving AMOS Pro.

I think the Squash function and the compiler squash are different. I've got the source now and am sloooowly adding comments and trying to figure out how it works.

Anyone want to help figuring out the assembly?

[Lonewolf10]

Originally Posted by ant512

I think the Squash function and the compiler squash are different. I've got the source now and am sloooowly adding comments and trying to figure out how it works.

Hmm, 2 different squash's... I didn't know that.

Originally Posted by ant512

Anyone want to help figuring out the assembly?

Errr... maybe. I already downloaded the AMOS sources last year and might take a look tomorrow. I can't promise anything as work is busy at times and I might forget.

PS. Bruceuncle has documented a fair chunk of AMOS Pro. Primarily the start-up sequence, variable storage locations and the like. The information may be helpful to you.

[ant512]

Originally Posted by Lonewolf10

Errr... maybe. I already downloaded the AMOS sources last year and might take a look tomorrow. I can't promise anything as work is busy at times and I might forget.

That would be extremely helpful! My attempt went like this:

Ok, get a pointer to the file size.
Hmm, what does that addressing mode do? Oh, ok; moving the pointer back.
Now why are we getting those two long words?
XOR? Why are we XORing things?
Er, move d0 into d5.
Now we're right-shifting d5. What's in d5?
BNE? Which CCR flag does that check?
What's happing now?

After an attempt at following the flow in Devpac I'm now decoding everything in AMOS, ready for loading up with another language on another platform. It's far from ideal.