Jump to content

Idea: wireless LocalTalk adapter


Recommended Posts

I was just thinking how much of a ball ache it is to get old Macs talking to each other, not because LocalTalk doesn't work really well, just because of the practicality of stringing cable everywhere (and finding LocalTalk adapters). 

 

What would be amazing would be a gadget I could plug into my printer/modem port that took the LocalTalk signal and joined my wi-fi network, and posted the serial data "over" the wireless TCP/IP connection and then the same gadget on the other end could convert it back into LocalTalk. 

 

Would such a thing even be possible? 

 

Joel

Link to post
Share on other sites
  • 68kMLA Supporter

Yes, it's possible, and I've thought quite a lot about how to build them.  But in order to actually build one I'd have to pick up skills I do not currently have, and I haven't had the time to actually do that yet.

 

Some time ago, I came up with a roughly standard and pretty simple way to tunnel LocalTalk over UDP multicast, which gives you an "overlay" LocalTalk network over an IP network.  Code to speak this is already in Mini vMac, so you can have plug and play networking in that these days. :-)

 

LocalTalk itself uses framing on the wire based on that of SDLC. In the Mac, this framing is dealt with by the SCC chip.  There were (are?) Zilog microcontrollers that have a built-in SCC, but I don't think that it's reasonable to look for one that has both a built-in SCC and has built-in WiFi :-p.  So we're probably looking at an ESP32 or similar.

 

Therefore, the dongle would probably need to do SDLC in software.  Last time I looked, no really convincing libraries for this existed; @saybur had a plan for how to do it but it was a bit skeletal and I have not had the time or energy to flesh it out.  Once you have something that can hand off SDLC frames, you would essentially use exactly the same code as in Mini vMac to turn those frames into UDP multicast packets.

 

I also have cunning ideas as to how to configure the WiFi, but those would have to wait until at least the basics were in place :-).

 

So, basically, I need someone to help me write an SDLC framer/unframer/well behaved bus member.  Anyone want to collaborate? :-p

Link to post
Share on other sites
  • 5 weeks later...

Some random thoughts on this, in no particular order.

 

Train-of-thought the first:

 

- This is not an entirely new idea. Technically, the AppleTalk network-protocol family works natively over wifi just as well as it ever has over Ethernet cabling, even if the simple market forces of having to continuously reinvent the wheel did eventually impel Apple to abandon it wholesale in favour of Internet protocols. As you may or may not have reason to personally recall, the end-user experience did not match that; the tragic (and cringeworthily avoidable) cause follows, but first, some background.

 

- When Apple separated the AppleTalk logic (i.e., the signalling protocols) from the AppleTalk hardware, during which they renamed the latter "LocalTalk", they did it so they could cheaply make AppleTalk work over a few specific types of existing network hardware, one of which was Ethernet. That part was actually a lot simpler than it sounds.

 

- Low-level Ethernet packets, in themselves, carry hardly any information. They have the sender's 48-bit MAC ("Media Access Control") address, the receiver's 48-bit MAC address, and (if I recall correctly) the length of the packet. Everything else is the user's problem.

 

- In those days there were a _LOT_ of competing networking protocols, most of which could plausibly be found inside Ethernet packets in SOMEBODY's network, and often simultaneously with at least one other protocol ("That says 'Ethernet', and this says 'Ethernet'. I hooked both of the wretched things up correctly, so why isn't it working?"). Out of sheer necessity, a simple wrapper format had evolved (I think it was called SNAP, for "Shared Network Access Protocol" or some such) that added a few header fields inside each Ethernet packet; one such field contained a number meant to uniquely identify which protocol family could make sense of the contents.

 

- For quite a long time, a wide assortment of Apple products were shipped with (as was later discovered) a minor but disastrous oversight in the networking drivers: In every single Ethernet packet of a certain flavour, where that protocol identifier was supposed to be inserted, it had instead been left as a zero. According to all existing industry conventions, a zero in that spot should have been interpreted as "no protocol", leading to the packets being discarded unread. It had gone undetected because, by that point, it was rare for networks to carry traffic for more than one protocol family at a time, and for several years it had been almost unheard of for any single user's machine to be watching for multiple types; presumably, no one at Apple was bothering to actually check that incoming packets were in fact AppleTalk packets. (Any non-AppleTalk packets addressed to a specific Macintosh would have been silently discarded before ever being seen, as their alien contents would have been misinterpreted as corrupt data.)

 

