• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

TashTalk: Single-Chip LocalTalk Interface


Well-known member
Yeah, the LToUDP protocol doesn't require it because we've already got a UDP checksum in the packet header, and there's no point making the receiver calculate another checksum, especially a perverse one. This is, I'll admit, partly because I looked at the SDLC CRC in Inside Appletalk and just thought .... "or, hear me out, I could not implement that".

If receiver.py sends the FCS out onto UDP that's not following the protocol. AirTalk, for example, does do FCS validation and strips/adds it, so if you send an extra FCS to AirTalk, the extra FCS will make it through to the client's AppleTalk stack as junk data. Whether that stack cares probably doesn't matter, but in the cases of large file transfers, it could make packets overlength, in theory. That's a good find, @NJRoadfan.

Now I come to think of it, @tashtari, could that partly account for why you were seeing weird slowdown between mini vMac and your tashtalk prototype when copying files (which I couldn't reproduce?)


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.

Correct, the XOR byte was a (cheesy) extra checksum I added in my firmware to make sure the packet made its way safely through the UART. The SCC automatically dealt with the CRC -- as far as I can remember, the CRC wasn't actually being sent through the UART (or even read by my firmware). The SCC simply had a bit to tell me whether the CRC was good or not. And on sending, the CRC would automatically be sent by the SCC. So I wanted some kind of protection on the UART communication between Linux and the MCU.


PIC Whisperer
It's here! And it works! Here it is "in action", so to speak:


Thanks are owed to @bdurbrow (who also, it must be said, did a really professional packaging job...)


Well-known member
I wanted the effect to be as if you'd picked it up at Macworld Expo in 1985 or 1986 from a vendor in a small booth... obviously commercial, but more of a "mom-and-pop" outfit than a megacorporation.


Well-known member
Has anybody had any odd behavior from their hat? The reason I ask is that one of the ones that went overseas vented it's magic blue smoke... based on the description I got I think it's the PIC12F1840 that died... I don't think he did anything wrong, so at the moment I'm guessing that it's just a case of getting unlucky with that particular chip.

I've requested that unit be sent back here for post-mortem diagnostics; and he'll of course get a replacement as soon as I'm able to provide one.


PIC Whisperer
Has anybody had any odd behavior from their hat?
I've only plugged one of mine in, but it's behaved admirably. Strange that the PIC up and died, they're usually pretty tolerant of rough handling... I've been a PIC disciple for probably about 15 years now and I've only ever fried one once.


Well-known member

I'm in my mid 40s now, and this is only the second time I've ever had first-hand experience with a device smoking. The first was the Rifa cap on my 128K Mac's analog board going bang... but, well, Rifa caps. There's a reason they're notorious for this.

I didn't dig much further in to see of the PIC 12F1840 was marketed for this, but they do have a whole page dedicated to Functional Safety applications of PIC micros... I haven't gotten my test equipment on it yet, so I'm just guessing; but it's entirely possible that a) that was the one-in-a-billion unit that was going to short out, and b) we'll never know the full story on it.

Hmm... kinda wish I had a better microscope; decapping the chip might be enlightening... I wonder if Microchip's QA department might be interested?


Well-known member
Hello all,

I would like to thank all members of this community and especially @tashtari, @bdurbrow and @cheesestraws for making this neat solution.
I recently received a raspberry hat from @bdurbrow (excellent quality pcb and packaging) and bought a raspberry pi zero WH.
I then followed the notes described here:http://somedisassemblyrequired.com/index.php/2017/11/04/raspberry-pi-zero-serial-port/ and successfully connected my mac SE30 to mini vmac on the first try!

One thing: could someone share a compiled (LToUDP) version of mini vmac? The version I made compiled with some warnings and has no sound.

Thanks again,



Well-known member
Thanks. Did you compile it yourself? With xcode? How did you overcome the deprecated library warnings and errors?

I built it with xcodebuild but on an older machine, so I didn't see any messages about deprecated libraries. Ignorance, bliss, etc, you know how it is ;-)
Last edited:


