Really great to read that my struggling with the LocalTalk PC card you in this project! And.... I always thought I was the only human being on the planet working with LocalTalk and Linux. Now I also know that there is at least one more!
About dumping the 2764 EPROM .... I have never done this before. Yes.... I dumped a occasional ROM..but never an EPROM on a card. Could you give me a direction how to do that? I will also Google around.
I tried MacGated to get MacIP running, but without any success. Would be great to know if you can get it working. That would be a nice alternative to the macipgw solution.
I'm working on a beta of my MacIPgw now which has AFP working... That is in software almost as I think your hardware. I tested it yesterday and it works fine.If you start the virtual machine you have a file server with 200MB free disk and TCP/IP.
From your photo of the card it looked like the 2764 was socketed, so you simply need to remove it from the socket and plug it into an EPROM reader/burner (pretty much any of them will support a 2764, even a cheap Willem). After that plug it back into the card, making sure you have the notch pointing the right way.
This is the first Localtalk to Ethernet gateway, developed in the context of Stanford U's SUMEX project (which also created VAX BSD to Mac cross compilers), which later evolved into the Kinetics FastPath products. The code ran standalone on the original SUN 68000 CPU board, which was used in the original Sun workstation as well es a number of other early Unix machines and the first Cisco router. It used a homebrew Z8530 SCC board and a Multibus Interlan NI3210 ethernet adapter. It's probably mostly of historical interest now, but might clear up some of the miracles on controlling the SCC.
Thanks, Michael! I was actually trying to find that code about a month ago to verify how I configured the SCC versus how SEAGATE did. I did a huge search all over the internet and asked a few people, nobody could find it. So this is quite exciting that you were able to find it. Thanks to you and to Al!
I'm definitely still interested in bitbanging the SCC. IIRC, it's the most expensive part on the entire LocalTalk board I've designed. If it's not the most expensive, it's the second most expensive. I think the MESS developers would also be interested in having more complete SCC emulation.
It's undoubtedly possible, but I don't think adding a CPLD would make much sense--the point would be to reduce the number of parts needed by trying to do the SDLC communication directly in the microcontroller, which I still think is possible.
I've been told by balrog on IRC that the BBB's processor has a couple of programmable real-time units (PRUs). It's actually possible that you could do the communication directly inside the BBB's PRU, although I'm not sure if I have the motivation to look into that in my spare time.
I started to investigate what would be required to implement the low-level protocol layers of LocalTalk (which is essentially what the Z8530 SCC does). The most intricate part would be getting the digital PLL working in order to decode the FM0 bitstream. There is quite a bit of example code for this in VHDL for a similar protocol - FM1, which simply inverts the meaning of the bits - used in S/PDIF audio streams. However, the pre/postamble signaling of the SDLC protocol used by Localtalk is different. A simple VHDL example for FM1 decoding can be found at:
The idea of using the RISC coprocessors on the Beaglebone is interesting, IIRC they were rather well documented and quite fast. Something similar has been done on the Motorola 68k-based (QUICC) protocol processors, e.g. 68302 and 68360. These also use a small RISC coprocessor for signal processing. Motorola even published example C code for the 68302 to implement LocalTalk which seems to be a direct translation of the Pascal code published in Inside AppleTalk. The code can be found at http://www.lysator.liu.se/~celeborn/sync/atari/misc.html (under the "68302 Files" heading). The 68302 used a separate chip (68195) to handle FM0 de/encoding and bitstuffing, while the later processors (68360 and PowerQUICC) could do this on chip.
Similar approaches would also work with XMOS hardware, which is especially well suited for software-defined protocol processing.
I think the following approaches would be interesting:
1. Adding support for a more complete SCC implementation supporting SDLC to the PlusToo scc Verilog code
2. Create low-level protocol handling software for the Beaglebone or similar
3. Adding support for parsing SDLC-related interaction with the SCC for the various Mac emulators and translating the related data stream to/from, e.g., EtherTalk
Nice find on the FM1 decoding! I'll be completely honest -- I've tinkered with VHDL/Verilog on an FPGA, but I'm not at the level yet where I could help much with this type of project. I might be able to help explain some of the SCC's behavior though (it's a weird, weird chip). Also, great find on the 68302 code! I agree, definitely looks like they just did a translation of the Inside AppleTalk code. That's also what I did on my project.
All three of the approaches you suggested definitely sound interesting. As far as emulators go, converting between LocalTalk and EtherTalk is a little complicated because you're hooking a nonextended network up to an extended network, which pretty much means a router is probably going to need to be involved to stay fully compatible, unless you do a hack like the EtherWave Printer Adapter does.
At the moment, I'm at the stage where I want to get my initial version with BBB + external microcontroller + SCC working first, since I've already thrown so much effort into it. But I'm definitely interested in helping with a low-level SDLC implementation inside the BeagleBone's PRU in the future.
How difficult was it to get just the Localtalk side of your hardware working? Did you ever try talking directly to the Mac's SCC from your microcontroller, or do you think using a second SCC chip along with a microcontroller is a better way to go?
I'm thinking it might be cool to design something like a Floppy Emu, but that works over LocalTalk, and appears as a LocalTalk file server. It wouldn't help you if your Mac didn't have any other functional drives, but assuming you already had a working boot drive, it would be pretty handy as a file server. It would provide functionality similar to the Emu when in HD20 mode, except you couldn't boot from it (dang!), but it would work on any Mac instead of only the 10 or so Macs with HD20 hardware support (woohoo!). I'm not sure how the transfer speed of LocalTalk drives compares to HD20 speeds, but they're probably similar.
I never tried bitbanging the SDLC communication from my microcontroller (which would bypass the need for a second SCC chip), but I remain confident that it should be possible to do. I also think that the SCC is a really complicated chip to work with. I guess it depends on whether you think learning the SCC's registers is a harder task than figuring out the SDLC communication. Before I started the project I would have said interfacing with the SCC is far easier. After doing the project and struggling with the SCC, I'm less convinced, but I dunno for sure. The SCC is probably still simpler to get up and running, but you could really cut down on costs if you did it inside a CPLD or a fast ARM MCU.
Sounds pretty cool! That's essentially what you'd get if you took this project and installed netatalk on the BeagleBone Black, although a dedicated microcontroller or microcontroller+SCC solution could probably be much less expensive than this. It will probably be a fun challenge implementing all of the protocol stack needed for AFP over AppleTalk LocalTalk is about 230.4 kbps, but there is definitely overhead with everything, so you wouldn't get that good of performance in a real world scenario--bit stuffing, checksum bytes, RTS/CTS handshaking, flag bytes will all decrease the max possible performance.
I was wondering if the prototype of this project is now ready for production?
I see that bigmessowires has time for some hacking. Maybe you could team up take this one to the market. I would be definitely the first buying customer!
I have successfully created a Linux LocalTalk network interface, and I can use it to bridge EtherTalk and LocalTalk networks with atalkd. It's known to work for accessing EtherTalk servers from a LocalTalk computer, but the other direction isn't tested yet
I think Linux's AppleTalk networking system might have some issues...I can't get nbplkup to correctly find anything on the LocalTalk side, and I think it's the fault of Linux deciding to only send broadcast requests over Ethernet.
Haven't touched macipgw yet. Was not able to get MacGated working, but I don't know if Linux's AppleTalk support might be partly to blame.
There are a few minor annoying things that need to be added to the microcontroller program -- LocalTalk's automatic node ID assignment algorithm for example. Right now I'm assigning a fixed node ID which seems to work, but I'm not sure what would happen if a collision occurred. This may not be a problem in practice, so it's low-priority.
I'm a little afraid to call it production-ready yet. I need to find time to polish a few things, and debugging Linux's networking internals does not sound like a very fun time
The 8530 is definitely an... interesting chip. There's still a lot of demand out there for HDLC/SDLC line protocol stuff, which is why they still sell it; I've worked with some of the applications at work that use it or its cousins, though they just use the NRZI mode instead of the FM mode (much easier to implement).
SDLC isn't hard at all to do in an FPGA. It might be a bit big for a typical CPLD, though you could probably fit the essentials on one of those miniature FPGAs that Altera calls a CPLD these days (Max II, Max V families). The bit stuffing/unstuffing logic is pretty simple, as is the logic for latching on flags and aborts (which uses the bitstuffing logic to determine when it's getting a special character). I have no experience with modern PSOC chips; my only experience with them was in their beginning days, when they were an interesting idea but not very practical, but I understand they're actually pretty nice to work with now.
If you need any assistance with VHDL or Verilog (I don't really care which, I use both regularly), I'm glad to help, though my spare time is limited these days.
In any case, it's nice to see this; this is something I'd been thinking of doing for a very long time now. Bit-banging SDLC is probably possible, but even on a nice fast micro using timers, it'd probably eat up a prodigious amount of CPU time (especially if you're using interrupts). My own intended approach was to use a microcontroller with a real external bus (lots of Cortex-M3 and related processors that would do the trick) with integrated Ethernet to connect to a real SCC (especially if I could use the DMA modes), but I never got around to actually trying it. I'd be happy to lend a hand as time allows.
Hehe, I agree. "Interesting" is definitely the right word. I got the 8530 working, but only after tons and tons of messing around to get the right combination of settings and the right access pattern during usage.
I don't have enough knowledge to help much with the CPLD/FPGA side of things...I'm in the process of trying to learn it all by myself, but it's taking a while. I do have a small bit of experience with the basics of the PSoC on the SCSI2SD project and it's quite a cool idea, although I know nothing about the programmable logic part of it. I don't know how it compares to CPLDs/FPGAs in terms of the number of logic blocks available. My biggest complaint is that the Cypress stuff is only available on Windows. Not a huge deal because I use Windows at home, but I wish they had a Linux version.
You're right, the bit-banging would probably take up quite a bit of CPU time. It is one less component if you get it working though, and the program wouldn't be doing a whole lot else anyway (at least in its current form where it's a dumb UART device that a BeagleBone Black talks with). I definitely think there's a need for a smaller/cheaper device with an MCU with onboard Ethernet (external bus talking to the SCC instead of bitbanging read/write cycles would definitely be cool!), but it will be a bit more work because it requires implementations of some of the lower AppleTalk protocol layers that you get for free with Linux/netatalk.
I am currently using a LocalTalk bridge (AsanteTalk) and would very much like to see your project be successful. A modern bbb or rpi with integrated localtalk interface would remove a significant hurdle that is keeping a lot of vintage Apple devices off the network.