TashTalk: Single-Chip LocalTalk Interface

[twelvetone12]

Yes it is on wifi OS X does some weird prioritizing/ throttling, this is not the first time it happens to me. Will try via Ethernet or on Linux and see.

 

[tashtari]

I grabbed a proper usb adapter with CTS, plugged it in and... it works! :O

Glad you figured it out! CTS is indeed crucial to TashTalk's proper functioning, the PIC has a buffer of only 128 bytes for inbound data and if it overflows, the wheels start to come off pretty quickly.

 

[twelvetone12]

I have another small question: should I stick with v 1 or should I try version 2? If I understand correctly, the only difference is that the LT IO is multiplexed in one pin right? How should this look on the final circuit, I was thinking of adding a couple transistors to DE so only TX or RX from the mac is connected at a given moment.

 

[tashtari]

I have another small question: should I stick with v 1 or should I try version 2? If I understand correctly, the only difference is that the LT IO is multiplexed in one pin right?

Essentially, yes. The core LocalTalk functionality is the same across versions, so really, you should use whichever version makes sense for your particular application:

1.0 has separate LocalTalk output and input pins.

2.0 uses a single pin for LocalTalk output and input (in sync with the driver enable pin). The pin formerly used as LocalTalk input is now the PIC's "!MCLR" pin - when held low, the PIC is held in reset and all its I/O pins are tristated. This is useful for applications where it is sometimes desirable to use the serial line for other purposes besides LocalTalk.

2.1 is the same as 2.0 except the firmware now has the option to calculate CRCs for inbound and outbound data packets. This is useful for applications with a low-power host where it is desirable to outsource this functionality to save time.

How should this look on the final circuit, I was thinking of adding a couple transistors to DE so only TX or RX from the mac is connected at a given moment.

For your application, you're effectively pretending that the Mac is on a two-node (physically) LocalTalk network, so it seems like using 1.0 makes the most sense - connect the PIC's LT input to the Mac's Tx line and the PIC's LT output to the Mac's Rx line and leave driver enable unconnected. If you used 2.x, you'd need to do something with transistors to ensure that you didn't get into a situation where both the Mac and the PIC were driving the line at the same time.

 

[techknight]

Edit: nevermind, wrong thread.

 

[DiskJockey]

Victory! \o/

Victory not so much - there seems to be major issues (likely not HW) with the solution. Very flakey - it's worked once (and a 1/2) and failed otherwise. Not sure what's going on.

 

[cheesestraws]

I have another small question: should I stick with v 1 or should I try version 2? If I understand correctly, the only difference is that the LT IO is multiplexed in one pin right? How should this look on the final circuit, I was thinking of adding a couple transistors to DE so only TX or RX from the mac is connected at a given moment.

if you're wanting to use the airtalk firmware, stick to v1

 

[twelvetone12]

ok! it is also the easiest to implement hardware wise.

 

[tashtari]

Victory not so much - there seems to be major issues (likely not HW) with the solution. Very flakey - it's worked once (and a 1/2) and failed otherwise. Not sure what's going on.

It sounded earlier like your issue was a loose connection with the DIN plug. Has that changed?

 

[tashtari]

Anyone else want one of the TashTalk Hat 2.x kits? I will have three more to sell once my Digikey order with the transceivers arrives.

Sadly, TI is discontinuing their line of RS422/485 transceivers in DIP packages this November, so this hat design is going to have to be replaced with one that uses surface-mount chips at some point. I really should learn how to do SMT soldering. Boo, hiss.

Anyway, kits available for $12 each (my approximate cost), plus shipping. Slide into my DMs. =)

 

[techknight]

Anyone else want one of the TashTalk Hat 2.x kits? I will have three more to sell once my Digikey order with the transceivers arrives.

Sadly, TI is discontinuing their line of RS422/485 transceivers in DIP packages this November, so this hat design is going to have to be replaced with one that uses surface-mount chips at some point. I really should learn how to do SMT soldering. Boo, hiss.

Anyway, kits available for $12 each (my approximate cost), plus shipping. Slide into my DMs. =)

Oh damn I didnt get this notification since I use the 65HVD08 extensively in my product line, the DIP version.

 

[sfiera]

Oops, did I forget to respond here? I put mine together a couple months back. Easy soldering, though I had a frustrating time on the software side until I realized that login over serial was enabled—a couple of packets would get through, then the baud rate would change. I somehow disabled that and I think I was able to see packets reliably afterwards.

 

[twelvetone12]

Would anybody be interested in a localtalk to USB adapter? It would be very easy to make, and probably those cheapo USB to serial adapters would work. Then tashtalk then the transceiver and and connectors.

 

[cheesestraws]

Would anybody be interested in a localtalk to USB adapter? It would be very easy to make, and probably those cheapo USB to serial adapters would work. Then tashtalk then the transceiver and and connectors.

Yeah, this is a good idea - I sketched some bits using I think a CH340 and it seemed easy, but I didn't have the time or energy to pursue it, partly because lack of software. But now you're working on the tashtalk driver...

 

[robin-fo]

I also like the idea

 

[tashtari]

It might be a little scope-creep-y, but I like the idea of a USB PhoneNet box, basically what you described except with a transformer built in and 4P4C connectors instead of a mini-DIN. That way you can hang a PhoneNet box off a modern machine to make it part of a LT network and it aesthetically matches the PhoneNet boxes plugged into your Macs' serial ports. The trouble for me was finding an appropriate transformer - couldn't find one exactly matching the specs in Inside AppleTalk, and I lack the EE knowledge to know which ones are important, which are maxima/minima, &c. @ErinRF was looking into this at some point but I don't know if they came up with anything...

 

[cheesestraws]

It might be a little scope-creep-y, but I like the idea of a USB PhoneNet box, basically what you described except with a transformer built in and 4P4C connectors instead of a mini-DIN.

It would be nice, but the audience would be smaller—PhoneNet less of a thing outside the US. And the Mini-din jacks with little switches in aren't available any more for "proper" LocalTalk compatibility, so you'd need a termination switch...

 

[robin-fo]

I'd vote for Mini-DIN 3 connectors. Don't worry about the switches, we can 3d print levers to operate standard switches (or just add external switches for manual operation). The transformers are more of an issue here. In the worst case, we just make a USB to Mini-DIN 8 female dongle and the user can supply a PhoneNET or LocalTalk box of their choice or just use a plain serial cable.

 

[robin-fo]

Or just use something like this instead of transformers? https://www.analog.com/media/en/technical-documentation/data-sheets/ADM2485.pdf

 

[tashtari]

If you go with an 8-pin mini-DIN, you could also leverage one of the bits of functionality added to TashTalk 2.x, namely being able to disable TashTalk with a pin. Combine that with a switch and some buffers and you could have a port with two modes - LocalTalk or standard RS422. But maybe I'm just muddying the waters... =)

Or just use something like this instead of transformers? https://www.analog.com/media/en/technical-documentation/data-sheets/ADM2485.pdf

Oh, cool! I didn't know such a thing existed. Does the integrated transformer meet the specifications to interoperate with LocalTalk?