• 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

CircuitBored

Well-known member
Very exciting stuff! I can't wait to get my hands on one. Congratulations to everyone involved in bringing this project to life.
 

bdurbrow

Well-known member
It looks like Tindie is not working out for handling the international orders... and they seem to be in violation of the EU/UK's tax rules, as far as I can tell... well, I think. If anybody knows better, please correct me!

There's only five international orders, though, and I've already spent way more time on the subject than it's worth, so I'm just going to eat the cost and send them out as gifts.

Until eBay lets me set up an international store or Tindie gets it's act together with the tax & customs situation, I'm afraid that I won't be able to send any more projects overseas... :cautious: oh, well...

Domestic orders are proceeding as planned, however.
 

mactjaap

Well-known member
Maybe this helps:
You can send out International orders without dealing with taxes. The shipment company will settle this for us. I have lots of experiance with this. I just pay to the shipment company the taxes. if you send out with normal mail our national mail will deal with the costs.
 

cheesestraws

Well-known member
Yes, the easiest way is just to put the things in the post with a customs form on it, then all the tax is dealt with by the receiver, generally, at least here.
 

bdurbrow

Well-known member
Took this before leaving for the post office...

IMG_0910.JPG

So, all but one (which I need the shipping address for) have now shipped.
 

bdurbrow

Well-known member
Thanks!

That's what happens when you a: run out of packing tape; b: have a huge box of large shipping labels for your Dymo LabelWriter that you got off of Amazon for less than the price of a single "genuine" one; and c: happen to still have the TashTalkHat logo still open in Affinity Designer...
 

NJRoadfan

Well-known member
I implemented a userspace barebones LocalTalk to EtherTalk bridge for my project, prior to getting the kernel module working. I believe I emulated the approach used by the Farallon EtherWave Printer Adapter. It was pretty hacky and incomplete, but it did work as a proof of concept. I've attached a zip of the userspace portion of the code (GPLv2). Hope this is useful!

Is it possible to post the code to the kernel module somewhere?
 

cheesestraws

Well-known member
Oh, belatedly, we can add the 3peak TP75176E-SR to the list of transceivers known to work with TashTalk (that's what's on the prototype AirTalks)
 

dougg3

