FireWire drives and drivers: Radialogic and Retrospect: a follow-up

This item gets fairly technical, but it also offers some interesting tidbits concerning FireWire drives and driver software that are relevant to more than just the specific issue covered here. Regarding our previous coverage of a possible problem with Radialogic drivers and Retrospect, Radialogic offers this further reply: "Retrospect does support talking to our drivers since our drivers speak SDAP, but there was a bug with earlier versions of their SIM that caused problems." This is what Dantz had to say: "There was a problem with the initial SDAP SIM we shipped that the Radialogic drivers brought out with unplug and replug that could cause us to hang when scanning for devices. It would only happen in the case where the Radialogic drivers would change the driver refnum on an unplug/replug and the SDAP SIM cached the old one to try and speed up scans and would hang when Retrospect scans for devices. Otherwise, there is no issue. We are just using the file system to write to the disk. We fixed this case and are sending it to customers who need it and have remastered all our CDs to include it. I will ask someone to send this to you in the next day for your testing." Meanwhile, Paul Derby (who first reported the problem) writes: "Radialogic's reply is true. However, if you are writing to a Mac FireWire fixed drive, as opposed to removable FireWire devices, then you have to disable the 'Retrospect SDAP Support' extension. This SDAP support extension was intended only for use with the removable FireWire devices such as ZIP drives, CD-RW drives, etc. With this extension disabled, you are then using whatever native FireWire driver you have installed. (Hopefully you don't have two native drivers installed, or you will have problems). With "Retrospect SDAP Support" disabled I can read and write to my Fantom drive just fine as long as the reads and writes are less than 500K blocks. If any application, including Retrospect, tried to read a 1MB block the PowerBook hangs and I have to do a restart. This situation is unique to the PowerBook, not to the desktop machines with FireWire ports. Fantom claims that some of the FireWire Bridges, made by Indigita, do not allow large block reads and writes. So the problem isn't between Dantz (Retrospect) and ProSoft (Radialogic), but a difference between the FireWire ports on a G4 desktop and the Pismo PowerBook with the Indigita bridge not accommodating these difference. This brings up the point...why did Apple design FireWire so that native drivers are required by the< various manufacturers....and only one native FireWire driver at a time can be active? This results in an extremely complicated end user situation if you have to enable/disable drivers every time you change FireWire devices. Being able to hot swap devices and add devices on the fly is worthless if you have to change extensions via enabling and disabling drivers." Radialogic replies to Paul's question: "Why did Apple design FireWire so that native drivers are required by the< various manufacturers...?": Apple was put in a rather difficult situation with FireWire and USB. Both technologies were brand new and thus greatly "in flux" - not the specs about communicating over the bus itself, but dealing with all the hardware that can be put on the other end of the wire. Mass storage is uniquely difficult because even today there are no solutions widely available with a mass storage device that speaks FireWire or USB natively. Every hard disk or Zip drive or CD-RW you buy is usually an ATA or ATAPI (very rarely SCSI) device that is connected to FW/USB via what we call a bridge board. And every bridge board is different and has its own peculiarities. For Apple to commit to supporting every bridge board and every possible device you could connect through every bridge board is a monumental and difficult undertaking. So Apple chose the simpler approach: design a system where 3rd parties can write their own drivers and a loading scheme whereby each driver identifies which types of devices it will work for and then Apple's FireWire code picks the one that matches "best" according to the criteria. By the way, with Mac OS X drivers, this situation will improve. People will still need to create drivers for each device, but the idea of a driver in Mac OS X is much simpler than in OS 8/9.