Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!nic.csu.net!beach.csulb.edu!csus.edu!wuarchive!sdd.hp.com!caen!hellgate.utah.edu!fcom.cc.utah.edu!npd.novell.com!newsun!rbailey From: rbailey@kinetics.com (Robert Bailey) Newsgroups: comp.sys.mac.hardware Subject: Re: Reviews of Non-Apple CD-ROM drives (Summary) Message-ID: Date: 12 Apr 91 18:53:14 GMT Sender: news@novell.com ( Lines: 55 The News Manager) Nntp-Posting-Host: plasma Reply-To: rbailey@wc.novell.com Organization: Novell, Inc. References: <7188@mace.cc.purdue.edu> <1991Apr8.205628.28550@cs.ucla.edu> <50@goblin.ntg.uucp> Distribution: usa Date: 11 Apr 91 17:27:50 GMT In <50@goblin.ntg.uucp> dplatt@ntg.uucp (Dave Platt) writes: >In article <1991Apr8.205628.28550@cs.ucla.edu> tj@kona.cs.ucla.edu (Tom Johnson) writes: >>If you are using it purely for data, it's works fine. The drive is indeed >>faster than the Apple, and we have had no compatibility problems >>with it whatsoever. >> >>If you are using it for playing audio CDs, watch out. The Toshiba driver, >>does not support all of Apple's music calls. You have to use Apple's >>CD Remote desk accessory and INIT to play disks, but you can't scan >>thru the disk (no fast-forward or rewind). You can jump to different >>tracks, if you wish, you just can't fast-forward into the middle of >>a track. --lot's o' stuff deleted >The underlying technical issue is, I think, that the Apple and Toshiba >drives have slightly different command sets and status responses. This >is due, I think, to the fact that the SCSI-1 standard did not include a >command-set for CD-ROM drives, and so each vendor was forced to invent >one. The newer SCSI-2 standard does define a common language for >CD-ROM drives, and the next generation of such drives will probably be >much more intercompatible. Actually the problem is more that when Apple defined the set of Control and Status calls that their driver accepts they did it such a way that some of them are highly dependant on the specific command set of the Sony mechanism used in their CD-ROM drive. So when another vender tries to write a driver for another drive it is difficult or impossible to accept all of the possible calls. They aggravated the problem by distributing Hypercard XCMDs, etc. that have effectively established their set of Control/Status calls as a standard. So the problem is not that the command set of the drives is different, but that the driver's Control/Status calls are badly chosen. An analogous situation would be if Apple were to use a HD drive 'X' that had a non-standard command set. They then define a set of Control calls that a HD driver had to accept that depended on 'X's wierd comand set. The File Manager was then made dependant on those calls being accepted. You would have a situation whereby only HD drives made by 'X' would be usuable on a Mac. Now you have a similar situation: multimedia CDs use Apple's XCMDs to control audio playback. CD Remote is used by everyone. And because Apple didn't take a bit of time to look at the specs of any CD-ROM drive besides Sony's, driver writers have to jump through hoops just to make a non-Sony drive behave like a Sony, and often times it is impossible to do a complete job. The only solution now is either for other companies to copy Sony's command set, thus effectively creating an Apple-compatible standard, or for Apple to redesign the interface to their driver to be in line with whatever standard emerges for CD-ROMs. (fat chance.) Robert Bailey rbailey@kinetics.com