Hardware Localtalk to Ethernet Router

[bd1308]

So I've been thinking about this for about a year now. Localtalk (serial) used RS-48 something, (I think RS-488 but ive been corrected before). Anyway, there's a spec called FDTI that supposedly communicates using the same protocol. These devices are available to convert RS-232 to localtalk. I am imagining something like a embedded Intel Atom machine, or perhaps some of the AMD Geode junk I have lying around (which includes a built-in RS-488 whatever port) to pick up signals from the serial side of the mac. There would be a C program listening to these serial messages (which I have not seen yet) and construct IP packets which contain the IP version of these messages (which is easy using Wireshark). The layout is a bit cryptic from the TCP/IP side of things, however the messages appear to be standard.

Anyone interested in helping??

 

[Trash80toHP_Mini]

IIRC, it was RS-422 for the serial ports, but I've been known to NotRC at times. :-/

 

[Dog Cow]

IIRC, it was RS-422 for the serial ports

That's correct.

 

[techknight]

You dont even need all that really. This is something i stumbled upon recently, the other day actually.

You can use whats called the Wi-Fly module from roving networks. I have used thier bluetooth modules for phone interfacing and they work well.

Anyway, it has a built in wireless radio, AND, it has a built in TCP/IP stack and its RS232 TTL serial interfaced. so you would need a MAX232 or some other chip to convert the standard over. But you can make IP address and port connections over TCP or UDP. and you can send/receive serial data back and forth once connected. For example, the Wi-Fly can connect to another Wi-Fly and you have 2 serial ports attached, essentially, and since its a TCP/IP connection, it could be in the same room, or in a different state, doesnt matter.

or, you can connect to port 80 on a webserver, and you can send and receive GET/PUT messages, same as what a web browser does low-level. The module also has a few built in functions, such as DNS lookup, DHCP, etc... So you can query the DNS request through the module itself. It also has a very basic HTTP decoder, but its really really basic.

If you google the WiFly user guide, its insane what these things can do and support, and its serial interfaced and the thing is smaller than a USB thumbdrive.

I discovered this little guy a few days ago, I might get a couple of them and use these for my Duo and other machines. BUT since it IS serial, you can imagine, your gonna be bottlenecked by the 115k limit of RS232. Not sure what the max baud is on these WiFly, but I am going to assume 115k. May be able to push it up to 232K. I know the roving networks bluetooth can push up to 2Mbps on the RS232 serial connection, given the host connection can supply a baud this fast. the FTDI can i believe. Macs serial ports can be externally clocked within limits, so technically if you can push the mac serial port as fast as it can go, and set the baud the same speed, you can actually get some decent throughput i would assume.

So really, appletalk localtalk packets would just fly in and out of the serial port, the module would encapsulate these into TCP/IP packets on its own, or UDP depending on how you tell the module to connect. the module is like a modem, you setup and configure it with AT commands, SSID, etc. can do an SSID scan as well.

Drawback is for full functionality, we need a driver made for the mac. Basically the Macs TCP/IP driver would just simply forward it to the module as the module handles it on its own. So when a browser makes a socket connection and request, it just passes it directly to the module instead.

 

[bd1308]

But if im not mistaken, the serial data and the IP data are different. So if you took a device that encapsulated raw serial data, no Appletalk IP devices would know what was going on.

 

[techknight]

not really. serial is just a hardware medium for transferring data bytes.

IF the databytes were Appletalk packets, depending on the MTU setting of the adapter, those appletalk packets would be encapsulated into TCP/IP packets at the module then transmitted to the socket connection. If the module encapsulates the Appletalk packets the same way as the mac would, then it should work. (not sure how mac does its encapsulation, but the wifly manual states how its own encapsulation works).

If you encapsulate serial localtalk packets as they are, which is what i mentioned in my last post, then yes appletalk IP devices may not recognize them. But if you customized a driver to send appletalk IP packets over serial connected wifly instead of localtalk, itll probably work just fine.

Or, you could just put another wifly module at the other end and itll take the localtalk over TCP/IP back to standard localtalk serial again. Kinda the same thing.

 

[gsteemso]

The trouble with this is that LocalTalk does not use the same byte framing conventions as RS-232. The most non-marketese name I could find for the format LocalTalk uses is “FM0”; its only compatibility with RS-232 is electrical.

An RS-232 byte frame involves a logical zero called the start bit, 5-8 data bits, an optional parity bit, and 1, 1.42 or 2 logical one bits called the stop bits, all transitions happening no more often than one bit period apart. (The 1.42 stop bits option is because some of the old mechanical teletypes originally were not able to reset between bytes any faster than that; a lot of old chips fudge that as 1.5 bits because the logic is simpler.) The options are always the same from one byte to the next and must be agreed upon in advance. Significant features are that every byte transferred has 25-80% framing overhead (25% in the usual Mac serial case — 8 data bits, no parity bit, 1 stop bit, abbreviated 8N1) and that the longest possible logical zero is the number of data bits plus one or two (9 bit periods for 8N1). A logical zero that lasts longer than this time is interpreted as a break in the wire, which goes all the way back to current-loop teletype equipment.

FM0, on the other hand, doesn’t really have any concept of a byte frame. Each transmission happens on a packet basis. The first transition on the wire marks the beginning of the first byte’s first bit. Transitions happen once per bit period for a data 1 and twice per bit period for a data 0. A bit period with no transitions at all must be outside of the packet. Significant features are that framing overhead is amortized over an entire packet rather than being per-byte, and that the transmission medium must be able to handle a maximum frequency of twice the bit clock frequency.

Obviously, steering an FM0-formatted LocalTalk packet into anything that is expecting plain RS232 simply is not going to work.