Looking for Extraction tools for 7z and Shrinkler

[Brian]

The advantage of XZ is it's the same compression but not using as much memory to decompress, and XZ compressing a "stored" archive is more efficient then 7-Zipping the files (as there's more data to work with).

You should be able to set the dictionary to 256K with XZ and get better compression whilst still being able to extract.

(btw, when I said compress using 7-Zip I actually meant compress using the 7-Zip GUI tool, but using XZ compression... although I realise it doesn't read like that!)

I understood that after a while... XZ refusing to accept the file was a hint... bit I was working with a 6 y/o 7zip that didn't have xz implemented. Good now that's updated.

Another optimisation would be to use a BCJ filter.  However, there isn't one for 68k so it would need writing... but that should help the compression a fair bit with the executables.

I'm all for better compression with little to no extra memory usage. Tell me when you find a BCJ filter.

[Brian]

The advantage of XZ is it's the same compression but not using as much memory to decompress, and XZ compressing a "stored" archive is more efficient then 7-Zipping the files (as there's more data to work with).

You should be able to set the dictionary to 256K with XZ and get better compression whilst still being able to extract.

(btw, when I said compress using 7-Zip I actually meant compress using the 7-Zip GUI tool, but using XZ compression... although I realise it doesn't read like that!)

Ok I stand corrected, I was able to gain 17KB (after deducting the the 13KB for shrinkler crunched xzminidec) using store then compress without running out of memory. It does mean I have to up the requirement of HDD space from 3MB to 5MB but that's cool (even back in the days Commodore thought an OS partition should be at least 8MB).

And I'll probably look at a different tool to store the files than 7z now that the compression is taken care of by xz since there's smaller unpackers than 7zdec.

[chris]

I'm all for better compression with little to no extra memory usage. Tell me when you find a BCJ filter.

Should be easy enough to write for somebody with knowledge of 68k asm.
PPC version: http://git.tukaani.org/?p=xz.git;a=blob;f=src/liblzma/simple/powerpc.c;h=54dfbf102878ef53ecf694ae3eb7e68473811be1;hb=HEAD

All it does is replace relative offsets in Branch/Call/Jump instructions with absolute values.  The theory being that subroutines are referenced multiple times, and this makes the code more repetitive and compressible.  The filter than undoes this change when it is decompressed.

And I'll probably look at a different tool to store the files than 7z now that the compression is taken care of by xz since there's smaller unpackers than 7zdec.

If you're doing a store then an Amiga-specific archiver is best as it will keep all the special attributes.  LhA would be my suggestion, maybe even go back and find a really old version as it'll be smaller.  The newer ones have all sorts of extra compression schemes and things that won't be relevant.

[Brian]

Should be easy enough to write for somebody with knowledge of 68k asm.
PPC version: http://git.tukaani.org/?p=xz.git;a=blob;f=src/liblzma/simple/powerpc.c;h=54dfbf102878ef53ecf694ae3eb7e68473811be1;hb=HEAD

All it does is replace relative offsets in Branch/Call/Jump instructions with absolute values.  The theory being that subroutines are referenced multiple times, and this makes the code more repetitive and compressible.  The filter than undoes this change when it is decompressed.

If you're doing a store then an Amiga-specific archiver is best as it will keep all the special attributes.  LhA would be my suggestion, maybe even go back and find a really old version as it'll be smaller.  The newer ones have all sorts of extra compression schemes and things that won't be relevant.

We can always hope someone makes that filter, I can't do it myselv and I'm not holding my breath.

Think I'll go with LZX as I had before... with UnLZX being only 10KB Shrinkler compressed it's hard to beat.

[chris]

We can always hope someone makes that filter, I can't do it myselv and I'm not holding my breath.

I might be able to work it out given enough time but I also might screw it up spectacularly.  Hence why ideally it needs somebody who knows about 68k asm.

In the meantime I've shaved 5K off xzminidec for you. (by recompiling optimising for size and then stripping the binary, hopefully this hasn't broken anything!)

[Brian]

I might be able to work it out given enough time but I also might screw it up spectacularly.  Hence why ideally it needs somebody who knows about 68k asm.

In the meantime I've shaved 5K off xzminidec for you. (by recompiling optimising for size and then stripping the binary, hopefully this hasn't broken anything!)

I'm sure you'd screw it up far less than I would.

Thanks for the slimmer zxminidec. It translated into 624b saving when shrinkler had run through it but every block counts so this helps... if it's not broken.