Tech Flashback: More ZIP Defect Tests & Trouble In Paradise Utility

Once you get started on something, often times, you realize there are things still left to be done. Indeed, this post comes about because of my previous experiments inspired by Matson’s comments, and this time, he came up with another hypothesis worth testing. What if you write-protect a cartridge using Iomegaware tools? Does that stop the background defect management from operating?

Another thing I realized was that, in the past, I had dabbled with Gibson Research Corporation’s Trouble in Paradise ZIP utility, which came out around the “click of death” days. I had always meant to demo it for the website, but I don’t think I ever did, as the system where I ran the experiments on suffered a combination software and hardware failure that led to me wiping the hard drive along with the recorded results. Seeing as I was delving into the depths of ZIP, Steve Gibson’s utility does have a lot to offer in terms of showing us that the rabbit hole does go deeper.

Before we jump in, here’s a pair of cartridges for your viewing pleasure:

ztdisk sontzip

The left one is the worn out cartridge with the worst stats of my fleet at this moment. This was a donated cartridge, and is dated 22nd May 1996. This cartridge would have been a bundled cartridge with a ZIP drive and contains ZIP Tools 5 – the original name for the utilities (so yes, Matson, you are also correct). I thought I’d put this in, despite the writing all over the label, as it is an artifact. The other cartridge is just a Sony branded ZIP 100 which is IBM formatted. This would have arrived in an outer packing similar to the Sony card I imaged in the last post, just with IBM formatted rather than Macintosh.

Defect Management Redux

We started this experiment using the left cartridge above, as a cartridge with plenty of existing defects is a good candidate for having something happen to it by automated defect management. No long format was performed, and about 97MB of data was thrown onto the cartridge just so it had some fresh data to work with. After the write, it was immediately protected using Iomegaware Tools under Windows 2000 Professional, and the cartridge ejected.

Rebooting into Linux, the cartridge was inserted into the internal ATAPI ZIP 100 and the defect lists were read straight away. The results were:

Defect Lists
------------
39 entries (312 bytes) in primary (PLIST) table.
Format (5) is: physical blocks [Cyl:Head:Sect]
Sector -1 marks whole track as bad.

    71: 0:   32|    72: 0:   13|   177: 0:   57|   253: 0:   14|   270: 0:    0
   271: 0:   53|   275: 0:   31|   338: 0:   35|   458: 0:   34|   466: 0:   35
   569: 0:   18|   573: 0:   50|   598: 0:   33|   812: 0:   14|   827: 0:   16
   853: 0:   24|   891: 0:   11|   907: 0:   57|  1006: 0:   38|  1165: 0:    9
  1190: 0:   27|  1327: 0:   35|  1422: 0:   15|  1538: 0:   38|  1623: 0:   15
  1624: 0:    5|  1665: 0:   16|    74: 1:   15|   105: 1:   16|   246: 1:   37
   325: 1:   67|   851: 1:   28|   883: 1:    5|   906: 1:    1|  1183: 1:    4
  1324: 1:   17|  1324: 1:   18|  1545: 1:   23|  1686: 1:    2|

