TashTalk USB

I can actually test that since I have a LocalTalk compatible printer on my desk at the moment (the same one that broke the original TashTalk firmware!).

On a related note. Is the USB VID/PID expected to be stable with the TashTalk USB dongles? I have setup auto-detect with that VID/PID plus a device name of "TashTalk USB". This isn't set in stone (its in python and easily changed). I just don't want to be TOO specific with the device in case something does change in the future.
 
At least for my version yes, I don’t think I’ll likely ever change the USB chip out unless it went out of production. But there was another device here that is based on a Pi Pico that speaks TashTalk that I know of: https://github.com/hanshuebner/tashtalk-pico. I am unsure if he plans to mass produce them though.

Otherwise the current VID+PID and the device name / manufacturer fields should be the same for every device including the ones Joe at JCM makes (at least based on the emails I spoke to him on).
 
My TashTalk USB board arrived the other day (very prompt!), and one of our fine colleagues in the Seattle Retro-Computing Society kindly printed me a case for it according to the supplied design files. Yesterday I acquired a suitable USB A-C pigtail cord – via Amazon (*spit*), sadly – and I finally had a chance to try it out just now. It’s unfortunately far too hot today to fire up any other LocalTalk devices to connect to using it, but I can confirm it was recognized as a valid USB serial device on my MacBook running Sequoia even before I downloaded the TailTalk app, and the app itself seems to work very well. Of course I can’t say that with total certainty until I try to connect to it from a LocalTalk host, but I’m really looking forward to doing just that as soon as the current heat wave dies down a bit.
 
I have a PR up here if either of you (@Iesca / @NJRoadfan) want to give it a try: https://github.com/FeralFirmware/TailTalk/pull/29. I am so thankful for the kinda hidden process-but-dont-actually-print PostScript option because I would have gone through so many page prints trying to get this all working 😅

One of the things that made it a bit more complex was any modern pages I tried to print resulted in huuuuge postscript data which made the printer sit there and think for 5 to 10 plus minutes on top of the LocalTalk transfer time. I used Ghostscript to render it down to 1-bit monochrome PBM which my lowly 4/600 can process as fast as you can throw the data at it, regardless of how complex the page gets. It does require Ghostscript to be installed and available in your PATH of course to work.

I've only tested this on my Apple Silicon Macbook but I _think_ it should work on Linux too. Less sure of course about how it will work on Windows but I think it should Just Work(TM) there too.

Probably will clean this code up some more and give it some more testing with other devices before I go to merge it but it seems to work as a proof of concept for now.

My TashTalk USB board arrived the other day (very prompt!), and one of our fine colleagues in the Seattle Retro-Computing Society kindly printed me a case for it according to the supplied design files. Yesterday I acquired a suitable USB A-C pigtail cord – via Amazon (*spit*), sadly – and I finally had a chance to try it out just now. It’s unfortunately far too hot today to fire up any other LocalTalk devices to connect to using it, but I can confirm it was recognized as a valid USB serial device on my MacBook running Sequoia even before I downloaded the TailTalk app, and the app itself seems to work very well. Of course I can’t say that with total certainty until I try to connect to it from a LocalTalk host, but I’m really looking forward to doing just that as soon as the current heat wave dies down a bit.
Glad it made it there OK! We ended up with a good few really cool case designs from members here and elsewhere which is so cool to see. Hope it works with all the LocalTalk devices you can throw at it (when its not so toasty too!)
 
Hmm, in order to test I will need to acquire an older printer... As fun as an IWII is, I've been thinking about getting a StyleWriter instead recently. Any particular model people recommend? Mac Plus compatibility would be best, and so doesn't need to be in color. (Their ink carts are still made, yes?)
 
A couple of questions.
  1. Is the speed the full Localtalk speed, or serial connection speed?
  2. Has anyone tried this with Basalisk II? Similar to what I did with a serial to USB connection? Minus the need for ARA I assume? https://www.savagetaylor.com/2020/1...pnetrouter-and-a-usb-serial-null-modem-cable/
Full LocalTalk speed. It will not work with Basilisk II as it requires additional coding in the emulator to treat it as a LocalTalk device vs. a serial device.
 
Well, I finally had a chance to try it out... and I think there may be an issue or two with the (Mac release of the?) software. Trying to connect to my Intel MacBook running Sequoia, from a Quadra 700 (admittedly, a heavily upgraded one) running OS 8.1, yielded only an error message claiming that my “file server will not allow any additional users to log on” and I should try again later.

Has anyone else encountered this problem? If so, did you find a workaround?
 
Well, I finally had a chance to try it out... and I think there may be an issue or two with the (Mac release of the?) software. Trying to connect to my Intel MacBook running Sequoia, from a Quadra 700 (admittedly, a heavily upgraded one) running OS 8.1, yielded only an error message claiming that my “file server will not allow any additional users to log on” and I should try again later.

Has anyone else encountered this problem? If so, did you find a workaround?
Sorry it's giving you trouble! Any chance you could record a packet capture of it (Just need to tick the PCAP option on the GUI and then DM it to me if possible) as well as provide the log files for one of the runs that you hit this on (File -> "Open log directory" on the top menu). What does your share look like too - is it just a regular folder in your user directory, some external share, or something else? It currently only support HFS+, APFS on macOS - it will bail on FAT and friends, or network shares.

I'm thinking that it's a permissions issue most likely - we check if we can actually open the folder pretty late in the AFP login process and if we cant write to that path (Be it the database, xattrs, or resource forks) we will throw an error back to the client which shows up like this.

I test each release of this on my Macbook Neo on my 512K with Sys 6 through Mac OS 9 on my PowerBook so it should work OK, but I will admit that our error handling should be better here.
 
Last edited:
I can indeed send you the log and the pcap! Because of obsessive completism, I had left the pcap running during the entire session; which involved trying to connect repeatedly from numerous old machines, all of which got the same error out of it – and if it was a permissions thing, that makes perfect sense. The share directory was “~/Public/Pyreflyer” (a normal directory as far as I know; the weird name is simply because the machine’s name is Pyrefly.) Looking at it now, both ~/Public and ~/Public/Pyreflyer have the usual 0755 permissions, while I see in the log that it thinks the filesystem is read-only because it was unable to create a Desktop Database. Does it run that part using Group permissions or Other permissions? In principle, I would expect either Owner or Group permissions for internal operations and Other permissions for external users’ actions, but my minimally-informed speculation can’t tell me what it actually does require.
 
Back
Top