TashTalk USB

[Tashtari]

It should be capturing all traffic.

tashtalkcap.py literally just dumps bytes to a pcap file

Correct on both counts. TashTalk (the PIC firmware, that is) does no filtering of what it sees on the LocalTalk bus - every frame it sees, whether it's a control frame (RTS, CTS, ENQ, ACK) or a data frame, no matter who it's addressed to, is relayed over the UART output.

Frames that TashTalk itself sends out, however, are not relayed over the UART. That is, if the host sends a LocalTalk frame to TashTalk, TashTalk will send an RTS frame (not relayed), wait for a CTS frame (relayed), and then send the data frame (not relayed).

None of this explains why the AppleTalk ImageWriter's response isn't being seen by TashTalk. If the TashTalk device is on the same PhoneNet/LocalTalk network as the ImageWriter and the machine it's communicating with, it absolutely should be picking up the ImageWriter's response. The fact that it's not could be a bug in the TashTalk firmware (or, depending on how you frame it, yet more buggy behavior from the AppleTalk ImageWriter that TashTalk is going to have to learn to deal with). @iigs123 Do you happen to have a scope or a logic analyzer that you could use to get a trace of the ImageWriter's response along with the serial output from the TashTalk?

 

[Bolacore]

I just got my card a little bit ago too and assuming I get the same behaviour I’ll get a cap of it on my Saleae. Hopefully can see what might be _weird_ about it then.

 

[iigs123]

I have a cheap sparkfun 24MHz/8-Channel logic analyzer. How should I hook it up?

 

[Tashtari]

I have a cheap sparkfun 24MHz/8-Channel logic analyzer. How should I hook it up?

8 channels should be plenty. The signals you want to attach to are all on the PIC (U2 on the USB-TashTalk board):

                       .--------.
               Supply -|01 \/ 08|- Ground
    LocalTalk <-> RA5 -|02    07|- RA0 --> UART Out
Driver Enable <-- RA4 -|03    06|- RA1 <-- UART In
        !MCLR --> RA3 -|04    05|- RA2 --> UART Flow Control
                       '--------'

I'd clip onto LocalTalk/RA5 (pin 2) and UART Out/RA0 (pin 7). TashTalk should be outputting on pin 7 at the same time it sees anything on pin 2, so if TashTalk is somehow not recognizing the beginning of a frame from the ImageWriter, there should be activity on pin 2 that's matched with silence on pin 7.

 

[Bolacore]

Just got my card set up and with a direct cable connection and via a PhoneNET set it appears to find it just fine with TashTalk USB + TailTalk (So only two things on the net is TashTalk and the ImageWriter - nothing else):

Looking up '=:=@*'...
Found 1 result(s):
  ImageWriter:ImageWriter@* — 0.139 socket 138

So I think most likely it's not a firmware bug, but I'd be curious to see what @iigs123 sees on their analyser.

 

[NJRoadfan]