122 entries (976 bytes) in grown (GLIST) table.
Format (5) is: physical blocks [Cyl:Head:Sect]
Sector -1 marks whole track as bad.

   321: 0:   48|   538: 0:   32|   773: 0:   50|   988: 0:   18|   989: 0:    5
   990: 0:   40|   991: 0:   27|   992: 0:   14|   993: 0:    1|   994: 0:   36
   999: 0:   19|  1300: 0:   34|  1301: 0:   21|  1302: 0:    8|  1303: 0:   43
  1304: 0:   30|  1305: 0:   17|  1306: 0:    4|  1307: 0:   39|  1308: 0:   26
  1423: 0:    2|  1554: 0:   12|  1555: 0:    2|  1556: 0:   32|  1557: 0:   22
  1558: 0:   12|  1559: 0:    2|  1663: 0:   36|    75: 1:   24|    76: 1:    4
   191: 1:   32|   277: 1:   33|   278: 1:   13|   279: 1:   66|   280: 1:   47
   281: 1:   27|   282: 1:    8|   283: 1:   61|   656: 1:   10|   657: 1:   54
   759: 1:    8|   761: 1:   36|   762: 1:   20|   763: 1:    4|   764: 1:   48
   765: 1:   32|   766: 1:   16|   767: 1:    1|  1011: 1:   41|  1227: 1:   17
  1228: 1:    4|  1365: 1:    4|  1366: 1:   39|  1366: 1:   40|  1367: 1:   26
  1367: 1:   27|  1368: 1:   13|  1368: 1:   14|  1369: 1:    0|  1369: 1:    1
  1370: 1:   35|  1370: 1:   36|  1371: 1:   22|  1371: 1:   23|  1372: 1:    9
  1372: 1:   10|  1373: 1:   44|  1373: 1:   45|  1374: 1:   31|  1374: 1:   32
  1375: 1:   18|  1375: 1:   19|  1376: 1:    5|  1376: 1:    6|  1377: 1:   40
  1377: 1:   41|  1378: 1:   12|  1378: 1:   13|  1379: 1:    0|  1379: 1:   47
  1380: 1:   34|  1380: 1:   35|  1381: 1:   21|  1382: 1:    8|  1382: 1:    9
  1383: 1:   43|  1384: 1:   30|  1385: 1:   17|  1386: 1:    4|  1387: 1:   39
  1387: 1:   40|  1388: 1:   26|  1389: 1:   13|  1390: 1:    0|  1391: 1:   30
  1391: 1:   35|  1392: 1:   22|  1393: 1:    9|  1394: 1:   44|  1395: 1:   31
  1396: 1:   18|  1396: 1:   19|  1397: 1:    5|  1398: 1:   40|  1399: 1:   27
  1399: 1:   28|  1401: 1:    2|  1402: 1:   37|  1403: 1:   24|  1404: 1:   11
  1405: 1:   46|  1406: 1:   34|  1407: 1:   21|  1408: 1:    8|  1409: 1:   43
  1410: 1:   30|  1411: 1:   17|  1775: 1:   21|  1807: 1:   -1|  1810: 1:   -1
  1811: 1:   -1|  1815: 1:   -1|

The cartridge was then read using dd into /dev/null three times over, and then the defect list was read and recorded.

39 entries (312 bytes) in primary (PLIST) table.
Format (5) is: physical blocks [Cyl:Head:Sect]
Sector -1 marks whole track as bad.

    71: 0:   32|    72: 0:   13|   177: 0:   57|   253: 0:   14|   270: 0:    0
   271: 0:   53|   275: 0:   31|   338: 0:   35|   458: 0:   34|   466: 0:   35
   569: 0:   18|   573: 0:   50|   598: 0:   33|   812: 0:   14|   827: 0:   16
   853: 0:   24|   891: 0:   11|   907: 0:   57|  1006: 0:   38|  1165: 0:    9
  1190: 0:   27|  1327: 0:   35|  1422: 0:   15|  1538: 0:   38|  1623: 0:   15
  1624: 0:    5|  1665: 0:   16|    74: 1:   15|   105: 1:   16|   246: 1:   37
   325: 1:   67|   851: 1:   28|   883: 1:    5|   906: 1:    1|  1183: 1:    4
  1324: 1:   17|  1324: 1:   18|  1545: 1:   23|  1686: 1:    2|

