Here’s another one for those nostalgic people who just can’t get enough of the Iomega ZIP. This site’s seen quite a few postings on the ZIP drive and disks, but because of its influence, I still to this day handle ZIP disks and equipment on occasion. This week, I had something to celebrate as I finally managed to have a working ZIP250 drive and cartridge donated to me for a recovery exercise. These aren’t that easy to come by, especially compared to ZIP100 equipment. More on that later though …
ZIP100 USB Drive
Say hello to the translucent blue USB ZIP drive. This would have been one of their mid-early USB ZIP drives judging by the size, and has a model number of Z100USB. This unit was made in Malaysia on 2nd August 1999, and comes complete with the over-cartridge-window label. The cartridge label window is starting to fall into the drive, a rubber foot has gone missing and the eject button plastic hinge has given way, but that’s what you expect from something of this age.
Users of the older parallel port and SCSI ZIP 100’s would feel immediately at home, as the drive practically has the same footprint.
The rear has a single USB-B connector for data and a Kensington lock slot. As usual, there is an emergency eject hole as well.
Unlike the later pocketable ZIP drives, this one requires an external DC power adapter input, making it less portable and less convenient. I don’t have the adapter for it (yet) but it’s probably the same 5v 1A centre positive 2.5mm DC barrel jack adapters as used in their other models.
ZIP100 Colour Cartridge
As I had earlier posted the packaging from a pristine ZIP cartridge, I thought it’d be noteworthy to show that of the ZIP100 colour cartridge series. These were their late attempts to make their cartridges more attractive to home users and make them more fun by following the floppy disk manufacturers into such gimmicks. I’m not sure if it worked, but it did make for some iconic coloured cartidges which are still occasionally seen.
Four colours are available, as per the image on the outer card, with the packaging dated 1999 and the disk Made in Malaysia. This is in contrast to the older package which claims Assembled in Taiwan.
Some of the text written on the card was scrubbed out by hand in software, so if you see something unusual, it’s probably just my handy-work. The warranty for the cartridge is 5-years, as opposed to lifetime before.
Best of all, it wasn’t only the card I managed to get, but an actual coloured disk. This is the first in my collection … or electronic museum.
Not quite pristine on the label as it had been penciled on before, but the disk has the same physical dimensions, but is my favourite colour – green.
Sony ZIP100 Insert Card
Most of the ZIP disks I get donated are bare disks or are in jewel cases sans their branding cards. Where that has not been the case, the branding cards get put up online, and I only have a few. I knew third party manufacturers branded cartridges, including Sony and Fujifilm to name a few – so when I received a jewel case with a Sony card, it was an opportunity for a blog.
Sadly, the card I received was somewhat mistreated with lots of scratches. The cartridge was also Macintosh formatted (which is a little rarer than IBM/PC formatted) and the original owner had taken the time with a permanent marker to cross over it all and write IBM all over it. Luckily, with some handy-work in Photoshop, I was able to sort of re-create the damaged areas in a roughly passable way. Hand-tracing their custom fonts was only mildly successful, but you wouldn’t notice it at a glance. This one claims the cartridge was Made in Taiwan rather than assembled in, and it seems to be a known thing that the cartridges were the same regardless of brand as they were all Iomega manufactured.
The inside features an area for users to write their notes in. I had to clone the left panel over the right as it was completely written and labelled over by the previous owner, but you get the idea. Interestingly, Sony seems to make no mention of any warranties.
ZIP250 Drive
This was a rather lucky donation to have had, because I had previously hunted down a ZIP250 on the street only to find it as dead as a doornail and thus, torn apart and disposed. This was my second shot to have a functional ZIP250 in my collection for data recovery purposes and as a museum piece.
The unit has a black fascia and came from a Dell server, hence the Dell P/N on the label. The model is Z250ATAPI and the drive is dated 16th August 2001. I was assured from the condition of the drive and its former custodian that it was rarely, if ever, used and from my playing around with it, the eject spring is still very taut and suggests that was probably the case.
The footprint is practically identical to the ZIP100, including its fully shielded nature. Without taking a closer look at the front bezel, it’s very easy to mistake it for a ZIP100. The ZIP250 drive is backward compatible in the sense it will read from and write to (slower) ZIP 100 cartridges, but it doesn’t long-format them. It’s still worthwhile to have both drives so I don’t end up wearing out the ZIP250 drive on ZIP100 cartridges.
The rear has a standard IDE/ATAPI interface. It generally needs to be interfaced to a real IDE port, as it doesn’t seem to work with most USB to IDE adapters, nor IDE to SATA adapters in my experience. It is detected as a removable disk device with some custom commands.
A nice warranty label is plastered on the side, but due to age, it likes to try to fall off … there’s no more warranty anymore anyway. Iomega as we knew it back then is long dead.
Best of all, I put it into my recovery box and it came up first time. I managed to test it with a known good ZIP100 cartridge, and it completed testing with no problems and was commissioned for work.
ZIP250 Disk
While ZIP250 drives are somewhat rare in my experience, ZIP250 cartridges are just as rare. It was a chance coming together that I also was left with this ZIP250 cartridge from the same donor for recovery, which gave me a chance to put the ZIP250 to its intended use.
The ZIP250 cartridge has the same mechanical footprint as the ZIP100 cartridge, with the change being to the retroreflector which is now a cream white panel instead. This causes ZIP100 drives to eject the disk immediately upon insertion. The label does have a blue speck of ballpoint ink from an adjacent card, and scuffs from its questionable storage past.
ZIP250 Recovery
Because of problems with Lubuntu’s media handling, I had changed my recovery-box over to Debian Jessie which works very well. Sticking the 250Mb cartridge in, I had expected recovery to be simple using ddrescue. This wasn’t the case.
In all, it seems that the disk itself may have suffered some radial damage judging from the evenly spaced error blocks. Ultimately, after seven hours, the disk was fully recovered with innumerable retries and stress on the drive itself. It did achieve its goal, but it was a pain compared with the ZIP100 cartridges I also received from the same facility which all recovered correctly with no retries at all.
In the case of this disk, the drive gave two kinds of errors:
Recorded entity not found is something which is more common on tape drives than removable media drives …
… and the classic Unrecovered read error, which we dread, but learn to accept. What follows are the long technical bits …
After the recovery had finished, I decided to read the defect lists using sginfo to find it was very much filled with bad sectors:
Defect Lists ------------ 364 entries (2912 bytes) in primary (PLIST) table. Format (5) is: physical blocks [Cyl:Head:Sect] Sector -1 marks whole track as bad. 4: 0: 26| 37: 0: 47| 49: 0: 85| 78: 0: 98| 107: 0: 88 114: 0: 45| 115: 0: 14| 118: 0: 42| 121: 0: 70| 149: 0: 56 165: 0: 1| 228: 0: 39| 256: 0: 48| 262: 0: 100| 350: 0: 7 417: 0: 82| 491: 0: 57| 562: 0: 76| 563: 0: 49| 564: 0: 22 565: 0: 99| 566: 0: 71| 567: 0: 43| 568: 0: 16| 569: 0: 94 570: 0: 67| 571: 0: 40| 572: 0: 12| 573: 0: 89| 574: 0: 61 575: 0: 33| 576: 0: 5| 577: 0: 81| 578: 0: 53| 579: 0: 25 580: 0: 103| 581: 0: 76| 582: 0: 48| 583: 0: 20| 583: 0: 21 584: 0: 97| 585: 0: 69| 586: 0: 42| 587: 0: 14| 588: 0: 91 589: 0: 63| 590: 0: 35| 591: 0: 7| 592: 0: 85| 593: 0: 58 594: 0: 30| 595: 0: 2| 596: 0: 79| 597: 0: 51| 598: 0: 23 599: 0: 100| 600: 0: 73| 601: 0: 45| 602: 0: 17| 603: 0: 40 604: 0: 12| 605: 0: 89| 606: 0: 61| 607: 0: 29| 607: 0: 34 608: 0: 7| 609: 0: 84| 610: 0: 57| 611: 0: 30| 612: 0: 2 613: 0: 80| 614: 0: 52| 615: 0: 25| 616: 0: 103| 617: 0: 75 618: 0: 47| 619: 0: 19| 620: 0: 95| 621: 0: 68| 622: 0: 40 623: 0: 12| 624: 0: 90| 625: 0: 63| 626: 0: 35| 627: 0: 8 627: 0: 34| 628: 0: 86| 629: 0: 59| 630: 0: 31| 661: 0: 4 661: 0: 20| 699: 0: 53| 722: 0: 96| 748: 0: 0| 748: 0: 76 749: 0: 48| 750: 0: 20| 751: 0: 98| 752: 0: 70| 753: 0: 42 754: 0: 15| 755: 0: 93| 756: 0: 66| 757: 0: 40| 758: 0: 14 759: 0: 89| 811: 0: 91| 837: 0: 86| 863: 0: 54| 906: 0: 22 1017: 0: 29| 1050: 0: 45| 1062: 0: 10| 1092: 0: 89| 1160: 0: 41 1338: 0: 43| 1367: 0: 44| 1396: 0: 6| 1426: 0: 54| 1441: 0: 36 1449: 0: 12| 1520: 0: 17| 1881: 0: 0| 2024: 0: 28| 2025: 0: 11 2100: 0: 57| 2128: 0: 35| 2207: 0: 37| 2261: 0: 1| 2267: 0: 0 2300: 0: 50| 2423: 0: 23| 2507: 0: 50| 2523: 0: 9| 2572: 0: 37 2625: 0: 39| 2651: 0: 28| 2724: 0: 54| 2728: 0: 4| 2825: 0: 20 2834: 0: 2| 2835: 0: 46| 83: 1: 67| 104: 1: 28| 106: 1: 78 127: 1: 110| 153: 1: 105| 165: 1: 63| 181: 1: 96| 182: 1: 66 183: 1: 35| 184: 1: 5| 185: 1: 95| 186: 1: 64| 187: 1: 34 188: 1: 4| 189: 1: 94| 191: 1: 34| 192: 1: 3| 193: 1: 93 194: 1: 62| 194: 1: 93| 195: 1: 31| 195: 1: 62| 196: 1: 1 197: 1: 91| 198: 1: 61| 199: 1: 31| 200: 1: 0| 201: 1: 89 202: 1: 58| 202: 1: 107| 213: 1: 83| 214: 1: 52| 215: 1: 22 216: 1: 112| 217: 1: 81| 218: 1: 50| 219: 1: 19| 220: 1: 109 316: 1: 100| 335: 1: 2| 468: 1: 99| 508: 1: 13| 607: 1: 104 608: 1: 76| 609: 1: 48| 610: 1: 19| 611: 1: 97| 612: 1: 69 613: 1: 41| 614: 1: 13| 615: 1: 91| 616: 1: 63| 617: 1: 35 618: 1: 7| 619: 1: 84| 620: 1: 56| 621: 1: 29| 622: 1: 2 623: 1: 79| 624: 1: 51| 625: 1: 23| 626: 1: 100| 627: 1: 73 628: 1: 46| 629: 1: 18| 630: 1: 95| 631: 1: 67| 632: 1: 39 633: 1: 11| 634: 1: 88| 635: 1: 61| 689: 1: 64| 711: 1: 7 771: 1: 7| 901: 1: 4| 916: 1: 36| 1025: 1: 74| 1046: 1: 55 1119: 1: 3| 1122: 1: 27| 1133: 1: 29| 1143: 1: 27| 1146: 1: 56 1245: 1: 69| 1246: 1: 45| 1247: 1: 21| 1248: 1: 87| 1249: 1: 64 1250: 1: 40| 1251: 1: 16| 1252: 1: 82| 1253: 1: 58| 1254: 1: 22 1254: 1: 34| 1255: 1: 10| 1256: 1: 76| 1257: 1: 52| 1258: 1: 28 1259: 1: 4| 1260: 1: 70| 1331: 1: 57| 1390: 1: 14| 1427: 1: 19 1429: 1: 30| 1433: 1: 0| 1439: 1: 88| 1440: 1: 64| 1447: 1: 38 1454: 1: 46| 1456: 1: 48| 1459: 1: 29| 1508: 1: 4| 1552: 1: 2 1580: 1: 47| 1589: 1: 16| 1591: 1: 32| 1601: 1: 49| 1608: 1: 43 1613: 1: 38| 1614: 1: 18| 1615: 1: 78| 1616: 1: 58| 1617: 1: 38 1618: 1: 18| 1619: 1: 78| 1620: 1: 58| 1621: 1: 37| 1622: 1: 17 1623: 1: 77| 1624: 1: 57| 1625: 1: 37| 1626: 1: 17| 1627: 1: 76 1628: 1: 56| 1629: 1: 36| 1630: 1: 16| 1631: 1: 76| 1632: 1: 56 1662: 1: 2| 1663: 1: 62| 1670: 1: 42| 1713: 1: 71| 1714: 1: 50 1717: 1: 23| 1752: 1: 18| 1788: 1: 33| 1791: 1: 53| 1792: 1: 33 1814: 1: 74| 1882: 1: 16| 1901: 1: 6| 1963: 1: 8| 1969: 1: 49 1978: 1: 26| 1980: 1: 25| 2038: 1: 24| 2058: 1: 16| 2085: 1: 61 2096: 1: 10| 2105: 1: 39| 2126: 1: 6| 2126: 1: 38| 2172: 1: 34 2211: 1: 59| 2217: 1: 25| 2251: 1: 68| 2315: 1: 6| 2316: 1: 51 2317: 1: 36| 2318: 1: 20| 2319: 1: 4| 2320: 1: 49| 2321: 1: 33 2322: 1: 18| 2323: 1: 3| 2324: 1: 48| 2325: 1: 33| 2326: 1: 18 2327: 1: 3| 2328: 1: 48| 2329: 1: 33| 2330: 1: 17| 2404: 1: 39 2427: 1: 52| 2452: 1: 35| 2453: 1: 54| 2457: 1: 14| 2458: 1: 59 2536: 1: 8| 2612: 1: 54| 2647: 1: 0| 2647: 1: 25| 2648: 1: 10 2649: 1: 55| 2650: 1: 39| 2651: 1: 24| 2652: 1: 9| 2653: 1: 54 2654: 1: 39| 2655: 1: 24| 2656: 1: 9| 2657: 1: 54| 2658: 1: 38 2659: 1: 22| 2660: 1: 6| 2661: 1: 51| 2662: 1: 35| 2663: 1: 19 2664: 1: 4| 2665: 1: 49| 2666: 1: 34| 2667: 1: 19| 2668: 1: 4 2669: 1: 49| 2670: 1: 34| 2693: 1: 49| 2694: 1: 34| 2711: 1: 48 2733: 1: 22| 2792: 1: 42| 2797: 1: 27| 2822: 1: 17| 250 entries (2000 bytes) in grown (GLIST) table. Format (5) is: physical blocks [Cyl:Head:Sect] Sector -1 marks whole track as bad. 1: 0: 64| 4: 0: 93| 5: 0: 62| 6: 0: 31| 36: 0: 36 37: 0: 5| 38: 0: 94| 40: 0: 33| 41: 0: 3| 42: 0: 92 43: 0: 62| 44: 0: 31| 45: 0: 0| 46: 0: 89| 47: 0: 58 48: 0: 28| 49: 0: 117| 50: 0: 87| 51: 0: 57| 52: 0: 26 53: 0: 116| 54: 0: 85| 55: 0: 55| 56: 0: 24| 57: 0: 114 58: 0: 83| 59: 0: 53| 60: 0: 23| 61: 0: 113| 62: 0: 82 63: 0: 51| 64: 0: 21| 65: 0: 111| 66: 0: 80| 67: 0: 50 122: 0: 97| 123: 0: 66| 124: 0: 36| 125: 0: 6| 126: 0: 96 165: 0: 104| 166: 0: 73| 179: 0: 91| 180: 0: 60| 181: 0: 30 184: 0: 59| 185: 0: 29| 186: 0: 4| 243: 0: 62| 337: 0: 91 471: 0: 61| 472: 0: 32| 473: 0: 4| 474: 0: 81| 475: 0: 53 476: 0: 26| 477: 0: 104| 478: 0: 76| 479: 0: 48| 480: 0: 20 481: 0: 98| 482: 0: 71| 483: 0: 43| 484: 0: 15| 485: 0: 100 624: 0: 64| 625: 0: 37| 626: 0: 9| 627: 0: 87| 628: 0: 60 629: 0: 33| 630: 0: 5| 631: 0: 82| 632: 0: 54| 633: 0: 26 634: 0: 103| 635: 0: 75| 636: 0: 47| 637: 0: 20| 638: 0: 97 639: 0: 69| 640: 0: 41| 641: 0: 13| 642: 0: 91| 643: 0: 63 644: 0: 36| 645: 0: 9| 651: 0: 54| 924: 0: 42| 925: 0: 17 926: 0: 91| 927: 0: 66| 928: 0: 40| 928: 0: 41| 929: 0: 15 930: 0: 89| 931: 0: 63| 933: 0: 11| 933: 0: 12| 934: 0: 87 935: 0: 61| 936: 0: 36| 937: 0: 10| 937: 0: 11| 938: 0: 85 939: 0: 60| 939: 0: 61| 940: 0: 34| 942: 0: 83| 944: 0: 33 945: 0: 7| 946: 0: 83| 947: 0: 56| 947: 0: 57| 949: 0: 4 951: 0: 53| 952: 0: 28| 1176: 0: 69| 1178: 0: 19| 1180: 0: 67 1181: 0: 43| 1182: 0: 19| 1183: 0: 91| 1184: 0: 67| 1185: 0: 43 1186: 0: 19| 192: 1: -1| 436: 1: 58| 714: 1: 38| 715: 1: 10 719: 1: 3| 720: 1: 80| 721: 1: 52| 722: 1: 25| 723: 1: 103 724: 1: 75| 725: 1: 47| 726: 1: 19| 727: 1: 97| 728: 1: 70 729: 1: 42| 730: 1: 14| 731: 1: 91| 732: 1: 64| 733: 1: 37 734: 1: 10| 735: 1: 87| 736: 1: 60| 737: 1: 32| 738: 1: 4 760: 1: 55| 761: 1: 29| 763: 1: 78| 764: 1: 53| 765: 1: 28 766: 1: 2| 767: 1: 76| 768: 1: 51| 769: 1: 26| 771: 1: 74 772: 1: 48| 774: 1: 96| 775: 1: 70| 777: 1: 20| 778: 1: 95 780: 1: 45| 781: 1: 20| 782: 1: 94| 783: 1: 69| 784: 1: 44 785: 1: 19| 786: 1: 93| 787: 1: 67| 788: 1: 42| 789: 1: 17 790: 1: 92| 833: 1: 90| 1144: 1: 28| 1145: 1: 4| 1146: 1: 76 1148: 1: 28| 1151: 1: 52| 1152: 1: 28| 1153: 1: 4| 1154: 1: 76 1155: 1: 52| 1156: 1: 28| 1157: 1: 4| 1158: 1: 76| 1159: 1: 52 1161: 1: 4| 1162: 1: 75| 1163: 1: 51| 1186: 1: 48| 1300: 1: 46 1371: 1: 3| 1372: 1: 69| 1373: 1: 45| 1374: 1: 21| 1375: 1: 88 1376: 1: 64| 1377: 1: 40| 1378: 1: 16| 1379: 1: 82| 1380: 1: 58 1403: 1: 49| 1404: 1: 25| 1405: 1: 1| 1406: 1: 67| 1407: 1: 43 1408: 1: 19| 1409: 1: 85| 1410: 1: 61| 1411: 1: 37| 1412: 1: 13 1413: 1: 79| 1438: 1: 28| 1835: 1: 3| 1964: 1: 60| 2192: 1: 43 2194: 1: 8| 2195: 1: 63| 2196: 1: 46| 2197: 1: 29| 2198: 1: 12 2199: 1: 67| 2200: 1: 49| 2201: 1: 32| 2202: 1: 15| 2203: 1: 70 2204: 1: 52| 2205: 1: 35| 2206: 1: 18| 2207: 1: 1| 2208: 1: 54 2209: 1: 37| 2210: 1: 19| 2211: 1: 0| 2212: 1: 55| 2213: 1: 37 2214: 1: 20| 2215: 1: 3| 2216: 1: 57| 2217: 1: 38| 2218: 1: 21 2219: 1: 4| 2220: 1: 59| 2221: 1: 41| 2561: 1: 7| 2563: 1: 36
For comparison, here’s a moderately used ZIP100’s defect lists:
Defect Lists ------------ 34 entries (272 bytes) in primary (PLIST) table. Format (5) is: physical blocks [Cyl:Head:Sect] Sector -1 marks whole track as bad. 160: 0: 39| 199: 0: 67| 283: 0: 32| 326: 0: 69| 327: 0: 50 482: 0: 11| 483: 0: 55| 486: 0: 7| 487: 0: 51| 675: 0: 53 676: 0: 37| 684: 0: 7| 892: 0: 34| 899: 0: 35| 900: 0: 19 931: 0: 8| 940: 0: 12| 975: 0: 41| 1114: 0: 45| 1535: 0: 38 211: 1: 10| 212: 1: 63| 308: 1: 38| 355: 1: 63| 503: 1: 53 536: 1: 5| 734: 1: 9| 754: 1: 29| 967: 1: 3| 1062: 1: 17 1067: 1: 33| 1275: 1: 29| 1377: 1: 22| 1406: 1: 22| 8 entries (64 bytes) in grown (GLIST) table. Format (5) is: physical blocks [Cyl:Head:Sect] Sector -1 marks whole track as bad. 102: 0: 0| 466: 0: 11| 467: 0: 55| 468: 0: 39| 1113: 0: 10 1311: 0: 36| 440: 1: 21| 728: 1: 45|
Ultimately, I’m not sure whether this is just a particularly bad cartridge or not, but I’d have to assume that the ZIP250 may have been a less robust system compared to the ZIP100 disks.
Getting Technical – Geometry and SCSI Mode Pages
As I now had a ZIP100 and ZIP250 drive on the same machine, and I discovered that they do respond to sginfo and sgformat, I decided to give the mode pages a check to see how the drives were configured. Here is the full mode-page output for the ZIP100:
INQUIRY response (cmd: 0x12) ---------------------------- Device Type 0 Vendor: IOMEGA Product: ZIP 100 Revision level: 12.A No serial number (error doing INQUIRY, supported VPDs) Read-Write Error Recovery mode page (0x1) ----------------------------------------- AWRE 1 ARRE 1 TB 0 RC 0 EER 1 PER 0 DTE 0 DCR 0 Read Retry Count 22 Correction Span 0 Head Offset Count 0 Data Strobe Offset Count 0 Write Retry Count 90 Recovery Time Limit (ms) 20512 mode page: 0x05 [Flexible Disk] --------------- 0x02 0x80 0x03 0x00 0x04 0x40 0x05 0x20 0x06 0x02 0x07 0x00 0x08 0x00 0x09 0x60 0x0a 0x00 0x0b 0x00 0x0c 0x00 0x0d 0x00 0x0e 0x00 0x0f 0x00 0x10 0x00 0x11 0x00 0x12 0x00 0x13 0x00 0x14 0x00 0x15 0x00 0x16 0x00 0x17 0x00 0x18 0x00 0x19 0x00 0x1a 0x00 0x1b 0x00 0x1c 0x0b 0x1d 0x7d 0x1e 0x00 0x1f 0x00 Caching mode page (0x8) ----------------------- Initiator Control 0 ABPF 0 CAP 0 DISC 0 SIZE 0 Write Cache Enabled 1 MF 0 Read Cache Disabled 0 Demand Read Retention Priority 0 Demand Write Retention Priority 0 Disable Pre-fetch Transfer Length 65535 Minimum Pre-fetch 0 Maximum Pre-fetch 65535 Maximum Pre-fetch Ceiling 65535 FSW 0 LBCSS 0 DRA 1 NV_DIS 1 Number of Cache Segments 48 Cache Segment size 12320 Non-Cache Segment size 2105376 mode page: 0x2f --------------- 0x02 0x5c 0x03 0x0f 0x04 0xff 0x05 0x0f
Here is the full mode-page output for the ZIP250:
INQUIRY response (cmd: 0x12) ---------------------------- Device Type 0 Vendor: IOMEGA Product: ZIP 250 Revision level: 41.S No serial number (error doing INQUIRY, supported VPDs) Read-Write Error Recovery mode page (0x1) ----------------------------------------- AWRE 1 ARRE 1 TB 0 RC 0 EER 1 PER 0 DTE 0 DCR 0 Read Retry Count 100 Correction Span 0 Head Offset Count 0 Data Strobe Offset Count 0 Write Retry Count 90 Recovery Time Limit (ms) 20512 mode page: 0x05 [Flexible Disk] --------------- 0x02 0x80 0x03 0x00 0x04 0x40 0x05 0x20 0x06 0x02 0x07 0x00 0x08 0x00 0x09 0xef 0x0a 0x00 0x0b 0x00 0x0c 0x00 0x0d 0x00 0x0e 0x00 0x0f 0x00 0x10 0x00 0x11 0x00 0x12 0x00 0x13 0x00 0x14 0x00 0x15 0x00 0x16 0x00 0x17 0x00 0x18 0x00 0x19 0x00 0x1a 0x00 0x1b 0x00 0x1c 0x0b 0x1d 0x7d 0x1e 0x00 0x1f 0x00 Caching mode page (0x8) ----------------------- Initiator Control 0 ABPF 0 CAP 0 DISC 0 SIZE 0 Write Cache Enabled 1 MF 0 Read Cache Disabled 0 Demand Read Retention Priority 0 Demand Write Retention Priority 0 Disable Pre-fetch Transfer Length 65535 Minimum Pre-fetch 0 Maximum Pre-fetch 65535 Maximum Pre-fetch Ceiling 65535 FSW 0 LBCSS 0 DRA 1 NV_DIS 0 Number of Cache Segments 53 Cache Segment size 12320 Non-Cache Segment size 2105376 mode page: 0x2f --------------- 0x02 0x5c 0x03 0x0f 0x04 0x3c 0x05 0x0f
From the mode pages, we can see both drives are defaulted to automatically rewrite errors found on read and write, but the ZIP250 is configured for a much higher persistence of 100 read retries, whereas the ZIP100 is configured for just 22. Both drives have a write retry count of 90, which implies that the medium can be quite unreliable and instead achieves its reliability through persistence in retries. Both drives have a recovery time limit of about 20.5 seconds.
Both drives have mode pages 0x05 and 0x2f whose attribute naming is not known to sginfo. The caching mode page shows both drives having write cache ability and 64k maximum pre-fetch, with the 250 drive having more cache segments (53 vs 48). NV_DIS is enabled on the ZIP100, although its significance is unknown to me.
As we had mentioned the defect lists earlier, they haven’t been re-mentioned, but it appears that it follows the same two-list methodology that hard drives also use. The geometry of the ZIP disk is somewhat perplexing, as the detected logical geometry is not the physical geometry:
Disk /dev/sda: 239 MiB, 250640384 bytes, 489532 sectors Geometry: 64 heads, 32 sectors/track, 30 cylinders Units: cylinders of 2048 * 512 = 1048576 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/sdb: 96 MiB, 100663296 bytes, 196608 sectors Geometry: 64 heads, 32 sectors/track, 12 cylinders Units: cylinders of 2048 * 512 = 1048576 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes
Obviously the ZIP disk only has two heads, so this is likely to be a compromise emulated geometry based on some calculation. The physical geometry seems to be somewhat mysterious, but judging from the ZIP250 numbers, it seems quite possible that a variable zoned sectoring scheme is in use resulting in a meaningless physical geometry. Regardless, based on the bad sector information, we can conclude that a ZIP100 has at least 1406 cylinders x 2 heads x at least 69 sectors per track physically. Doing the same for the ZIP250 results in a conclusion that it has at least 2835 cylinders x 2 heads x 117 sectors per track which is much more than the logical sectors, which implies a variable zone recording strategy is likely in use.
Conclusion
Again, I’m very thankful to have been donated a set of disks and drives for recovery work, and it’s nice to have a working ZIP250 and a coloured ZIP100 disk as part of my collection. It definitely gave me the impetus to learn more about them, and it’s nice to know sgformat and sginfo work with the ATAPI drives, so there is no need to use Iomegaware Tools under Windows 2000 to check cartridge health or to perform a long format.
Volunteer Data Recovery Offer
As with the Syquest 88Mb cartridge, I realize that rare drives are quite valuable as they can be the last chance some people have to access their data. As interfaces rapidly change, drives become impossible to purchase/obtain/connect or fail outright, it is only responsible of me to use whatever remaining lifetime of my collection of drives to help people regain access to their data, or to close mysteries such as I wonder what’s on that cartridge.
As a result, I would like to extend my offer to any individual for personal use, subject to my approval and ability to do so, to help them recover data from their ZIP100, ZIP250 or Superdisk/LS-120 cartridges.
This service will be provided free, with optional donation, provided you:
- Ccover the cost of postage of the media to an address nominated by me in Australia, preferably using a service that is tracked and registered.
- Accept that the physical media will not be returned.
- The data will be delivered electronically as a Dropbox download – a raw image of the cartridge at the least least, and extracted files if possible. The files may not be usable due to software incompatibility – no guarantees are provided here, no conversion service is provided unless I feel particularly interested.
- I will endeavour to maintain the privacy of the data, but you authorize me to view and retain records of the data as necessary to perform the requested recovery work.
- I will not be held responsible in case of damage, loss, viruses, consequential losses, negligence, loss of items in postage, etc.
If you wish to take me up on this offer, please contact me directly through my e-mail on the Contact Me page. Please note that as this is a voluntary service performed at my cost in my own time, there is no guaranteed timeframes, but two-weeks from receipt is typical.
Great article. New for me to hear of sginfo and Debian Jessie. Appreciate that.
One tip for those recovering Zip 100 disks. I’ve heard that they read much faster on a Zip 100 drive than they do on the 250 drives.
Thanks for the reply. I actually did a bench test but I didn’t report the results – the ZIP250 is slower by a hair, taking about 5s per disk longer. But seeing as I have ample ZIP100 drives, I wasn’t going to wear out its heads on ZIP100 media that could be better served by my ZIP100 fleet. The ZIP250 is half as fast when it comes to writing though, owing to the thinner head width which it probably uses a double-write strategy with offset to account for backwards compatibility.
Debian Jessie has been working great for me – no more waiting for boot processes to time out when it meets removable disk drives with no media during bootup, or bad sectors in the system track. I wasted so many minutes in boot-up using Lubuntu/Ubuntu in the past, it wasn’t funny, and with the latest updates I was getting stack dumps resulting in the drive being entirely unresponsive due to a driver crash, so I decided to go away from the *buntus for now. It may have to do with my hardware since the recovery box currently has SATA, IDE (consumed with ZIP100 + ZIP250), physical floppy, DVD-RW, SCSI 50pin and 68-pin (two separate buses, currently unoccupied but useful for external ZIP100/Syquest 88Mb drive), GbE, USB 3.0 (and 2.0), wireless LAN, etc. The more hardware you cram into it, the more likely you run into these issues. I disabled automounting in GNOME as well to keep things from being “disturbed” since the ZIP disks don’t have physical write protect. The package name is sg3_utils, which bundles sginfo, sgformat amongst other commands which are useful for dealing with any device that uses the SCSI Generic driver type (i.e. /dev/sd*). I also do use smartctl from smartmontools for other SCSI drives which also has the ability to read defect lists given the right switches, but doesn’t give you all mode-page data dump.
If I was really willing, I would probably choose to alter mode pages to turn AWRE and ARRE off so that the drive doesn’t rewrite corrected data in place – this prevents say an incorrect ECC correction (very improbable but possible) being written back to cartridges in recovery, as ZIP has no hardware write protect switch (yet again) …
– Gough
The thought that the drive could be written to, as a bad ECC correction, when attempting an archive dump, yes, that’s a bit disturbing. Would be great to be able to flip off such “fixes” in case temperature or humidity adjustments might fix read issues.
Zip 250 is not rare in USA. What is rare, or at least uncommon, is the rounded cartridges (shaped a bit like UMD / ECMA-365). In this photo, the corner reflector certainly does look more ‘cream white’ than ‘light-banana-yellow’ (do you think it faded? None of mine were so white.).
Very interesting! When I was using Zip (as recently as three or four years ago), I was a stupid, ignorant, plug-and-pray user. It bugged me that Zip, and its software, was proprietary: I hated that disk health, reported as a percent-number, was only available to Windows and Macintosh users. I had no idea, the drives report such detailed information! I never saw a disk health lower than “97%” or so. I wonder: does Zip Tools calculate health percent from the long defect list, or does drive report health by a different command? If former, then: is Zip Tools not able to report health from plain AT Attachment drive (pre-ATAPI)? Does your SCSI drive return identical information?
A project I will likely never be competent enough to tackle, is finding how Zip Tools sets and unsets read only, and writing libre code to achieve this.
A comment about USB bridge: some drive firmwares/revisions had a bug, could not complete large requests. I cannot find such discussion in the *nix mailing lists now, but I know it exists. If small read/write requests were made, then my bridges worked, but large (say, 64Kio) timed-out. The *nixes have a quirk list for the PATA drives, which of course does not match USB drives.
Happy season!
Happy holidays to you too! Indeed, I’d have to say it does look pretty faded, but part of that was probably due to flash photography. It is still a pretty light pastel yellow-green … but alas getting accurate colour is not easy.
I will try to verify the defect lists with another drive, but I am highly certain that it carries over as it’s likely information stored in the Z-track and I have seen correlation between cartridge health and reported number of defects. I’ve seen health as low as 44% depending on the cartridge and the drive used to long-format – my parallel port drive is especially bad and probably has a dirty head which makes it more likely to reduce the health of the drive. I’ll try with a few cartridges and drives to see what is reported.
It would be interesting if you do manage to work out the set/unset read-only but I suspect it’s either a custom command which I have no idea about, or maybe one of the removable disk mode pages which aren’t attribute-labelled by sginfo. I’m not game enough to change those mode-page values willy-nilly in case it borks the drive, since I would like to keep mine operative as much as possible.
Rarity is indeed highly dependent on the popularity of the product. Whenever I speak of such things, I generally mean “within my vicinity”, in which case, Sydney Australia. ZIP250 and 750 were just rarely ever seen, probably because most were onto CD-RW drives by then and local distributors kept cartridge costs almost artificially high. That being said, while Hi-MD is also locally “rare”, I do have a Hi-MD recorder … maybe I should also see if it responds to sginfo queries as I’ve never checked that.
Sadly, things are getting too busy around here with my dissertation and a load of good experiments worth conducting, so we’ll see if I get around to it, but it will certainly be another article. Should probably get another copy of Windows 2000 installed to handle the ZIP drives under Iomegaware Tools just to verify the correlation and see if I can scope out the set/unset read-only business.
Thanks again for taking the time to comment. Much appreciated!
– Gough
EDIT: By rounded cartridge, I seem to have a vague recollection of a large round one, as well as the smaller Clik! 40Mb disks which were hardly popular and had to be renamed due to Click of Death. As usual, I always love getting my hands onto unusual, less common devices for documentation and experimentation.
Hello again.
Just in case you miss it, here’s a post especially for you, which was most of my work today – http://goughlui.com/2015/12/21/experiments-zip-disk-defect-lists-mode-page-changes-protected-cartridges/
Hope you find that at least a little bit insightful.
– Gough
I wanted to try Clik!, to play with it, ever since I first heard of it. So mini, almost like a prop from a sci-fi film, so cool! But I am glad I resisted urge to buy one through eBay. Clik! was destined to fail: Iomega did not even make Mac drivers for it, and it was poor in competition against IBM Microdrive, CompactFlash, and other NAND-based storage. In my nonsense, made-up opinion.
Oh, right, Iomegaware, that’s what I meant! *blush* Not ‘Zip Tools’. 🙂
Do you agree with me in thinking, it is baffling that Sony submitted their PSP UMD to Ecma (it is standard ECMA-365), but none of the superfloppy formats made effort to be a standard? At least, not so far as I know. Maybe Insite, Caleb, Sony, Iomega, or 3M did propose their formats, but no body would accept it.
I so much wish one of (LS-120, Zip, Floptical) became a documented, open standard. I believe with my heart, if industry had embraced one format as successor to Sony’s 90 mm diskette, then: quality would have been higher, failure rate lower, and many tonnes of landfilled CD-Rs and CD-ROMs would have been avoided.
Thank you for taking time to read comments. I know you do not have enough of it!
It may be baffling, but I suppose it’s less baffling in light of the early 21Mb Floptical (https://en.wikipedia.org/wiki/Floptical) which did have de-facto industry support but rarely actually saw adoption. I suppose the “bad taste” lingered with reliability issues and expense. It would always have been nice to see industry wide standards for competition, choice, and stability in the future but I think it was also a double edged sword – I’m sure Caleb, 3M/Imation, Iomega, Syquest (while they were still around) and Castlewood (guys behind the Orb drive) all wanted to catch the market while it was still hot, and standardization is a long route that involves other manufacturers imposing their desires, and political nonsense, and can just serve to delay and strangle the technology while a competitor takes the market by storm. As a result, I can understand why that might have been the case.
Another thing with standardization is the need to license patents under fair, reasonable and non-discriminatory terms which would potentially mean loss of profits, and in a dot-com boom era, I think the companies were only concerned about the bottom line.
Iomega’s efforts had been long, and they also had the early success with the Bernoulli Box which was pretty proprietary too. Ultimately, I think Sony’s move to make UMD an ECMA standard was quite misguided – they might have had hopes for their format, but it never really fruited in the market quite in the right way and it had its own limitations. If anything, their MD/Hi-MD could easily have had similar sizes for similar requirements too, but I’m not sure what their agenda was because outside of the PSP, I’ve never seen them used.
I think it’s also pertinent to remember that BluRay is a bit of a shambles as well, as they’re not truly open-standardized in the sense that they’re not an industry consortium, but more a private consortium/entity holding the specifications, but it did succeed and people do often think of it as a “natural” successor after the death of HD-DVD. But in fact, ECMA standardized UDO for violet-blue laser discs and that’s really relegated to professional applications and is rarely seen. So having ECMA standardization is no guarantee of success, timing is often quite critical to adoption.
Another thing is the Magneto-Optical discs which were also ECMA standardized – how many of them actually became successful in the consumer realm? Despite their standardization and multi-source vendor arrangements, the costs didn’t fall down quick enough that even 3.5″ 90mm MO cartridges were not popular enough to displace superfloppy formats although it was thought that it was a natural evolution (having a very similar, double thick shell size, random access/rewrite ability, and write protect tabs_.
CD-ROM/CD-R/RW served their purpose quite well, at least, the quality media did. The issue with standardization can also rear its head from “compatible” manufacturers taking shortcuts, and the robustness of the ZIP standard seems to come partly from their proprietary servo/system track (aka Z-tracks) that are pre-written on media, so that all brands of disks are actually coming from Iomega, meaning dollars in their pockets and full control of the ecosystem. Sadly, as the ecosystem crumbled, so did their quality control and that eventually lead to click-of-death going viral (news wise, but not so much in actual practical use in my experience) which helped accelerate the death.
I suppose I don’t want to pass myself off as someone who’s defending proprietary technologies – I really hate proprietary stuff for the sake of profits, but at the same point in time, proprietary stuff can be “good enough” if it takes the market quickly enough to become the de facto standard from a consumer/user perspective, as their main concerns are usually related to compatibility/interchange/cost.
– Gough
Is it physically possible to rewrite to the Z-track area? Possible to ignore it and raw dump, step by step, the other sectors?
Do you think something like the Kryoflux could be interfaced to allow for recovery of the zips with the click issue???
Love your know how and desire to discover new from old.
Well, that’s a good question. It’s easy to damage the Z-track area by using a magnet or degausser, and it’s four physical tracks on the media, all redundant copies, so indeed, it is theoretically possible to modify them. Sadly, consumer drives are likely not to allow you through any means of doing this, aside from modifying/rewriting the firmware for them. Someone with enough expertise and time on their hands might have a chance of doing this, but the road is long – you have to know the physical data structures in the Z-tracks as well to make sense of it.
ZIP drives operate off a more sophisticated (compared to floppy drives) servo which uses positioning information embedded in the disk (as far as I can tell). As a result, a Kryoflux-style device isn’t sufficient, as it thinks of floppy drives as dumb fixed-track positioning devices and just steps the head by providing /DIR and /STEP pulses to drive the head, whereas ZIP requires a full feedback loop (assuming you tap into the hardware itself and wire to the voice coil linear seek motor). The data rates are higher (as witnessed by the read-back benchmarks), so signals are more demanding, and the format of the sector headers, gaps etc aren’t known. It’s a deep rabbit hole, as even if you got the raw flux transitions/timings, you still need to know the encoding (how the bits were scrambled/randomized to prevent long strings of patterns) and verification (ECC size, algorithm) and the Z-tracks need to be read and interpreted so the random defect locations can be redirected to their alternate sectors to grab the correct data.
Matson earlier mentioned stuff about ECMA standards and how none of the superfloppies ever made it into ECMA – indeed, without such standardization, these details are all proprietary and have likely sunk to the bottom of the ocean along with the staff and “real” Iomega company, never to resurface.
– Gough
My first encounter with ZIP 250’s was back in 1999 when I was doing consulting and a client sent me a stack of ZIP 100’s with data on them. I contacted them and told them I did not have ZIP drive. Client said buy one and send them the bill. I went to a local computer store and picked out the first box I found that said “Zip” on it. Got it home and it turned out to be a ZIP 250 drive. It was backward compatible but I was surprised to see the higher capacity model. Unfortunately it only worked about two years before it refused to recognize anything other than a ZIP 100 drive. Rather than try and get it fixed, I managed to find an OEM ZIP 250 ATAPI drive which I still have and is about the size of a 3 1/2″ floppy drive! Not sure if I still have any ZIP 250 discs lying around. I pretty much cleaned them and my ZIP 100’s out when I started using thumb drives.
Hi Gough,
i’m currently trying to get a NEC FZ110A (ZIP-100 IDE) drive to work in a modern system environment. You wrote that in general they doesn’t seem to work with USB Adapters.
Unfortunately, i just made the same experience with a Digitus DA-70148-3 (IDE to USB) Adapter. It is based on some JMicron Chip.
Can you give me any hints regarding working Controllers? Or do you have any experience with PCIe IDE Controllers?
Thank you very much in advance!
best regards
Volker
As far as I know, no USB adapter I’ve ever tried it with has performed properly, and that may be because that the commands passed through by most adapters are suitable for IDE and ATAPI CD-ROM/CD-RW drives only. The other thing is that no USB to IDE bridge I have ever used has handled drives <528Mb properly, most of them freeze or just don't detect because they only support LBA mode and not CHS addressing.
On the whole, I can only recommend hardware IDE ports and "older" machines in general as that's what they were designed with - I've had no problems using on-board ports. I've never tried any PCIe IDE board before, but the chances are better than for a USB bridge, but no guarantees as they could be designed with silly assumptions that stop smaller drives from working or don't support the slowest modes of transfer with quite exactly the right timing (the ZIP 100 drives I have are PIO from memory).
- Gough
NEC µPD720130 supports CHS/geometrical addressing. The specimen I had used _only_ geometric addresses: for drives with LBA size slightly greater than CHS size, the bridge provided the slightly smaller geometry-addressed area. Maybe, depending on firmware, it might support LBA-mode and ATAPI (I am too lazy to research that, if only to add to this comment).
I suppose, as the PCIe IDE controllers aren’t too expensive, you might buy it and try it anyway.
However, I would recommend you stay away from IDE to SATA adapter boards as well, as all of the ones I tried will not accommodate any ATAPI device – even CD-ROM/CD-RW/DVD-RW drives do not work through these adapters.
– Gough
Thank you for the information. I found an adapter procaliming to support Iomega Zip Drives, a Sabrent USB-DSC5. Unfortunately, it is not available in my country. I guess next thing i’ll try are PCIe (only PCIe Ports available) IDE Adapters.
Hi,
just a quick follow up. I bought a controller based on the JMB363 chipset. The drive is listed fine while booting up, and a Linux live CD had no problems accessing the disc.
However, Windows makes some problems at first. The JMB363 based Addon cards are usually listed as an AHCI card and therefore the ZIP drive is not recognized. Nevertheless, is is possible to select a different driver for that listed AHCI controller by manual selection. Force to update the driver and select to list also (seemingly) non-compatible drivers. Here, choose the ‘Standard Dual Channel PCI IDE Controller’. This seems to set some control register bits differently and the controller is set in another mode.
And now the drive works perfectly on a modern Windows 7 x64 system.
Setting different modes (RAID, AHCI or IDE) can also be achived via modified firmwares. Unfortunatelly, beside the manufactureres ‘RAID’ firmware my system would not boot with any of the others.
http://blog.stuffedcow.net/2012/08/jmicron-jmb36x-add-on-card-ahci-mode/
best regards
Volker
Good to know that you did find a way to get it to work in the end. Jmicron stuff has been hit and miss for me – some of their products are acceptable whereas others are always trouble.
– Gough
I just queried goolag ‘LS-120 DMF’, and came across a rather complete table of Zip and SuperDisk specification in _Maintenance and Service Guide_ : Compaq Prosignia Notebook Family of Personal Computers (Documentation Part Number 382712-001, Spare Part Number 382793-001) section 6.5 and 6.6.
indexed by Manualslib
The increased disk RPM definitely explains why the LS-120 drives are faster at regular floppy accesses, comparable to the 2x Mitsumi USB drive. Definitely a great find! Thanks for sharing.
– Gough
Hey Gough.
This is really useful, thanks!
I was just wondering what ddrescue commands/parameters do you use to image a failing disk? As I have searched through your blog and can’t really find anything on which commands you actually use, or which options are the best to use in your experience of data reccovery.
Thanks
George 🙂
The main reason I didn’t mention anything regarding commands is that it highly depends on the project and the media what command I will actually use, and often, ddrescue’s own default logic is good enough where the media is not particularly stubborn.
In general, from a superuser shell, invoking ddrescue [source] [destination-file] [log-file] is sufficient. Having the log file argument, and matching this on subsequent runs allows for interruption of the recovery process without losing recovery progress, which is highly recommended. I generally will start the first recovery pass using defaults, because this avoids damage to the drive from bad areas because the logic will only retry a limited number of times and “skip ahead” to better parts with a divide and conquer style algorithm and come back to “trim” the bad blocks.
For particularly picky devices, or where some other kernel/software interference is slowing things down, adding the ‘-d’ direct option can help. Where a drive is being particularly nasty, the resulting file may have lots of non-trimmed and non-scraped blocks which are because the drive stopped responding. Re-invoking the recovery after resetting the drive using the ‘-A’ option will reset these non-trimmed and non-scraped blocks back to non-tried so recovery proceeds sequentially again.
For more stubborn devices, where the data recovery is absolutely necessary even if that means a drive gets damaged, I will often add ‘-r -1’ options to force unlimited retries and give the drive a lot of time. Where the recovery is being re-invoked after not being successful with defaults, it is necessary to add ‘-M’ to mark all failed blocks as non-trimmed so they get tried again.
If copying from a device to another device rather than a file, adding ‘-f’ is necessary to force the operation, as a safeguard against inadvertently overwriting a device.
Aside from this, if the recovery doesn’t fully succeed, the logfile will help you pin-down which ranges are bad. ddrescue can be invoked using the fill-mode to fill these sectors with something like a pattern. I won’t detail this, because it’s all in the manual: https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Fill-mode
Also, I tend to run ddrescueview alongside ddrescue, loading the log-file that is in progress and setting auto-refresh for a graphical view of the recovery as its progressing.
Best of luck with your recoveries.
– Gough
Nice post!
Do you know if there’s any way to recover ZIP disks which have read errors on their partition tables? Like telling the drive to force a seek and read of sector no matter what? I have one disk which causes the drive to stop only a few seconds after inserting it (sometimes it also clicks).
Fortunately the data that’s in it is not critical, but it’d be good to have at least part of it. Any ideas? Tried ddrescue but after a while it returns “errsize: 100 MB”, while the drive does not even try to read anything.
Thanks!
After being sure that the disk is compatible with the drive and not “physically” damaged, if there are errors within the ZIP’s own internal management Z-tracks such that the disk won’t even set-up to the point of attempting to read the data on the surface (e.g. using ddrescue), I’d say there’s nothing that really can be done about it without having some low-level access to the firmware and some “real professional” expertise (of which I don’t have). I’m not aware of any commands that will read/return anything to a disk that hasn’t been set-up to the point of being accessible as a block device – there may even be a chance that such a disk may even refuse to be long-formatted. I’d still probably check with a few different drives just in case one of them can read any one of the redundant copies of the Z-tracks to the point of mounting it. The risk is that you may have a bad drive somewhere causing corruption to disks as ZIP seems to “silently” rewrite any weak areas on a near continuous basis so that even just “reading” the disk in a drive may cause reallocations and writes to occur even if not intended and the software write-protect is set.
– Gough
My 250MB zip drive recognizes 100MB media but immediately ejects 250 MB zip disks. The reflective spot still looks light pastel yellow-green on the 250MB disk, but seems matte rather than shiny/reflective (the 100MB disk reflector is shiny plastic). Is that the way it is supposed to be? I only have one 250MB zip disk at this time. I would like to figure out whether the problem is with the disk or with the drive media type sensor.
The 250MB disk has a pale green matte plastic in place of the shiny reflector of the 100MB disk. That seems to be normal.
– Gough