LocalTalk... but faster?

[tashtari]

So my objective in starting this thread is to fork from this one in asking the question of how to do LocalTalk faster.

I know there were a handful of schemes for LocalTalk-but-faster back in the day, and I'd love to know more about them. I know the SCC can be switched into a mode where an external, faster-than-230.4-kHz clock is provided over the GPi pin, and if there's software out there that simply enables that mode, I'd like to play with it and see what kinds of bitrates I can get out of a PIC with some clever firmware. I know the Farallon EtherWave was one such scheme - though according to @dougg3 's research, it appears to do more than just switch the SCC into external-clock-on-GPi mode, so it may not be suitable. Are there others? Is there a way to switch on the external-clock-on-GPi mode by patching LTLK resources, and if so, is that enough to take care of the problem of the Mac being able to load/unload the SCC fast enough, or is further hackery necessary?

My interest here is in creating a faster TashTalk-like device to provide connectivity to Ethernet-less macs. The limits of its current capabilities are the stock 230.4 kHz speed, which provides maximum compatibility, but unimpressive throughput. My thought is that if it's possible to provide the clock externally and the TashTalk-like device is the only device connected, it can pulse the clock whenever it's good and ready to receive a bit, potentially allowing for greater throughput as it doesn't have to worry about recovering the clock from somewhere else.

What do folks think?

 

[LaPorta]

I think you never stop pushing the envelope…too cool if this worked over Ethernet and flew.

 

[Phipli]

So my objective in starting this thread is to fork from this one in asking the question of how to do LocalTalk faster.

I know there were a handful of schemes for LocalTalk-but-faster back in the day, and I'd love to know more about them. I know the SCC can be switched into a mode where an external, faster-than-230.4-kHz clock is provided over the GPi pin, and if there's software out there that simply enables that mode, I'd like to play with it and see what kinds of bitrates I can get out of a PIC with some clever firmware. I know the Farallon EtherWave was one such scheme - though according to @dougg3 's research, it appears to do more than just switch the SCC into external-clock-on-GPi mode, so it may not be suitable. Are there others? Is there a way to switch on the external-clock-on-GPi mode by patching LTLK resources, and if so, is that enough to take care of the problem of the Mac being able to load/unload the SCC fast enough, or is further hackery necessary?

My interest here is in creating a faster TashTalk-like device to provide connectivity to Ethernet-less macs. The limits of its current capabilities are the stock 230.4 kHz speed, which provides maximum compatibility, but unimpressive throughput. My thought is that if it's possible to provide the clock externally and the TashTalk-like device is the only device connected, it can pulse the clock whenever it's good and ready to receive a bit, potentially allowing for greater throughput as it doesn't have to worry about recovering the clock from somewhere else.

What do folks think?

There were externally clocked "fast" localtalk box. But I've never owned one. This might be the most interesting thing if we can find one and the software. Sorry I can't add more, I don't know much about them.

Sorry for my pointless post. All enthusiasm, no content.

 

[twelvetone12]

This would be super cool. Until this morning I didn't even know there were faster localtalk implementations!

 

[tashtari]

external-clock-on-GPi

Looks like I mean HSKi, not GPi.

From Apple Guide to the Macintosh Family Hardware, 2nd Ed.:

Each port's Input Handshake signal (HSKi) is connected to the SCC's Clear To Send (CTS) input for that port, and is designed to accept an external device's Data Terminal Ready (DTR) handshake signal. This line is also connected to the SCC's Transmit/Receive Clock (TRxC) input for that port, so that an external device can perform high-speed synchronous data exchange. Note that you can't use the HSKi line for receiving DTR if you're using it to receive a high-speed data clock.

 

[bigmessowires]

Interesting. What's the intention for interoperability? If you could get super-speed LocalTalk working between the Mac's SCC and the TashTalk PIC, what would the PIC be connected to on the other side that could handle the faster data rate? Are you envisioning a whole LocalTalk segment where all devices are communicating with each other at super speed?

 

[Phipli]

what would the PIC be connected to on the other side that could handle the faster data rate?

Not sure if you're aware bigmessowires, but the TashTalk is one of the chips in the AirTalk - it acts as the interface between the ESP32 and the old Mac.

 

[cheesestraws]

Yeah, you could hook it up to something that speaks LToUDP (or similar) at the back end, so that you could have machines with heterogenous localtalk wire speeds on the same network.

That said, I think the problem of "how do you autodetect, or at least appear to autodetect, what LT line speed each machine can use" is an important one for usability here.

 

[tashtari]

What's the intention for interoperability?

Either it'll do the same thing as TashTalk does, i.e. bridge to a UART so it's accessible to another system like AirTalk, or as another possibility, it could go straight to LToUDP over an Ethernet interface via a chip like the ENC28J60.

how do you autodetect, or at least appear to autodetect, what LT line speed each machine can use

Yeah, that part I'm not sure about. A knob that you turn up until it breaks is the simplest solution, of course, but it might be possible to autodetect what "too fast" is by means of counting CRC errors in transmitted frames (and thus notice when the chip tried to clock out a bit before the Mac was ready)... of course, that doesn't account for load level on the Mac.

 

[Melkhior]