121 entries (968 bytes) in grown (GLIST) table.
Format (5) is: physical blocks [Cyl:Head:Sect]
Sector -1 marks whole track as bad.

   321: 0:   48|   538: 0:   32|   773: 0:   50|   988: 0:   18|   989: 0:    5
   990: 0:   40|   991: 0:   27|   992: 0:   14|   993: 0:    1|   994: 0:   36
   999: 0:   19|  1300: 0:   34|  1301: 0:   21|  1302: 0:    8|  1303: 0:   43
  1304: 0:   30|  1305: 0:   17|  1306: 0:    4|  1307: 0:   39|  1308: 0:   26
  1423: 0:    2|  1554: 0:   12|  1555: 0:    2|  1556: 0:   32|  1557: 0:   22
  1558: 0:   12|  1559: 0:    2|  1663: 0:   36|    75: 1:   24|    76: 1:    4
   191: 1:   32|   277: 1:   33|   278: 1:   13|   279: 1:   66|   280: 1:   47
   281: 1:   27|   282: 1:    8|   283: 1:   61|   656: 1:   10|   657: 1:   54
   759: 1:    8|   761: 1:   36|   762: 1:   20|   763: 1:    4|   764: 1:   48
   765: 1:   32|   766: 1:   16|   767: 1:    1|  1011: 1:   41|  1227: 1:   17
  1228: 1:    4|  1365: 1:    4|  1366: 1:   39|  1366: 1:   40|  1367: 1:   26
  1367: 1:   27|  1368: 1:   13|  1368: 1:   14|  1369: 1:    0|  1369: 1:    1
  1370: 1:   35|  1370: 1:   36|  1371: 1:   22|  1371: 1:   23|  1372: 1:    9
  1372: 1:   10|  1373: 1:   44|  1373: 1:   45|  1374: 1:   31|  1374: 1:   32
  1375: 1:   18|  1375: 1:   19|  1376: 1:    5|  1376: 1:    6|  1377: 1:   40
  1377: 1:   41|  1378: 1:   12|  1378: 1:   13|  1379: 1:    0|  1379: 1:   47
  1380: 1:   34|  1380: 1:   35|  1381: 1:   21|  1382: 1:    8|  1382: 1:    9
  1383: 1:   43|  1384: 1:   30|  1385: 1:   17|  1386: 1:    4|  1387: 1:   39
  1387: 1:   40|  1388: 1:   26|  1389: 1:   13|  1390: 1:    0|  1391: 1:   30
  1391: 1:   35|  1392: 1:   22|  1393: 1:    9|  1394: 1:   44|  1395: 1:   31
  1396: 1:   18|  1396: 1:   19|  1397: 1:    5|  1398: 1:   40|  1399: 1:   27
  1399: 1:   28|  1401: 1:    2|  1402: 1:   37|  1403: 1:   24|  1404: 1:   11
  1405: 1:   46|  1406: 1:   34|  1408: 1:    8|  1409: 1:   43|  1410: 1:   30
  1411: 1:   17|  1775: 1:   21|  1807: 1:   -1|  1810: 1:   -1|  1811: 1:   -1
  1815: 1:   -1|

The only change was the loss of 1407/1/21 from the GLIST, which was not that big of a difference at all, but still illustrates that the write protection is ineffective against reallocations.

I then decided to get a little more drastic, as the minimal changes to the GLIST is likely due to the fact that the cartridge was written by the same ATAPI drive earlier, and most drives are better at reading media they have written themselves, compared to those written by others. This time, I decided to employ the SCSI drive which is known to be a little more aggressive in scrubbing out defects, and had it perform three dd read-outs. The defect lists were as follows:

Defect Lists
------------
39 entries (312 bytes) in primary (PLIST) table.
Format (5) is: physical blocks [Cyl:Head:Sect]
Sector -1 marks whole track as bad.

    71: 0:   32|    72: 0:   13|   177: 0:   57|   253: 0:   14|   270: 0:    0
   271: 0:   53|   275: 0:   31|   338: 0:   35|   458: 0:   34|   466: 0:   35
   569: 0:   18|   573: 0:   50|   598: 0:   33|   812: 0:   14|   827: 0:   16
   853: 0:   24|   891: 0:   11|   907: 0:   57|  1006: 0:   38|  1165: 0:    9
  1190: 0:   27|  1327: 0:   35|  1422: 0:   15|  1538: 0:   38|  1623: 0:   15
  1624: 0:    5|  1665: 0:   16|    74: 1:   15|   105: 1:   16|   246: 1:   37
   325: 1:   67|   851: 1:   28|   883: 1:    5|   906: 1:    1|  1183: 1:    4
  1324: 1:   17|  1324: 1:   18|  1545: 1:   23|  1686: 1:    2|

