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.