• 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.
 

bdurbrow

Well-known member
Finally got a few minutes for myself, and... my PicKit 2 won't talk to MPLAB. So, I've ordered a new PicKit 3 off of Amazon; should be here sometime wednesday.
 

bdurbrow

Well-known member
PicKit3 arrived, and is now successfully talking to MPLAB; and has programmed the first PIC12F1840. The first hat should be done; I'm planning on testing it tomorrow (er, later today - it's 4AM, and I really need to get some sleep).
 

bdurbrow

Well-known member
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.
 

cheesestraws

Well-known member
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.
 

bdurbrow

Well-known member
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:

Code:
./tashtalkd --device /dev/ttyAMA0 --verbose

Is there something else that I should be doing to get it to talk to the PIC?
 

tashtari

Well-known member
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.
 

bdurbrow

Well-known member
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.
 

tashtari

Well-known member
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.
 
Top