116 entries (928 bytes) in grown (GLIST) table.
Format (5) is: physical blocks [Cyl:Head:Sect]
Sector -1 marks whole track as bad.

   321: 0:   48|   538: 0:   32|   773: 0:   50|   988: 0:   18|   989: 0:    5
   990: 0:   40|   991: 0:   27|   992: 0:   14|   993: 0:    1|   994: 0:   36
   999: 0:   19|  1300: 0:   34|  1301: 0:   21|  1302: 0:    8|  1303: 0:   43
  1304: 0:   30|  1305: 0:   17|  1306: 0:    4|  1307: 0:   39|  1308: 0:   26
  1423: 0:    2|  1554: 0:   12|  1555: 0:    2|  1556: 0:   32|  1557: 0:   22
  1558: 0:   12|  1559: 0:    2|  1663: 0:   36|    75: 1:   24|    76: 1:    4
   191: 1:   32|   277: 1:   33|   278: 1:   13|   279: 1:   66|   280: 1:   47
   281: 1:   27|   282: 1:    8|   283: 1:   61|   656: 1:   10|   657: 1:   54
   759: 1:    8|   761: 1:   36|   762: 1:   20|   763: 1:    4|   764: 1:   48
   765: 1:   32|   766: 1:   16|   767: 1:    1|  1011: 1:   41|  1227: 1:   17
  1228: 1:    4|  1365: 1:    4|  1366: 1:   39|  1366: 1:   40|  1367: 1:   26
  1367: 1:   27|  1368: 1:   13|  1368: 1:   14|  1369: 1:    0|  1369: 1:    1
  1370: 1:   35|  1370: 1:   36|  1371: 1:   22|  1371: 1:   23|  1372: 1:    9
  1373: 1:   44|  1373: 1:   45|  1374: 1:   31|  1374: 1:   32|  1375: 1:   18
  1375: 1:   19|  1376: 1:    5|  1376: 1:    6|  1377: 1:   40|  1377: 1:   41
  1378: 1:   12|  1379: 1:    0|  1379: 1:   47|  1380: 1:   34|  1381: 1:   21
  1382: 1:    8|  1382: 1:    9|  1383: 1:   43|  1384: 1:   30|  1385: 1:   17
  1386: 1:    4|  1387: 1:   39|  1387: 1:   40|  1388: 1:   26|  1389: 1:   13
  1390: 1:    0|  1391: 1:   30|  1391: 1:   35|  1392: 1:   22|  1393: 1:    9
  1394: 1:   44|  1395: 1:   31|  1396: 1:   18|  1396: 1:   19|  1397: 1:    5
  1398: 1:   40|  1399: 1:   27|  1399: 1:   28|  1401: 1:    2|  1402: 1:   37
  1404: 1:   11|  1405: 1:   46|  1406: 1:   34|  1407: 1:   21|  1410: 1:   30
  1411: 1:   17|  1775: 1:   21|  1807: 1:   -1|  1810: 1:   -1|  1811: 1:   -1
  1815: 1:   -1|

A more marked change was noted this time, with the loss of 1372/1/10, 1378/1/13, 1380/1/35, 1403/1/24, 1408/1/8, 1409/1,43 and addition of 1407/1/21. Specifically, 1407/1/21 was removed by the ATAPI drive only to be flagged again as defective later. This flip-flopping behaviour has been noted multiple times by myself, but represents the “putting back into service weak areas which are later detected as too weak for service” and potentially a risk to data integrity. This represents a relatively major change by comparison, lets see if we can inspire some more changes. I pushed it for a further three dd read-outs, resulting in the following defect list:

