ƒH!geoZIP ReadMe   H RPRG formatted GEOS file V1.0CONVERTED WITH geoZIP V0.8ż˙˙˙€˙ˆ‹˙ÁŠAŠ˙ńŠ€ŠŽŠ€Šż‘Š€ŠŸŠ€Šż‘Ž€‚ż‘ƒ€€€€˙ń˙˙˙ƒ˙˙Write Image V2.1geoWrite V2.1đŒ7@˘É1đʎ‚AŠheels Version of GeoZip. Read the README file first!äí °˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙@ Welcome to the world of ZIP archiving on the GEOS platform with geoZIP. geoZIP is largely written by Pasi Ojala for the decompression/dearchiving and for the compression/archiving. In addition, Maurice Randall has contributed a lot with his GEOS input/output code and other user interface niceties. Werner Weicht has contributed some bugfixes and troubleshooting. Werner also does the MP3 GEOS version of geoZIP. Me? I'm like a conductor, seamlessly integrating these two wizards, Mr. Randall's and Mr. Ojala's source codes into a cohesive package. However, my major contribution was the 'SuperDB' routine, which I hope to port to my future GEOS creations. That all said, all copyrights remain with their respective authors, (C) 2000-2002. geoZIP GEOS has some requirements before it can run--Requires the following: * Wheels 64 or 128 * SuperCPU with SuperRAM * At least 128Kb of available SuperRAM Werner Weicht has created a special version of GunZIP GEOS for the MegaPatch3 GEOS platform. You can get it from his website at: http://home.t-online.de/home/wweicht/ This program is very intuitively easy to operate by just about anybody. That said, here's a short primer: There are four menu items: * Set Destination Directory * UnZip files from an archive * Zip files into an archive * Exit geoZIP The Set Source Directory menu option was deleted altogether since geoZIP v0.7. The source directory can be selected now in 'SuperDB' during 'Unzip files from a archive' or 'Zip files into an archive' is used. The Set Destination Directory menu option allows the user to select a destination directory on his/her system. The SuperDB will pop up at that point, allowing you to navigate your GEOS system using drive icons and the DISK icon. You can't select files, but files are displayed so you have a pretty good idea of where you want to go for your destination directory. When you're done selecting your destination directory, click on the [OPEN] icon to accept your selections and exit the SuperDB. The UnZip files from an archive menu option allows the user to actually select any ZIP or GZIP files for dearchiving. The first dialog box will pop up, prompting you for the archive you want to dearchive, and these are files that usually end with a .ZIP or .GZ extension. The SuperDB will show up at this point, and you can select more than one archive files and geoZIP will process them one by one as if it were running a batch file. The SuperDB is restrictive, displaying only valid ZIP or GZ filenames. No need to wade through numerous files to find that elusive ZIP archive. Additionally, you can navigate your GEOS system by using the drive icons and the DISK icon and by doing so, you are actually setting the source directory as well. After that, the UnZip routines will work and will prompt you with dialog boxes for each file it comes across in the archive, with the following options: [Yes], [No], [ALL] or [Cancel]. Selecting 'Yes' will extract that file into the destination directory. You can also edit the filename or leave it as is. Pressing 'RETURN' is the same as clicking on 'Yes'. Selecting 'No' will skip that file and not extract it into the destination directory. Selecting 'Cancel' will cancel the UnZip process. Selecting 'ALL' will allow the UnZip routines to extract every single file it comes across in the ZIP archive onto the destination directory without further prompting. There is a window at the bottom of the screen and it describes the UnZip activity as it is progressing. geoZIP automatically recognizes extracted files from an archive to be that of actual GEOS files and will convert them back into GEOS format. No prompting is necessary. The planned SEQ file option is on hold and if implemented, will enable the user to convert the file into a PETASCII SEQ file. For now, use any commonly available utilities to convert text files into PETASCII or geoWrite v2.1 format for further editing, reading, etc. The Zip files option will bring up the same 'SuperDB' box, but this time, with two more icons. One icon, [Huffman/Stored], looks like a disk that is 'squeezed' or 'straight'. It acts as a toggle; Clicking on it will bring either the Huffman 'squeeze' icon or the Stored 'straight' icon. It affects how the SuperDB operates; If the Huffman icon is on, any files selected will be compressed using a Fixed Huffman algorithm with a 32Kb lookahead buffer. If the Stored icon is on, any files selected will be 'compressed' using a Stored algorithm, meaning that those files will not be compressed at all and will be left intact within the ZIP archive. Files selected with the Stored icon active will look shorter than their Huffman counterparts. Just try out the Stored icon and select files and you'll see what I mean. ean. @0 The other icon, [Toggle All], looks like two disks, one light, one dark, superimposed on each other. Use that to select/deselect all files in the SuperDB requestor, just as if you had used [CMD+X] while in the Dashboard. Please use this icon if you do not plan to store any files and just want to compress all files using the fixed Huffman algorithm. Otherwise, toggle the files you want to compress using fixed Huffman compression, and then set the Stored icon and selectively single out files you want stored within the ZIP archive. The drive icons and DISK icon is also available in this SuperDB and by using them, you are actually setting up the source directory. When you're done selecting the files you want to add to a ZIP archive, click on the [OPEN] files icon to begin the zipping process. First, it will prompt you for the ZIP archive filename. At this point, you can add the .ZIP extension or not as geoZIP does not add it automatically yet. Next, you can add zipfile comments, which is purely optional. You can type in comments or simply press the RETURN key w/o any comments. Finally, the ZIPping process starts! In the bottom of the text window, zipping activity goes on by, with filename, text message and statistic reporting. First of all, it tells you to wait, as geoZIP needs to convert any user-selected GEOS files into Commodore PRG format, with a .CVT extension. This process can take up some time, depending on how many GEOS files you may have selected. Then it processes all user-selected filenames in succession and reports compression statistics for each file. (BTW, this text-reporting behavior closely mimics Pasi Ojala's PuZIP's reporting system.) The first number (all decimal) tells you the uncompressed size (in bytes) of the file. The second number (also decimal) tells you the compressed size of the file (in bytes) The third number tells you the percentage ratio, where any number less than 100% shows some kind of compression, and any number above 100% shows that this file, while can be compressed, is better left off as stored. The lower the percentage numbers, the better compression went. The converse is also true, where the higher the percentage numbers, the worse compression went. When all user-selected filenames are added to the ZIP archive, geoZIP then converts all user-selected .CVT's back into GEOS format. Depending on how many GEOS files you may have selected, this process can take up some time. Finally, it reports with the statistics of how many files were included in the ZIP archive, the total uncompressed size of all included files (in bytes), the total size of the resulting ZIP archive (in bytes) and the total percentage ratio of the compression for the entire ZIP archive. The Exit geoZIP menu option will exit the user back to the deskTop. Inevitably, some users may encounter problems-- Here's some possible answers:  @Problem : geoZIP refused to run. I have SuperCPU, Wheels and SuperRAM!  @Answer : It needs at least 128Kb of FREE RAM. If you run Wheels with a large ramdisk, that could be the problem. I suggest you reduce the size of the ramdisk to consume less SuperRAM memory.  @Problem : What does the text mean? 'ID Mismatch or End Of File - Usually not an Error.'  @Answer : Pasi Ojala, the author of the UnZip routines, stated that EOF (End of File) handling needs to be done better. Usually, it means that EOF has been reached on the ZIP or GZIP archive and that the dearchiving was successfully done. This is NOT an error. One quick way to tell if an error really has occurred is when you do not see a 'filesize' indicator immediately prior to this text message. If you do not see this, then assume that an error with the ZIP/GZIP archive has occurred.  @Problem : What do they mean? 'size mismatch error' and 'crc mismatch error'?  @Answer : @  In every Zip/GZip file archive, the filesize and crc values are stored for each and every file to assure integrity of the archiving/dearchiving process. They are 32-bit values and theoretically, a person can unzip a file of over 4.2 gigabytes! Thankfully and hopefully, we Commodore users never have to deal with archives of that size. If the values do not match, then it means that the Zip/GZip archive is bad, possibly due to a bad download or transfer. Also, if the SuperRAM heats up, it can be flaky and will definitely cause bad size/crc values resulting in mismatch errors.  @Problem : geoZIP refused to convert a file which I know is a GEOS file. Why is that?  @Answer : Normally, geoZIP will convert GEOS files back into GEOS format on the fly during dearchiving from a ZIP/GZip archive. However, if the original GEOS filename as hidden in the converted file conflicts with an existing filename on the destination directory, geoZIP will inform you with an 'File Exists Error' and leaves the file as it is, in a PRG format. You then can use your normal GEOS tools to deal with the problem, such as Convert v2.5, deleting the offending file, etc. ffending file, et@0 @Problem : geoZIP previously refused to overwrite a file. Now, it can? Please explain.  @Answer : Some users wanted geoZIP GEOS to automatically overwrite files, particularly for offline messaging use, such as the QWK packets under QWKRR. So, I allowed geoZIP to automatically overwrite files if it is operating in the [ALL] mode. The [ALL] mode is invoked when the user wants to automatically unzip all files in a ZIP archive w/o further prompting. By theory of unattended automation, geoZIP will now overwrite files w/o further prompting. However, geoZIP will NOT overwrite files if the [ALL] mode hasn't been invoked yet or if they are GEOS files. Only Commodore PRG files can be automatically overwritten in this fashion.  @Problem : geoZIP does not restore the exact filename from a ZIP/GZ archive?  @Answer : That is partly true. geoZIP will force capitalization of all characters for Commodore PRG files because it is deemed the 'safe' method of doing so. GEOS is the only operating system that can utilize lowercase characters in filenames. However, GEOS files will retain their original uppercase/lowercase characters because the CONVERT file format preserves such attributes. Just keep this in mind as there is a uppercase characters limitation of Commodore PRG filenames for ZIP archive activities.  @Problem : geoZIP crashes if it tries to use the 1571 disk drive as a destination device?  @Answer : Thanks goes to Colin Thompson for detecting this bug. I will look into this. But in the meantime, do not use the 1571 disk drive in the Select Destination Directory dialog box. It works fine as a source device, though. I myself, rarely, if ever, use the 1571 disk drive, and apparently, for a lot of other users as well, so this bug went undetected for a long time.  @NOTE : I fixed this bug, thanks to help in troubleshooting this problem by Werner Weicht and Maurice Randall. Feel free to use the 1571 disk drive as either a source or destination device, although it is preferable that one use faster media such as the RAMLink, CMD HD/FD or a ramdisk.  @Problem : The SuperDB seems to 'stall'?  @Answer : When you invoke the unzip files menu selection, the SuperDB will imploy a restrictive filename filter in displaying only valid ZIP or GZ filenames for the user to select from. Unfortunately, this restrictive filter takes up quite a bit of time as it has to scan the directory, analyze first few bytes of each and every file, and then reach decisions on whether to display such filenames into the SuperDB requestor. This process can be slow on regular disk media like a 1581, 1571, 1541, etc. This pause is barely noticeable on a ramdisk, CMD HD or a CMD RAMLink. However, the SuperDB is plenty fast when it is called by the zip files menu selection as it simply displays nearly all filenames without this restrictive file filter routine. The SuperDB is limited to displaying only 255 filenames at any given time, though.  @Problem : I selected the destination directory in the SuperDB, but I changed my mind and clicked on the [CLOSE] icon and the SuperDB went ahead and picked this destination directory anyway!  @Answer : I forced this for the reasons of safety and integrity to a GEOS users' system. Imagine this; You originally were on drive B when you fired up SuperDB in selecting a destination directory. The critical BAM directory layout for drive B was stored on computer's memory. You travel to drive C and land on some subdirectory there only to decide that you don't want to go there. So, you click on the [CLOSE] icon and think that your selection has been 'cancelled', i.e., your destination directory was still drive B. Then you unzip a ZIP archive and the files will go to drive C, but the BAM directory layout in computer's memory will still correspond to drive B and may even mess up the critical BAM of drive C and hose down your system. Not very good, eh? So, even if you use the drive icons and the DISK icon in SuperDB, there's no way for you to 'cancel' your selections other than navigating physically to the original directory you want to use. The same holds true in selecting the source directory. This meant there is no different between the close and the open icon. The current selected drive/partition/subdirectory was stored if you leave SuperDB with close icon or open icon.  @Problem : The ZIP file that geoZIP created contains bad CRC values or bad bytes?  @Answer : geoZIP relies extensively on SuperRAM within the SuperCPU in compressing files for adding into ZIP archives. As a result, geoZIP can create 'bad' ZIP archives if the SuperRAM is acting up due to overheating, etc. One way to spot a bad archive is to detect incorrect CRC values by unzipping the ZIP archive and skipping the individual files. When you skip a file in decompressing a ZIP archive by using the [NO] selection, decompression still occurs and a CRC value is generated and checked against. It is just that the resulting decompression isn't written to disk. deleting the offending file, etc. @0 @Problem : I transferred the geoZIP's created ZIP archive to my 'modern' computer and used 'modern' ZIP utilities and it refused to unzip this archive?  @Answer : The same thing happened to me. I used Quarterdeck's Zip-It! utility for Windows and it could only display the contents of the archive, but not decompress any files. However, PKZIPC.EXE from PKWare at www.pkware.com was able to successfully list the contents of the archive and decompress the individual files of the archive. It's hit or miss as some ZIP utilities depend on a certain arrangement or patterns in ZIP archives. Pasi Ojala stated that he has successfully tested such archives by using ZIP utilities for the Linux and Amiga platforms. At any rate, geoZIP certainly can dearchive its own ZIP archives it has originally created. I suggest that you use the WWW in finding ZIP utilities that work for your modern computer in which it can handle geoZIP's created ZIP archives.  @Problem : How can I unzip GEOS files on my modern computers using my modern ZIP utilities?  @Answer : Keep in mind that while modern ZIP utilities can handle individual files in such archives, they do not know the .CVT format which contains GEOS information. However, geoZIP makes valid MS-DOS 8.3 filenames, so most modern platforms can handle this filename convention. You would need to use other utilities for handling those .CVT's such as StarCommander. From the perspective of a modern computer, a .CVT looks like a regular binary file.  @Problem : I created a ZIP archive of some files on my modern computer using my modern ZIP utility, and the resulting filesize was smaller than what geoZIP can come up with in creating a ZIP archive of those same files?  @Answer : It lies in the particular compression algorithm used; Modern ZIP utilities for modern computers tend to use the Dynamic Huffman compression routines with a 32Kb lookahead buffer. geoZIP uses Pasi Ojala's PuZIP Fixed Huffman compression routines with a 32Kb lookahead buffer and as a result, is a little bit behind in the compression department. Dynamic Huffman compression can adapt itself and its compression tendencies on the particular stream of databytes it encounters and offers better compression as a result. That all said, geoZIP enjoys the largest lookahead buffer of any Fixed Huffman compression algorithm available for PuZIP, coming up with a 32Kb buffer as opposed to the PuZIP's largest at 8Kb. This 32Kb lookahead buffer allows the Fixed Huffman compression routines to look at a much larger databyte stream and look for best possible matches, resulting in better compression. Pasi Ojala may or may not implement Dynamic Huffman compression routines, and if he does, I will be sure to put it in geoZIP!  @Problem : Why should I use the Store algorithm in including files within a ZIP archive?  @Answer : There are some reasons why you may want to store files as opposed to compressing files; Some files just do not compress very well! JPEG files, for example, are better left off as stored in ZIP archive. Also, storing a file is a very quick process as opposed to compressing a file, which will take up some time, even at 20MHz speeds in a RAMLink or ramdisk.  @Problem : The border flashes occasionally.  @Answer : This only happens in 40 column mode. If you're running geoZIP in 80 columns, you can still see the effect on 40/80 column monitors by switching to the 40 column screen and see the color change there, while the text updating, etc. all happens in 80 columns. I left it there as a debugging device, where each time the border changes colors, at least 32,000 bytes has been compressed (or decompressed), or that the end of file has been reached. This 'feature' has been removed since version 0.7. geoZIP does not carry any express or implied warranties of any sort. It is a BETA program and is treated as such. You are well advised to always  @BACKUP your important files before using any disk intensive utility like geoZIP. Or use geoZIP on files/directories that you can 'afford' to lose. I have taken great care to ensure the integrity and safety of a GEOS users' data and files in his/her GEOS system for all aspects of geoZIP's operations. Despite that, data loss and compromised integrity of a GEOS users' system may still result. You agree to hold me, and other authors such as Pasi Ojala, Maurice Randall and Werner Weicht entirely harmless from any damage or loss that may result from using geoZIP. Programming geoZIP has been a labor of love for the GEOS/Commodore platform and let's not tarnish it with any unnecessary pleasantries. If you note a bug or a problem, please bring it to my attention by emailing me at eyeth@videocam.net.au or eyethian@msn.com. Comments, suggestions, beta testing reports, encouragement, etc. is very much welcomed and send them my way via email! Enjoy using geoZIP! -Todd Elliott -Werner Weicht January 23th, 2002