• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

TashTalk: Single-Chip LocalTalk Interface

cheesestraws

Well-known member
Here's some teasers: this is a PowerBook 3400 connecting to a file share in Mini vMac over "LocalTalk". (It only works this way around at the moment, for protocol reasons)

Progress is being made...

Screen Shot 2021-11-20 at 20.28.png

Picture 2.png

Picture 3.png
 

bdurbrow

Well-known member
Thanks all for the sympathy regarding Maria. She is, and will continue to be, missed.

However, I do have some GOOD news for a change! I finally got a chance to do some soldering and have the first one assembled and cleaned. It's at the moment untested, but I hope to get to that soon. I gotta drag a 68K machine out of the corner and set it up on the dining room table again along with an o-scope to check that everything is OK.

Does anybody have a Pi SD card image or install steps to make one that would be suitable for testing this thing out?

IMG_0892_s.jpeg
 

tashtari

Well-known member
Looking good!

Does anybody have a Pi SD card image or install steps to make one that would be suitable for testing this thing out?
I don't have an image per se, but you should be able to use stock Raspberry Pi OS (the thing they used to call Raspbian) with some configuration.

My notes on the subject are here. The key thing is to make the Pi connect its main UART on the GPIO header - the "PL011" UART at /dev/ttyAMA0, rather than the "mini-UART" at /dev/ttyS0. We need the PL011 UART because it supports RTS/CTS and the mini-UART does not. If you're using a Pi that doesn't have Bluetooth, this should be the default, but if you're using a Pi with Bluetooth, it will by default give the PL011 UART to the Bluetooth interface and connect the mini-UART to the header.

I'm not 100% on how much of my notes is specific to the version of Raspberry Pi OS I was using; some websites I've found give different instructions... it seems like they change this up every so often in ways that aren't necessarily well communicated.

Once you have the UART set up properly, easiest way to test it is to fire up tashtalkd on the Pi and see if you can get communication running between it and a copy of Mini vMac that has @cheesestraws 's LToUDP feature enabled.

Let me know if you run into trouble anywhere, I'm eager to help get things going. I'm also on the #68kmla IRC channel if it would help to chat live.
 

cheesestraws

Well-known member
Hmmm, I'm seeing what seems to be an extremely intermittent issue ( :( ) where I think the TashTalk is stopping answering RTS frames that it should be sending answers to. If unmitigated, sending end just retries RTSing forever.

I've added a mitigation where if I receive 10 consecutive frames that are all RTSes I should be answering, I reinitialise TashTalk (send 1024 0x00s followed by resending the nodebits), and this seems to kick it back into action for a while.

Subjectively, it feels like it gets more frequent over time, but I haven't measured that yet: My next plans are to measure time between occurrences, number of packets between operations, number of packets in total, and number of control packets between occurences. I'm also going to stick my "neighbourhood gossip" board in the middle to see if anything is happening in response to those RTSes.

Anything else anyone can think of that I should be doing here?
 

tashtari

Well-known member
The biggest potential suspect in my mind is queue overflow/underflow, the chip's behavior in such a situation is very here-be-dragons. If there's an overflow or underflow and the chip suddenly starts interpreting junk data as commands, any 0x02 byte among that junk data will cause it to overwrite the node ID bitmap with the next 32 bytes on the queue, which could account for its sudden failure to respond to RTSes from a certain node. It would be possible to confirm this hypothesis by throwing a series of ENQs at it from the LocalTalk side when it gets into this bad state - if it responds on IDs that it shouldn't, that's likely to be the problem.
 
Top