Errol Smith's unzip64 can also dissolve .zip and .gz files. (Deflate/Store only.)
See also: PuZip -- C64/C128 ZIP archiver/compressor.
See also: Burst -- C64 burst modification.
See also: geoZip -- ZIP file extractor/creator for the Wheels (GEOS) operating systems
After a while the disk image distribution became so popular that users with real C64 machines were left at disadvantage. Because a disk image contains a whole disk, 683 disk blocks, a disk image is a 689-block file. A 1541 disk can't hold a file this large, so unless you have a 1571/81 drive or a ramlink/REU, you can't convert the disk image back into a disk because you don't have enough space to save the disk image anywhere in the first place.
A solution stared us right into our faces when the disk images (.d64) got gzipped (compressed with the deflate algorithm) for storage in e.g. ftp.funet.fi. A compressed disk image almost always fits even into a 1541 disk. Then you only need a C64 program to decompress the image and simultaneously create a disk from the disk image.
At this point I had studied the compression field fairly extensively for pucrunch (see http://www.iki.fi/a1bert/Dev/pucrunch/). I searched and found gzip source code and documentation and the deflate algorithm specification and started "cleaning up" the decompression C-code. The C-code had to be written in a way that made it possible to make a more or less direct translation into C64 assembly code.
I had already rolled up my own huffman routines for C64 before work on pucrunch, so that part at least went pretty effortlessly. I represent the Huffman decode tree as an array and this makes the decode routine as fast as possible for a one-bit-at-a-time decode routine. Only a routine which decodes multiple bits at a time would be perceptively faster, but would need more memory than can be spared.
Somewhere along the line I heard about Errol Smith's UnZip64, which decompressed ZIP packets. At that point it didn't understand gzip files, so I didn't abandon my project. Also, I hoped that my program would be faster than unzip64. Still, lack of free time and multiple other projects interfered and many months passed.
Then the idea of compressed disk images came up again and I decided to give it another go. A from-file-to-file version was working a weekend's work later. I then proceeded to add things: disk image write (with standard block write routine at first), CRC32 checking, ZIP support, one-drive disk image handling (custom read and write routines), directory listing, and some error checking for corrupted input files.
Later I have also added some of the older PKZIP algorithms (Implode and Shrink) so that you don't need to have another program to handle the older .zip files. After some time I got ahold of an old pkzip version (092) which generates Reduced files. This enabled me to test the decompressor for this method and include it into gunzip.c64.
And bit by bit I have included useful features. And I will continue to do so if new useful features are requested. Upto a point, of course. See the history section for further developments and general monologue and thoughts.
Then give the input filename or an empty name to select a file from the directory listing.
Output drive is asked next. 8-17 can be used.
If the input drive is the same as the output drive, and a 1541 format disk is detected, you can next select whether you want to dissolve a disk image or files. In disk image mode no other selections are possible.
Unless one-drive disk image mode was selected, several selections are possible for each file in a packet.
If you want to create SEQ files, you can do this by editing the filename to include ",s,w", e.g. "file.doc,s,w". The same procedure can be used for USR files.
The border is flashed when reading or writing data. The screen is blanked during writes.
If a disk error is encountered in disk image write with the one-drive version (gunzip-1.c64), the drive will flash its led multiple times in succession:
The file size is displayed in hexadecimal after a successful decompression. If the final output size does not match with the size indicated in the packet, an error is displayed. Also, if the CRC32 does not match, both the expected and the resulted CRC are displayed.
If the file is not detected to be either Zip or GZip, the user is asked if the file is a plain non-compressed D64. Answering yes allows you to answer yes to the next question and write the file to a 1541 disk. These questions are not asked if one-drive D64 dissolve has been selected or the source disk is in 1541 format (it can not contain a non-compressed disk image, so there is no need to ask). Note that it generally takes longer to write a non-compressed D64 to disk than it takes to write a compressed image, because there is more data to read.
Compiled a standard-io version (gunzip-std.c64) to be used with strange devices (e.g. IEEE488-connected drives) or jiffydos-equipped systems. This version only uses KERNEL calls. Note that one-drive D64 dissolve is not possible with the standard-io version.
Oh how long did I try to find an error when the only thing wrong was a missing call to CLRCHN (which C64 doesn't need, btw) when taking my first steps programming a C128. Anyway, the first beta of a native C128 gunzip is now reality. Note that one-drive D64 dissolve is not possible with the C128 version.
It is true: if nobody wants anything, nobody gets anything. No requests and suggestions means no updates.
Fooled by the docs again. Appnote.txt omitted the information that the data descriptor also has a header: $50,$4b,$07,$08. Gunzip now allows a data descriptor with or without the header, but this of course means that gunzip has a 0.0000000232% chance of detecting it incorrectly.
Btw, the only non-seekable device I could use to check what the Amiga zip program generated was my c1581-handler. (Seeking is possible if a file is opened for reading, but not if it is opened for writing.) If the file is not seekable, the zip program can not back up in the file and fix the CRC32 and length values in the file header and it has to use a data descriptor instead.
Both C64 and C128 versions now use burst read and write if possible. The C64 burst modification is also detected automatically. See http://www.iki.fi/a1bert/Dev/burst/ for details. Note that you can not have the cassette drive connected while using burst-capable devices with the C64 burst modification.
The next thing to do is a dynamic output buffer sizing, a simpler version of directory selector or none at all, and of course history reference checks that inform you if the compressor used too big a window instead of just getting a CRC error.
"PK00" string is now skipped in WinZIPv8-compressed files.
IDE64 detection interfered with Action Replay. Tries to detect AR first, and only if no AR found checks for IDE64.
Automatically skips directories in zip files.