I get a lot of enquiries about the driver that I have written for
the Philips CM 205 CDROM, and I do not want to answer the same
questions over and over again.  So please read this file
carefully *before* you mail me about your problem!


First of all, there are lots of Philips CD-ROM drives.  They
include:

CM 205: This is the drive, which my driver was written for.  This
	version of the drive (read carefull: drive, not driver)
	does not support the multisession (photo) CD-ROMs.

	The latest version of the driver is found in a file
	called /pub/Linux/kernel/patches/cdrom/lmscd0.3c.tar.gz
	on sunsite.  Soon there will be a file lmscd0.3d.tar.gz
	in the same directory which adds LMS support to the linux
	kernel 1.1.82 or newer.  Thanks for Martin Seine for
	keeping my driver current (he did follow the latest linux
	versions, while I did not).

CM 206: The double speed version of the 205.  It uses an 16 bit
	interface card (CM 260).  This drive is *not* supported
	by my driver.

CM 205MS: This is the new version of that drive, shipped from
	approx beginning of 1994.  It is *not* supported.  Using
	my 205 driver with the 205MS drive results in an error.
	First, the adapter is reset and identified correctly, but
	detecting the drive fails.  The drive's light starts
	blinking in funny colors (green - yellow - yellow or
	something like that).

	Both the 205 and 205MS use an 8 bit interface card, which
	is called CM 250.  I am not aware, though, whether 205
	and 205MS use the same interface card.

CM 207: Again, a double speed drive.  But it does not have a
	propriety interface, but connects to the (enhanced?) IDE
	bus.

There are several more drives.  Some are SCSI, and should work
with Linux, if your SCSI controller is supported by Linux.  Some
are real old (2 years or more) with an propriety interface.  So
few people have them, that it should not be worth the effort to
write drivers for them.


I am often asked, whether I or someone else is working on a
driver for his particular drive.  Well, I am not working.  I am
quite busy studying Physics right now, and doing only occasional
programming to earn some money.  So, if you gave me some money,
I could write a driver, but it will be cheaper for you, if you
spend your money on a different drive.

One person is working on adding sound support for the old 205
drive.  He is halfway through, so expect sound support to come
out by March 95.  Until then, you can use a feature of the
drive, which is not described in the drive's user manual: press
the volume knob to start playing an audio CD, and press it once
again to skip forward to the next track.

There is also an early ALPHA version of a driver for the 206
CD-ROM.  Unless you are eager to help developing, it is probably
better to wait.

Several people ask me, if I have documentation about the new
drives, so that they could write the driver themselves.  Yes, I
have the docs, they are printed material.  But let me issue a few
words of warning, first.  Several people attempted to add support
for the CM 206 and/or CM 205MS.  So far, all of them have given
up.  While writing device drivers is always hard, the Philips
drives appear to be especially complicated.  I want to explain,
why:

There are two serial lines between the adapter card and the
drive.  One of them is an asynchronous 19.2 kBaud line, and is
driven by UARTs, which have no cache.  This line is used to
transfer commands from the computer to the drive, and status
information back from the drive to the computer.  These are
typically between 10 or 20 bytes at a time, and on a time sharing
system like Linux, you do not want to busy wait while 20 bytes
have made it through a 19.2 kBaud line.  So you have to send the
first byte of a command, then call sleep_on() to change to some
other tasks.  After that first command byte has been transferred,
the adapter will send an interrupt, and your interrupt handler
can send the next byte.  Of course, the interrupt handler also
has to handle the error conditions, which may occur, and must not
forget to wake up the original process, once the command has been
successfully transferred, or uncuccessfully aborted ...

The second serial line is a high-speed (2.8 or 5.6 MHz in case
of the double speed drive) synchronous line, and is used to
transfer the real data, which was read from the CD.  In the
adapter card, there is some cache (32k or 64k) to hold a copy
of the data, which was received from this line.

Again, an interrupt request is generated, when a full block of
data has been read from the drive.  Another job for the interrupt
handler.  Furthermore, the CM drives do not read ahead, so that
you suffer a big performance decrease, if you read small chunks
(less than 100 kilobytes) from the CD-ROM.  So the driver always
reads very big chunks.  But that may require you to abort a read,
because the chunk was choosen to big.  Now, while using the slow
serial line to transfer the "ABORT READ" command to the drive,
another block of data may come in on the fast line.

You probably got it.  Lots of things can go on, and they happen
all asynchronously.  Race conditions lurk everywhere.


Nevertheless, have fun with your drive.

Kai
