> what i want is a _simple_ s-link->serial device that I can build

[been meaning to write a message like this for a while, to contribute something
in return for all the free resources I used during this project.]

I've been down this road. Here's my advice, if you don't want to buy a
Slink-e (I would have, but by the time it came out, I had spent too much
to give up): forget serial. RS-232 is nice, and efficient, but a total
bear to implement, compared to the parallel port.

Coming from someone with almost no electronics background, who's spent
lots of dough deciding that microcontrollers and fancy adapter logic weren't
needed, here's my dirt simple S/Link connector guide:

1) Read and print http://www.doc.ic.ac.uk/~ih/doc/par/ so you know what
I mean when I say "the interrupt pin".

2) Get these parts: a 25-pin male DB-25 connector, a head shell to hold
it, a 2N222 small signal transistor, a female 1/8" mono plug receptacle,
and a smallish resistor (I used 470 ohm, I think -- it doesn't matter too
much), and some high-guage wire (a few inches of it, I used 28 ga., and
solid core is easier to work with than stranded wire). If the computer
isn't near your CD players, you'll also need a 1/8" cable, or an extension
for the existing cable. I used a 25' extenion on a 6' cable with no problems.

Total cost, if you pay top dollar for everything, will be about $10.

3) Solder the bus signal wire (center wire of the mono plug) to the parallel
port's interrupt pin (S6, pin 10).

4) Solder the interrupt pin to the busy pin (S7, pin 11). This is useful
when debugging, but not really needed for operation.

5) Determine which of the three transistor leads are which. They are the
"base", the "collector", and the "emitter". Looking at it from above, they
are ordered clockwise: collector,emitter,base. If your transistor is a
plastic knob-thing with one side lopped off, the collector and emitter
are on the lopped-off side. If it's a metal can with a little tab, the
tab is above the collector. (Someone jump in here if I got these wrong,
it's been a while)

6) Solder the base to DATA0 (D0, pin 2). I put my resistor in between the
pin and the base; you don't have to.

7) Solder the collector to the bus (along with the interrupt and busy pins).

8) Solder the ground pins together (pins 18-25 inclusive) and solder in
the emitter and the bus ground (the outside wire of the mono receptable)
to these as well.

9) Slap a head shell around the whole thing. The existing hole in mine
didn't quite hold te mono recaptacle in place (hole too big), so I put
a tie wrap around the receptacle on the inside of the shell. This made
it wide enough to stay put.

10) To recap: bus signal ==> interrupt+busy+collector base ==> data0 bus
ground ==> pins 18-25,emitter

If you don't have/want a soldering iron, you can buy a crimp-type connector
instead. This will make it harder to fit everything inside the head shell,
and crimp connectors are less forgiving of mistakes (desoldering is easy,
de-crimping usually ruins the connector).

Programming it: Write 0x10 to the control port, to get things set up right
(data enable, bi-direction disable, interrupt enable, etc.)

You send a logical 1 (0V) to the bus by writing a 1 to the data port (the
transistor is there to limit the current draw on your data port, but it
conveniently inverts the signal as well, to keep things simple).

Send a 0 to the data bus to let the bus float high.

You should be able to read what you write back from the status port. If
not, make sure you didn't use any stereo plugs or receptacles (they can
short the ground and signal lines), and that there are no shorts in the
connector. A logic probe and continuity probe are helpful here.

The next step is to write an interrupt handler to timestamp incoming bits,
so they can be decoded later. On a 386sx/16, running DOS and using Turbo/C,
I was able to get interrupt latencies of around 20us, occasionally as high
as 40us. This leaves plenty of margin for error (anything under 150us is
OK). Make sure you aren't using a disk-caching program if you go this route.
If you write some kind of interface, you can use DOS's CTTY command to
send everything to serial, and use a null modem to control everything from
a "real" machine. I did this, but found the serial part was flaky above
9600bps and too slow at <= 9600.

Instead, on a P150 Linux machine, I wrote a module to talk to the connector,
and got interrupt latencies consistently under 6usec. The module provides
a /dev/slink device, which accepts data in ASCII-hex bytes (e.g. "98 00")
and returns data from the bus the same way.

I'm still working on the interface code (to do CDDB lookups, etc.), but
the low-level stuff is working great.

If anyone wants copies of the software I've written to accompany this thing,
I'd be happy to provide it -- just send e-mail (don't have a web page,
sorry). The linux module needs beautifying (documentation and configuration
stuff), so you'll need a passing familiarity with C to make it work for
you.

The DOS prog is all the way there; if your connector is built right (and
your parallel port is vaugely standard) it will almost certainly work.

One final note: if all of this sounds complicated, do yourself a favor
and buy a Slink-e (http://www.nirvis.com). Not only is it a gem of electronic
and human design, but the guy responsible, Colby Boles, has done more to
advance the state of s-link hacking than anyone else I can think of. Before
the Slink-e was available as a product, I spent many, many, many hours
with hardcopies of his early schematics and painstakingly-researched device
files by my side, playing on a breadboard or in front of that 386.

Then, when I had all the hardware and timing and everything else worked
out, and was trying to make CDDB queries work, I sent him e-mail with a
couple of questions. I got a nice response a few hours later with more
detail than I had any right to expect. A good guy, selling a good product,
for a reasonable price. What more could you ask?

cheers, mike