S-Link Parallel Device for Linux

Last Update: February 2, 2003

Credit Where Credit is Due

For a list of good links to other projects and experiments using S-Link and Control-A1 please visit the credits and references page.



The Software

Exciting news for those that have been asking! We finally posted a large piece of source that uses the slink parallel port driver. The first jukebox complete with source is now also available on the download page. This is dead code which Brian and I have abandoned for other projects. It isn't bug free, but it works and we'd love to see it get some use or improvement by someone with more inclination to work on it!

Also on the download page is the version 3.0 device driver package. To use the 3.0 driver a 2.4.x kernel is required, and any version other than 2.4.18 is recommended (see download page for details). As a reward for updating your kernel, there is much improved functionality, and slightly better error control added. As usual, Brian gets the credit for playing in the kernel space. Enjoy the new version.

The driver uses the parallel port and the hardware described below to transmit slink/control-a1/IR over the parallel port using a Mendelson-like encoding scheme. See the download page for details of the various driver versions.

S-Link Device Driver Packages



The Hardware

There had to be a catch didn't there?

Build your own parallel port adapter to send Control-A1 / Control-A1 II (Commonly called S-Link) and Control-S commands using the linux device driver and tools available on the device driver download page.



The Protocol

S-Link and Control-A1 use a relatively slow serial like protocol to transmit data. A description of the transmission style itself is detailed under the heading Control-A1 Encoding. For those of you not particularly interested in the details of how to talk to the decks at the hardware level, the following summary will suffice to use the device driver correctly to get your messages across.

Each device has at least two device identifiers. One for sending data and one for recieving data. In the case of CD changers the following applies:

Device Command Code Response Code



CD Player 1 0x90
0x93
0x98
0x9B
CD Player 2 0x91
0x94
0x99
0x9C
CD Player 3 0x92
0x95
0x9A
0x9D
ALL CD Players 0x97
(200 or less disc players only)
0x93, 0x94, 0x95

Now that looks a little confusing I know. The reason is a work around to address more than 100 and then more than 200 discs. The first two hundered discs are addressed using the lower command/response device numbers. The first hundred are numbered in BCD (Binary Coded Decimal), the second hundred are in hexadecimal starting at 9A and going up. The second command/response device numbers are used to address discs over 200. They are numbered in plain hexadecimal. Clearly this wasn't thought through in the beginning. The general formats of a command and response are:

Command: [device code] [command code] [extended data...]

Response: [device code] [response code] [extended data...]

For those of you using the version 1.0 device driver from this site, I will say right now that you won't see the whole picture. Some basic assumptions about the structure of information exchange from the decks were made for this piece of code and as a result some information is inadvertantly filtered. We are now recommending anyone using the 1.0 driver download either the 2.0 driver or 3.0 driver depending on your kernel preference.

Both of these more recent revisions of the driver correct this short fall as well as implementing a way to send infrared remote commands across the same bus. The commands and responses are formatted primarily for the standard slink commands and all of the IR codes are lumped under one command code. This isn't how they are really sent, but it allows elegant integration into one command structure.

We still don't understand all of the commands and responses, but the existing lists are fairly complete and quite powerful. It is possible to chain two CD changers on the same slink bus and control them from a PC. They must be staggered correctly however or they identify each other and tend to issue unwanted commands without your permission. My pair is set to CD1 and CD2. If you need more than two changers, you'll need to put them on seperate busses and use the 3.0 version of the device driver.

There are cross-fade controls and feed through inputs on more expensive CD changers. These can be forced using the IR remote commands, however they only work in "Megacontrol" mode, which cannot be enabled unless the decks identify each other on powerup. This is catastropic for computer remote applications due to messaging sent by the decks that interferes with remotely generated instructions. So, while the cross fades are there, we have found it better to just issue independant fade-in and fade-out commands to the decks and create a cross fade effect manually.

If anyone is interested in an example of just how much can be accomplished using this hardware/software solution, our jukebox project is continuing to move forward amid the various associated distractions. The ANSI version of the jukebox shown on this page is now avaiable with the source on the download page. This may be a good starting framework to work forward from or just an elaborate and functional (if somewhat buggy) test program to play with. Related to the newer client/server jukebox is the cd24 identification specification which is now officially released as version 1.0 at www.cd24db.com. With the release a first database of 250,000 records has been made available. Unfortunately the only tool which uses the database is unfinished and kinda clunky. Check it out regardless.

So, with that I'll leave you to experiment and explore. -Jeff