TashTalk: Single-Chip LocalTalk Interface

[tashtari]

Interesting issue, I wish I had a solution, but I'm not all that great at networking...

One thing I wanted to point out, though: running tashtalkd with -vv on the command line is useful for debugging, but it slows things down a fair bit, so once you're confident that you're seeing the traffic you expect, it's a good idea not to use it.

 

[NJRoadfan]

It could just be AppleTalk being wonky. The network numbers are all over the place! Looks like netatalk's atalkd on the MacIPiRpi is assigning 65280 to the Ethernet side of things and is acting as a seed router. If the Asante bridges are on the same network, they should have picked up the network number.

I don't know how multitalk handles routing, but packets might not be making it over the bridge. Also, running multitalk on the same machine as netatalk and/or the tashtalk gateway may cause issues.

Also, the network number of "0" and "65280" appears to be problematic and not a valid value. Even though LocalTalk doesn't support extended addressing, it's still assigned a valid network number (between 1 and 65279).

From: http://www.tmetz.net/os/Apple/atroute/atroute.html

1. Rules to live by #1 - Network numbers must fall within a specific range. AppleTalk requires that a network number on a routed network be between the numbers 1 and 65279, inclusive. The network number range 65280 through 65534 is called the startup range and is used by the Macintosh when it is on a network without any routers. Network numbers that fall within the startup range cannot be assigned to a router port.

 

[Stannol]

Hi all,

first post here and I am not a native english speaker, so please bear with me.

For another project I started digging into LocalTalk and found this thread during my research, very interesting indeed. Thanks a lot for your work @tashtari.

I only need one hat so I didn't bother making a proper PCB and built myself a protoype, here are my experiences so far:

- Due to the chip shortage I had to experiment with different RS-422/RS-485 Transceivers and can confirm that both ADM 485 JN and SN 75176BP work very well. On the other hand I've had mixed results with MAX485, these appear not to be reliable.

- One Transceiver per hat is sufficient when correctly connecting "Driver Enable" (Pin4 of the PIC) to both the DE and /RE Inputs (Pins 2 and 3) of the Transceiver. These Transceivers have their Driving Outputs and Receiving Inputs internally connected so it is sufficient to connect the A and B lines (Pins 6 and 7)of the Transmitter to the Tx lines of the 8 pin mini DIN connector (Pins 6 and 3).