The issue is when there is a router in the mix (the network isn't '0') and a local machine sends a NBP Broadcast to the router. I'm guessing all it needs in those cases is for the router to broadcast a NBP Lkup using extended DDP headers.

 

[iigs123]

Just got my card set up and with a direct cable connection and via a PhoneNET set it appears to find it just fine with TashTalk USB + TailTalk (So only two things on the net is TashTalk and the ImageWriter - nothing else):

Looking up '=:=@*'...
Found 1 result(s):
  ImageWriter:ImageWriter@* — 0.139 socket 138

So I think most likely it's not a firmware bug, but I'd be curious to see what @iigs123 sees on their analyser.

Well, I moved my ImageWriter and connected it with a different piece of phone cord between it and the tashtalk, and, it shows up!

So perhaps the length of the phone cord matters for tailtalk, but not so much for the Mac. Would this be a software timing thing or a hardware thing where the signal is too poor? I'll try to get the logic analyzer going soon for more information.

 

[Bolacore]

Well, I moved my ImageWriter and connected it with a different piece of phone cord between it and the tashtalk, and, it shows up!

So perhaps the length of the phone cord matters for tailtalk, but not so much for the Mac. Would this be a software timing thing or a hardware thing where the signal is too poor? I'll try to get the logic analyzer going soon for more information.

Huh interesting - What length was it? I've only tried with a 3 footer admittedly so I wonder if things get a bit noisy when its long enough.

 

[Bolacore]

And after adding a few quirk handlers in TailTalk (and some minor ImageWriter repairs) I have the very first print coming from it, woohoo!

 

[NJRoadfan]

PhoneNET is very robust. I've run it across like 30 feet of sketchy wire without a problem. Farallon states that you can have up to 4000ft runs with 22 gauge wire and up to 2000ft with typical 26 gauge phone cabling. People got it working across barbed wire fence!

Ian Scott :apple_inc: 🐙 (@polpo@bitbang.social)

Attached: 3 images Today I visited @mediaarchaeologylab@post.lurk.org's Barbed Wire Fence Telephone II installation to see if Localtalk over PhoneNET would work on it. I wanted to do this since @paulrickards@mastodon.social asked who'd be the first one to run LocalTalk over barbed wire a while...

bitbang.social

dan 💾 (@billgoats@bitbang.social)

Attached: 1 image Rate my networking setup 💁 #LiveLaughLocalTalk #GlobalTalk #RetroComputing #FieldTalk

bitbang.social

 

[Bolacore]

One more try with something a little more complex. For an old ribbon that was just in the printer it seems to still mostly work which is nice. Not sure if the belt is slipping or if I still have a bug somewhere in my code (I reused the paper so the top part isn't from buggy stuff) but it's not bad for a first try.

PhoneNET is very robust. I've run it across like 30 feet of sketchy wire without a problem. Farallon states that you can have up to 4000ft runs with 22 gauge wire and up to 2000ft with typical 26 gauge phone cabling. People got it working across barbed wire fence!

Ian Scott :apple_inc: 🐙 (@polpo@bitbang.social)

Attached: 3 images Today I visited @mediaarchaeologylab@post.lurk.org's Barbed Wire Fence Telephone II installation to see if Localtalk over PhoneNET would work on it. I wanted to do this since @paulrickards@mastodon.social asked who'd be the first one to run LocalTalk over barbed wire a while...

bitbang.social

dan 💾 (@billgoats@bitbang.social)

Attached: 1 image Rate my networking setup 💁 #LiveLaughLocalTalk #GlobalTalk #RetroComputing #FieldTalk

bitbang.social

I thought that was the case, but it could very well be I am missing something in the way I wired the driver on these boards, especially as it works with a real Mac and not the USB board. I'll have to get some longer cables too to see what it might be.

 

[Tashtari]

Well, I moved my ImageWriter and connected it with a different piece of phone cord between it and the tashtalk, and, it shows up!

So perhaps the length of the phone cord matters for tailtalk, but not so much for the Mac. Would this be a software timing thing or a hardware thing where the signal is too poor? I'll try to get the logic analyzer going soon for more information.

Just to ensure all the bases are covered - did the non-working phone cord have four conductors? (PhoneNet uses the second pair, which many phone cords omit.)

 

[iigs123]

My IW is usually across the room, connected by a 25' (or perhaps longer) phone cord. It works with real hardware.

It was only detected by tailtalk with a shorter cord. I'll try to do more testing soon.

 

[iigs123]

I did a few captures with my basic logic analyzer and the original setup with long cables.

The LC's startup traffic is captured by tashtalkcap.py (top is localtalk in, bottom is UART out):


Here the ImageWriter is starting up, then, a wait as I open the chooser to view AT Imagewriters:



Zooming in to the 2nd half - where the Chooser was open and the IW showed up:



Checking the pcap file - I don't see the IW responses. Again this is the long cable, not the short.

I'm not experienced enough to go much farther into this, but I'd be happy to try to capture whatever I can if it is interesting to others. I'll try to shorten my phone cord, too

 

[adespoton]

Just to ensure all the bases are covered - did the non-working phone cord have four conductors? (PhoneNet uses the second pair, which many phone cords omit.)

Just re-stating this here with other words: the phone cord needs four coloured wires inside that are terminated at each end; if it only has two wires terminated, or if the four wires are terminated incorrectly, the cord won't work. Usual configurations are a direct mirror or with the two TX and RX reversed on one end:

 

[iigs123]

The phone lines I have are all 4-conductor, Yellow, Green, Red, Black on both ends. They all work with old school phone net connectors and original hardware. The length of the cable is the issue.

 

[Tashtari]

Here the ImageWriter is starting up, then, a wait as I open the chooser to view AT Imagewriters:

This (the first half) is the part that looks odd to me - LocalTalk activity but no corresponding activity on the UART output. I'm assuming that the dense part of the first half is the ImageWriter firing out a bunch of ENQs to make sure its chosen address is not in use, but not sure about the second, less-dense part. In either case, TashTalk should be relaying this data over the UART. Something electrical might be going on caused by the cable length, but if so, it's very strange that it suddenly starts working as expected after a delay. If you can manage it, it'd be useful to see what the LocalTalk line is doing when the UART line is quiet, zoomed in far enough that you can see the individual transitions...

If memory serves, the LocalTalk line transactions should begin something like this:

    ___     ___     _   ___     ___     ___     _   _...
___|   |___|   |___| |_|   |___|   |___|   |___| |_|
 1   1   1   1   1   0   1   1   1   1   1   1   0   ...

That is, a "clock" transition every ~4.3µs and another transition halfway in between the clock transitions to indicate a zero (with no transition indicating a one).

 

[iigs123]

The tashtalk is only capturing the lookup requests from the LC - and not the responses from the IW. I don't think anything "started to work" with this.

I can attach a file from pulseview if you are interested.