[Damien]

I'm hoping that those of you with one of the new G4 towers with a CD-RW drive (133MHz logic board) and an internal zip drive can help me out with this problem.

I've seen the following behaviour on two machines now (one 466Mhz model, one 533 model) and have come to the conclusion that perhaps I've discovered a new undocumented problem with these models. Before I contact Apple further about this issue, I wanted a little more information.

If you have one a machine with the abovementioned combination, I'd appreciate it if you could answer the following questions to the best of your ability.

1) Did you install the zip drive yourself?
2) Are you experiencing any problems copying large amounts of data (20+) to or from your zip disks?
3) Do the copies cancel out with a Disk I/O error about midway through?
4) During the copy process, does the mouse become very "jerky"...like the copy process is using 99% of the computer's processing power leaving nothing for normal Finder operations like mouse movement, opening windows, etc.?
5) If you are experiencing these problems, what have you done to troubleshoot the problem? Are you running the Iomege 6.0.8 driver? (6.0.9 was removed by Iomega for unrelated reason).

Please respond to this query even if you aren't having these problems but have this combination fo hardware. It'd help give me an idea of ratios, percentages, etc.

I'll do my best to check back here for reponses, but email is appreciated.

Email me: [email protected]

Thank you! If I discover the problem, you can be sure I'll report it back here.

Note that I work as an Apple Certified Technician in Manhattan and fix these things for a living. This problem is not related to some software misconfiguration/conflict or faulty hardware issue--I've more or less ruled out everything but a hardware conflict, and am looking for numbers, even if they don't support the possibility.

Damien Barrett

[Bugs Bunny]

1) Did you install the zip drive yourself?
Yes

2) Are you experiencing any problems copying large amounts of data (20+) to or from your zip disks?
No

3) Do the copies cancel out with a Disk I/O error about midway through?
No

4) During the copy process, does the mouse become very "jerky"...like the copy process is using 99% of the computer's processing power leaving nothing for normal Finder operations like mouse movement, opening windows, etc.?
Normally no, but I have seen this happen a few times.

5) If you are experiencing these problems, what have you done to troubleshoot the problem? Are you running the Iomege 6.0.8 driver? (6.0.9 was removed by Iomega for unrelated reason).
Running Iomega 6.08 driver, never moved to IomegaWare 3.

G4 533/512/40/Zip(Internal)

[zac4mac]

Damien,

Sounds like you are describing the problem Zip 250's have with 100MB disks.
Do you see these issues with both 100 and 250 MB disks?
My config is different(DP500 Giga/DVD/Zip-100 BTO), but I have no probs with mine.

Zack

[Damien]

Thanks for replying.

Just to clarify. This problem happens with both a Zip 250 and a Zip 100 drive, regardless of which is installed in the computer.

And it's not a master/slave or jumper-setting issue. I've checked these settings a zillion times and tried numerous combinations. No go.

And on one machine, I've replaced every component in the computer: logic board, processor, CD-RW drive, zip drive, IDE cabling on both buses, RAM, everything short of the case itself.

Thanks for the suggestions though. Still struggling with this one.

One reply from the Mac-Mgrs mailing list said that he'd seent this problem with some older Beige G3 computers in his labs and the workaround was to put a CD (any CD) in the drive. I tried this and it WORKED!! For some reason, having a CD in the drive allows the copies to/from the zip disk to work properly. I've been doing this for a long time, and it's not often I encounter something this strange.

Damien Barrett

[Xaositect]

Not strange at all. Remember how IDE works - the controller consists of three parts working together (main CPU or DMA, IDE bus chip, chip on master drive). The slave drive's chip is only partially used. Some IDE bus chips (on logic board) do a general broadcast for all clear rather than specific to the device it's supposed to be talking to. If the slave drive is the current target, and the general all clear query is made, the master must also respond. On some removable media drives, the drive will check for media if it thinks it doesn't have any before responding (drive chip set dependant). This can delay the next packet, even to the point of timing out the transfer (usually reported as a general I/O error).

Not strange, but not easy to see except in hindsight.

[Damien]

Okay, that definitely sounds like the problem we're having...data copy doesn't happen and reports the general I/O problem...but...

Is there any way to fix it?

You're implying that this slowdown and copy I/O problem is normal for an IDE bus? This is acceptable? In all my discussions with Apple technical support, not one of the engineers has mentioned that what I'm experiencing is "normal behaviour".

Could you provide for me some insight as to how to fix this, or even something I could suggest to the Apple engineers next time I talk to them?

Thanks,

Damien Barrett