From Apple Guide to the Macintosh Family Hardware, 2nd Ed.:

Meanwhile in "Devices" (p496):

The Serial Driver does not support synchronous communication protocols. However, it
does support synchronous clocking supplied by an external device

And later (p510):

Although the Serial Driver does not support synchronous communication protocols, it
does allow you to select an external timing signal for synchronous clocking between the
sender and receiver. You connect the external timing signal to the handshake input
(HSKi) signal on pin 2 of the serial port, and select external clocking by sending a control
request to the output driver with a csCode value of 16 and bit 6 set in the csParam
field. See the section “Low-Level Routines,” beginning on page 7-27, for more
information.

If you can identify where the stack sets the baudrate to 230.4 kbps, it might be possible to overwrite by a 'use external clock' setting, supply the clock to HSKI without changing much else? Seems overly optimistic, but you never know...

 

[tashtari]

If you can identify where the stack sets the baudrate to 230.4 kbps, it might be possible to overwrite by a 'use external clock' setting, supply the clock to HSKI without changing much else? Seems overly optimistic, but you never know...

My hope is that one of the commercial LocalTalk-but-faster devices sold contemporaneously provides a driver that does exactly that and not much more, since writing software for vintage Macs is not my area... though of course, if someone wants to collab with me in writing one, I'm certainly up for that.

 

[twelvetone12]

Either it'll do the same thing as TashTalk does, i.e. bridge to a UART so it's accessible to another system like AirTalk, or as another possibility, it could go straight to LToUDP over an Ethernet interface via a chip like the ENC28J60.

The ESP32 can do ethernet, just add PHY and magnetics! It could open the door for some cool things.

 

[rplacd]

Huh – apparently, looking at the datasheet for the Z8030, a channel on the ZCC can do 1.5 Mbit/s (knowing that this has nothing to do with Apple's use.) I remember reading that the SCC was meant to be Steve Jobs' idea for expansion. in the same way that he originally wanted web apps for the iPhone, but I didn't know it was that capable.

 

[Mk.558]

Front side of a EtherWave Mac/PB or Printer Adapter (they're the same thing).



Back view of the device. You can see some crusties next to a..possibly isolation transformer?



There's an article on LEM about a Centram FlashTalk and a DaynaTalk device. I have never heard of those, never seen one. However the implementation is probably not that different than we're trying to do here.

If someone wants me to scrub the labels off, or heck, mail it to them for testing, let me know. It doesn't work at all, but perhaps could be revived. (The red light comes on, but the green LINK light below it doesn't turn on and seems to be flaky.)

 

[twelvetone12]

Wait, this thing uses ethernet as the comm bus? Does it use custom cabling? What RJs are those? I'm intrigued!

 

[Mk.558]

It uses standard straight or cross over cables. RJ45, 8P8C as standard. It's basically an AppleTalk bridge that can route TCP traffic (to a point) while it also clocks HSKi at 1.25MHz so it can, based on my limited understanding, dump data into the SCC as fast as it can process it out. Speeds vary based on the protocol (AFP is much faster than FTP, for example), but anywhere from 45 to 100KiB/s on download is possible depending on the machine. SE/30 -- 45 to 65KiB/s. IIfx -- 100. Also depends if you're using System 6 or not, as System 7 is slower.

Need to rewrite the section about it on the Guide, but yeah. Neat when it works. Emphasis on "when".

 

[twelvetone12]

wow

 

[tashtari]

All I could find about DaynaTalk and FlashTalk is a brochure for DaynaTalk, which confirms that it consisted of both software and hardware and had a dynamically-adjusting clock. It'd be cool if the software just enabled external-clock mode on the SCC and the dynamic clock adjustment happened on the hardware side, but without a copy of the software, I think we might be limited to guesswork...

 

[NJRoadfan]

The Farallon EtherWave is a LocalTalk-to-Ethernet bridge with the added ability to run a 3x the line speed when connected to a single machine. Its doubtful it talks TCP/IP (or any other protocol) without another MacIP bridge on the network, unless the driver speaks a custom data-link layer protocol between the computer and adapter since LLAP only supports DDP.

Thing is, I don't really see the reason to replicate this mess when we have new SCSI-to-Ethernet adapters. Besides PiSCSI, there is now a BlueSCSI WiFi edition that supports DaynaPort Ethernet emulation as well. Plus the driver fully supports Open Transport unlike the Farallon.

 

[Fizzbinn]

I've played with the Farallon version of this. Faster than LocalTalk, slower than Ethertalk, AppleTalk using the same serial port as LocalTalk. Without the special Farallon drivers the device still works but at normal Local Talk speeds.

As BlueSCSI v2 with Pico-W allows you to emulate a DaynaPORT SCSI/Link device (using the Dayna Drivers) could the Product X here ("AirTalk+"?) in this case emulate a Farallon EtherWave (using Farallon Drivers)? Without the Farallon drivers it just behaves as it does today?

Thing is, I don't really see the reason to replicate this mess when we have new SCSI-to-Ethernet adapters. Besides PiSCSI, there is now a BlueSCSI WiFi edition that supports DaynaPort Ethernet emulation as well. Plus the driver fully supports Open Transport unlike the Farallon.

True, but having more options is a good thing?