Sega Saturn CD interface:
20 Pin version:

Transaction is initiated by the cd drive by asserting Start then asserting Enable.
Enable is deasserted after each 8 bits are transferred. Enable is low for ~175us.
During the transaction the cd drive provides its current status on the "status data" line while command bytes are sent on the "saturn command data" line.
Data is valid at the rising edge of the clock.
Bytes are sent least significant bit first.

STATUS DATA (LSBit first):
--Dervied mostly of Q subcode data
Current CD operations:
--IDLE: 0x46
--Stopped: 0x12
--seeking: 0x22
--Lid Open:0x80
--Read DATA Sectors: 0x36
--reading audio data: 0x34
--0x30 unkown - error reading audio sector?
--seek security ring: 0xB2/0xB6

Command DATA (LSBit first):
00=NOP
02,09=Seek
03=read TOC
04=Stop DISC
06=read data at LBA
--if lba=0 and byte 10=0 then resume play at current offset
08=stop pending commands (pause)
0A=scan forward audio cd
0B=scan backwards

Timing Diagrams for audio and sector data:

MISC INFO:

• Sectors are synchronized to command/status transactions when reading game data
• Each sector starts ~1000us after last byte (or ~3600us after the beginning) of the command/status transaction
• When disc stopped transactions are ~16000us apart
• When disc is reading transactions are ~6600us apart
• The first sector that is sent (along with status) is 4 LESS than the requested LBA, then increments from there
  

files directory

raw modchip data with subcode
audio part of modchip data only
raw captured sector data during real disc authenticate
text file with modchip command/status log and notes

homebrew modchip:
modchip schematics
MODCHIP VHDL
CD_emulator/modchip pics,2
sega cd patent describes how the security protection works and how the logo is printed using sector data

security ring data(as generated by the modchip):
0000: 00 FF FF FF-FF FF FF FF-FF FF FF 00-71 82 02 62 ............q..b
0010: 00 28 28 1E-80 08 48 06-A0 66 A0 66-A8 59 A8 59 .((...H..f.f.Y.Y
0020: A8 59 A8 59-A8 59 A8 59-A8 59 A8 59-A8 59 A8 59 .Y.Y.Y.Y.Y.Y.Y.Y
.... repeats, ends with:
0910: A8 59 A8 59-A8 59 A8 59-A8 59 A8 59-A8 59 A8 59 .Y.Y.Y.Y.Y.Y.Y.Y
0920: A8 59 A8 59-A8 59 A8 59-A8 59 A8 59-72 DD E5 99 .Y.Y.Y.Y.Y.Yr...

The security ring above is how it appears when it comes off the disc or modchip.
Bytes 12 thru 2352 of a sector in mode 1,2 etc data is scrambled(xor) with LFSR, so to record your own security like the above you need to
XOR it before you write it to your ISO or bin/cue file or whatever.
A dump of real security ring data.(0x59 is background data, 0xA8 is logo data, check ecma-130.pdf for efm bit patterns)

F/B sync byte
start of sector=40 C0 C0 C0 C0 C0
rest of sector=00 80 80 80 80 80
Sub code byte:
same 8 bit pattern is repeated for 1 frame : starts at R1 and wraps around into next frame R0
so you should only see patterns that are multiple of 6
(Appears as though the saturn ignores all F/Bsync and subcode data,since that info is provided in the status data)
example subcode bytes:
00F0: 40 40 40 00-00 00 00 00-00 40 40 40-40 40 40 40 @@@......@@@@@@@
0100: 40 40 40 40-40 40 40 40-40 40 40 00-00 00 00 00 @@@@@@@@@@@.....
0110: 00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00 ................
0120: 00 00 00 40-40 40 40 40-40 9F 9F 9F-9F 9F 9F FD ...@@@@@@.......
0130: FD FD FD FD-FD 00 00 00-00 00 00 40-40 40 40 40 ...........@@@@@
0140: 40 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00 @...............

21 Pin version (unconfirmed):