Mac68k Forums

Nice find, I'll need to read through it. I ordered a couple z53c80's in DIP form factor to experiment with some breadboarding, using the stm32f4discovery I've been using for the USB to ADB stuff. It'd be kind of nice to do localtalk to USB CDC interface or something.

RS422 is RS485 at full duplex I think. as RS-485 is half-duplex differential bus. Unless of course RS422 runs at different voltages?

Thats what I thought. 2 RS-485 transceivers will work just fine. Use 1 set as a transmitter, and another set as a receiver. They are capable of handling up to +/-12V I think.

The lowest rated, cheapest quality is the ADM483. There are muuuuch better ones like MAX1487, and some SN74HC based ones. I forget what is what though.

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.

Thanks! Yeah, I'm excited to make some progress on this.

Yesterday I designed and ordered my own Mini-DIN-8 breakout board because I couldn't find anything that would fit my needs. It has female Mini-DIN-8 sockets on each side hooked together, so it's like a short female-to-female cable that breaks out access to each signal on a pin header and provides convenient locations for clipping onto ground. I should be able to put this in line with my EtherWave to get a much higher-quality signal. Hopefully it'll be able to see what's going on with the faster clock mode. I even meandered the traces so they're all the same length, although I don't think it matters at this bit rate

Should work, but it's untested as of yet.

http://oshpark.com/shared_projects/ey1EBH8f

Ooh, I never thought of that. Looks like it would work just fine! I just overlaid the PCB layouts for 4-pin, 6-pin, and 8-pin connectors on top of each other and the holes all overlap. I see no reason why it wouldn't work. If you'd like a board, I'd be happy to send one your way when I receive them. I won't have use for all three.

Yeah, it'll be some work. My copy of Inside AppleTalk just arrived today and has some diagrams that the PDF version did not have. It looks to me like the main idea behind this is going to be converting LLAP frames to and from ELAP frames. I'm hoping that the frames will mainly just directly convert between each other but there might be weirdness with how LLAP and ELAP addressing work and the translation between the two--haven't gotten that far yet into the AARP stuff. Anyway, once we have that working, we can implement the MacIP server.

I've been investigating the SCC documentation. I have a few Z85C30 chips here in DIP form so I can do some breadboarding. Umm...all I can say is it's a very complicated chip. It's going to take some serious work to do anything with it, starting with interfacing to it. I'll need to get both read and write cycles working correctly with it so I can configure it before I'll be able to sniff any packets. It looks like the chip has to be clocked, so I'm going to need an oscillator to run the chip. The chips I have can handle 8 MHz max. I also am pretty sure the LocalTalk bit rate (230.4 kbps) will require a 3.6864 MHz clock, unless there are special divider things I haven't figured out yet. So I have to decide if running the SCC with a 3.6864 MHz oscillator will work well enough, and if not, I'll have to use a faster oscillator for the SCC's main clock (which is a TTL level input) and a separate crystal for its baud rate stuff -- I believe you can configure two pins to handle the amplifier circuit for just using a crystal for that.

The linked PDF is scaring me a little bit because it's talking about how difficult it is to meet some timing requirements, as well as how some things have to be timed because the SCC won't let us know what's going on. And that's on a processor/SCC combo chip that has the whole mess integrated together. It's also talking about how DMA might be needed in cases where the processor also has other things to do. I'll be curious to see how intensive the processor usage will be for both it and the Ethernet code. The good news is that this PDF was written before cheap 100 MHz ARM microcontrollers were a thing, so my worries may not even matter today.

I'm definitely getting this working as LLAP<->ELAP at the standard 230.4 kbps rate before even thinking about higher clocks, MacIP, and fun stuff like that.