Post by Cyberjank on Nov 11, 2005 14:29:48 GMT -5
Ello folks. I decided to write a short and sweet help file pertaining to simple archiving on a commodore. I will be putting this up on MW BBS as soon as its done. Can someone please go thru it and make sure it makes sense. If you have any suggestions, please let me know. Im a horrbile speller and even worse writer. Thanks folks....
BEGIN----------------------------------------------------
CJ
Land of Confusion : Dealing with archiving and compression on a C=
There has been a bit of confusion surrounding the file compression formats and emulation possibilities concerning commodore and other systems. I will attempt to explain some of the more important formats and their meanings in this piece. For sake of convoluted and long explanations, when I refer to PC, it could be a Mac or any other hardware and software combination out there other than commodore.
Here is a simplified list of C= side files, these can be within a .D64, .D81, .D71, etc… but we’ll get into that later. Lets start with “zip coded” types.
1!acrojetd1
2!acrojetd1
3!acrojetd1
4!acrojetd1
These are zip coded files, often referred to as zipped. Generally speaking this is a C= only side utility (unless using a emulator) not to be confused with the PC style zipping (.ZIP) that we see, for PC style archives. The zip code format actually takes every piece of data from a disk (or tries to), compresses the data then splits the whole disk into four #! files. Some C= zip programs may split it differently, but this is the basic idea. There are now four files that represent a whole disk side. This is extremely useful for programs that don’t just use file access, but hidden data in the disk is accessed. A good example would be a commodore 128 bootable disk, a simple file copier would not do the trick but a whole disk copier would.
Now we can move onto our next type of file format, .LNX or as some call it “Lynxed” or “Lynx” files.
Lynx files are simply many files archived into one file with no compression and no regard to other areas of the disk. It only pertains to files and retains their names when “unlynxed.” This could be useful for a number of reasons, but I will go into the two most significant. Remember the 4 zip coded files in the example above? Well wouldn’t it be nice to have them reflect only one filename? You see, if you archive 250 disk sides in a directory, each zipcoded – you could easily have to deal with (4 files * 250 disk sides = 1000) filenames to view. This is as tedious as it is wasteful. So, we can use lynx to make these four files turn into one .lnx file. Again this does not compress the data, it only groups the files into one archive. It will recall the original filenames when unlynxed. One other reason to use lynx could be that there is a program or utility that does not care about special data on this disk. In other words it only pertains to the files on a disk. In this case it would be okay to only lynx the files together. A good rule of thumb is whole disk programs usually would need to be zip coded and lynxed whereas disks with multiple programs containing multiple files for each program would probably only need lynx. If you are ever unsure - zip coding and lynxing will always be the safest bet. These two programs are not the only compression and archiving utilities, there are many of them out there and I only used these two as an example. On the C= most compression and archiving utilities follow the same basic logic.
We’re now ready to move onto emulation files. Try to imagine .D64’s as being real disks. They are whole disk sides and can act as such on a PC. If you mount a .D64 in VICE, just pretend you are inserting a diskette into the drive of a real commodore computer. When you go to load the disk, load”$”,u and list it, you will see a directory contents just like you would if you were on a real commodore. These are disk image files, and the interpreter (VICE, 64HDD, or any other non-commodore emulator) will try to emulate a disk drive when reading them. These .D64’s are not commodore files, they are for emulators only. Unconverted to a real floppy disk they are for the most part useless to a C= unless it’s a commodore connected to an emulator like 64hdd. Granted there are probably utilities out there that will convert a .D64 file to a while disk on the commodore side only. I wouldn’t want commodore only users downloading a .D64 image to a disk and have a 664 block file on their disk they cant use. Nor would I want a PC user to download a .LNX file that wont work on their VICE emulator.
Of course, there are many ways around this, CTOOLS, for instance on the pc side can take files and insert them into image files like .D64’s. Star commander on the PC side can take .D64 files and turn them into useable commodore formatted disks or vice versa. And of course some .D64’s are “zipped” – They can be unzipped the infinate available utilities on the PC side.
I will not go into all of the possibilities; I simply wanted to give examples to show some of the compatibility requirements of these types of files.
END------------------------------------------------------------
BEGIN----------------------------------------------------
CJ
Land of Confusion : Dealing with archiving and compression on a C=
There has been a bit of confusion surrounding the file compression formats and emulation possibilities concerning commodore and other systems. I will attempt to explain some of the more important formats and their meanings in this piece. For sake of convoluted and long explanations, when I refer to PC, it could be a Mac or any other hardware and software combination out there other than commodore.
Here is a simplified list of C= side files, these can be within a .D64, .D81, .D71, etc… but we’ll get into that later. Lets start with “zip coded” types.
1!acrojetd1
2!acrojetd1
3!acrojetd1
4!acrojetd1
These are zip coded files, often referred to as zipped. Generally speaking this is a C= only side utility (unless using a emulator) not to be confused with the PC style zipping (.ZIP) that we see, for PC style archives. The zip code format actually takes every piece of data from a disk (or tries to), compresses the data then splits the whole disk into four #! files. Some C= zip programs may split it differently, but this is the basic idea. There are now four files that represent a whole disk side. This is extremely useful for programs that don’t just use file access, but hidden data in the disk is accessed. A good example would be a commodore 128 bootable disk, a simple file copier would not do the trick but a whole disk copier would.
Now we can move onto our next type of file format, .LNX or as some call it “Lynxed” or “Lynx” files.
Lynx files are simply many files archived into one file with no compression and no regard to other areas of the disk. It only pertains to files and retains their names when “unlynxed.” This could be useful for a number of reasons, but I will go into the two most significant. Remember the 4 zip coded files in the example above? Well wouldn’t it be nice to have them reflect only one filename? You see, if you archive 250 disk sides in a directory, each zipcoded – you could easily have to deal with (4 files * 250 disk sides = 1000) filenames to view. This is as tedious as it is wasteful. So, we can use lynx to make these four files turn into one .lnx file. Again this does not compress the data, it only groups the files into one archive. It will recall the original filenames when unlynxed. One other reason to use lynx could be that there is a program or utility that does not care about special data on this disk. In other words it only pertains to the files on a disk. In this case it would be okay to only lynx the files together. A good rule of thumb is whole disk programs usually would need to be zip coded and lynxed whereas disks with multiple programs containing multiple files for each program would probably only need lynx. If you are ever unsure - zip coding and lynxing will always be the safest bet. These two programs are not the only compression and archiving utilities, there are many of them out there and I only used these two as an example. On the C= most compression and archiving utilities follow the same basic logic.
We’re now ready to move onto emulation files. Try to imagine .D64’s as being real disks. They are whole disk sides and can act as such on a PC. If you mount a .D64 in VICE, just pretend you are inserting a diskette into the drive of a real commodore computer. When you go to load the disk, load”$”,u and list it, you will see a directory contents just like you would if you were on a real commodore. These are disk image files, and the interpreter (VICE, 64HDD, or any other non-commodore emulator) will try to emulate a disk drive when reading them. These .D64’s are not commodore files, they are for emulators only. Unconverted to a real floppy disk they are for the most part useless to a C= unless it’s a commodore connected to an emulator like 64hdd. Granted there are probably utilities out there that will convert a .D64 file to a while disk on the commodore side only. I wouldn’t want commodore only users downloading a .D64 image to a disk and have a 664 block file on their disk they cant use. Nor would I want a PC user to download a .LNX file that wont work on their VICE emulator.
Of course, there are many ways around this, CTOOLS, for instance on the pc side can take files and insert them into image files like .D64’s. Star commander on the PC side can take .D64 files and turn them into useable commodore formatted disks or vice versa. And of course some .D64’s are “zipped” – They can be unzipped the infinate available utilities on the PC side.
I will not go into all of the possibilities; I simply wanted to give examples to show some of the compatibility requirements of these types of files.
END------------------------------------------------------------