39 entries (312 bytes) in primary (PLIST) table.
Format (5) is: physical blocks [Cyl:Head:Sect]
Sector -1 marks whole track as bad.

    71: 0:   32|    72: 0:   13|   177: 0:   57|   253: 0:   14|   270: 0:    0
   271: 0:   53|   275: 0:   31|   338: 0:   35|   458: 0:   34|   466: 0:   35
   569: 0:   18|   573: 0:   50|   598: 0:   33|   812: 0:   14|   827: 0:   16
   853: 0:   24|   891: 0:   11|   907: 0:   57|  1006: 0:   38|  1165: 0:    9
  1190: 0:   27|  1327: 0:   35|  1422: 0:   15|  1538: 0:   38|  1623: 0:   15
  1624: 0:    5|  1665: 0:   16|    74: 1:   15|   105: 1:   16|   246: 1:   37
   325: 1:   67|   851: 1:   28|   883: 1:    5|   906: 1:    1|  1183: 1:    4
  1324: 1:   17|  1324: 1:   18|  1545: 1:   23|  1686: 1:    2|

114 entries (912 bytes) in grown (GLIST) table.
Format (5) is: physical blocks [Cyl:Head:Sect]
Sector -1 marks whole track as bad.

   321: 0:   48|   538: 0:   32|   773: 0:   50|   988: 0:   18|   989: 0:    5
   990: 0:   40|   991: 0:   27|   992: 0:   14|   993: 0:    1|   994: 0:   36
   999: 0:   19|  1300: 0:   34|  1301: 0:   21|  1302: 0:    8|  1303: 0:   43
  1304: 0:   30|  1305: 0:   17|  1306: 0:    4|  1307: 0:   39|  1308: 0:   26
  1423: 0:    2|  1554: 0:   12|  1555: 0:    2|  1556: 0:   32|  1557: 0:   22
  1558: 0:   12|  1559: 0:    2|  1663: 0:   36|    75: 1:   24|    76: 1:    4
   191: 1:   32|   277: 1:   33|   278: 1:   13|   279: 1:   66|   280: 1:   47
   281: 1:   27|   282: 1:    8|   283: 1:   61|   656: 1:   10|   657: 1:   54
   759: 1:    8|   761: 1:   36|   762: 1:   20|   763: 1:    4|   764: 1:   48
   765: 1:   32|   766: 1:   16|   767: 1:    1|  1011: 1:   41|  1227: 1:   17
  1228: 1:    4|  1365: 1:    4|  1366: 1:   39|  1366: 1:   40|  1367: 1:   26
  1367: 1:   27|  1368: 1:   13|  1368: 1:   14|  1369: 1:    0|  1369: 1:    1
  1370: 1:   35|  1370: 1:   36|  1371: 1:   22|  1371: 1:   23|  1372: 1:    9
  1373: 1:   44|  1373: 1:   45|  1374: 1:   31|  1375: 1:   18|  1375: 1:   19
  1376: 1:    5|  1376: 1:    6|  1377: 1:   40|  1377: 1:   41|  1378: 1:   12
  1379: 1:    0|  1379: 1:   47|  1380: 1:   34|  1381: 1:   21|  1382: 1:    8
  1382: 1:    9|  1383: 1:   43|  1384: 1:   30|  1385: 1:   17|  1386: 1:    4
  1387: 1:   39|  1387: 1:   40|  1388: 1:   26|  1389: 1:   13|  1390: 1:    0
  1391: 1:   30|  1391: 1:   35|  1392: 1:   22|  1393: 1:    9|  1394: 1:   44
  1395: 1:   31|  1396: 1:   18|  1396: 1:   19|  1397: 1:    5|  1398: 1:   40
  1399: 1:   27|  1399: 1:   28|  1401: 1:    2|  1402: 1:   37|  1403: 1:   24
  1404: 1:   11|  1405: 1:   46|  1406: 1:   34|  1410: 1:   30|  1775: 1:   21
  1807: 1:   -1|  1810: 1:   -1|  1811: 1:   -1|  1815: 1:   -1|

