PCA Forums

Client has a Duron 750 system, P.O.S. Transcend AKT4/A mobo (VIA chipset). Running Win98SE.

The IDE Zipdrive is acting very strange. If you copy anything to the zip drive it starts copying very quickly (the normal speed for an IDE Zip) and then around 20% of the way it slows to a crawl.

It will eventually finish but it takes a LONG time (like 20+ minutes to copy 70Mb of files). I've noticed the same problem when formatting (either quick or normal). Format starts out normal speed and the 25% or so takes a long time.

Otherwise it works.

I've done the following with no effect:

- Tried several different disks including one of my own I carry. All do the same thing. Not the media.

- Uninstalled the Iomegaware software (you don't really need it with the internal IDE drive and I don't like to use it anyway). Didn't help, just more stable (the Iomegaware likes to lockup if you try to cancel the file copy). It's staying off - I don't like using that Iomega software. FIVE friggin' background files.

- Changed drive from slave to master (it's on the 2nd EIDE port by itself)

- Swapped drives (client had a spare unit in another old computer in the closet - different brand, one is an Iomega the other is NEC. Both do the same thing so it's not the drive.

- Upgraded to latest VIA 4-in-1 drivers (it had old 4/99 drivers installed). No improvement.

- Changed the IDE ribbon.

I'm stumped. I can't find any reason for this. According to the client it's always done this since he bought it. It's a custom built rig by one of my competitors.

Worse comes to worse I'll trade him one of my parallel port Zip drives I have lying around for his IDE, but I would like to know WHY it doesn't work.

Anyone know of any compatibility issues with Zip drives? I was going to do some research on the newsgroups and KB when I get back from Miami next week.

Zip drives had an issue with the read/write head awhile back but I think that only applied to the externals.I belive it was called the "Click of death" due to the constant thrashing. I'll try to see If I can find a notice I had somewhere that listed the models.Also there was a software test floating around
but if I have it it's buried somewhere.I think in your case you may want to take the drive and try it on a diffrent board first. lmk and I'll look for what I have lying around.
Bill

not sure but i think its the drive itself, i myself got a driver for windows 2000 to speed up transfer and wrting to zip drive. Might wanna give it shot at drivers section at iomega.com. Hope this helps.

David

FP,

I don't know if this will help or not.

Gibson Research Download Page

Scroll down and look for "Trouble In Paradise"

MAC

Don't think so, but thanks. Nice utility for the service kit.

interesting - i still have a bunch of zippers, internal and external, but haven't seen that problem - i had some disks that were acting odd - but a full reformat cured them

dosn't sound like the ol' click of death either - almost sounds like some sort if buffer is filling and then draining slowly

I had a hard drive that had the click of death a while back. Hated to lose it. It was a 15gb WD. Not a big drive by todays standards, but it was still a good drive. Anywho.. That's my two cents. I thought originally while reading the first thread by FP that it may have been one of the motors in the zipper, but then he said that he swapped them out and to no avail. Does it do it w/a parrallel port zip? Or have you tried that yet? Just curious. eGo

Going out of town for a LAN party but when I get back next week I'm going to try one of my spare parallel port drives on it. If it works I'll probably work out a swap for one of his IDE drives.

Has to be some kind of IDE controller issue is my guess.

Guys:

This is not a "click of death" issue. That "Trouble in Paradise" software is only for checking a zip disk to see if it has bad sectors. The click of death was associated with the zip read head not being able to read the tracks properly - usually due to physical damage on the edge of the media. The software works well, and I recommend it to anybody that has a zip disk.

Now the problem with the internal IDE zip disk is a strange one. It does sound like a controller issue. I have four machines all running internal zip drives. One machine is has the W2K operating system, the other three use W98SE. I am running all the zips on either separate controller cards (SIIG ultra-66, SIIG ultra-133), or on a spare IDE port by itself. In all cases, they are set to be the master. All drives transfer files without problems, and quite quickly too. I found it was difficult to install the zip drives as a second drive on the IDE chains, and that's why I elected to use separate ports or controller cards.

FlyingPenguin tried all the quick checks I would try. I would still install the latest Iomega software, even if it leaves a number of programs running in the background. This is the only way to write-protect the zip disks, should you desire to do so. I think that after reading everything he did, the problem is with the mainboard, and the only solution for using the internal IDE zip drive is to get a cheap PCI controller card. An ultra-66 card is real cheap (maybe $20), and for a few bucks more, you can get an ultra-133 ($30). Besides, it gives you more ports to add optical drives on!

FOLLOWUP: Installed one of my Parallel port ZIP drives on the client's system and it works fine. I swapped him for the internal IDE drive. I'm certain there's nothing wrong with it but I'll install it in my customer loaner and try it out.

I guess his IDE controller just doesn't like ZIP drives.

I only mentioned the C.O.D. because it was the only problem I ever heard of that warranted a notice from the company as far as I knew.My drive sits in a box somewhere and never gave me a bit of trouble.
I was gonna look for the paper incase there was another issue I didn't read.Sorry.I think WVJohn had a pretty good idea worth looking at though.
Bill