USB2LT TashTalk Usb to LocalTalk

[twelvetone12]

I'm moving the topic of discussing the USB interface to LocalTalk here so we don't OT too much the other thread.
While on the train I drafted a simple adapter. It uses an FT230X instead of the CH340 since the latter seems to have been obsoleted. In my experience with FT230X it is only a 3.3v volt part and will die at 5v, hence I decided to run everything at 3.3. The tranceiver is a SN65HVD12 (even if the schematic says SN65HVD11 since I didn't have the other symbol, and I guess the unit load is the same?) which in 8-SOIC seems to be active and available on DigiKey. I copied the filtering for USB from the datasheets and a couple known-working projects.

I copied the Mini DIN connections from the RPI hat but I'm not 100% sure, so I will have to verify those. I choose an USB-B plug since is is nice, big and sturdy and in my experience mini-usb can be a little fragile especially with hand assembled stuff. My idea is to make it all SMD which I know sounds scary but in reality is very easy to mount by hand, and if ever we need to make a small batch I have the means to do so professionally.

In all this circuit is quite simple and I should be able to do the layout myself quite comfortably. I think then making a DIN-3 or PhoneNet as we discussed on the other thread should by very easy - it just needs a transformer and another chip + connector. We can see then if there is interest.

Comments are welcome and keep in mind this is just the first draft

 

[tashtari]

Cool! The only thing I can think of is that the way the TashTalk 2.x hat is set up, the mini-DIN has to be connected to a LocalTalk or PhoneNet dongle, it can't work with a direct serial cable since it ties Tx and Rx together. If you're fine with that restriction, no need to change anything, but if you're interested in making it work with a serial cable, you'll need to separate out the receiver and driver (whether by using two SN65HVD12s or a chip that combines them).

 

[twelvetone12]

Ah-ha! I was wondering where the catch was there The tranceiver is the most expensive part on the board, I can see for a combined one if it is cheaper, IIRC Maxim still makes them.

 

[cheesestraws]

Yeah, this is why AirTalk has separate transmit/receive paths after the TashTalk, so that it works with serial cables.

 

[twelvetone12]

Now I figured it out I could not understand why the tx and rx were mixed in the LT adapters, but it makes sense: to use a serial cable obviously! I think I will go with a second SN65HVD1x since it seems the easiest part to find (both seem active @digikey but TI says the 12 is discontinued, sigh)

 

[bigmessowires]

What's the high-level functional description, for viewers who are just tuning in now? This device connects a LocalTalk-equipped computer via USB to... what? Is there a LocalTalk-on-USB stack for Windows / OSX?

 

[twelvetone12]

It basically bridges Localtalk to serial USB using a TashTalk. On linux it works with tashtalkd / multitalk / my kernel driver when it will be finished / any other appletalk stack that can use TashTalk. I did not really try any of this on osx or windows.
For my personal use, I want to have a share on the linux machine so I can easily copy and print via localtalk and a serial cable from my old macs. I also need it to help me work on the linux kernel driver and maybe can come handy with others wishing to develop things with TashTalk.

 

[tashtari]

tashtalkd should work under OS X and Windows, though I have only tested it on Linux. multitalk, too, perhaps, though I haven't tested it either...

 

[bigmessowires]

Thanks. I have not been following any of this development or the related past projects, so apologies if I'm asking dumb questions. By serial USB, do you mean a USB device that's implementing a serial port for the host, like those USB-to-serial cables you see with Arduino and RPi projects?

Then on the host software side, there's AppleTalk (the network protocol) which is separate from LocalTalk (the physical network). From a very quick look, I guess tashtalkd and multitalk are AppleTalk stacks for Linux? The multitalk page that I found mentions operation over Ethernet with TCP or UDP, but nothing about using a serial interface. But assuming there's a suitable AppleTalk-over-serial stack on the host, what application software exists that can use it? You've mentioned printing, which presumably would require more plumbing on the host side to advertise available printers over AppleTalk and accept/process print jobs. What about file sharing a directory on the host computer as an AppleTalk share? Is that possible, and what software would you use to set it up?

 

[tashtari]

tashtalkd isn't a stack per se, it's a simple utility that translates between TashTalk's serial protocol and LToUDP, which is arguably the "stack" in this case. @cheesestraws 's AirTalk does the same thing in a self-contained, purpose-built unit. Mini vMac supports LToUDP, too, though the current stable release doesn't have it enabled. @sfiera 's multitalk can function as a simple bridge between LToUDP and EtherTalk, allowing LToUDP traffic to communicate with Macs with Ethernet and/or with Netatalk 2.x, and support is in development to allow multitalk to subsume tashtalkd's function and talk to LocalTalk directly via TashTalk, though I don't believe it's functional yet.

 

[twelvetone12]

What I'm been trying to do is to implement a localtalk driver (though TashTalk) for Linux, since Linux still contains AppleTalk + LocalTalk stacks in the kernel. This would permit to run netatalk (that does file and printer sharing) directly on the localtalk network, without needing a localtalk / ethernet bridge. Since my PC has no serial ports, I need a serial + usb adapter, and then an rs422 tranceiver. I have all this on a breadboard, but the idea is to integrate it all in one board.
Having this will also (hopefully) make other developments easier, since it will permit any modern machine to communicate on the localtalk network, and hopefully it will make developing other appletalk stacks or routers a bit more easy.

 

[twelvetone12]

Small update on this too: I made a new schematic and finished the layout, I promised the Linux developers there was a device to use the TashTalk driver so now I need to make it

 

[Mk.558]

Do you have any plans for higher speed LocalTalk? When it works, the EtherWave Printer Adapter / Mac/PB adapter is great for shuffling things over the serial port. The fastest I recorded it was on a IIfx at just over 100KiB/sec -- five times faster than standard LocalTalk which caps out at 19-20KiB/sec or 230400bps.

As the number of Ethernet cards/devices continues to dwindle, I'm sure future-us will find that feature very helpful.

 

[tashtari]

Do you have any plans for higher speed LocalTalk?

The limiting factor here is TashTalk. it's only capable of communicating at the normal rate of 230.4 kHz, and I don't see that changing - the PIC is not rated for being clocked any faster, and the code that bitbangs LocalTalk is just about as tight as it can be.

 

[tashtari]

...You've sort of got the gears turning. I'm now wondering if it's possible to use the external-clock functionality to bridge what the Mac thinks is LocalTalk to some other bus, such as Ethernet. It might be.

 

[twelvetone12]

This is interesting, I never heard about the EtherWave Printer Adapter, I guess going faster on the PC side would be mostly a question of serial adapter capabilities?

 

[tashtari]

If you're connecting TashTalk (or a similar device in the same situation) directly to the Mac, with no other Macs on the bus to worry about, and TashTalk controls the clock speed, it opens up a lot of possibilities. The clock doesn't have to be regular, it can just be whenever TashTalk feels like receiving another bit. This is interesting, I'm going to have to think about this.

 

[dougg3]

I have an EtherWave Printer Adapter. Almost 10 years ago, I did a bit of research on it when I was playing with my LocalTalk adapter project. Without any special drivers, it just does normal 230.4 kbps LocalTalk communication. When you activate the "PB Adapter" driver for it in the Network control panel, that's how the faster speeds are enabled. It seems to be putting the Mac's SCC into some weird mode that is no longer FM0 encoding I think.

Unfortunately a lot of my research related to this dropped off the internet, but archive.org saved some of it. Here's the relevant scope traces of the higher speed mode:

Mac68k Forums: Localtalk bridge ...

 

[tashtari]

Ah, interesting, it's a whole other communication scheme. I wonder if there were any other setups that just clocked the SCC faster through the GPi pin and were otherwise the same as LocalTalk.

 

[Mk.558]

I have a "dead" Mac/PB Adapter that has is available for experimentation/testing/whatever you want to do to it. It's got some minor crusties, but if you want it, it's yours. My other one decided not to route TCP traffic anymore so it is either the capacitors on board or it's too tired for that thing.

I'm not very well versed on technical matters but instead of bit-banging it why not just do some kind of ASIC system with DMA that you dump data into and then have the ASIC process it out? Like, sure PIC/AVR microcontrollers are great, but why not just emulate the RS232 Clear to Send / Request to Send concept? The host machine can surely dump data into the memory much faster than it can be offloaded, so you can let the ASIC/PIC uC to do whatever speed negotation itself. The Tashtalk driver can then be focused on just sending AFP/TCP compatible data at whatever speed it wants, but the chip can handle the exchange. We obviously need a UART whether we like it or not, so...

An ATmega328 can run at 20MHz and (according to the datasheet) can process nearly 1MIP/s per MHz, and I'm pretty sure that there's equivalent PIC microcontrollers, such as a PIC18F26K22. "Equivalent" being used loosely here as each one has different capabilities in different areas. A quick look at the datasheet for both indicates they kind of cap out at 115200bps for asynchronous, but I don't have any information about synchronous limitations as that's above my head. I don't know much about FIFOs or buffers.

As far as the GPi pin was concerned, I made a post about that so pretty sure GPi is not being used here.

edit: the main reason I'm interested in this is mostly because the supply of 030 PDS ethernet cards has basically dried up. Who knows the time when getting a SE network card is going to be "no". Think about the other models too - Portables, PowerBooks, Duos...when was the last time you saw a UltraDock 16sce?

edit2: Wow I'm just rambling like someone who has no idea what they're talking about. Anyways I'm interested in the PIC choice now that I look at the first post of the TashTalk thread. I may have dabbled in some Arduino stuff briefly but I'm guessing the PIC12F1840 is ...basically equivalent to an ATtiny85, a 8 pin DIP or 8 pin SOIC that runs at 20MHz-ish. I'm curious if a more powerful uC would be helpful for the the faster data throughtput because ... well, transfer a 7.6.1 completed System Folder and a bunch of applications over on LocaTalk at 115200bps (it's not always 230400bps!) or roughly 10KiB/s and you'll be wondering about that faster speed...

They do make RS485 chips that are *supposed* to handle 2Mbps. Sure they cost more than a small SOIC PIC uC where you're using the built-in UART to handle the exchange, but 2Mbps is 2Mbps...