Gunzip.c64
Here it is: gunzip.c64 - a GZIP/ZIP decompressor for C64. 
gunzip.c64 version 1.4 (2.8.1999). [gunzip.asm.gz gunzip.c Sources may not be upto date!] 
Handles Deflate, Implode, Shrink, Reduce, Store methods! 
Now also writes non-compressed D64 files! 
Errol Smith's unzip64 can also dissolve .zip and .gz files. (Deflate/Store only.) 



--------------------------------------------------------------------------------

Features

Decompresses both ZIP & GZIP compressed files! 
Supports Deflate, Implode, Reduce, Shrink, Store (PKZIP methods 8,6,5-2,1,0) 
Very fast decompression (file I/O takes the most time) 
CRC-32 data integrity checking 
Filename conversion into non-graphical PETSCII 
Filename editing 
Select the packet to decompress from a directory listing 
Dissolves compressed D64 images directly into a 154x/7x disk 
Writes non-compressed D64 images also 
Has one-drive D64 dissolve! 

--------------------------------------------------------------------------------

Introduction

Surprisingly, the whole thing started with C64 emulators. At some point their emulation had gotten so good that it became possible to run almost any program and some of them needed multiple files to work correctly or at all. The emulators started supporting 1541 disk images, thus allowing distribution of whole disks instead of single files or awkward .tar, .lzh, or .zip packets which needed complicated depacking and transfer procedures. 
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.cs.tut.fi/~albert/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. 


Usage

First the program asks for an input drive. Press 8 or 9 for drives 8 and 9, respectively. Use 0-7 for drives 10-17. 
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. 

Yes - decompress this file 
No - skip this file 
All - decompress this file and all following files 
Edit - edit the destination filename 
D64 - write the file directly into a 1541 disk 

The last selection is only available if the input drive is different than the output drive. 
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, the drive will flash its led multiple times in succession: 


 1 
 2 sector not found 
 3 no sync 
 4 data block not found 
 5 data block checksum error 
 6 format error 
 7 verify error 
 8 write protect error 
 9 header block checksum error 
 9 data extends into next block 
11 disk ID mismatch / disk change 
12
13
14 syntax error 
15 no drive present 

The only error I have received is 2:sector not found. It is usually a sign of a faulty format or failed writes and can be cured by first reformatting the disk in question. 
The file size is displayed in hexadecimal after a successful decompression. If the final output size does not match 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. 


Speed

The decompression speed itself is not the dominating part of the executing time; the disk input/output is. The following lists the execution times for a test disk image (97275 bytes compressed, 174848 bytes uncompressed). The first two tests show from-file-to-file times, the last three show the creation of 1541 disks with two drives and one drive. The one-drive test includes disk changes. 

 7:56 1581 -> 1581, standard file I/O 
 9:00 1541 -> 1581, standard file I/O 
10:55 1541 -> 1541 disk, custom sector write 
 9:46 1581 -> 1541 disk, custom sector write 
 9:55 1541 -> 1541 disk, one-drive, custom read / write 

History

15.9.1999 
Source code is now available for interested parties. The C-language version is a very simple, yet not so slow decoder you can try to understand instead of the bloated source code of the gzip release. 

2.8.1999 
Drive ready detection changed. Now you have a chance that your REU, ramlink and/or HD will be detected. Still, no special support for these peripherals is implemented. 

7.7.1999 
Now includes Reduce1-4 methods. 

4.7.1999 
Can also write plain (noncompressed) D64's. 

8.6.1999 
Updated .gz handling to correspond to RFC1952 instead of gzip1.2.4. 

6.6.1999 
A bug in the deflate fixed Huffman decode fixed. 

3.6.1999 
Removed the counting sort routine stage from the Huffman tree create by using slightly different algorithm. This reduced the code size from 397 to 202 bytes and removed 576 bytes of work memory, and probably didn't even slow down the routine. 

5.5.1999 
Added decompression for the Shrink method (PKZIP method 1). Because the LZW tables take 32kB, there is only 8kB left for the output buffer. That's why saving is done more frequently. 

3.5.1999 
A small bug in the Implode code fixed. Fortunately the older version also has CRC checking which catches this bug. 

2.5.1999 
Now handles both Deflate (Gzip and PKZIP method 8) and Implode (PKZIP method 6) methods! 

14.3.1999 
One-drive D64 dissolve (154x/7x) added. 

1.3.1999 
The first public release.