CDio Writing/Reading CDs and Recommended CD writers FAQ Carsten Koch, July, 1996 1. Writing CDs. In order to write CDs using an SGI system, you need a CD writer (hardware) and a writer driver (software). The writer driver can be implemented in the kernel, i.e. treating the CD writer almost like a hard disk, or it can be a user-level SCSI driver that just transfers file system images (for CD-ROMs) or sound files (for CD-DA) to the CD-recordable disc. All SGI writer drivers I am aware of are user-level programs. 1.1. Free writer drivers. 1.1.1. mkdisc. There is a writer driver called mkdisc on the SGI Developer Toolbox (DT) CD and web site. The only CD writer supported by mkdisc is the Sony CDW-900E (and its predecesoor, the Sony CDW-E1/CDW-W1). The CDW-900E is somewhat outdated (1993) and very much overpriced according to today's standards. Also, mkdisc only supports CD-ROMs, i.e. data CDs. You cannot create audio CDs, etc. with it. The DT also contains a shell script "make_efs" that creates an SGI EFS image which can be transferred to a CD using mkdisc or other writer drivers. Starting with DT version 4.2, Eric Youngdale's (Eric@aib.com) program "mkisofs", which creates an ISO 9600 CD data image, is also included. mkisofs can also be found on ftp://tsx-11.mit.edu/pub/linux/BETA/cdrom/mkisofs Note that the CD-writing stuff is missing in the DT 5.0 CD, but it does exist in older versions, such as 4.2 as well as in the 6.0 CDs and on the DT web site. DT CDs are shipped to registered SGI developers. Send E-Mail to devprogram@sgi.com for details. 1.1.2. cdwriter. Paul Bruggemann (bruggemn@netcom.com) has ported the Linux cdwrite writer driver to IRIX 5. Paul has tested the ported program with his Kodak 225PCD writer, but the Linux original was written for the older Philips writers, so it can be assumed that Paul's port still works with some Philips writers. This software is avaialable from ftp://ftp.netcom.com/pub/br/bruggemn/cdrom/cdwriter.tar.Z 1.1.3. WriteCDR. I wrote a writer driver that supports the Sony CDU 920 and the Yamaha CDR 100 both in data and in audio mode (it can write AIFC files directly to an audio CD). This program, together with ReadCD, a program that can read file system images and audio tracks off a CD (see 2.3 below), has been included in the SGI DT and can be found on the DT web site https://www.sgi.com/toolbox/src/apps/CDio and the 6.1 version of the DT CD set. I am unable to give you any direct support for this software. You will have to go through the DT support if you have questions or if you want to submit extensions for additional hardware. 1.2. Commercial writer drivers. There are many. One example is CDR publisher by Creative Digital Research. Check out their web page at http://www.cdr1.com or download a demo version from ftp://ftp.cdr1.com AFAIK, CDR publisher does not yet support Audio CDs. Also, the SGI version tends to be a bit behind other platforms. The SGI versions of all commercial writer drivers that I am aware of share one common disadvantage: They cost about as much as the sum of the corresponding PC version plus a PC. 2. Reading CDs. Many CD writers can also be used as CD-ROM readers. However, it is questionable whether you should wear off an expensive CD-writer with the workload that a much cheaper CD-ROM can handle better or equally well. Also, as has been discussed in comp.sys.sgi.hardware and the SGI hardware FAQ, IRIX is kind of picky as to which CD-ROMs it chooses to work with. I am aware of the following five problem areas: 2.1. Vendor-specific commands. The SGI software issues Toshiba vendor-specific SCSI commands even to CD-ROM drives that have identified themselves as a non-Toshiba drive. This *may* cause problems with certain drives and/or other devices on the SCSI bus. For example, the Yamaha CDR 100 just times out causing a SCSI bus reset, which in turn may cause other problems. In fact, I have observed a scenario where the bus reset causes the system disk to time out on the next command, which causes another bus reset, etc. I wrote a patcher program that *may* be able to find the offending code in binaries such as mediad and mount_iso9660 and replace the Vendor-specific command with a harmless test-unit-ready command. See the sample source code at the end of this article. 2.2. PF bit in the modeselect command. According to the SCSI-2 standard, host software should set the PF bit in modeselect commands to SCSI-2 drives: "A page format (PF) bit of zero indicates that the MODE SELECT parameters are as specified in SCSI-1, (i.e. all parameters after the block descriptors are vendor-specific). A PF bit of one indicates that the MODE SELECT parameters following the header and block descriptor(s) are structured as pages of related parameters and are as specified in this standard." Unfortunately, IRIX does not always set the PF bit, but some SCSI-2 CD-ROM drives do require it. The most common problem caused by this is the drive not setting the correct block size, causing subsequent reads to fail. As a workaround you can set the required block size with a separate program. 2.3. Audio support. While the Silicon Graphics CD Audio Library was written to make a calling program independant of hardware details, right now it does the opposite: It only works with the Toshiba way of reading digital audio data over the SCSI bus. Therefore, all programs based on this library (including SGI's cdman) cannot play audio CDs with most non-Toshiba drives. I have written a program (ReadCD) that works with any drive that supports the READ-CD-DA SCSI command. It has been tested successfully with the Sony CDU 920S and the Yamaha CDR 100 CD writers and with the Sony CDU 76S CD-ROM. This program is not based on the Silicon Graphics CD Audio Library, but uses the SCSI library (dslib) directly. 2.4. 512 byte blocks. SGI machines can only boot from CD's that contain an EFS filesystem. Also, the driver insists in reading the data in logical 512 byte blocks (instead of the physical 2048 byte blocks that are recorded on the CD). If your drive is not in any way switchable to 512 byte blocks, you're out of luck: IRIX will not boot from it and it will also not mount an EFS CD under the running system. But even if your drive does support 512 byte blocks, IRIX may not figure out how to switch it to 512 byte mode, see 2.2. 2.5. Peripheral device type. Many CD-writers identify themselves as a WORM drive (peripheral device type = 4). However, IRIX does not recognize these as a drive they can read a CD from. In particular, the prom monitor and the sash will not boot from them, mediad will completely ignore them (sorry, no indigo magic desktop icons, no eject command), etc. According to a Sony salesperson, the latest revision of the CDU 920S now has a jumper that will make the peripheral device type selectable between 4 (WORM) and 5 (CD-ROM). I have not yet personally seen such a drive. Some of the problems mentioned above may be fixed in IRIX 6.2. According to SGI, there will be no IRIX 5.3 patches in this area. 3. Recommended CD writers. Most CD-writers are incompatible with the way IRIX handles SCSI disconnects. This means that you have to reconfigure the kernel in order to disable SCSI disconnects, which will have very bad side effects on your system performance (the whole system will freeze at certain times when you write CDs or access tapes, etc.). CD-writers known to have this problem include: Kodak PCD 200, 200+, 225 Philips CDD 521, 521 Upgrade, 522 Plasmon RF 4100, 4102 Yamaha CDE 100, CDR 100 up to firmware version 1.09 CD-writers that do NOT have this problem include: Sony CDW-E1/CDW-W1, CDW-900E, CDU 920, CDU 921 Yamaha CDE 100, CDR 100 with firmware version >= 1.10 Kodak PCD 600. Among the latter ones, I only know the Sony CDU 920S and the Yamaha CDR 100 well. The Yamaha is faster (4x speed versus 2x speed on the Sony), but it does not support 512 byte blocks (see 2.4). So if you care more for speed, I'd recommend the Yamaha. If you need to read EFS CDs from this drive, the Sony may be better for you. Note that both drives can WRITE EFS CDs as long as your writer software supports it. -----------cut-----------cut-----------cut-----------cut----------- /* patcher that replaces vendor-specific 0xc9 command with a harmless test-unit-ready command. use at your own risk. Sample use: cp mediad mediad.orig patchermediad */ #include main() { unsigned long *buf = (unsigned long *)malloc(32 * 1024 * 1024); unsigned long pat[] = { 0x240600c9, 0x0320f809, 0x00003825}; unsigned long l = read(0, buf, 32 * 1024 * 1024); unsigned long i, j, best_j = 0, best_i = l, duplicates = 0; if (l <= 0) { fprintf(stderr, "No data.\n"); exit(1); } else fprintf(stderr, "%u bytes.\n", l); l /= sizeof(unsigned long); for (i = 0; i < l; i++) { if (buf[i] == pat[0]) { j = 1; while ((buf[i+j] == pat[j]) && (j < sizeof(pat) / sizeof(unsigned long))) j++; if (j > best_j) { best_j = j; best_i = i; duplicates = 0; } else if (j == best_j) duplicates++; } } fprintf(stderr, "best match is %u out of %u at index %u. %u duplicates.\n", best_j, sizeof(pat)/sizeof(unsigned long), best_i, duplicates); if ((best_j > 1) && (duplicates == 0)) { buf[best_i] = 0x24060000; write(1, buf, l*sizeof(unsigned long)); } }