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

StarTalk: a new LocalTalk hub

Is this a device to allow one Mac use many serial devices or a device that allows many Macs to send each other packets via AppleTalk? Or is it something else again?

This is a device that allows you to wire a LocalTalk network up with wires running to a central point, instead of a long daisychain. It's really just a wiring convenience. (It will also, in theory, allow you to have more than 32 nodes on a single LocalTalk network, but I'm not sure how well that will work in practice, nor am I in any kind of position to test that).

If it can be used for networking Macs, would you stick on an RJ45 port to it please? It would obviate the need for a bridge Mac. I certainly would be interested in one if I could connect my Mac 512K to my Mac Mini G4 file server.

No: this isn't an intelligent device, it's just shuttling around and amplifying electrical signals. It doesn't understand the packets themselves, and certainly doesn't speak Ethernet. Keep an eye on the other project I've got chuntering away in the background for that - I've got the hardware for a new bridge done, and when I'm feeling up to an actually difficult project again I'll start working on the software.

Could one play NetTrek on a group of, say, SEs with this?

Yeah, should work if it'll run over LocalTalk.
 
I have a 512k, eMate, 660av and 8150 running on LocalTalk, plus a FastPath and TashTalk running on a Pi for Netatalk. Happy to give it a test if there’s one available!
 
I have a 512k, eMate, 660av and 8150 running on LocalTalk, plus a FastPath and TashTalk running on a Pi for Netatalk. Happy to give it a test if there’s one available!

Cool! Drop me a DM with where you'd like it sent, I'll get some DIN-8s on it this weekend and send it out your way.
 
I used to run a school network with a Farallon StarController. Looks like you have basically built the same thing. The only advantage was to keep a number of LocalTalk chains separate from each other so the noise/traffic was contained within the chains. An example would be multiple classrooms each on their own LocalTalk zone but with the ability to cross zones for file servers and printers. The StarController did well for LocalTalk networks that had grown and the school didn’t want/addors to have to run CAT5 cable. Old school buildings are a nightmare to cable if the only network they had was one 4 core cable between buildings.
 
No affiliation with the seller, but there's a guy on eBay selling TOPS FlashBoxes.

I bought one of them, and of course the very first thing I did is take it apart.

It's just a 2 layer board from what I can tell, nothing but traces on the backside. There was a sticker on top of the PAL chip, I removed it and stuck it to the backside. Looks like it's got a PAL chip, a RS422 bus transceiver chip and some passive components like diodes/ferrite beads/resistors/6.144MHz oscillator/some capacitors and a 7805 voltage regulator. On the side marked with COMPUTER it uses a PS/2 jack, with a regular Mini-DIN-8 for the NETWORK side. It doesn't use GPi or HSKo.

IMG_0005.JPG

Apparently it handled up to 770Kbps. Surely there's some way we can implement this in a modern format. The driver disk is somewhat interesting, but I wonder if we can do this without a driver. A switch on the unit could set the clock speed from 230.4Kbps all the way up to 921.6Kbps with intermediate ranges of course. While it is said that there were DE-9 adapters for the FlashBox intended for the 512Ke (I suspect the 512K would be compatible too), I believe that was separate, and I highly doubt the 512K platform can push anything beyond 115.2Kbps because real-world testing of a 512K struggled to reach 7.5KiB/sec (i.e. less than 115200bps) -- and that was on a RAM disk.
 
Rev2 has arrived, and is working! It's slightly smaller, also has both blinkenlights and filtering on the ports (the same low-pass R/C networks as are found in a Mac, on AirTalk, etc). Orange light is "transmitting out of port", green light is "receiving on port". Thanks to @demik and @Hollie for iterative suggestions on rev1


View attachment IMG_3549.MOV
 
I would assume that since it is a hub (and not a switch) you could save on BOM cost by omitting the orange light except for one.
 
I would assume that since it is a hub (and not a switch) you could save on BOM cost by omitting the orange light except for one.

Yes, although given they cost 1 US cent each (and the transistors to drive them another 1 US cent each), not hugely :-). By far the most expensive component on here is the USB power connector, followed by the mini-DIN connectors, followed by the line drivers.

Here's some bonus photos: the rev2 board is quite noticeably smaller because it doesn't have the BNC holes on it. This knocked it down a price notch and even with the added filtering and LEDs, I think it came out cheaper per board.

IMG_3551.jpg

And here's the thing fully clothed:

IMG_3552.JPG

IMG_3553.JPG
 
This is a really nice device, especially since it allows for the use of regular printer cables instead of the need for: 1. PhoneNet boxes and harder-to-find phone cables, and 2. the need for the official Apple dongles with their proprietary cables between them.
 
So can we now safely say 2025 is the year of LocaTalk?

year of linux localtalk on the desktop tbqh

As usual, really well executed and it looks lovely!

thankyou - you say this, but it may yet prove to be a polished turd. More testing is needed. The problem is that I am doing this the easy way, because I'm not good enough to do it the better way.

The way I'm doing this relies on the differential signalling of RS485: when a mac is transmitting a packet, it ought to assert a differential voltage across the transmission pair. The hub detects the differential voltage to detect a transmission, and when it sees one, passes that transmission through to the other ports.

This works well for hardware that follows the rules: but badly made or cheap "meh, it works with localtalk, ship it" hardware doesn't entiely obey these rules. In the "badly made" category, for example, the thing I made to have a localtalk activity LED on my appletalk router seems to result in 0.5V being permanently across the lines, which confuses the hub (and isn't standard compliant, I need to fix that). In the "cheap" category, I have my suspicions about the AsanteTalks - if I remember correctly (must do a teardown and document what's in one...) they don't actually have any kind of proper differential drive. A lot of these cheaper things rely on the fact that if you pass what they're producing through a LocalTalk or PhoneNet box, the results more or less look right enough to work, and that is probably the case for this hub too (it's also the case for, for example, AirTalk, where there are some things you have to have two localtalk boxes between it and them for various reasons).

The better way to do this would be with clock detection. This is actually what the Mac uses to do its collision avoidance - it checks whether there is any kind of clocked signal being received, and if so it won't transmit (the gory details of this are in Inside Appletalk - I only just understand them so I may be misrepresenting this). But that's much harder and I don't know how to do it, so this will have to do for now.

So this is only a proof of concept. Now I need to work out if this is actually good enough for practical use or not.
 
OK - I have a spare "built up" one of these. One left unspoken for. Anyone want it? Cover postage and it's yours.

I will be putting up the design files on github as soon as I have the time and energy.
 
Hmm, would love to have an 8-port variant of this for Pippin lanparties.
 
Back
Top