Some programs you might be interested in. Found it as part of my digging for the mysteries concerning the Mac/PB adapter mess. Say, you said you have a EtherWave Printer Adapter, how is that different than the EtherWave Mac/PB adapter? I just got done with borrowing one, and it (a Mac/PB) didn't work at all on my borrowed IIci, only on a borrowed PB 170.
I am told that EtherPeek and LocalPeek were commercial programs, but I trust that you know how to work around any minor inconveniences with a hex editor and a debugger Sure could use someone with such skills to bypass the disk check for RocketShare 1.3.2 installation disks (kicks an error saying these aren't the right disks...they are named right).
Very cool -- thanks for the link! That may come in handy as I get closer to the end.
As far as I know, the Printer Adapter and Mac/PB Adapter are basically identical. I have heard of small differences like one is powered by the ADB port and the other is powered by an AC adapter (mine is powered by an AC adapter), but I don't know if that's the distinction or not. They both work with both LocalTalk and TCP, but the TCP support is not MacIP -- it's some weird proprietary thing that requires a special driver.
You can use it driverless at 230.4 kbps, or with a driver at a faster rate. Like I said, the driver is required for the TCP stuff too.
I've read that thread pretty well, and as far as I can tell, the Printer Adapter is the same thing except it has the Printer Compatibilty Mode enabled by default in the Adapter Setup Utility. If that is so... Well, I've got to hand it to the Marketing Clowns, they've got something on me.
Say, you wouldn't happen to have a manual for this thing? I'm looking for one right now, doubt I'll get anything other than the ReadMe.
As far as ethertalk, etc.. Why not use the netatalk source code? ethertalk is likely going to be in there as a code class/module. That should help alot.
I think the most simple solution is a linux OS running on the Pi, one of the drivers would be "localtalk" which contains the code and API to speak via SCC LLAP. Then of course the Ethertalk driver that gets built from the netatalk code. Along with the off-the-shelf ethernet drivers, etc..
Then from that point its a linux exe, or script that runs which does the translation and uses the two drivers in place. You could also use netatalk in its entirety by creating a network share with the USB port, or the SD card.
As I understand it, netatalk is removing support for the older versions of the protocol, which of course are precisely the versions we care about here. So it's not necessarily a great idea to rely on their code.
Yeah...netatalk 3.0 removes AppleTalk support. You could still base code off the earlier 2.x series, and I'm sure it could be used to do all kinds of cool things on a Raspberry Pi.
Either way, for this simple bridging, I don't think the existing code would help that much. It's actually not that complicated to handle the packet translation myself. Once the bridging is working, existing solutions like netatalk might (hopefully?) work out of the box.
I keep seeing this as a suggestion, but I'm still just not confident about a Pi/BBB talking directly to the SCC. LLAP is very time-critical. Definitely shouldn't be done in user space when there are constraints like a CTS packet being within 200 microseconds of an RTS packet. I don't think vanilla Linux can make those types of guarantees in userspace, even on modern fast processors. Correct me if I'm wrong on this, but trusting a user space Linux program to do stuff that quickly is just asking for trouble. In kernel space it's probably possible, but I'm not in the mood to go there when I already have a working solution on a microcontroller through a fast UART. The Pi will talk with the microcontroller which will talk with the SCC. In the future, the microcontroller may be able to emulate an SCC to remove the SCC from the equation. We'll see.
Here's an earlier discussion about making a LocalTalk driver for Linux:
What I'm doing is exactly what the prior LocalTalk cards did: they offloaded the SCC timing-sensitive part to a separate processor. An LPC1769 is probably overkill for just that purpose, but it can be changed to do the Ethernet portion in the future as a standalone solution.
Well, once its up and running however you build it, it would be cool if a localtalk router function was added on. Basically hook the device up to a phone-net network and get multiple macs onto the ethernet network at once. That would be cool
OK, so I have LLAP-to-UART working in both directions. The code is committed to the mac68k.info repo. I ran into a problem: the LPC1769 was having trouble receiving data at the 3 Mbps baud rate, even though it can transmit at that rate with no problems. I verified with my scope that the data going to the RX pin was good, and I also verified that the LPC1769 was sending bytes at the correct rate, so my guess is it's some kind of limitation with the receiver. I slowed down to 921.6 Kbps and now it's working. It's still plenty fast for communication of LLAP packets.
I made a very simple protocol that is used in both directions over the UART:
0x02 -- start of transmission
high byte of length of LLAP packet
low byte of length of LLAP packet
the LLAP packet
XOR checksum byte.
I've verified that I can send an echo request from my computer over a USB to TTL serial adapter, and I immediately receive the response. So yeah, I've essentially got an LLAP-to-normal-serial adapter working.
I'm still running into a few problems. When my stuff is hooked up to my IIci, it doesn't want to enable AppleTalk for some reason. It says: "AppleTalk cannot be opened" whenever I try to enable AppleTalk. As soon as I power off the LPC1769 board, or unplug from the printer port, AppleTalk works. Then if I power on the LPC1769 board, everything's fine. So I'm clearly doing something that's upsetting the IIci when it initializes AppleTalk. Haven't figured it out yet. I'm also occasionally completely losing communication until I reboot the LPC1769 board. I'm not sure what's happening there--perhaps the SCC is getting into a bad state and everything's getting stuck. Those two issues need to be figured out before I can say it's ready to go.
Wow.. your alot further than anyone else has gotten So just having 2 issues really isnt that bad, but im sure they can be figured out.
This is nice, because technically that means you can do LLAP over bluetooth. I can actually make a modem card for my macintosh portable, lop an LPC and SCC on the card along with a BT transceiver, keep it all inside, and just put another SCC/LPC/BT card on the bridge mac I have.
if I am understanding the function correctly? Or I can make the link over BT direct to PC using a UART link, and then maybe basilisk II have some sort of driver to handle LLAP via serial.
Also in case your not aware, Digi makes WiFi to UART transceivers, and i have used them before. kinda neat. Problem is, your stuck with either TCP or UDP. I know WizNet makes SPI based ethernet transceivers, might go that way to gain full support to implement your own protocol like ethertalk.
This looks like some cool hacking! After skimming through four pages of old posts, I'm still not sure exactly what it does. Mind posting a short executive summary? A LocalTalk to Ethernet bridge, so you could connect a vintage Mac to a modern Ethernet network? Would that require some special software running on your modern Mac or PC so it could act as a file server? I have to admit I'm totally confused as to the difference between LocalTalk, AppleTalk, and EtherTalk.
techknight: I think you're definitely understanding the functionality. As long as you can use some kind of transport that does a serial byte stream at a rate fast enough to keep up, it should be able to transmit LLAP frames across it. Yeah, I've seen various "blah to UART" converters out there. The LPC1769 actually has an Ethernet controller built in. So I actually should be able to use the internal Ethernet controller if I decide to get that part working to make it more standalone. We'll see...
bigmessowires: Here's a summary. The basic original idea is exactly what you described -- a LocalTalk to Ethernet converter. So you hook one of these up to your old Mac's printer port, and suddenly your old Mac sees your other old Macs that are on the Ethernet network, as well as compatible server software on modern computers (such as netatalk 2.x). It's more than just a file server though. With the correct server software running, it should be able to implement MacIP, which would allow you to do TCP/IP traffic over LocalTalk. This wouldn't require any special client software to be installed on the Mac -- it's all built into MacTCP/Open Transport. These bridges already exist, but they're getting harder to find out in the wild, so there's definitely value in creating a modern one.
As bbraun has pointed out, having a generic implementation of LocalTalk available opens up the doors for all kinds of possibilities like portable file servers, network bridging, etc. I personally like it because the microcontroller only has to focus on the time-sensitive LocalTalk/SCC communication, and it can be hooked over a UART to something more powerful like a BeagleBone Black or Raspberry Pi, which will probably also make the rest of the code easier to write since the Linux computer isn't really resource-constrained. With that said, some people might find value in a smaller, cheaper device that only focuses on the LocalTalk to Ethernet conversion. So right now my working plan is to make a PCB that is designed to stack on top of the BBB/RPi (not sure which yet) and hook to a UART, but is also designed so it can be used standalone with its own Ethernet jack.
I won't claim to be an expert, but my understanding is that EtherTalk and LocalTalk are two of the possible physical layers for AppleTalk. EtherTalk uses ELAP and LocalTalk uses LLAP (EtherTalk/LocalTalk Link Access Protocol). On top of both of those you can send DDP packets, which are used underneath most of the AppleTalk protocols. So the meat of a LocalTalk to Ethernet converter is taking these DDP packets and sending them back and forth between ELAP and LLAP, with a few fixups here and there.
At some point it will probably be nice to implement it as an actual AppleTalk router that can handle multiple LocalTalk devices on the LocalTalk side, but for now, the plan is to do the same type of scheme that the EtherWave Printer Adapter does, which is to pretend it's a router on the LocalTalk side, and actually grab a node ID on the EtherTalk side--only compatible with one LocalTalk device per converter, but simpler to implement to get started.
LOL, the "AppleTalk cannot be opened" problem is solved. Actually, I'll call it a test
What happened was my IIci was trying to obtain an address on the LocalTalk network. It does this by sending out an enquiry request to the node ID it wants to take. The SCC is programmed to receive messages destined to all addresses, so I was responding to all enquiry requests by saying "this address is already in use". After trying all 256 possible addresses, the IIci gave up. That's what the error message was telling me. So it was a good test to make sure I'm responding to enquiry packets correctly.
I think my code was written with the thought that the SCC would be programmed to only receive messages destined for my address. Instead, I'm programming the SCC to give me all traffic, which is a lot more fun. I fixed it by checking the enquiry request to make sure its destination address is my address before replying to it.
Thanks for the explanation. I'm not much of a networking expert, but I think that makes sense. Nice find with your "Appletalk cannot be opened" bug. Apple could have come up with a nicer error message for when all 256 addresses are in use.
I spent a good chunk of this weekend doing some quick and dirty implementation of what was remaining to get Ethernet to LocalTalk working. Basically I had to do the following:
A main event loop in my Linux-based program with timer support -- libevent seemed to be appropriate for this.
A barebones implementation of AARP, the American Association of Retired Protocols, err I mean the AppleTalk Address Resolution Protocol. Its purpose is to take a destination AppleTalk address (2-byte network number, 1-byte node ID) and turn it into an Ethernet MAC address. So the same purpose as ARP, but for AppleTalk. This still needs a lot of work like an LRU cache and expiration timers instead of a really dumb array that I've made right now.
DDP parsing (Datagram Delivery Protocol -- this is the common protocol that is used over both LocalTalk and EtherTalk, similar concept to IP)
Spoofing of addresses in DDP packets a little bit to make the LocalTalk computer appear like it's another EtherTalk node to everybody else.
Limited NBP parsing (NBP is Name Binding Protocol, I guess kind of similar to DNS, which operates on top of DDP). It needed some special fixups because it acts differently when going through an AppleTalk router, and I'm spoofing a router on the LocalTalk side in order to get the LocalTalk computer to realize that it can talk to a network with extended addresses (which EtherTalk is).
It was really exciting seeing my Mac mini running netatalk show up in my IIci's Chooser! Then, a little bit later, it was super exciting being able to log into it and open files. There is still a lot of room for improvement. I have very ugly hardcoded AppleTalk addresses for both the LocalTalk and EtherTalk side, and I need to implement a protocol that automatically obtains those addresses through the correct algorithms. I also need to figure out why things get hung up sometimes. I'm still having problems where the whole microcontroller program gets screwed up until I power cycle my LPC1769 board, so I need to figure out why it (or maybe the SCC) is getting stuck. This may be annoying to troubleshoot, but it's pretty easy to reproduce the problem now, which should help me track it down.