-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
TashTalk: Single-Chip LocalTalk Interface
- Thread starter Tashtari
- Start date
I'm so sorry. I recently had to do this with my beloved cat of 10+ years, a couple of months ago, and I felt gutted for a couple of weeks. Hang in there.
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...
Progress is being made...
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?
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?
That's looking very nice!
Looking good!
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.
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.
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?
) 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?
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.
That's a good idea. I'll try to work out how to do that...
For anyone who hasn't already seen it, @cheesestraws 's AirTalk project (which uses TashTalk) is well worth a look: https://68kmla.org/bb/index.php?thr...ireless-plug-and-play-localtalk-dongles.39661
Woo. Nice!
Got a few more spare minutes tonight...
Well, the good news is that the magic blue smoke is still in the epoxy IC packages... I still need to dig out my oscilloscope to see if the signals on the board are behaving, though... also need to setup a machine in here that has a LocalTalk port. Tashtalkd is installed and appears to run, but I don't have any traffic flowing through it yet.
Eh... not really "bad news", more like "odd news"... but for some reason the "lite" version of Raspberry Pi OS won't talk to my WiFi network. Spent a few hours fighting that before giving up and installing the full 3GB version onto the SD card... which, inexplicably, works just fine.
Well, the good news is that the magic blue smoke is still in the epoxy IC packages... I still need to dig out my oscilloscope to see if the signals on the board are behaving, though... also need to setup a machine in here that has a LocalTalk port. Tashtalkd is installed and appears to run, but I don't have any traffic flowing through it yet.
Eh... not really "bad news", more like "odd news"... but for some reason the "lite" version of Raspberry Pi OS won't talk to my WiFi network. Spent a few hours fighting that before giving up and installing the full 3GB version onto the SD card... which, inexplicably, works just fine.
I just tested the GATEMODE GM3085E RS485 transceiver with Tashtalk. Seems to be working fine. It looks like it's very similar to the TI SN65HVD3085E, but it can also run happily on a 3.3V supply. It's also fairly cheap and available through the JLCPCB SMT assembly process, which is useful.
OK; I think I'm probably missing a step on the RPi side... Wireshark shows that I'm successfully generating LToUDP packets; and I know that the RPi is on the same network and talking because VNC from Mac OS X to the RPi works.
However; launching tashtalkd generates no console output; and both the UART receive and transmit pins are stuck high - no data is being transmitted. I'm launching tashtalkd like so:
Is there something else that I should be doing to get it to talk to the PIC?
However; launching tashtalkd generates no console output; and both the UART receive and transmit pins are stuck high - no data is being transmitted. I'm launching tashtalkd like so:
Code:
./tashtalkd --device /dev/ttyAMA0 --verboseIs there something else that I should be doing to get it to talk to the PIC?
Sorry for not responding sooner... holidays.
You're invoking tashtalkd correctly, though I'd replace `--verbose` with `-vv` for extra verbosity, that'll give you frame dumps whenever it does anything.
First thing I'd try to bisect the problem space is to generate some traffic on the LocalTalk side, the firmware will always relay any frame that it receives over the UART, and if it isn't doing that, something is awry with the PIC or something else on the board. If it is doing that, then we can say it's either tashtalkd or something to do with the network.
You're invoking tashtalkd correctly, though I'd replace `--verbose` with `-vv` for extra verbosity, that'll give you frame dumps whenever it does anything.
First thing I'd try to bisect the problem space is to generate some traffic on the LocalTalk side, the firmware will always relay any frame that it receives over the UART, and if it isn't doing that, something is awry with the PIC or something else on the board. If it is doing that, then we can say it's either tashtalkd or something to do with the network.
General Update:
Currently trying to get a classic Mac with LocalTalk running. The IIvx I bought last year started up three times (good chime, and it was accessing the drive; but I still haven't found a setting on the D-sub 15 to VGA adapter that I have that makes it put out video compatible with the LCD TV I have, so I'm only assuming that it was booting), and then no activity whatsoever - no PSU fan, nothing. I suspect that something (likely a capacitor) shorted out in the power supply, taking a fuse with it. I'll troubleshoot that machine later when I have time.
My SE I have reassembled (it was apart for a RAM upgrade); and gets thru to a flashing question mark disk icon. There is activity on the hard drive LED, so either something went bad on the drive (corrupted boot blocks, or System Folder damage?), the drive hardware is toast, or the SE's SCSI port is bad. My guess is that there's a bad sector in a critical spot on the drive - it's an original Apple 20MB SCSI drive, so it's not surprising that it could have issues after all these years. If I can't recover the machine with my FloppyEMU, then I'll have to order a SCSI2SD - something I've been meaning to do anyway; I just haven't actually done so.
Currently trying to get a classic Mac with LocalTalk running. The IIvx I bought last year started up three times (good chime, and it was accessing the drive; but I still haven't found a setting on the D-sub 15 to VGA adapter that I have that makes it put out video compatible with the LCD TV I have, so I'm only assuming that it was booting), and then no activity whatsoever - no PSU fan, nothing. I suspect that something (likely a capacitor) shorted out in the power supply, taking a fuse with it. I'll troubleshoot that machine later when I have time.
My SE I have reassembled (it was apart for a RAM upgrade); and gets thru to a flashing question mark disk icon. There is activity on the hard drive LED, so either something went bad on the drive (corrupted boot blocks, or System Folder damage?), the drive hardware is toast, or the SE's SCSI port is bad. My guess is that there's a bad sector in a critical spot on the drive - it's an original Apple 20MB SCSI drive, so it's not surprising that it could have issues after all these years. If I can't recover the machine with my FloppyEMU, then I'll have to order a SCSI2SD - something I've been meaning to do anyway; I just haven't actually done so.
Good luck, hope you're able to get one or both of them working.
I think if you pull the PRAM battery on the IIvx (which you've probably done already), AppleTalk defaults to being on, so you might get a burst of LocalTalk activity on startup through the printer port, even if there's no video... I could be wrong, though.
I think if you pull the PRAM battery on the IIvx (which you've probably done already), AppleTalk defaults to being on, so you might get a burst of LocalTalk activity on startup through the printer port, even if there's no video... I could be wrong, though.
Similar threads