- The problem came to light when third-party wifi-hardware vendors started getting complaints that their stuff was failing to propagate AppleTalk-formatted Ethernet packets. By that point, getting a software patch out to absolutely everywhere it needed to be would have been a gargantuan undertaking for Apple, at a time when they were already in the midst of halfheartedly transitioning everything to work over IP anyway. As far as Apple was concerned, a headache of this scale was basically the last nail in AppleTalk's coffin.

 

Train-of-thought the second:

 

- The logical structure you outline for this project is, essentially, a multicast tunnel. If you set it up such that your little adapter dongles logically isolated themselves onto an otherwise unused IP4 subnet, they'd never actually need to know what was in the data streams they were conveying. They'd only need to gather up the raw bitstream and forward it to the handful of other nodes on that logical subnet, which would then immediately feed it into their own host machine. The native LocalTalk protocols would take care of any unfortunate data collisions, exactly as originally designed.

 

I don't know if either of those little conceptual cow pies will be of use to this project, but you're welcome to them. :¬)

Link to post
Share on other sites
  • 68kMLA Supporter

Thankyou.  I was very much aware of the background here, but other readers of the thread perhaps are not.

 

22 hours ago, gsteemso said:

For quite a long time, a wide assortment of Apple products were shipped with (as was later discovered) a minor but disastrous oversight in the networking

 

This wasn't the only issue.  Apple used both EtherType and LLC/SNAP for AppleTalk packets.  In theory these should have been identical.  But Apple misread the spec, and specified (not just implemented!) the difference between Ethertype and LLC/SNAP to tell the difference between two different versions of the protocol.  Which means that bridging AppleTalk to wifi and back is actually lossy, and there is no clear way that the Wifi to Ethernet bridge should behave when faced with a 802.11 frame with AppleTalk LLC/SNAP headers.  I found a fascinating postmortem on this on an IETF mailing list once, but I can't find it now.

 

22 hours ago, gsteemso said:

They'd only need to gather up the raw bitstream and forward it to the handful of other nodes on that logical subnet, which would then immediately feed it into their own host machine.

 

There's a couple of issues with this approach, unfortunately; firstly, that although LocalTalk is synchronous serial, the clock is generated by the speaker at any given time, and the protocol stack uses the 'loss of clock' signal to make detection of some situations much quicker.  (It is educational to compare this to Econet, which is technically very similar but has a network-global clock, and so recovers from some failure situations much more slowly than LocalTalk does).  So you would also have to transmit metadata about the clock, specifically when there was or was not a clock on the line, and regenerate that clock in the appropriate way at the receiver.  This is covered in detail in the first section of—and in even more detail in the appendices to—Inside AppleTalk.  This is also exactly the same reason you can't just run LocalTalk over RS232, that just transmitting the data bitstream is lossy.  Secondly,

 

22 hours ago, gsteemso said:

The native LocalTalk protocols would take care of any unfortunate data collisions, exactly as originally designed.

 

The timing requirements on LocalTalk's collision detection are quite tight, and are significantly tighter than what I would consider a reasonable worst-case normal for IP round-trip, especially over wireless.  In fact, they're tight enough that, for example, the Zilog technote on 'how to implement localtalk in one of our microcontrollers' specifically calls them out as difficult even when you're on the bus directly.  So this is a recipe for actually having lots of collisions, and this is especially silly when you're on a multipoint full-duplex "bus" like IP multicast, when collisions are not actually a thing anyway!  And exacerbating this is the problem of packetisation: depending on how much of the bitstream you transmit per packet, your collision notification will likely arrive at the speaker far too late to be of any use.

 