Again, a reduction in list length (by just 2 entries this time) is seen but only changes in GLIST were seen.  The two entries change actually involved the removal of 1374/1/32, 1407/1/21, 1775/1/21 and addition of 1403/1/24. The additional read-outs flip-flopped 1407/1/21 back off of the defect list, which is all fun and games, indicative of a “weak” sector. It also flip-flopped 1403/1/24 back onto the defect list, which was removed in the previous read-runs. This indicates another weak sector, but the consistency to which these numbers match on a read-out-by-read-out basis seems to suggest these are the real defect lists.

Regardless, it actually could be thought of as “cartridge health improving” due to the removal of sectors from the defect tables, representing soft errors which were recoverable or marginally weak areas that are borderline resulting in later flip-flopping between in-service and defective states.

Ultimately, it is clear that setting the cartridge write-protect using Iomegaware Tools is ineffective in ensuring background defect management does not alter the cartridge state and cause silent modifications of the sector mapping. Sadly, this puts two methods of attempting to prevent this behaviour into the “ineffective” category. Despite us not witnessing any change in the PLIST in this experiment, I find that changes in the PLIST are generally rarer compared to GLIST changes, even after long-formatting, and thus the PLIST/GLIST distinction may come down to a drive-measured metric of the severity of the error at the sector. Maybe a certain number of errored bits or retries are necessary to promote a sector into the PLIST where it is less likely to be scrubbed out and put back into service, but this is a hypothesis I don’t have sufficient time or energy to test.

However, if you look at the next section, you may begin to understand just how sophisticated the error handling system of the ZIP drives are, and why my thoughts “align” in this manner.

Trouble in Paradise

tipiconSteve Gibson, author of Spinrite and guy behind ShieldsUp! firewall testing service, was also highly involved in the ZIP click-of-death issues and sought to help people by providing a tool he called Trouble in Paradise which served as a cartridge and drive diagnostic, which is more sensitive and detailed than any other utility. This freeware tool is still being distributed today and can still be downloaded from the website linked earlier.

If you want to run and use the tool today, you will come across several issues – the first namely that the program has time expired, but has been abandoned with no new edition actually available. (Screenshot from my Windows 7 box because I forgot to grab the file from my Windows 2000 box.)

tip-exipired

It’s not hard to get around this, because it’s just a date-lock, so winding back the clock allows us to get it going.

tipopenClicking next, the program itself has quite comprehensive information about ZIP click of death displayed in a window (not shown), but instead I’ve reproduced the information as a PDF so that users can still access it today. One important point is:

Non-ATAPI Internal IDE Zip drives did NOT support the standard ATAPI / SCSI software interface, so this program can not operate upon those IDE ZIP drives at all. I really wish it could, but those drives conceal ALL special Iomega information. TIP does operate upon ALL OTHER internal and external ZIP and Jaz drives.

As a result, it confirms that older IDE ZIP drives, pre-ATAPI, were not able to return special diagnostic information, but other drives are capable. Continuing greets you with the main screen where the cartridge testing takes place …

tipnodrives… except now you are told No Iomega Drives even though I have three attached to the system. Those who didn’t live in the era of Windows 9x/2000 would not remember the issues with CD-RW software and ASPI/SPTI transition, so a quick explanation is in order.

Basically, under Windows 2000, Microsoft decided to provide a SPTI (SCSI Pass-Through Interface) as a new default API for accessing SCSI devices. Modern software all uses SPTI to query and work with ATAPI drives, such as CD-RW/DVD-RW drives etc. However, older software designed to work with Windows 9x as well did not have the option of using SPTI and instead used an older, less standardized API known as ASPI (Advanced SCSI Programming Interface) championed by Adaptec. This particular driver was also allowed to operate under Windows 2000 through to XP at the latest, allowing older programs to keep running, but it was a royal pain in the neck when certain software needed certain ASPI driver versions. I’m glad SPTI took over in the end.

