See also: gunzip, GZ/ZIP decompressor.
See also: Burst -- C64 burst modification.
A number of solutions exist for transferring data from e.g. a PC into a 1541 disk so that path is no longer a problem. GunZip.c64 and UnZip64 can even handle the decompression of GZIP and ZIP files on the C64 or C128 if necessary. But it still has been a real pain to transfer files from commodore systems to the outside world for some people. Creating lynx files on the C64, transferring this through a machine to another machine to dearchive the packet and rearchiving it as ZIP is unnecessarily troublesome.
The discussion, if I remember anything about it correctly, tried to find a common format for all commodore files. Someone contemplated writing a ZIP archiver (not necessarily compressing) for C64 to help eliminate redundant and proprietary formats. Unfortunately nothing ever came of it. When the idea was mentioned again, I decided to take a look into it.
I started December 11th 1999 by writing a C-language skeleton and after a couple of nights got it working so that all the offset fields were calculated correctly. Without the correct offsets unzip's in other systems may not want to decompress the files although GunZip.c64 and UnZip64 may decompress then without a hitch.
First I created a simple archiver where the files were not compressed. One of the problems with the ZIP store method is that it requires that the stored file size is written to the ZIP file first. The file size can only be calculated by reading the file, which would mean two passes over the input files and a lot of waiting. This made the store method unusable.
Fortunately the Deflate method includes the possibility to save blocks of data instead of the whole file AND you can select from three block types: stored, LZ77 with fixed huffman, and LZ77 with dynamic huffman. With the Deflate stored method I can read a part of the file and store it, repeating this until the input file ends.
When I got this working with C64 I continued working on the C model and included the LZ77 stuff into it. The main idea at this time was to keep in mind the C64 architecture so that the algorithm would be easily and efficiently converted to 6510 assembly language. When I got the C code to the appropriate condition I started the conversion.
A few modifications were done during this time to make the mapping to 6510 easier and more efficient and the final product was quite good. Compressing the test files (two D64 images) in my 25MHz 68k Amiga took 55 seconds, so performing the same with C64 in 26 minutes is excellent, and with C128 in 15 minutes is really great. Note that the nine-minute difference is accounted totally to file I/O. The only difference between the versions is that the C128 version uses burst read when the C64 version doesn't. C128 in FAST mode only wastes 8 minutes, slightly more for C128 in 40-column mode.
It is possible to get a little more compression with the 2kB window size PuZip is currently using and I'll probably do it. Increasing the window size to 4kB does not help much and larger window sizes are not possible nor practical with a 64kB machine.
See the history section for newer additions to the program and other talk about this and that. Features will be added as they are needed or I'll think of something crazy enough. If you need a feature, just tell me and we'll see if and how it can be implemented.
Then select the files to be archived into the ZIP file by pressing either Y for LZ77 compression or S for store (no compression). You can also use 1-3 to use faster but less efficient compression, 3 being the fastest. You can also press D to select disk image compression. The image type is automatically detected and selected between D64/D71/D81. If you don't want a file included in the archive, press N. When you have selected all files you want included, you can press Q to skip the rest of the files.
Output drive is asked next. 8-17 can be used.
Then the archive name is asked and you can also give a zipfile comment. If you do not want any comment, leave the string empty. In the "zip file?" prompt you can also send a command to the destination drive by "@command". If you give just "@", the drive error string is read.
The border is flashed when reading or writing data. The screen is blanked whenever it can be to speed up compression. The 2MHz mode is also used when possible. The screen in turned back on for 3 block times each 32 blocks, if an error is encountered, and of course at the end of compression.
These figures are not very helpful because I can't release the images I used and you can't compare your results to mine. That's why I rerun the tests with this disk image t.zip for some hardware combinations. If you try compressing this image file with some exotic hardware, I would be very interested in knowing your results and will add them to this table. Decompress it first to the drive you are testing (either as a file or as a disk image) and then use PuZip to recompress it.
| Machine | InDrive/Type | OutDrive | Time |
|---|---|---|---|
| VIC20 | 1581/File | 1581 | 13:25 |
| C64 | 1581/File | 1581 | 13:30 |
| C64 +Burst | 1581/File | 1581 | 8:01 |
| C64 +Burst (NTSC) | 1581/File | 1581 | 8:01 |
| C128 40 Columns | 1581/File | 1581 | 4:50 |
| C128 80 Columns | 1581/File | 1581 | 4:39 |
| C128 C64 Mode | 1581/File | 1581 | 11:18 |
| C128 C64 Mode +Burst | 1581/File | 1581 | 5:57 |
| C64 +Burst | 1570/Disk | 1581 | 9:19 |
| C64 (+Burst) | 1541/Disk | 1581 | 15:58 |
| C64 (+Burst) | 1541/Disk | 1570 | 18:31 |
| C64 +Burst | 1570/Disk | 1541 | 12:00 |
| C64 | IDE64/File | IDE64 | 6:12 |
| C64 | 1541-II/Disk | IDE64 | 14:04 |
| C128 C64 mode | IDE64/File | IDE64 | 4:01 |
| C128 C64 mode | 1541-II/Disk | IDE64 | ---- |
Also, ",s" is now appended to the filename for SEQ files (",u" for USR and ",r" for REL if you want to be silly). The maximum number of files is now 64 and the limit is also checked. You can't accidentally select more than 64 files anymore. [Note: Currently the limit is 254.]
This time I tested PuZip with C64 and C128, 1541->1581, 1570->1581, and 1581->1581. All 6 combinations were okay.
"Lowercase" PETSCII characters in filenames are now converted to uppercase ASCII instead of becoming ISO-Latin-1 accented characters.
Error detection and reporting is now better in both burst and non-burst modes. The created archive will contain as much of the file as possible. Now you at least get to know if a file read fails.
You can now give a 36-character zipfile comment.
Also, partial D64/D71/D81 support has been added. Partial, because it is only available in the C128 version and you need the source drive to be burst-capable (i.e. 1570/1571/1581). Select the drive normally and press "D" in the file selector to select disk image compression. This isn't possible for empty disks though. I'll have to figure out something, but you seldom compress disk images with no files in them anyway. Note also that if a disk is full of files, you get better compression for a disk image than individual files. If there is a read error, the actual data is still transferred even if header or data CRC is wrong. In disk image mode errors do not abort the compression.
You can enter disk commands intended for the output drive in the ZIP FILE prompt by using @. A single @ just reads the error channel.
Note that the dostype and the double-sided flag are used for automatic detection of D64/D71/D81. 1581 disks have dostype "D", 1541 and 1571 disk have "A". Double-sided 1571 disks also have the double-sided flag set in the first directory block.
IDE64 does not support the raw directory format that PuZip uses to detect the disk type for disk image creation and the file start track and sector for burst read. The directory menu now detects this kind of directory and adapts accordingly. Also, IDE64 currently does not set ST when the error channel has been fully read, so now PuZip ends reading at CR ($0d).
Thanks to Tuomas Rantala for IDE64 raw-directory dump, although IDE64 does not actually support it yet.
If opening the directory file with the secondary address 2 fails (reads directory as a raw data file), the directory is opened with the secondary address 0 (reads directory converted into a program). This is for future IDE64 compatibility (if I only got it working now).
You can now press RUN/STOP (no RESTORE) in "OUTPUT DRIVE" selection to go back to select a new input drive.
Also, I made a simple 80-column cable to test PuZip in 80-column mode. It seems that using backspace is veeeeryyyy ssloooow with C128 and even slower with the 80-column screen. Now I use cursor_left + space + cursor_left instead. I also tested the compression in FAST mode and it was almost twice as fast than in SLOW mode.
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. I could've use AmigaDOS shell and pipes, my own shell uses files to simulate pipes.) 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.
I also found out a bug in the store algorithm. It didn't work right for files bigger than the current output buffer size.
I also cleaned up the code to make GEOS adaptation easier.
Also fixed a 2MHz problem when PuZip was run on C128 in C64 mode and a disk image was compressed from a non-burst device, such as 1541. Thanks to Tuomas Rantala for the report, although it took me all too long to provide a fix for the problem.