Well-known member
@Andrew Thanks for your feedback. Nice to hear from fellow pioneers with the hat! And also my thanks to @tashtari, @bdurbrow and @cheesestraws for there work. Really great that LocalTalk is back on the map! Special thanks to bdurbrow for his patience with me and explanations!

I also got things going. I made a kind of logbook for myself how I did things. Sharing this with the forum.
I used an RPi 4 and a Macintosh ED. Wrote down what I did. Maybe also nice for future reference.

The installation I did was on top of my own MacIPRpi image. See www.macip.net where that is all about. Some steps:

- Attach the hat

- Use raspi-config to open your serial port.
command rasp-config / 3 Interface Options / P6 Serial Port. Enter Yes and Finish to stop raspi-config

- Edit the file /boot/config.txt
At the end enter this:

# TashTalk Hat

- Download the tashtalk daemon (https://github.com/lampmerchant/tashtalk/)
I used this command:
git clone https://github.com/lampmerchant/tashtalk.git

On the Pi the serial Python library is missing so install this first.
apt install python-serial
Then run tashtalkd in the tashtalk/tashtalkd directory:
./tashtalkd -d /dev/ttyAMA0 –vv

To test I installed Mini vMac with LocalTalk support on my daughter her MacBook. I got the file on the Gryphel site. Use version 37


Enter in the first box -br 37, otherwise you get an error. If you don’t want a dancing demo box on the screen pay a Subscriber code. It worked fine. For disk I downloaded this:

See the pictures.

WhatsApp Image 2022-02-24 at 23.44.52.jpeg

WhatsApp Image 2022-02-24 at 23.38.19 (2).jpeg
WhatsApp Image 2022-02-24 at 23.38.19 (3).jpegWhatsApp Image 2022-02-24 at 23.38.19 (5).jpegWhatsApp Image 2022-02-24 at 23.38.19 (8).jpeg

I’m now testing if I can bridge things. My Macintosh ED does see the MinivMac, but doesn’t see my Basilisk II, MacIPRPi or normal Macintosh SE connected by Ether Print LocalTalk bridge. This would be nice. I am running now multitalk. Which does something. I can see the Basilisk II on my PC from the MacBook. The MacBook can see the Macintosh ED with TashTalk, so I can exchange files. I think maybe there is an AppleTalk routing issue I don’t understand yet. For more information about multitalk look here:

You will need to install Go language (https://shores.dev/install-go-language-on-raspberry-pi-3-and-4/)

This is how my network looks on the MacBook

CheckNET    4:23 PM    3-2-2022    Device List    Number of entries = 16  
Name    Type    Net    Node    Skt    Enum    IPGATEWAY    65280    73    72    3    IPADDRESS    65280    65    72    0
753MacBook    Workstation    0    1    4    1
753MacBook    AFPServer    0    1    251    1
753MacBook    PPCToolBox    0    1    252    1
753MacBook      Macintosh    0    1    253    1
AsantŽTalk 94081D2A    AsantŽTalk    65510    127    252    1
AsantŽTalk 940863E7    AsantŽTalk    65403    247    252    1
LocalTime    TimeLord    65280    73    131    1
MacIPiRpi    netatalk    65280    73    4    4
MacIPiRpi    Workstation    65280    73    4    5
MacIPpi    AFPServer    65280    73    129    2
UTC    TimeLord    65280    73    133    0
virtquadra    Workstation    65280    65    4    0
virtquadra    AFPServer    65280    65    251    0
virtquadra      Macintosh    65280    65    252    0

I can see 753MacBook from my Macintosh ED connected with the RPi 4 and the TashTalk Hat. The Macintosh ED is also on the 0 network, but CheckNet doesn't see it. Other way around works!


  • WhatsApp Image 2022-02-24 at 23.38.19 (4).jpeg
    WhatsApp Image 2022-02-24 at 23.38.19 (4).jpeg
    70.5 KB · Views: 5