TashTalk: Single-Chip LocalTalk Interface

[NJRoadfan]

I did get multitalk to bridge TashTalk to LToUDP, but it is not as stable as tashtalkd is. Multitalk's bridging of TashTalk to EtherTalk didn't work at all and resulted in the above errors.

On a side note, multitalk simply bridging LToUDP to EtherTalk does not work correctly if you have a router on the EtherTalk side (netatalk with atalkd in router mode providing zone names).

On the totally silly side. I was successful in configuring a Shiva Fastpath using mini vMac and tashtalkd from start to finish. Not totally useless as unconfigured Fastpaths need a Mac on a Localtalk network to "bootstrap" them.

 

[NJRoadfan]

For those wondering if a TashTalk hat fits the RPi 400..... it does. Making it the first LocalTalk equipped desktop computer since the 90s.

 

[CC_333]

I got curious and checked on Raspberry Pi prices since I hadn't looked since last year when I was so disgusted by all the scalping and gouging that was happening, and just made the astonishing discovery that RPi 400 prices are double digits again!

c

 

[DiskJockey]

OK - so help me out here. I have the TashTalk hat running - testing between Centris machine and vMac on MacBook. They chatter to each other but nothing shows up in Chooser on either side when I try to connect to AFP 3.0 servers.

 

[DiskJockey]

And does anyone have vMac 32-bit binary for RPi with LTOUDP to share? Or the instructions to build same?

 

[finkmac]

How is your centris connected?

 

[DiskJockey]

How is your centris connected?

Network cabling: AppleTalk connectors (not PhoneNet) - tested and good.
Centris using this on printer port
O
RPi with hat on other AppleTalk connector
RPi on AirPort Express
MacBook Pro running vMac also on AirPort Express

 

[tashtari]

Just to sanity check things, you could see what happens if you start up another instance of minivmac with System 7 and start its built-in server - check whether that's visible on the other minivmac and/or the Centris.

 

[DiskJockey]

Just to sanity check things, you could see what happens if you start up another instance of minivmac with System 7 and start its built-in server - check whether that's visible on the other minivmac and/or the Centris.

Ok - tell me how to turn on its built-in server please. This is Personal File Sharing? Using 7.5.5 image from savagetaylor.com but if there is some better image please tell.

 

[tashtari]

Ok - tell me how to turn on its built-in server please. This is Personal File Sharing?

That may be what it's called, I'm not sure. To turn it on, you go to the Sharing Setup control panel and (after setting up an owner name/password and computer name) click 'start' under 'file sharing'.

 

[DiskJockey]

That may be what it's called, I'm not sure. To turn it on, you go to the Sharing Setup control panel and (after setting up an owner name/password and computer name) click 'start' under 'file sharing'.

Done - the two vMac on my MacBook see each other. I have placed RPi and lacBook on wired network connections. Physical Apple IIGS does not show any servers. Some framing errors interestingly:

 

[DiskJockey]

I have swapped Centris back onto the network; still no go.

 

[tashtari]

Physical Apple IIGS does not show any servers

What about the Centris? I don't know enough about IIgses to know what to expect there.

edit: Didn't see the reply.

 

[tashtari]

Well, I'm struggling to explain what's going on. "TashTalk received good frame" means that the receive side of things is working properly, it's getting frames and their CRCs are checking out okay. It is unlikely, but possible, that the transmit side of things isn't working properly - i.e. the Tx line from the RPi to TashTalk is broken or the driver enable line from TashTalk to the RS422 driver is broken. It's hard to know without seeing more of the output of tashtalkd.

 

[DiskJockey]

I will tee the output of tashtalkd to a log file and upload here.

 

[DiskJockey]

I did the "tee" to capture the log but it turns out that this time it worked - passed all tests. The problem appears to be bad connection within the miniDIN on the hat. I needed to set the cable very firmly into it and then things worked. vMacs were able to connect to the Centris running Apple File Server 3.0 and the Centris was able to connect to the vMac with their Sharing Setup turned on. This has been a long ride to get here.

 

[tashtari]

Victory! \o/

 

[twelvetone12]

Hai tashtari! I'm bringing the discussion here since from the AirTalk thread for the internal PB 1xx modem to LT adapter.
As you can see from the photo, I implemented a high-tech adapter board. It is basically just a 741 buffer that disables the mac tx when CTS is high.



I tried using tashtalkd with version 1.0 (AFAIK it is the version AirTalk will use) and I get... something but I'm not sure what I should see.

On the mac -> tashtalk side, I see packets. I added a debug like to hexprint all the stuff coming from the serial port and I see messages:

[DEBUG] Incoming:
000000 80 .
[DEBUG] Incoming:
000000 80 .
[DEBUG] Incoming:
000000 80 .
[DEBUG] Incoming:
000000 80 .
[DEBUG] Incoming:
000000 80 .
[DEBUG] Incoming:
000000 80 .
[DEBUG] Incoming:
000000 80 .
[DEBUG] Incoming:
000000 FF 81 84 CB DB 80 FF .......
[DEBUG] Incoming:
000000 FF 81 81 80 1A 82 FE 82 21 2C 80 80 81 FE 80 81 ........!,......
000010 3D 09 41 46 50 =.AFP
[DEBUG] Incoming:
000000 53 65 72 76 65 72 81 2A BE E5 80 FF Server.*....
[DEBUG] Incoming:
000000 FF .
[DEBUG] Incoming:
000000 81 84 CB DB 80 FF

(I added this in after data = self.serial_obj.read(16384) in receiver.py). Tasktalkd never sees this data as valid, but I see some data here. When the system is idle I see many 0x80 bytes being transmitted even if the LTin line in on the PIC is idle? they seem to come in bursts.
When I turn on appletalk I see the initial name exchange for the workstation:

000000 FF .
[DEBUG] Incoming:
000000 81 84 CB DB 80 FF ......
[DEBUG] Incoming:
000000 FF 81 81 80 22 82 FE 82 21 82 80 80 81 FE 80 05 ...."...!.......
000010 50 42 31 30 30 0D 50 6F 77 65 PB100.Powe
[DEBUG] Incoming:
000000 72 42 6F 6F 6B 90 31 30 30 81 2A C1 79 80 FF rBook.100.*.y..

But tashtalkd does not decode anything...

On the tashtalk -> mac side of things, I see the incoming UDP packets, but on the LTout I seem to only see the first one and then it goes silent, is this expected behaivour?

If you have any pointers, I would appreciate that! thanks!

 

[twelvetone12]

Well turns out it is my fault, I completely overlooked CTS from the pic.... So I grabbed a proper usb adapter with CTS, plugged it in and... it works! :O


I can see the Powerbook 100 in mini vmac! And it connects too! The reverse is also true:


And I can copy stuff over:


It is *very* slow but maybe I just misremember how slow localtalk really was Probably my circuir + the usb adapter is not playing super well. Also tashtalkd refused to do sendto() on OSX so I had to run it into a linux VM, and that surely added some latency to everything. Debugging that is for another day.
I think it is promising in any case, since I want to really use it with @cheesestraws AirTalk, so the next step is the ESP, but I imagine it should work there too.

 

[cheesestraws]

It is *very* slow but maybe I just misremember how slow localtalk really was

If the Mac that is running Mini vMac is on WiFi, LToUDP is really slow, at least for me. I don't know why: I assume there's some power management or batching of packets going on in OS X somewhere. Mini vMac itself can't tell the difference. You might get better results if you stick the host Mac on Ethernet.