Tripredacus, on 08 July 2011 - 07:49 AM, said:
I ran into problems with it [SuperDisk] when I worked for Iomega. There was some sort of goofiness when in a system that also contained the internal Zip 100 drive. Something about having extra/phantom drive letters or it things where it would change letters on you.
As a general rule, one should NOT try to use/have connected LS-120 drives and Iomega zip drives at the same time. There are incompatibilities, possibly even by design, and I would not exclude Imation.
For example, under Win98, when you connect a parallel Iomega zip drive piggy back to an LS-120 parallel port drive, and then copy files from the Iomega zip drive to the LS-120 drive, many copied files are NOT identical, when checked with Beyond Compare. Windows Explorer may show source and target files to be identical, but their content is not. I experienced this, using various Iomega and LS-120 parallel drives.
Another more esoteric example: On my 11-year-old Inspiron laptop I can format as UDF, with some special software, an Iomega zip disk in the right-bay module containing a zip drive, if the left-bay is empty or contains only a regular floppy/DVD/CD combo module. If the left-bay module contains an LS-120 drive (i.e. both LS-120 and Iomega zip are connected at the same time), I cannot format the zip disk in the right-bay zip disk module to UDF anymore. LS-120 drives and Iomega zip drives don't work together. I have attached a screenshot of a UDF formatted Iomega zip disk.
LS-120 drives vs zip drives:
1) zip drives (parallel and SCSI models) are my choice for DOS because of the DOS scsi utilities, which allow the low-level formatting of zip disks, for example, while no such utilities are known to me for LS-120 drives. When fiddling around under DOS, however, e.g. with my old Toshiba 286, I don't use zip drives, but a jaz drive with a jaz traveller cable (is a SCSI to parallel adapter) to transfer files between the ancient Toshiba and my laptop. The Iomega scsi utilities also work with Jaz drives.
2) zip disks are a reliable and excellent archival storage media;
LS-120 disks are neither reliable nor excellent. Half of my LS-120 disks have gone bad, became inaccessible when the media byte could not be read anymore. LS-120 disks are lousy media, when you buy LS-120 disks from ebay, even new shrink-wrapped ones, about half of them are bad or near-bad.
3)
LS-120 drives are the worst pieces of computer junk I have ever seen, terrible workmanship. For example, I had purchased a new shrink-wrapped parallel LS-120 drive (model no. 1195, with the built-in parallel connector, no protruding parallel port adapter). Maybe it had been stored in a hot garage for 12 years. In any case, when I opened the shrink-wrapped box, the plastic front bezel fell off the drive, a tiny piece of plastic had apparently decayed over the years and fallen off into the drive enclosure. When I connected this new LS-120 drive, it only worked with regular floppies, not with LS-120 diskettes, which indicates that the LS-120 drive in the enclosure was bad, dead out of a very well protected box. At least the regular driver floppies and the brown/golden LS-120 diskette with the "Performance Accelerator for Windows 95" in the box were Ok. I would speculate that at least 50% of the LS-120 drives offered at ebay are defective.
Recently I have thrown out 3 bad internal LS-120 drives, lying in a storage box, which were either not recognized by the BIOS in my dual-core desktop or not assigned a drive letter under Win98/XP. Trash. One internal LS-120 drive, a Matsus***a LKM-F934-1, made in Japan in Feb.1999, works Ok in my dual-core desktop under Win98 and WinXP, but not under DOS; the DOS driver listed for this specific model at the Panasonic/Matsus***a website does not work with it. About my Digital Research DRLS 120 drive I will eventually make a separate posting.
I have 3 internal left-bay modules for my 11-year-old Inspiron 7500 laptop, which contain bootable LS-120 drives. They all worked fine, but one LS-120 drive recently died, after maybe 100 hours of actual use. First it had difficulty reading good LS-120 diskettes, and then, within an hour of further use, it didn't recognize LS-120 media anymore, although it did continue to work Ok with regular floppy disks. I doubt that it is just bad alignment, the bad new shrink-wrapped LS-120 drive had no prior usage. Maybe just bad junk.
Uses of LS-120 drives today
Despite of the foregoing issues, here the following features that make LS-120 drives
indispensible tools in 2011, while zip drives are of little use to me today:
1) LS-120 drives are the best readers of bad 1.44MB and 720kB floppy disks. When I was archiving my old floppy disks, maybe 95% of the disks unreadable with a regular floppy drive could be read with an LS-120 drive. Phantastic error correction.
2) LS-120 drives are much faster than regular floppy drives, making them the preferred tool for working with old floppy disks (except when using special DOS software, like DCF, which accesses the floppy directly via the floppy disk controller). An LS-120 drive, for example, formats 1.44MB and 720kB floppy disks about twice as fast as a regular floppy drive, and read access is even faster.
3) Because of their fast reading speed LS-120 drives are superior to regular USB floppy drives as 2nd floppy disk drives. Having 2 floppy drives is useful for comparing the content of 2 floppy disks, e.g. with Beyond Compare. A regular floppy drive in A: and an external USB LS-120 drive make a good combo.
4) LS-120 diskettes are the best media to experiment with UDF formatting. Apparently Iomega zip disks can get permanently damaged during experimentation with UDF. No idea how I trashed the zip disks, but occasionally they became bad during my UDF experimentation, out of the blue. After having trashed 3 or 4 zip disks during my experiments, I switched to LS-120 diskettes, which I have not been able to damage during my UDF experiments.
Also, LS-120 diskettes are slow when compared to UDF-formatted SDHC cards or UDF-formatted HDDs. This slowness is an advantage during my experiments, the activity lights on the LS-120 drive flash much longer, so that I can observe potential reading/writing/formatting issues on UDF-formatted media. Also, formatting a 1TB HDD as UDF takes much longer, and it might be expensive to trash it permanently during experimentation. Eventually I will move from experimenting with LS-120 diskettes to experimenting with old HDDs (8-80 GBs), possibly sending these old HDDs during my experiments onto their last voyage.
5) LS-120 diskettes can serve as obscure removable media for confidential encrypted data. Security thru obscurity. BTW, a lot of the info in this topic applies not just to LS-120 diskettes and LS-120 drives, but has analogies with readily available SDHC cards and other media.
Here an example of an LS-120 diskette, which could cause an "aggressor", as called by SecurStar, a little headache:
- a UDF formatted LS-120 diskette, manually labelled "bad" or "trash, corrupted", containing the encrypted container file A
- nested inside the encrypted container file A is another encrypted container file B, created with a different encryption software
and using a different encryption algorithm
The pdf manual of ScramDisk v3.01 states in the FAQ that it is not possible to recursively store ScramDisk container files inside of a ScramDisk container. During my experimentation, however, it was possible, to overcome this limitation and to work with an application plus data on a mounted container file (e.g. displayed in My Computer as S:) residing inside another mounted container (e.g. displayed in My Computer as X:). In other words: I was able to run my InfoSelect application residing on S: (mounted encrypted container file A); this encrypted container file A resided on X: (the mounted encryped container file B ). The container files A and B were encrypted with different algorithms.
DriveCrypt v4 and higher, for example, adds another barrier by making the inner container "invisible", by hiding it in the free space inside an encrypted container. This approach, however, may be prone to user error: adding by mistake another file to the outer encrypted container modifies the free space in it, thereby destroying the invisible inner encrypted container.
This post has been edited by Multibooter: 08 July 2011 - 06:44 PM
Frontpage
Forums
Tutorials
Members
Calendar
Subscription
Donate
Links
Contact 
Help
Back to top