Anyway, when the light bulb went off in my head, I ran over to Adaptec to grab the latest ASPI bundle and install it.

installaspi aspiinstalled aspireboot

After a reboot, we were in business at last. Trouble in Paradise only supports one ZIP drive and will take the first drive it sees, which is not necessarily the one with the lowest drive letter.

await-cartAfter a bit of checking (by that, I mean shoving the cartridge into one drive at a time), it turned out it had hooked onto my external SCSI drive, so I decided to plug in a decent cartridge and let it rip.

spinning-upWhile the test is in action, the indicators in the top corner cycle around, and this gives us an indication of how the program works, namely it reads a bit of data, writes a pattern, reads the pattern while checking the drive for error indications, then re-writes the original data back in place.

tip-working

While the test is running, quite a few different sorts of errors will turn up. I’ve tried to capture a screenshot of every error I saw, but I missed a Sector Mark not Found as it was only very transient.

read-with-retries data-corrected trackfollowFrom what I could see, read with retries is an informative soft error which claims the data had some errors but after retrying, was read successfully and no corrective action was taken. This is distinct with Data Corrected which indicates the data was faulty to the stage of needing an rewrite with possible reallocation. A track follow error seems to suggest faulty, weak or damaged servo information which can lead to track retirement, and could come across due to faulty drives or power-down during write.

one-run-completedAt the end of the run, you get a list of soft errors, firm errors and hard errors. For more explanation, you can choose Explain Results which provides this text which is worth a read:

explain-afterClicking Next gives you information on what to do on Click of Death affected devices:

remedy

Clicking next again gives you a little plug on GRC’s software. I, for one, applaud the efficiency that Steve Gibson has been able to achieve with his utilities.

grc-plug

As the full surface work-out has forced the drive to exercise every sector, a second run on the same cartridge reports less soft errors and no firm errors, indicating the tool has done its job and the drive is operating as expected.

re-runsame

Of course, it also has a status for when you eject the cartridge too. A nice touch.

ejectingIt really does tell you that Steve Gibson managed to read much more about the status of the drive’s operation, and the defect lists. How this was done is likely using custom commands, and polling the drive for status, but whether these commands were documented or whether the documents still survive today is unknown. Maybe someone can examine the calls made to ASPI.SYS and determine what CDBs were being used based on that.

Overall, I also did check my Linux box’s dmesg output and it seems data corrected events do not have any “sense” information sent from the drive to the host as information, so it’s likely that it can only be found by polling the drive. Furthermore, I did check the mode pages between using protected and unprotected cartridges, and it turns out there was no changes even in the un-labelled mode pages. Therefore, the cartridge manufacture date information and protection must be queried by a different command.

Conclusion

It seems that there is more information that meets the eye, and Steve Gibson’s utility shows us that the ZIP drives do actually have status information that provides more details about the errors occurring during usage which Iomegaware Tools do not provide. This information doesn’t seem to be provided to the host system automatically, so it’s likely a poll operation with a custom command is used to read the last error/error address from the drive. Again, custom commands seem to be involved, of which no other utilities I know had gone to this depth of reporting.

It shows that ZIP is a relatively complex medium with active defect management as part of its DNA. Its reliability is likely attributable to this “always-on” defect management which seeks to “repair” any firm and soft error sites on a continual basis, and doesn’t hesitate to mark out new firm-error sites in the normal operation of the drive. The retry algorithms and the ECC seem sufficiently complex to do this without data loss, providing adequate “warning” of any failing areas before data is actually lost. However, such systems leave us with the perpetual fear that a bad drive with a broken cache buffer RAM could corrupt a disk during such in-place repairs, a marginal drive could diminish the recording quality of a disk, and one-off freak occurrences (single bit flip events) could also cause corruption of the written data. ZIP is not alone in having this as a possibility, but those working to recover the data from ZIP cartridges should be aware that reading them will potentially modify them forever.

