I've started to look into this. My main setback has been that I didn't have the tools necessary to start investigating and get a feel for the challenge at hand. I have a print copy of Inside AppleTalk on the way and I'm using a
decent PDF version for now. I recently got a Rigol digital oscilloscope so now I can do some work on this. I have started by checking out what the EtherWave Printer Adapter does. The EtherWave will be helpful to look at because it is a working implementation of a LocalTalk-Ethernet bridge.
I got Mini Din-8 cables on Digi-Key that have a connector on one end and wires broken out on the other end. I got one
female and one
male version. Unfortunately they are 6 feet long each which is way more than I needed, not to mention expensive, but I'll deal with it. I soldered them to headers:
On some unused space on an SNES multitap breadboard I didn't want to tear apart, I hooked them up and gave myself some room to sniff some signals. I hooked up to the TxD- and RxD- signals. Through the EtherWave, I connected my IIci to my Linux Mac mini's netatalk server. I set up a trigger and then opened a folder on the server from the IIci.
Here's the initial capture of the data. All other pictures are derived from this same capture; I just zoomed in further and may have done slight fiddling with other knobs in the process. Yellow is TxD, blue is RxD.
Here's a zoomed version eliminating all of the emptiness on the right:
Here's the first group of frames:
I manually decoded them; it's an RTS from the IIci, followed by a CTS from the Mac mini, followed by an FPGetFileDirParms request from the IIci (encapsulated within an ATP packet, which itself is encapsulated within a DDP packet). Luckily we shouldn't need to delve this far into the protocol. I just decoded it to verify I was doing everything correctly.
To get an idea of how I decoded it, here's a zoomed version that shows the detail I'm looking at. You can see the synchronization pulse and idle period right before the beginning of the initial RTS frame. I'm not sure what's going on with the five "1" bits directly before the flag bytes (which start with the "0" bit on the right), but all of the frames began that way. Whatever...the SCC will sync to the flag bytes and then everything should be happy.
Finally, here's a byte between my vertical cursors (01000000, or 0x02 -- remember the bits are sent LSB first, this threw me off for a while!) You can see it's calculating the time between those two cursors as being 28.65 kHz. If we multiply that by 8, we get 229.2 kHz. Pretty close to LocalTalk's bit rate!
The waveform isn't very pretty, probably because of all the extra cable length and crap that I've added. In fact, if I put the EtherWave into the special mode that I believe clocks the SCC faster, it fails to work through the extra long breakout cable. If I can find some sort of smaller Mini Din-8 breakout board or something, I'll definitely grab one. Anyway, what I have now is more than good enough to look at the data at the standard 230.4 kbps LocalTalk rate, and that's the important part.
In conclusion, this was a fun experiment. The scope has a ton of memory so I can zoom in and see some pretty good detail. As has already been said, it would be pretty crazy to try to bit-bang this stuff. I think some of the stuff that synchronizes to the frames is handled automatically by the SCC and it would take some work to replicate that logic. Next up, I guess I'll wire up RS-422/485 transceiver(s) + Z85C30 SCC + ARM microcontroller to listen in on this traffic and spit it out already decoded. If I can get communication with the SCC working and start sniffing LocalTalk packets, that's a good chunk of the battle! I think that document linked by techknight will help with configuring the SCC.