Looking for Extraction tools for 7z and Shrinkler

[Pat the Cat]

I'm using LZX to pack different kind of data onto a floppy and use UnLZX (also need to fit the disk) to unpack the data. .
On a sidenote, does there exist any small decruncher for Shrinkler compressed programs?

---

Both need to work with 68000 without FPU.

Here's an oddity - different compressor programs vary in efficiency on different data types.

I reckon, 7z, even with a library, will do a better job. dear old Lentle-Ziff-Huffman isn't what it used to be, and that's what most Amiga crunchers are based around.

If you setup all your files at once, so they end up as one big file, that will cut a lot of redundancy out, for files of a similar type. Especially if they are not too big to begin with.

One datatype that will NEVER crunch is raw fax code. It's already 2-1 compressed or better to begin with.

And finally, do make it clear to the end user that they have to decrunch the stuff TO somewhere. A bit of text to explain how to use, in a readme.txt file. That's worth it. It will take up a couple of disk sectors (which is a good way to think about using floppy disks efficiently) but don't rely on the person with the disk to have a clue what to do with it.

I hope one day somebody codes up IFS compression, but that's not going to happen in a hurry. It's not exactly ideal for lossless, which is what you need for executables. It's a bit fuzzy.

[Pat the Cat]

In short I try to put all six OS3.1 floppys onto a single DD floppy and have that work as a standalone install disk that you can use first time setting up the HDD to install. I want it to work on 68000 and requier no more than 1MB memory (atm I uses less than 768KB). I've optimized the heck out of it and I'm at where there is nothing left I can do that would save space (that I'm willing to do). Except if I can get the already compressed files on the floppy to take even less space. Replace LZX archives with z7 and replace Implode crunched files with Shrinkler. There's space to be saved but it also depend on the size of the unpacking tools (Deplode added only 900B to the LZX archive it's in) and UnLZX is crunched to only 10KB and need no libraries... something I've not seen anything rival until Chris's post.

Without commenting on the lawfulness of the chosen data... Which would be perfectly OK if the person using it has an actual ROM chip somewhere in their collection. (Will Amiga Inc ever sue Mac over that, I wonder? Seems fair, it was the other way around in the past). Anyway...

That is your problem, doing single fles rather than a single joined up one. When you use any data sector, any unused space is wasted on the last sector. That is why arranging the data into a single set, then compressing that set into a single file, is going to save you space.

The snags are two fold - first, you need a fast Amiga with lots of fast RAM to set it up - second, your compressor has to first uncompress the archive, the correctly chop it up into single files and copy them to the HDD. You have set no margin for error on doing that on a 1MB single floppy with a HDD attached. But, I admire your thoroughness in pursuing that goal - trying to get it universal.

Here's a simpler way - do it as 2 disks. One as the uncruncher. The next one, when booted, splits up the decompressed file, makes a new set of sub directories, and copies all the split files into the right places. That might just work, and give the end user a nice front end when setting the thing up. The snag is, the decrunching has to happen on one file, which has to be gradually read in, decompressed, and copied to the hard drive. Very demanding.

It does mean two boots from different floppies, but it gives both you and the end user some control over how their hard drives will be setup. That might not seem an issue. Well, it is if the end user is running a real 1.3 Amiga. Having a warning saying "this isn't going to work without a ROM change" would be very helpful to noobs with Amigas, for instance.

Even if you don't for the single file option (it is very challenging), a second floppy for excess data and setup might be required anyway. For files crunches that won't fit, and also for the setup. It would save one reboot, so might be a bit quicker for the end user.

[Pat the Cat]

Hmmm... might be an idea to try combining compression methods.

If you stored the overall delivey folder arrangement as an LHA full of empty folders... and then did a series of 7-zips mini archives each with a folder content... then each folder gets its own mini dictionary, just for dealing with system files of that particular file type.

It should cut down on your system resource requirements. You may find two different compressors deal with each delivered system folder competetively.

Even if you stick with just 7 zip, that might be a way forward? What you are attempting is 6:1 compression. Better than that really, because you have to include decempression tools on your one delivering disk, as well as the 6 floppies worth of data.