(Note also that emulating LT's collision model in this way allows a third party on the emulated bus to prevent two other computers communicating without really trying to; this is a problem that is unavoidable on a physical bus network, but would make the emulated network enormously less useful for, say, implementing and testing AppleTalk services).

 

That's leaving aside the fact that trying to transmit a raw bitstream in this way muddles up network layers appallingly, which is likely to lead to the same kind of subtle breakage you get running TCP in TCP, and changes the risk profile for unreliable packet transport considerably.  I don't know what that breakage would look like, I prefer not to go above layer 3 :-)  (and I don't tend to live in AppleTalk's stream land anyway, so I don't know how congestion control works here—and thinking about congestion control gives me a headache, which is a shame, because it's one of the things I'm occasionally paid to do...).

 

In summary, then, I think that trying to transmit a packetised data stream as a dumb bitstream + control metadata over another packetised transport is a Bad Idea.  I did consider it when I was originally speccing out LToUDP, but it has a lot of nasty edge cases, it's harder to debug, and it would end up providing a worse experience.  When you combine this with the fact that HDLC framing as used by LAP is really not complicated or difficult to deal with—and that everything on a LocalTalk bus is specified to use LAP—it also basically wins you nothing in simplification of engineering.

 

23 hours ago, gsteemso said:

The logical structure you outline for this project is

 

I'd also note that the LToUDP protocol has in fact been tested "in production" (for want of a better word).  It's in mainline Mini vMac right now, and has behaved itself very well in that context.

Link to post
Share on other sites

Ah, I see! I had a vague idea that the timing might not work out so conveniently as I imagined in (for example) an environment with poor RF reception, but I didn't realize the concept was so implausible right down to the foundation. It does seem kind of obvious in hindsight, though. I really should try to spitball some numbers on that sort of suggestion before raising it in public.

 

I'm also intrigued by those details about a mistaken belief that the protocol-identifying numbers could be treated as distinguishing characteristics. This sort of thing is what keeps retrocomputing so interesting; there's always more wrinkles to the story than you thought!

 

…I realize that the inherent ambiguity caused by that definitional screwup means a bulletproof method of Doing It Correctly is demonstrably not possible, but it occurs to me that you _might_ be able to come close by getting clever with checksums. I haven't verified this against any documentation, but ISTR that most of the protocol-encapsulation layers within an Ethernet frame come with their own checksum fields; _if_ any of those are not calculated identically, it could (at least some of the time) give a useful hint on guessing the proper interpretation.

 

Also: I posted last night immediately before heading off to sleep, and remembered afterwards that I'd left out part of my ramblings.

 

Train-of-thought the third:

 

- Not sure if it's a majority trend, but when I build something that will be connected to a specific port, I tend to think in terms of the wire-level encoding that the port normally handles. For a vintage Mac — just like most other machines that have a connector labelled "SERIAL PORT" — that's the traditional, teletype-style, byte-framed format that they make U(S)ARTs to handle the fiddly bits of. (Specifically, individual bytes are sent at unpredictable intervals, but each individual byte is sent as a distinct frame; it has a rigidly-defined structure with a fixed length, and no frame's encoding is affected by any other frame.) Not only that, but the construction of a traditional "serial port" connection assumes that every signal line is one-directional and logically separate; as defined, no signals transmitted from any pin of a given port are going to be visible (i.e., received back) at any other pin of that same port.

 

- At the wire level, LocalTalk does not involve that format at all, but rather (as you mentioned earlier) SDLC frames, and with a completely different bit-level encoding (specifically, one of the "Non-Return [to/from] Zero" — NRZ — types, which vary in specifics but all involve forcing the line to make an extra transition between HIGH and LOW whenever it's remained in a constant state for too many bit-periods in a row, which could cause the receiver to get out of step with its timing and lose track of where one bit becomes ignored in favour of the next). Not only that, but every device on the same network wire will both send and receive every transmission in realtime; there is only one signal line for all traffic.

 

- That last point means that every bit transmitted by a given LocalTalk machine will simultaneously show up as being received by that same machine (better have disabled those "incoming data" callbacks!), and that every device on a LocalTalk network has to assume that the line is busy unless it first checks to see that no other signals are detectable.

 

- Let's see how well I remember the details, now… Each LocalTalk SDLC frame contains a variable number of bytes, and the encoding of individual bits involves the insertion of extra, opposite-polarity bits whenever too many of them in a row are equal — which depends on what bit patterns are present within the body of any given frame, and within the same frame, the encoding of a byte can be affected by the contents of adjacent bytes. With this variable-length encoding at the level of individual bits, it is not possible to know in advance precisely how many post-encoded bits will have passed across the actual wire by the time a frame has been fully received.


- More to the point, an SDLC frame _cannot_ be transmitted by a normal UART, which is why the fact that Macintosh serial ports were implemented by a full-on serial controller chip — which can be programmed to transmit signal formats of arbitrary complexity — was either amazingly lucky, or an amazingly wise bit of foresight. Something that powerful is not a very practical choice for any gadget that needs to be cheap and simple, though.

 

- Since doing NRZ-ish-encoded SDLC frames on the same port as normal teletype-style serial transfer is so very non-trivial a problem, yet large numbers of optionally-networkable devices like printers were built in that era, I really should not have been as surprised as I was to discover that several companies used to sell single-chip I/O devices to handle all of the irritating details. I personally have encountered actual data sheets for three different such devices, from two different commodity IC makers, and seen mentions of another besides. All of them and any others like them have long been out of production, but even now, I'd be shocked if none could be found anywhere — the various online IC sellers seem to hoard pretty much _everything_, because being able to advertise that they stock and can supply any of X many million distinct part numbers is worth more in marketing dollars than the marginal cost of storing one more little baggie at the back of a rarely-touched shelf in some warehouse.

 

TL;DR: I couldn't tell you whether "There's An App For That", but I know for sure that "There's Old Cr*p For That".

 

(Yes, that pun was bad and I should feel bad… but I really, really don't. *grin* )

Link to post
Share on other sites
  • 68kMLA Supporter
Posted (edited)
20 hours ago, gsteemso said:

All of them and any others like them have long been out of production

 

Zilog Z85C30s are still in production, IIRC.  Last time I checked, RS had about 500 of 'em in stock.  They're not cheap but nor are they particularly expensive.  So the sensible way to do the LocalTalk side would just be to do it with an actual Zilog SCC and just use the algorithms detailed in the back of Inside Appletalk.  How long SCCs will be available for, though, I'm not sure...

 

Also, yes, I meant SDLC not HDLC, sorry :-).

 

(also, I realise my responses have been rather terse; sorry, it's been one of those days.  No rudeness intended.)

Edited by cheesestraws
Link to post
Share on other sites
On 4/24/2021 at 2:51 PM, cheesestraws said:

 

Zilog Z85C30s are still in production, IIRC.

 

Bwah????

 

I know the SCCs are still being made. They're a flexible solution to a broad class of problems, and there would be no economic reason to discontinue them. (The specific parts made in the 1980s and 1990s have in many cases been replaced by newer equivalents made with better process technology, but that category of part is not going anywhere.)

 

No, I was speaking of the specialized I/O controller ICs that, for a time, were produced by third-party chipmakers to drive combination serial/LocalTalk ports for builders of Mac peripherals. As in, the specific parts I was describing in that same paragraph?

 

In other words, I can see that it has REALLY been One Of Those Days, and you have my heartfelt sympathy. Also, don't worry, you hadn't come across as rude at all. Trying to correctly grasp the details on this stuff is interesting enough that I tend to get a bit hyperfocussed and, I'm told, I sometimes come across as rude myself; no worries, it's all good. *big relaxed grin*

Link to post
Share on other sites
  • 68kMLA Supporter
On 4/25/2021 at 7:08 AM, gsteemso said:

No, I was speaking of the specialized I/O controller ICs that, for a time, were produced by third-party chipmakers to drive combination serial/LocalTalk ports for builders of Mac peripherals. As in, the specific parts I was describing in that same paragraph?

 

Oh, right, specifically third-party parts, got it now.  Sorry, that was the detail I was missing.  It really was one of those days :-).

Link to post
Share on other sites
  • 68kMLA Supporter
Posted (edited)
On 4/24/2021 at 10:43 PM, gsteemso said:

I'm also intrigued by those details about a mistaken belief that the protocol-identifying numbers could be treated as distinguishing characteristics. This sort of thing is what keeps retrocomputing so interesting; there's always more wrinkles to the story than you thought!

 

Here's some of the IEEE (turns out part of the reason I couldn't find it is that I thought it was the IETF) discussion around this: https://www.ieee802.org/1/files/public/docs2009/h-nolish-mickonh-0509-v01.txt, in case you're interested :-).  Come for the use of AppleTalk as an example, stay for the phrase "I think the document is better than it was, but I'm afraid it still fills me with a sense of despair..."

Edited by cheesestraws
Link to post
Share on other sites

I used to have a set of infrared wireless AppleTalk adapters, but I sold them.

 

Back when I volunteered at a technology teaching place, we had several really cool motorized infrared wireless AppleTalk adapters.  Those were really cool.  We liked to put our hands in front of the sensor because it'd make the little motors whirrr and turn it about as it looked for a signal to latch on to.

Link to post
Share on other sites
  • 2 weeks later...

Most LocalTalk devices appeared to have used the SCC or derivative anyway, The Kinetics/Shiva Fastpath series certainly did. As for Wi-Fi DDP AppleTalk, Apple themselves clearly had it working fine with PowerBooks and their AirPort cards and base stations. In my case, a now ancient D-Link DWL-1000AP worked fine with AppleTalk and my Powerbook G4.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...