MAC TIP Diagnoses Your Old Zip And Jaz Drives

Trouble In Paradise (TIP) was a popular Windows-only tool for troubleshooting  Iomega Jaz and Zip drives way back when. The drives have fallen out of favor with PC, but the drives are still highly prized amongst classic Mac collectors, who use the SCSI versions as boot disks for the vintage machines. Thus, [Marcio Luis Teixeira] set about porting the TIP tool to the platform.

Macintosh utilities used to have so much personality about them.

It all came about because running the original TIP recovery tool became difficult in the modern era. One must dig up a old Windows 98 machine and SCSI adapters in order to use it with Macintosh-compatible Zip or Jaz drives. This inspired [Marcio] to reach out to the developer, [Steve Gibson], who provided the original x86 assembly code for the tool.

[Marcio] then ported this line-by-line into C and compiled it with a retro Macintosh compiler to get TIP up and running on the classic Mac platform. Now, it’s possible to check and test Zip and Jaz drives and media on your old Mac without having to mess around with a vintage Windows machine.

It took plenty of effort, and the generous donation of code from [Steve Gibson], and all involved should be applauded for their work. It’s not every day we see such an impressive port, but they come along every now and then.

Meanwhile, if you’ve been tinkering on your own projects with Iomega’s classic removable storage, don’t hesitate to let us know! Video after the break.

23 thoughts on “MAC TIP Diagnoses Your Old Zip And Jaz Drives

    1. I don’t remember there being a fix. Zip disks were a bernoulli style drive where the read/write head was in direct contact with the disk.

      If you were getting firm errors it was either because the head was damaged or the disk was fubar. If it was the disk you’d chuck it and pray it did nothing to your drive. If your drive head was damaged you stopped using it so you didn’t damage your other disks.

      1. THIS. there were also disks that would induce the ‘click on death’ on zip drives as the disks were damaged in a specific way that would damage the heads on insert. it was still remarkable robust despite this rather easy manner of damaging both the media and the drive in one go.

        Also, Mr. Gibson’s software all had a certain ‘Je ne sais quoi’ with them that told you that a real human wrote it, that the human had a bit of a sense of humor about it. Spinrite was, for it’s time, an outstanding application for what it did.

        1. Yeah, I think “bernoulli” refers to the heads being tweaked just right to fly just above the platters, basically on ground effect. The Iomega drives were innovative in that they were basically relied on hard-drive tech, but put the heads in the drive and the platters in the cartridge. Usually that was considered a bit too risky, which probably feeds into the reliability issues …

  1. Zip drives are how I usually transfer data between a modern Mac and my 68030 Performa 400 (aka LCII) and also how I boot up my Mac Plus. I have a USB 1.1 based Zip250 (which can read/write 100Mb cartridges) and a SCSI based Zip100. It’s an interesting tool and I might try it, however my Zip 100 is 25 years old now, so I would have thought it would have gone into click of death mode by now and if it didn’t – I’m not sure how easily I could replace it, since I guess SCSI Zip100s are rare.

    1. I used to “network” an Amiga and a PC back in the day by sharing a SCIS bus and a drive on it between them. HD’s bit more reliable than a zip disk – which I had several off back then too, SCSI, IDE and PAR.
      Never had problems with accessing files on either side, it was all data not programs.

      The big problem I used to have back then was with NT4 on systems I was forced to use which would often replace the filetable on your zip disk with that of the previously inserted disk. And it was random. So when going to the labs would always take a couple of otherwise blank disks with the files wanted to work on and thus had a “backup”.

    2. The SCSI drives are hard to come by, but the parallel port one are easy to find on eBay. The read/write mechanism is the same, the only thing that is different is the motherboard. I’ve successfully swapped the mechanism from one to another. So simply keep your SCSI motherboard and you can easily replace the guts of the drive with another.

  2. Iomega tried for a while to make software that installed to a Zip disk and kept its data on the Zip disk. Pop it into a Zip drive connected to a computer then the program could launch and be used, leaving no trace behind when the disk was ejected.

    I beta tested a photo viewer Zip app. It was underwhelming and wasn’t much use with really large photos since a Zip 100 holds a bit less than 100 megabytes. On a Zip 750 it would’ve been more useful but I think Iomega had abandoned the run from Zip thing by then.

    The other thing I beta tested from Iomega was a CD-R burning program. Apparently they weren’t happy with my fast evaluation of their software. Their programs at that point in development functioned perfectly. I ran them through their paces in the span of a couple of hours and nothing went worng. The only thing I found to point out was a spot of graphics offset out of place in the CD burner UI.

    What’s the point in doing exhaustive, days long testing procedures on one-trick-pony apps *that work perfectly* out of the box? I reported everything I did, and that there were no issues. No crashes, blue screens, corrupted data etc.

    Back then it would’ve been nice to have been chosen to beta test the Zip CD-burner because testers got to keep the drives. All I bagged out of it was a free Zip 100 disk that came with the photo viewer app on it. Testing done, format it and put something useful on it.

    Testing something more complex, at an earlier stage of development, that’s where the exhaustive testing needs to be done, where weird edge cases crop up due to one tester having some other software or a driver installed that no other tester has, but an unknown number of paying customers might.

    1. The PowerBook is booting from an internal CompactFlash card via an IDE adapter. I occasionally use Zip disks to boot my Mac Plus, but to run tests you would either need some other boot medium to run the tool from or you could create a RAM disk and run the tool from that if the Mac has enough RAM.

  3. for the click of death reason i switched to MO drives and media. 230Mb to be exact. I have two portable olympus drives and a box full of media for the macs, sampler, nextcube and modern machine (max os x and linux) this is my main transfer methode.

  4. A couple of blasts from the past for me: Marcio Luis Teixeira, who I used to teach with a long time ago; and Steve Gibson, whose tools were the basis for a lot of my early desktop support career.

  5. It would be really cool to see this ported to linux as a regular fsck-style commandline diagnostic tool. The GUI would have to get changed out for commandline arguments and printing status messages, but the core testing procedures and logic could remain the same. All you’d need to do is strip off the GUI and port it to linux’s SCSI interfaces.d

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.