TashTalk: Single-Chip LocalTalk Interface

[NJRoadfan]

minivmac's LToUDP implementation has some bugs. Through testing with tashtalkd and TashRouter indicates its a problem with minivmac itself. The emulator's ability to transmit data onto the network seems to be speed limited, roughly to the speed of a modem. This is very noticeable if you ever try to print with the LaserWriter driver to a printer as it takes FOREVER. The emulator has no such problem receiving data though.

This explains the slowness of transferring data from the SE/30 to minivmac, but doesn't explain the timeouts. Looking at the logs, minivmac is replying to FPGetSrvrInfo requests from the SE/30 properly. Don't know why it would be timing out.

 

[cheesestraws]

'has some bugs' is a very polite way of putting it ;-) I didn't really know my way around the codebase and still don't, so it's more there's a gaping huge design flaw in it that I never really worked out how to fix. The reason is that as far as I can see all I/O tasks are basically dealt with on a per-tick granularity, which plays merry hell with anything that requires relatively rapid ACKing. This isn't very good, but I've never had enough energy to work out how to fix it, I'm afraid.

 

[NJRoadfan]

Its common to handle tasks on clock ticks with emulators. Its not surprising that most emulators the int main() is just one big loop . Somehow the GSport SCC emulation was able to handle this without a problem along with bridging to EtherTalk (with Ethernet speeds).

 

[cheesestraws]

Yeah. I'm afraid I can do network gubbins but I'm in no way qualified to wade into an SCC emulation and make it work in real time!

 

[Andrew]

But two mini vmacs can communicate with each other just fine (and mount shares), even on different computers. So the implementation of ltoudp is mostly functional. Do other users of tashtalk, airtalk etc have similar experiences, or are they able to make a successful connection?
Could it be a hardware defect with my se30? I've tried both ports. Is there a way to troubleshoot further? Any alternative to tashrouter perhaps? Something else I might be missing?

 

[Andrew]

Merry Christmas everyone! I don't have my mac to check, but do you believe that the issue might be with the CTS signal from the raspberry pi? I think it might be disabled by default on the Pi Zero W. I am reading that the tashtalk v1 requires it in order to function correctly. Perhaps some longer frames fail but not all?

 

[Tashtari]

Merry Christmas everyone! I don't have my mac to check, but do you believe that the issue might be with the CTS signal from the raspberry pi? I think it might be disabled by default on the Pi Zero W. I am reading that the tashtalk v1 requires it in order to function correctly. Perhaps some longer frames fail but not all?

All versions of TashTalk require CTS to function correctly, not just 1.x. It's certainly worth checking if you suspect it, as overflow or underflow of the receive buffer can result in all sorts of weird behaviors.

 

[NJRoadfan]

GPIO pins 16 and 17 likely need to be remapped to RTS/CTS. Adding gpio=16-17=a3 to your RPi config.txt will address that.

 

[Tashtari]

It took me a lot longer to do this than I said it would, but I finally got the time and spoons and plastic sandwich bags together aaaaand...

TashTalk hat kits are back in stock! Get 'em while they're hot! (Get some other stuff too, maybe?)

https://ko-fi.com/tashtari/shop

 

[Tashtari]

TashTalk hat kits came and went quickly... I'm working on getting them stocked elsewhere so you all don't have to depend on me having spare time. Will update as soon as I have news.

Also, I made a small addition to the TashTalk repo that I thought might be worth a mention - a simple program called tashtalkcap that uses a TashTalk to capture LocalTalk traffic for analysis using WireShark, in case that sort of thing is useful to anyone.

 

[twelvetone12]

I've been playing a bit again with TashTalk lately: I was trying out this emulator called "snow" which can pipe serial output to a TCP ports, so I was wondering if TashTalk could be used to pipe localtalk from an emulated environment directly to the physical wires. I actually managed to get data on the wire! The problem is that it seems to get "stuck" on RTS/CTS/ENQ packets. IIRC TashTalk managed these automatically no? Because I think I need to completely forward them to the emulated macos (and from macos to the wire), or things just seem to get stuck (and I see lots of RTS/CTS getting transmitted back and forth, but nothing then happens on the macos side).

 

[Tashtari]

IIRC TashTalk managed these automatically

Correct - the host tells TashTalk what node IDs it wants to use via the Set Node IDs command and TashTalk responds automatically to RTSes with CTSes and ENQs with ACKs for those node IDs, and likewise when sending data, the host just sends a data frame for TashTalk to deliver and TashTalk takes care of sending the RTS and waiting for the CTS.

Thinking about how you could make this work... you could insert a layer between Snow and TashTalk that works something like this:

• On startup, use TashTalk to find a free node ID on the LocalTalk network (via ENQs) and claim it
• Force the emulated Mac to use that node ID by replying to its ENQs with ACKs on every other node ID it tries
• Allow the emulated Mac to send data frames to any node ID (except its own) by replying to its RTSes with CTSes and then relaying the resulting data frame to TashTalk
• Receive and hold inbound data frames to the emulated Mac's node ID and send it an RTS for each (that it can then respond to with a CTS) before sending the data frame

This is a little clunky, but it should work. There may be a better way, but it's too early in the morning for me to think of it. =)

 

[twelvetone12]

I like this idea! I tried implementing the TCP part and some of the serial part, and it looks promising. I got my address using TashTalk on the serial and hijacked the emulated mac on TCP, tomorrow if I have a bit of time I want to try to put it all together.

 

[joevt]

I was trying out this emulator called "snow" which can pipe serial output to a TCP ports

The DingusPPC emulator uses a Unix Domain Socket. I suppose you could pipe that to a TCP port or a TTY device or a serial port using socat. But for output to a real serial port device, you would want the emulator to use that serial port character device directly which can support serial port features such as baud rate, CTS, RTS, BREAK, etc.