| Click here to select a new forum. |
| TashTalk USB |
Posted by: NJRoadfan on 2026-06-28 14:30:49
On the server side, PAP has to handle parsing Postscript comments as part of the Adobe Document Structuring Conventions.
Also see Inside AppleTalk Chapter 14.
Supporting Macintosh LaserWriter drivers older then 7.0 isn't straightforward to do. These expect the LaserPrep file to be stored resident on the printer or spooler. The LaserWriter 7.0 driver can be installed on older versions of MacOS if needed and came with System 6.0.8. The Apple IIgs LaserWriter driver does some funky stuff when starting a print job that tripped up Netatalk (it sends Postscript data before the magic string), which has since been fixed. |
Posted by: Bolacore on 2026-06-28 14:37:53
Yeah I figured it'd likely be the same way I'm using that for querying the LaserWriters to bridge to IPP. Always love a good excuse to break out my Inside AppleTalk book though 🙂 The only extra thing I think I'd do is bridge straight to IPP rather than rely on CUPS to try and keep it platform neutral and just translate the PostScript queries to and from IPP's versions. |
Posted by: NJRoadfan on 2026-06-28 14:52:58
In terms of attribute collection, CUPS is only used in Netatalk for the actual IPP communication link. Since papd always supported PPD files for retrieving printer attributes, a shim was built using IPP queries to generate a stub PPD on the fly with just the information the LaserWriter 8 driver needs. |
Posted by: Bolacore on 2026-06-28 14:54:45
Ahh that is great to know thank you! On another note too - any chance you know if the LocalTalk adapters for the later Colour StyleWriters use ADSP? I'm working on getting support added for the official Apple StyleWriter EtherTalk adapter to print to my CS 2200 which I know does and same with Grayshare, but I cant seem to find any docs about the LocalTalk module. |
Posted by: NJRoadfan on 2026-06-28 15:45:10
As per the lpstyl driver notes, at least the CS 2400 supports it: https://github.com/Godzil/lpstyl/blob/master/README.atalk
Notes say it hasn't been tested with the LocalTalk adapter. |
Posted by: Bolacore on 2026-06-28 15:48:28
I think that's just talking about the EtherTalk adapters though right? I cant see the localtalk reference unless I'm just looking right past it. The one I was curious about was this: https://applerescueofdenver.com/pro...pple-color-stylewriter-2400-localtalk-module/. |
Posted by: applesos on 2026-06-29 16:28:23
Just received mine and have confirmed that it works with a direct connection from a modern host and via AirTalk using the GUI to serve files over AFP. Will be testing with the MacIPGW virtual machine and will update with results there- my physical fileserver lacks the AppleTalk kernel modules. |
Posted by: applesos on 2026-06-30 19:37:35
I was able to get everything running without issue on Ubuntu but sharing ran into similar problems as others trying to get Netatalk and Tashrouter to run together on the same bare metal. Since Tashrouter can function as a LocalTalk-Ethernet bridge (unless I misread the docs), I'm going to try serving files over AFP from a G4 via ethernet and keep Tashrouter on the Ubuntu box- hoping to keep documenting stuff for anybody with the same use case later on. Definitely more complex than a Pi and a Tashtalk HAT but given the price increases, the ability to use this as a cheap, drop-in solution on any existing computer is very useful. |
Posted by: Bolacore on 2026-07-03 12:42:12
It was one of the most frustrating experiences ever but I now have TailTalk able to directly print to my Colour StyleWriter 2200 with the official EtherTalk adapter, which should also work with the LocalTalk adapters and GreyShare (I think).
Thankfully lpstyl documented most of the interesting parts but oh my is that printer not forgiving in the slightest. It's pretty lazy right now in that it waits for the SW buffer to be drained before sending more data (Same as lpstyl) but after capturing a session from the native Mac OS driver printing images I should be able to replicate the "topping up" buffer behaviour the native one does. I still need to get it a little more stable and get the CMYK conversion in but I hope to have auto discovery and IPP advertisement for this one in the next TailTalk release 🙂 |
Posted by: Iesca on 2026-07-03 12:44:31
I still need to get it a little more stable and get the CMYK conversion in but I hope to have auto discovery and IPP advertisement for this one in the next TailTalk release 🙂 Congratulations! |
Posted by: applesos on 2026-07-03 16:36:59
I was able to get everything running without issue on Ubuntu but sharing ran into similar problems as others trying to get Netatalk and Tashrouter to run together on the same bare metal. Since Tashrouter can function as a LocalTalk-Ethernet bridge (unless I misread the docs), I'm going to try serving files over AFP from a G4 via ethernet and keep Tashrouter on the Ubuntu box- hoping to keep documenting stuff for anybody with the same use case later on. Definitely more complex than a Pi and a Tashtalk HAT but given the price increases, the ability to use this as a cheap, drop-in solution on any existing computer is very useful. Looks like everything is working. My Powerbook can see zones and I can assign devices to the configured zones. File transfers route through TashRouter when using two LToUDP-connected peers. I still need to test connection between LtoUDP devices and hardware connecting via ethertalk but otherwise this is performing to spec.
I have a Powermac G4 which is connecting over WiFi via an adapter that plugs into the Ethernet port. As expected since AppleTalk cannot be encapsulated over Wifi, I'm getting errors that the DDP header length is invalid. Those extra characters in the header presumably are due to the ethernet frame being passed via WiFi.
Interestingly, attempting to enumerate connected hosts from a WiFi-connected device crashes all devices on the AppleTalk network.
I am unsure if this behavior is also present when using the TashTalk Hat or is specific to using TashRouter with a TashTalk USB. |
Posted by: NJRoadfan on 2026-07-03 21:08:37
DDP traffic generally passes via WiFi without a problem. Its AARP that has problems. |
Posted by: applesos on 2026-07-04 09:45:24
DDP traffic generally passes via WiFi without a problem. Its AARP that has problems. Weird, wonder what was giving me the DDP header length error then. |
Posted by: Bolacore on 2026-07-08 21:31:33
After wasting a painful amount of paper and far too much ink, I finally have my Colour StyleWriter 2200 working as an AirPrint capable printer 🙂 Should work the same as LaserWriters now in that TailTalk auto discovers them, queries the installed cartridge(s) and model, and makes them available on the network. I am so thankful big bottles of ink for this thing are cheap as I had to refill it far too many times during debug. Colour works just fine too, and I'm pretty sure this code should work with the 2400 and 2500 too but I dont have any to test with. Will have this in the next release ✌️ |
Posted by: SimbaSeven on 2026-07-09 17:41:55
Are any available for sale? |
Posted by: Bolacore on 2026-07-09 17:55:30
Yes I still have some! You can order from me directly here, or on Tindie: https://www.tindie.com/products/feralfirmware/tashtalk-usb/. |
Posted by: iigs123 on 2026-07-10 09:26:21
I had a break, but I'm back and poking around things again.
I added a little example program to capture tashtalk traffic and do nothing else. I thought I might observe how real hardware interacts with each other. In my capture I can see my LC II looking for =:ImageWriter@*
I also saved a capture from nbp-lookup, trying to find the same ImageWriter.
Interestingly the length of the frame generated by tashtalk is 31 bytes whereas the length of the frame generated by the LC II is 33 bytes. Are these two missing bytes the CRC? Or is this just some side-effect of the capture or something? |
Posted by: iigs123 on 2026-07-10 11:31:20
nevermind, I see in the comments:
/// Frames are written without the trailing CRC bytes. |
Posted by: Bolacore on 2026-07-10 11:32:12
Ahh sorry I didn’t think anyone would want them in the pcap - should they be there? It’s easy enough to add it back in. |
Posted by: iigs123 on 2026-07-10 11:40:33
I'm just comparing to see what is different and what might need to change to see devices like the ImageWriter via tashtalk.
Now that I write this I was capturing both via the tailtalk, so I'm still curious why one frame was 33 bytes and one was 31 bytes since the same code captured both. I noted the difference in wireshark.
Frame 2: Packet, 31 bytes on wire (248 bits), 31 bytes captured (248 bits)
vs
Frame 381: Packet, 33 bytes on wire (264 bits), 33 bytes captured (264 bits) |
| < 8 > |