Well-known member
Is it possible to post the code to the kernel module somewhere?
Sure thing! See attached. Unfortunately 68kmla doesn't allow me to upload a tar.gz file so I'll have to go with zip. I do believe it should be possible to adapt this code to work with TashTalk. Notes:
  • I coded this in an older Linux kernel version. I don't remember exactly which version, but it likely needs some tweaks on newer ones.
  • I used the approach of creating a new TTY line discipline, so you just apply that discipline to the serial port (see the sllocaltalk_attach program) and then Linux takes over the serial port, talks to the microcontroller [would be the TashTalk in this case] through the serial port, and creates a /dev/lt0 device. This is hacky, because there's a list of disciplines and I just randomly allocated one (25) which was unused at the time without going through the "official" process. Now it is defined as N_NCI in the official kernel. There's likely a better way of doing this in newer kernel versions without using line disciplines (I believe it's called "serdev"), or if this picks up some steam we could go through the right process of allocating a new line discipline and getting the driver mainlined.
  • The kernel's AppleTalk stack had a crashing bug with broadcast packets on LocalTalk devices which this module exposed. I submitted a patch to the kernel last year, so it's only fixed as of kernel 5.12. It also ended up being backported to some older stable releases. If your kernel doesn't have that commit, you will have to add it or else it won't work.
  • The driver wasn't finished. It doesn't implement address acquisition.
 

Attachments

  • sllocaltalk.zip
    11.4 KB · Views: 8

NJRoadfan

Well-known member
Seems that nobody implemented address acquisition as the ISA cards themselves did it in the past. I can't imagine its too hard, Inside Appletalk has guidelines.

The biggest difference between Tashtalk and your adapter is how it handles receiving data. TashTalk sends a whole frame and than a frame complete/error/aborted marker. This seems backwards to me as usually the beginning of a frame or packet gets a marker.
 

tashtari

Well-known member
TashTalk sends a whole frame and than a frame complete/error/aborted marker. This seems backwards to me as usually the beginning of a frame or packet gets a marker.
I was reading my code to try and remember why I did it that way, and I think the answer is simply that there's no time to send a frame-start sentinel. We don't know for sure that a frame is starting until we get the first byte of it (it could just be flags, i.e. almost but not quite a frame) at which point we need to start the UART transmitting that byte. As such, the chip's UART's output ends up being either "stick this byte on the end of your buffer" or "your buffer now contains a frame, process it" or "your buffer contains nonsense, dump it".

A lot of TashTalk's behavior (and coding technique, for that matter) can be explained by "this is the only way I could think of to accomplish this in the x cycles I had available". Buuut that's why it was such a fun puzzle to put together. =D And why I'm trying to think of other such puzzles I could have fun with. So stay tuned for another project that starts with "Tash"! ...Probably.
 

dougg3

Well-known member
That makes a lot of sense! The solution I originally developed with an LPC11U68 and a actual Z85C30 SCC has a ton of room for buffering up packets, so it gets a whole chunk of data prepared and ready to go before sending it over the UART. It's overkill (and much more expensive) given that the TashTalk itself is capable of accomplishing essentially the same thing on only a PIC.

Yeah, the address acquisition algorithm didn't seem like it would be too bad at all, I just never got around to it.
 

NJRoadfan

Well-known member
Next question I have is regarding the LLAP checksum. @dougg3 seems to only be doing a XOR of the packet's bytes, while tashtalkd does the full CCITT-CRC specified in Inside Appletalk. I'm guessing the actual SCC chip normally checks if a CRC is valid? Also I'm going to assume the CRC byte is stripped out by the host before being processed by the AppleTalk stack.
 

tashtari

Well-known member
My guess - @dougg3 can confirm or correct - is that that XOR checksum is an extra one added by his firmware, separate from the CRC in the LLAP frame. The length bytes in the CMD_LLAP_PACKET command are also separate from the length bytes contained within the LLAP frame, so it'd make sense.

By contrast, TashTalk's UART outputs anything that even looks like a frame (with one or more flag bytes at the start and one flag byte at the end), regardless of whether its CRC or length bytes match, so it's the host's responsibility to check. TashTalk does check the CRC if the frame is an RTS or ENQ that it might have to respond to itself, but it will relay the frame to the UART regardless.

I'm told that the real SCC checks the CRC, but may also (not sure) allow through frames where the CRC field is all zeroes.

If we're being technical, an LLAP "frame" is starting flag bytes + payload + CRC field + ending flag byte, and an LLAP "packet" is just the payload (I say "frame" for what TashTalk outputs because it includes the CRC field, though it does not relay the flag bytes; I also frequently slip up and say "packet"). But an LLAP "packet" is, I believe, what's delivered to the AppleTalk stack, sans CRC and flag bytes.
 

cheesestraws

Well-known member
I was reading my code to try and remember why I did it that way, and I think the answer is simply that there's no time to send a frame-start sentinel. We don't know for sure that a frame is starting until we get the first byte of it (it could just be flags, i.e. almost but not quite a frame) at which point we need to start the UART transmitting that byte

Yeah, we talked about this on IRC if I remember correctly and my recollection lines up with yours.

I'm guessing the actual SCC chip normally checks if a CRC is valid? Also I'm going to assume the CRC byte is stripped out by the host before being processed by the AppleTalk stack.

Yes, the CRC is part of the framing not part of the packet and on the SCC I'm fairly sure would be checked in hardware. This is why LT uses the weird IBM SDLC CRC, not any kind of sensible checksum. I think whether to let through bad-CRC packets is in a configuration register, but I can't remember that 100%, so please check that statement before doing anything based on it. The AirTalk firmware calls the thing that TashTalk hands off to it llap_packet, but it's really sort of halfway between the two. Perhaps a prame, or a fracket (the latter being what you say just after you've had to check a weird IBM checksum...)
 

NJRoadfan

Well-known member
So tashtalk is outputing the LLAP packet (dest node + source node + type + len + data) + FCS/CRC then appends 0x00 + 0xFD? Only reason I'm asking is that receiver.py appears to send the FCS/CRC over to the UDP bridge even though the protocol doesn't require it. Doesn't appear that mini vMac cares though. Both its SCC emulation and KEGS' SCC emulation doesn't check the CRC anyway!
 
Top