- Original Apple LocalTalk or Farallon PhoneNet adapters are a) difficult to obtain and b) way overpriced. So I startetd experimenting with "CapNet" adapers as well (https://www.jagshouse.com/localtalk.html). These can easily be DIY and are very cheap, just 4 resitors and 2 caps and even work in conjunction with PhoneNet adapters. I have two Powerbooks G3 and a TashTalk hat happily talking to each other with different permutations of PhoneNet and CapNet adapters. I do, however, strongly recommend against using CapNet adapters to connect computers in different buildings with possibly different mains. Personally, I do not trust these CapNet adapters too much with regard to galvanic isolation. If you plan to connect computers supplied by different mains do yourself a favor and use original Apple LocalTalk or Farallon PhoneNet adapters, these are designed for that.

Here's a pic of one of my CapNet adapters.

 

[cheesestraws]

Welcome to the forums, and nice work. Good to hear more empirical stuff about which transceivers work.

Here's a pic of one of my CapNet adapters.

That's a very neat build!

These Transceivers have their Driving Outputs and Receiving Inputs internally connected so it is sufficient to connect the A and B lines (Pins 6 and 7)of the Transmitter to the Tx lines of the 8 pin mini DIN connector (Pins 6 and 3).

If I'm understanding you properly, this won't work if you're talking to a mac directly through a normal Apple serial cable, as they're just crossed over serial wires with no joins. That's why my Airtalk thingy has two transceivers like this, because I wanted it to be able to be just plugged straight into the back of a Mac. I'm aware that's a specific choice, though, and most people perhaps wouldn't care about that .

 

[Stannol]

If I'm understanding you properly, this won't work if you're talking to a mac directly through a normal Apple serial cable, as they're just crossed over serial wires with no joins.

That's correct, thank you for clarifying this, @cheesestraws . For this particular use case you'd still need two transceivers.

 

[cheesestraws]

Aha, just wanted to make sure I understood you. Nice work, then .

 

[mactjaap]

Thanks for your comments on my "AppleTalk Hell". So net 0 is not a normal net number. Hmmm why does all the LToUDP vMac use net 0?
Is there a way to force it to a "normal" network number?

And why is the MacBook (or iBook) better in handeling some parts of the network? All devices can see the vMac with LToUDP support on the iBook. (I will do test without the MacIPRpi and netatalk.)


This is how my networks looks if I connect everything together now:

- Macintosh ED with AppleTalk adapter to Macintosh SE FDHD running the Chooser and SendEcho
- Macintosh Macintosh SE FDHD connected to the TashTalk Hat / Rpi ( MacSEFDHD)
- Rpi is also a MacIPRPI with netatalk 2.2.x ( also running multitalk). Also running two instances of running vMac with LToUDP support ( 753RPidemo1 and 2)
- Basilisk II on a Windows 10 PC ( virtquadra)
- iBook ( vintage laptop running MacOS 10.4.11 running vMac with LToUDP support

See pictures:


1 - Macintosh ED with AppleTalk adapter to Macintosh SE FDHD running the Chooser and SendEcho




2 - Macintosh Macintosh SE FDHD connected to the TashTalk Hat / Rpi ( MacSEFDHD)




3 - Rpi is also a MacIPRPI with netatalk 2.2.x ( also running multitalk). Also running two instances of running vMac with LToUDP support ( 753RPidemo1 and 2)



4 - Basilisk II on a Windows 10 PC ( virtquadra)



5 iBook ( vintage laptop running MacOS 10.4.11 running vMac with LToUDP support

 

[cheesestraws]

Thanks for your comments on my "AppleTalk Hell". So net 0 is not a normal net number. Hmmm why does all the LToUDP vMac use net 0?

net 0 is 'this is an isolated LT network with no router on it'. EtherTalk picks a high network number instead.

Multitalk doesn't currently properly deal with the whole EtherTalk network range, I think. I've been trying (desultorily) to work out an easy fix but one so far escapes me. The "rightish" answer would be to broadcast routing information on each network to force them to be the same, I suspect.

 

[tashtari]

I only need one hat so I didn't bother making a proper PCB and built myself a protoype, here are my experiences so far

I'm glad things are working for you! Just out of curiosity, what did you use to program the PIC? So far I think everyone has used actual hardware from Microchip (a PICkit or ICD) so it'd be interesting to know if you used something else successfully.

 

[Stannol]

I'm glad things are working for you! Just out of curiosity, what did you use to program the PIC? So far I think everyone has used actual hardware from Microchip (a PICkit or ICD) so it'd be interesting to know if you used something else successfully.

No I didn't. A friend of mine programmed the PIC for me and he used a PICkit II, AFAIK.

 

[lisa2]

I wanted to say thanks to all who contributed on this project. I have one of bdurbrow's pi hats and the whole setup is working perfectly! It is just amazing that tashtari was able to get the pic to bitbang the SDLC protocol. My dream is that someday this can be interfaced with netatalk.
Great Job!
Rick

​

 

[tashtari]

My dream is that someday this can be interfaced with netatalk.

It's a less neat solution than I might like, but you should be able to mix tashtalkd (which will interface with TashTalk and translate to LToUDP) with @sfiera 's MultiTalk (which will translate from LToUDP to EtherTalk) to accomplish this.

@cheesestraws has mentioned it in another thread, so I don't think it's divulging too much to say some hardware along these lines (also using TashTalk) is in the works...

 

[tashtari]

@cheesestraws has mentioned it in another thread, so I don't think it's divulging too much to say some hardware along these lines (also using TashTalk) is in the works...

Official announcement has been made!

 

[techknight]

Can this firmware/chip speak generic SDLC frames versus localtalk-specific?

Just curious.

 

[tashtari]

Can this firmware/chip speak generic SDLC frames versus localtalk-specific?

I don't know enough about generic SDLC to say for sure, but while I think there might be some bits of reusable code between it and a generic SDLC interface, a lot of TashTalk is quite LT-specific as it has functionality tied to several aspects of the LLAP frame format. It handles the RTS/CTS and collision handling mechanisms, it derives the length of frames being sent by the host from their length field, &c.

 

[techknight]

I don't know enough about generic SDLC to say for sure, but while I think there might be some bits of reusable code between it and a generic SDLC interface, a lot of TashTalk is quite LT-specific as it has functionality tied to several aspects of the LLAP frame format. It handles the RTS/CTS and collision handling mechanisms, it derives the length of frames being sent by the host from their length field, &c.

Ahhh ok. dang. Yeah i have a project that uses the Intel 8044/8344 for generic SDLC stuff so i was wondering how it could plug into that, but, i suppose it wont.

 

[Andrew]

Hello all,

I would like to thank all members of this community and especially @tashtari, @bdurbrow and @cheesestraws for making this neat solution.
I recently received a raspberry hat from @bdurbrow (excellent quality pcb and packaging) and bought a raspberry pi zero WH.
I then followed the notes described here:http://somedisassemblyrequired.com/index.php/2017/11/04/raspberry-pi-zero-serial-port/ and successfully connected my mac SE30 to mini vmac on the first try!

One thing: could someone share a compiled (LToUDP) version of mini vmac? The version I made compiled with some warnings and has no sound.

Thanks again,

Andrew

Hello all,

I am quoting my own post from earlier this year. It seems that I had successfully managed to use the tashtalk hat back then. Last night I tried to connect again but I was unable to find my pi on the network and had to factory reset and start over (maybe my wifi settings changed). The steps I have done at least 5 times are:

1) Use the pi imager - Successfully creates 32bit full image. Pi connects on my wifi and I can ssh
2) disable bluetooth in order to free uart port (Tried both the instructions in my earlier post, as well as the instructions from a post of @mactjaap )
3) download and start the tashtalk daemon.

What I get is "Received bad packet from tashtalk", some times followed by received 1 byte, received 3 bytes. Occasionally It may say received a good packet. In both cases it stops receiving anything more. If I restart the daemon and create some traffic I may receive some good or bad packet (95% is bad packet).
Do you have any thoughts? Could it be the mac se 30 failing? Can I switch apple talk to use the modem port?

Andrew

 

[Andrew]

Nevermind, the pi had attached its terminal on ttyAMA0 and was throwing garbage. It seems to work perfectly now.

 

[mactjaap]

Nevermind, the pi had attached its terminal on ttyAMA0 and was throwing garbage. It seems to work perfectly now.

Great!

 

[Andrew]

Great!

In a previous post of yours I see that you have successfully used multitalk to bridge LToUDP devices such as the tashtalk bridge and mini vmac together with apple talk devices on ethernet. Could you please elaborate how you have achieved this? Does your raspberry pi have one or two interfaces? What command line have you used?

Many thanks,

Andrew