• Hello Guest! We're hosting a challenge to welcome vintage Intel macs to the MLA during the month of July! See this thread for more information.
  • We've made some quality of life improvements to the Trading Post. More info here.

TashTalk USB

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?
 
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.
 
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):

Code:
                       .--------.
               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.
 
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):
Code:
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.
 
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.
 
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):
Code:
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.
 
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.
 
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!


 
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.
2833F939-8CA9-4549-B19D-193D0712B5C4_1_102_o.jpeg
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!


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.
 
Back
Top