That being said, the process of reading and modifying the cartridge inadvertently may in some cases be beneficial, similar to the occasional rewrite that Samsung 840 EVO TLC SSDs do, in order to refresh weak areas before the data is lost to the point that ECC cannot recover it. But it is a risk that floppy disks do not have, as their controllers generally do not rewrite anything unless explicitly told.

ASIDE: Sadly, just in time for Christmas, Telstra bought me and the adjacent few streets some bad copper line and water “mixture” resulting in a dramatic loss of ADSL2+ throughput and stability problems with the home connection.

5min-stable-2912-127

With lines that are waterlogged, the connection SNR jumps around dramatically, and despite looking like there is adequate margin at 2912/187, there isn’t, and within ~5 minutes, the link is often lost. Being at 2912/187 when formerly just yesterday we were running 9170/1020 is a big shift, but about six years ago when we started ADSL2+ service, we had 13800/1020 to 14200/1020. This is exactly why we need to get rid of the ageing copper, rather than buy it out! You can thank the infinite wisdom of the Liberal government for that decision.

Anyway, the fault itself was reported to TPG Forums, although nobody’s really looking at it today, but the most useful thing is to look at TPG’s Speed Map which allows you to check what your neighbour’s sync rates are like.

newstatsAs it turns out, the slow sync rates are basically in the couple of streets near me, where they used to be all 8-12Mbit/s down and 1Mbit/s up, now they’re looking at 3-4Mbit/s down and 0.18-0.53Mbit/s up. Good to know I’m not the only one, but not having reliable internet, or a link at all, during the Christmas break is certainly not most people’s idea of having a “good holiday”.

As a result, this post came to you courtesy of my “backup” – i.e. Telstra Mobile Data via 3G (mainly because I have no LTE class equipment) using up a few of my precious megabytes. Still beats being disconnected!

About lui_gough

I'm a bit of a nut for electronics, computing, photography, radio, satellite and other technical hobbies. Click for more about me!
This entry was posted in Computing, Tech Flashback and tagged , , , , , , . Bookmark the permalink.

4 Responses to Tech Flashback: More ZIP Defect Tests & Trouble In Paradise Utility

  1. matson numeric says:

    Is today’s disc under test (DUT) same as yesterday’s Cartridge #3? Do we know what format is Manufacture Date reported by Iomegaware/Iomega Toolbox/Zip Tools? If DUT is Cartridge #3, then format cannot be simple yyddd (22nd May is not day 258).

    If ever again you perform this write-protect experiment, then I request you test yesterday’s Cartridge #1. Because of three cartridges, it was the only one whose PLIST changed, and its PLIST did change in all four drives.

    I probably completely forgot about Trouble In Paradise, or was not ever aware of it. Neat. I guess most users were never aware of it. Further, I did not know mtools had special ZIP features. I did know, Iomega released a binary application for at least one Linux platform.

    I wonder whether Floptical and LS-120 drives provide defect lists.

    Thank you for all of your interesting work, Gough.

    • lui_gough says:

      Today’s DUT was indeed #3 from yesterday. I could retry with #1, although I think one of the potential issues is that whether the PLIST change continues to happen (flip-flop wise) or whether the changes experienced yesterday were a result of the cartridge being relatively fresh and unused, and the factory pre-format was being “questioned” and rectified by the drive (young cartridge).

      The cartridge date reported by IomegaWare Tools is most certainly the correct one and is likely yyddd – the date I named was the label date of the version of ZIP Tools on that disk, not the actual disk itself.

      I hope that clears that up. Maybe I’ll give #1 a quick spin and let you know.

      – Gough

    • lui_gough says:

      Dear Matson,

      Performed the experiment as requested, with immediate results:
      http://goughlui.com/2015/12/23/experiment-zip-defect-lists-software-enabled-write-protection/

      – Gough

  2. matson numeric says:

    Doh! I ignored that © next to MAY 22, 1996.

Error: Comment is Missing!