Thread
DIY Localtalk - Ethernet converter
Yeah I had just double-checked. Oh well --- I'll look for a MAX488 and a serial cable I guess. Out of all the mac stuff I have, I dont think I have a serial cable.
That's why I posted those two links above. The Bus Pirate is like $30
Yeah i'm going to go ahead and get the bus pirate or https://www.sparkfun.com/products/9857.
I'm leaning toward the Open Logic sniffer because it has the ability to look at 16 channels. The Bus pirate is really neat though, cause it'll automatically figure out what its talking to on the fly (including RS232/RS422 -- but not RS485 unless i have the transciever).
I'm going to try to get both of these -- each have their purposes
I'm leaning toward the Open Logic sniffer because it has the ability to look at 16 channels. The Bus pirate is really neat though, cause it'll automatically figure out what its talking to on the fly (including RS232/RS422 -- but not RS485 unless i have the transciever).
I'm going to try to get both of these -- each have their purposes
The other awesome thing about the Logic analyzer is that once I get through with this project and no longer need it anymore, or upgrade, I can reprogram the FPGA to start work on the Apple IIGS VGA card I've been wanting to work on 
Hah, I actually came back to this thread to add the Logic Sniffer (which I did, to the post on the previous page).
O.P.: At LocalTalk speeds of 250k bits/sec, you may find that a software "bit banging" solution drops some incoming bits while the Arduino's processor is off doing other things, like talking to the Ethernet port.
Take a look at the Zilog Z8530 SCC http://en.wikipedia.org/wiki/Zilog_SCC and its modern equivalents. The IC was used in the original Macintosh and it took care of grunt work involved in dealing with LocalTalk, including checking (and generating?) CRCs. It is a bus oriented chip, so it may tie up quite a lot of I/O lines on the Atmel microcontroller in an Arduino.
Back in the day, many amateur radio enthusiasts used Macintoshes as packet radio terminals. The Z8530 IC made the Mac a much better candidate than an IBM Compatible PC of that era, because much of the work involved in packet could be offloaded to the SCC hardware. This avoided buying an expensive Z80 based packet "terminal node controller" (TNC). Most TNCs had Z8530s in them too!
Take a look at the Zilog Z8530 SCC http://en.wikipedia.org/wiki/Zilog_SCC and its modern equivalents. The IC was used in the original Macintosh and it took care of grunt work involved in dealing with LocalTalk, including checking (and generating?) CRCs. It is a bus oriented chip, so it may tie up quite a lot of I/O lines on the Atmel microcontroller in an Arduino.
Back in the day, many amateur radio enthusiasts used Macintoshes as packet radio terminals. The Z8530 IC made the Mac a much better candidate than an IBM Compatible PC of that era, because much of the work involved in packet could be offloaded to the SCC hardware. This avoided buying an expensive Z80 based packet "terminal node controller" (TNC). Most TNCs had Z8530s in them too!
Well I haven't gotten to the point where I actually decided what solution I'd actually use. Ideally, it would be a two arduino solution, where one would take care of building a complete "LocalTalk" packet, and SPI would be used to trigger an interrupt on the second arduino which would throw the IP stuff around that packet and send it to the ethernet controller. I have two arduinos already so this is a low-cost endeavour. Right at the moment, I'm trying to sell off some of my mac things to fund this project.
Why arduino specifically? Because you're already familiar with them?
If you want two processors, you could consider a Parallax Propeller - 8 CPU cores one one die @20MIPS each, or the similar but more powerful XMOS XCores.
If you want two processors, you could consider a Parallax Propeller - 8 CPU cores one one die @20MIPS each, or the similar but more powerful XMOS XCores.
I had considered the Propeller, and the issue is that memory accesses are *slow* on these, and each cog has a specific amount of memory its allowed to access. And the total amount of memory available per cog is slow.
I know about arduinos, I built a robot based on a arduino, and I have a arduino in my toolbox. The parallax, being a multi-core processor, is designed from the ground up to be useful for parallel programming. I reallly wouldn't be taking full advantage of the multiple cores, because everything is completely sequential. LocalTalk packet recieved from serial->tear it apart->convert it to a ethernet packet->send out. and the reverse.
If I did this with a prop, I could certainly have two or three cogs work on multiple serial packets (or ethernet packets coming from ethernet) it's not completely thread-safe, IE I could have a situation where packets could "process" in the wrong order and cause problems.
Those are the reasons why I was leaning toward arduino. I think the propeller is neat ( and I do have a project that will totally take advantage of its unique and awesome power) but I'm not sure if it would be useful for this..
I know about arduinos, I built a robot based on a arduino, and I have a arduino in my toolbox. The parallax, being a multi-core processor, is designed from the ground up to be useful for parallel programming. I reallly wouldn't be taking full advantage of the multiple cores, because everything is completely sequential. LocalTalk packet recieved from serial->tear it apart->convert it to a ethernet packet->send out. and the reverse.
If I did this with a prop, I could certainly have two or three cogs work on multiple serial packets (or ethernet packets coming from ethernet) it's not completely thread-safe, IE I could have a situation where packets could "process" in the wrong order and cause problems.
Those are the reasons why I was leaning toward arduino. I think the propeller is neat ( and I do have a project that will totally take advantage of its unique and awesome power) but I'm not sure if it would be useful for this..
The book has arrived --- and I'm selling off things to fund this personally. So I'll be starting on this most likely this weekend
You know ... opencores.org has free AVR softcores ... Just sayin'
Meanwhile, this seems relevant:
http://hackaday.com/2012/10/08/usb-to-rs-232-adapter-hacked-to-use-rs485-instead/
Its here 
and?
Hate to necro this thread, but this document will probably be of use:
http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/datacomm/GA27-3093-3_SDLC_Concepts_Jun86.pdf
The reason the SCC was needed for LocalTalk is because LocalTalk uses IBM SDLC as its low-level transport protocol (hence the checksums, etc.)
http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/datacomm/GA27-3093-3_SDLC_Concepts_Jun86.pdf
The reason the SCC was needed for LocalTalk is because LocalTalk uses IBM SDLC as its low-level transport protocol (hence the checksums, etc.)
I'm going to bring this up from the dead with some tech info. Just about every Localtalk to Ethernet bridge made uses a Zilog SCC or compatible to interface with the Localtalk side of things. Here are the hardware specs for the "high end" Fastpath boxes. I'd imagine the Gatorbox CS uses similar hardware. Both are capable of routing Appletalk, DECNet, and TCP/IP. They can also tunnel Appletalk over TCP/IP.
Fastpath 4
CPU: 8Mhz 68000
RAM: 256k, upgradable to 512k
Localtalk Interface: Zilog SCC
Ethernet Interface: Intel i82586 10Mbit NIC
Onboard ROM has Appletalk routing software
Fastpath 5
CPU: 10Mhz 68000
RAM: 512k, PCB has solderpads to take 1MB
Localtalk Interface: Zilog Z181
Ethernet Interface: Fujitsu Etherstar 86950 10Mbit NIC
Minimal onboard boot ROM. Appletalk routing software is RAM based and has to be uploaded.
The "K-STAR" TCP/IP routing software is RAM based on both units and is an optional install. It is based on the now open source KIP routing software (later dubbed MacIP by Apple) from Stanford University.
Fastpath 4
CPU: 8Mhz 68000
RAM: 256k, upgradable to 512k
Localtalk Interface: Zilog SCC
Ethernet Interface: Intel i82586 10Mbit NIC
Onboard ROM has Appletalk routing software
Fastpath 5
CPU: 10Mhz 68000
RAM: 512k, PCB has solderpads to take 1MB
Localtalk Interface: Zilog Z181
Ethernet Interface: Fujitsu Etherstar 86950 10Mbit NIC
Minimal onboard boot ROM. Appletalk routing software is RAM based and has to be uploaded.
The "K-STAR" TCP/IP routing software is RAM based on both units and is an optional install. It is based on the now open source KIP routing software (later dubbed MacIP by Apple) from Stanford University.
Yeah, using the zilog chip is really the way to go for handling the wire protocol. I looked at bitbanging it from a uC, and it just doesn't make a whole lot of sense to do that unless you really have to.
There are still SDLC capable SCCs available out there. I've looked at trying to make an interface board with one for an rpi or beaglebone black or something.
There are still SDLC capable SCCs available out there. I've looked at trying to make an interface board with one for an rpi or beaglebone black or something.
nice thing about the rpi or beaglebone black, it can serve up localtalk appletalk shares with netatalk running on the chip correct? plus you can run an app to "filter" website HTTP/HTML fetches to make them text only for older localtalk based macs when using TCPIP over localtalk.
or... use the rpi/beaglebone to render the webpages, and then the rendered pages are converted into an older format that an older browser would understand before feeding it back to the mac. (i know, im getting carried away).
hell you could almost use the rpi/beagle bone for all the major grunt work and processing, streaming, scripting, etc.. and the mac is just the input/output device. But the only way for smooth video in that case would be if the beagle was directly on the PDS bus writing to an assigned videobuffer in RAM/V-RAM.
that would be the hackish way to bring flash/HTML5 video/audio to an old world mac. ;-) (kinda like the old DVD decoder days).
Would be kinda neat.
or... use the rpi/beaglebone to render the webpages, and then the rendered pages are converted into an older format that an older browser would understand before feeding it back to the mac. (i know, im getting carried away).
hell you could almost use the rpi/beagle bone for all the major grunt work and processing, streaming, scripting, etc.. and the mac is just the input/output device. But the only way for smooth video in that case would be if the beagle was directly on the PDS bus writing to an assigned videobuffer in RAM/V-RAM.
that would be the hackish way to bring flash/HTML5 video/audio to an old world mac. ;-) (kinda like the old DVD decoder days).
Would be kinda neat.
Something like this?
http://www.applefritter.com/content/apple-ii-pi
Or if, as above, you drive the Mac CRT directly from the Pi/Beagle/etc.
something like that yes... but I would use the pi strictly as a dsp or video rendering/data pump. That is DMA connected to the macs real hardware/pds. And real OS.
This way its still a mac. But it uses the pi for streaming audio or video. And of course web rendering. Then the pi outputs via dma to the macs vram/framebuffer.
So in theory you could watch youtube or netflix on a 68k mac using a special browser that displays the pi data.
A colorclassic streaming netflix would be kind of neat.
The wrb browsers window would simply just display whats comming from the pi. Kinda like spple video player did.
Of course you could write a new 68k browser that uses the pi for its connection and processing.
This way you have the look and feel of the real os and hardware but you have the power of a modern machine
This way its still a mac. But it uses the pi for streaming audio or video. And of course web rendering. Then the pi outputs via dma to the macs vram/framebuffer.
So in theory you could watch youtube or netflix on a 68k mac using a special browser that displays the pi data.
A colorclassic streaming netflix would be kind of neat.
The wrb browsers window would simply just display whats comming from the pi. Kinda like spple video player did.
Of course you could write a new 68k browser that uses the pi for its connection and processing.
This way you have the look and feel of the real os and hardware but you have the power of a modern machine
Coming back to earth somewhat...
(If you could abstract everything into usermode instead of the kernel, using USBlib and tap/tun interfaces, then in principle you could also make the packet routing functions work on OS X as well. Then you'd only need a small Linux VM running Netatalk 2.x set up to mount and re-broadcast your network volumes to get the old old doorstops talking with the modern world.)
But $400 is seriously ridonkulous. The dongles seem to uniformly use FPGAs to do the work while you can still buy a Z85C30 from Digikey for $6.85 and a PIC (or other) microcontroller with "full speed USB" is around $10. That looks like a minimum unit price, factoring in a PC board of around, what, $40?, for a homemade Localtalk-USB converter. That's not as cheap as some people might like but considering the "universal applicability" of such a dingus might that be a better bet then trying to interface an SCC directly to the GPIO ports on a Raspberry/Beagleboard/whatever?
(It looks like there's, what, 17? easily accessible GPIO pins on a Raspberry Pi, with some of them semi-dedicated for specific functions? Looking at the Z85c30's datasheet 17 is exactly how many lines there are on the "system bus" side of the chip. Unless there's another SCC that has a more friendly-to-modern-stuff bus structure...)
This does make me wonder what's inside those Appletalk-Ethertalk bridges. Is it a single custom IC or are they an SCC, Ethernet chip, and MCU bought in bulk and crammed together? I guess it does look like you can get Ethernet modules for Arduino for "shockingly cheap", so maybe that's not that unreasonable. An AVR+Arduino ethernet module+SCC chip might almost be cobble-together-able for around that same $40 price point. The difference is that you have to do all your protocol translation in the MCU you cram in there, while making a USB-SCC peripheral would let some "bigger iron" handle that part.
Anyway, blawblaw, yacketyschmackety.
Just out of curiosity I did the obvious Google and found that there are several companies out there that sell SDLC -> USB serial dongles. The common thing about them unfortunately is that they are *hideously* expensive. ($400+ is typical; it seems like the main use for them is talking to IBM mainframes.) If it wasn't for that I'd suggest that what might be the most useful thing to do with this project would be to target the cheapest available dongle and try resurrecting the Localtalk-related code that used to be part of Linux back in the Kernel 2.0 days. (Linux used to have support for the old "COPS" ISA cards, and in fact there used to be a howto document in the kernel documentation on how to use a Linux box to do both Appletalk routing and TCP/IP encapsulation.) If that software could be fixed then you'd be able to use any old Linux box (Raspberry Pi, home NAS server, whatever) to do the job...
(If you could abstract everything into usermode instead of the kernel, using USBlib and tap/tun interfaces, then in principle you could also make the packet routing functions work on OS X as well. Then you'd only need a small Linux VM running Netatalk 2.x set up to mount and re-broadcast your network volumes to get the old old doorstops talking with the modern world.)
But $400 is seriously ridonkulous. The dongles seem to uniformly use FPGAs to do the work while you can still buy a Z85C30 from Digikey for $6.85 and a PIC (or other) microcontroller with "full speed USB" is around $10. That looks like a minimum unit price, factoring in a PC board of around, what, $40?, for a homemade Localtalk-USB converter. That's not as cheap as some people might like but considering the "universal applicability" of such a dingus might that be a better bet then trying to interface an SCC directly to the GPIO ports on a Raspberry/Beagleboard/whatever?
(It looks like there's, what, 17? easily accessible GPIO pins on a Raspberry Pi, with some of them semi-dedicated for specific functions? Looking at the Z85c30's datasheet 17 is exactly how many lines there are on the "system bus" side of the chip. Unless there's another SCC that has a more friendly-to-modern-stuff bus structure...)
This does make me wonder what's inside those Appletalk-Ethertalk bridges. Is it a single custom IC or are they an SCC, Ethernet chip, and MCU bought in bulk and crammed together? I guess it does look like you can get Ethernet modules for Arduino for "shockingly cheap", so maybe that's not that unreasonable. An AVR+Arduino ethernet module+SCC chip might almost be cobble-together-able for around that same $40 price point. The difference is that you have to do all your protocol translation in the MCU you cram in there, while making a USB-SCC peripheral would let some "bigger iron" handle that part.
Anyway, blawblaw, yacketyschmackety.
See above, the Fastpath uses separate chips for all the listed functions, no fancy integrated stuff. They are in essence full 68000 based computers without a video output. Also realize these bridges cost $1500-2000 new back in the late 80s-early 90s.
Yeah, I noticed that after I posted. I was actually thinking of the smaller-cheaper "Printer adapters" (Ala, AsanteTalk, Farallon iPrint LT, etc) rather than the more heavy duty iron when I said it, but of course that last generation of those which came out in the late 90's-early '00s may well use MCUs that are (effectively) more powerful than the 68000 in the earlier "smarter" ones.
I was wondering if we couldn't revive this project. I think that it would be brilliant to have a small piece of hardware which can bridge LocalTalk....with TCP/IP support. I recently made a MacIPgw virtual machine. If you have a old LocalTalk bridge you can use it. Same for the A2SERVER. Also nice if you have piece of LocalTalk Bridge hardware.
I'm thinking of a Raspberry PI / Arduino card, etc with Localtalk support.
I have been experimenting with PC LocalTalk cards as well, so there is support in the Lunux kernel for it.
Anyone an idea what the changes are to build something like this? We even could make it a Kickstarter project......
See:
viewtopic.php?f=2&t=21983
and
viewtopic.php?f=2&t=16054&start=0
I'm thinking of a Raspberry PI / Arduino card, etc with Localtalk support.
I have been experimenting with PC LocalTalk cards as well, so there is support in the Lunux kernel for it.
Anyone an idea what the changes are to build something like this? We even could make it a Kickstarter project......
See:
viewtopic.php?f=2&t=21983
and
viewtopic.php?f=2&t=16054&start=0
I'm interested in this, but I've got a couple other projects to work through first. The PS2 to pre-ADB & ADB adapter PCBs are supposed to arrive today, and after that I've been thinking of reviving the 030 PDS project. This is on the list, just hasn't been gotten to yet. If someone else wants to tackle it, I'd be happy to do what I can to help. This opens up all kinds of possibilities, since localtalk is pretty much the most common, fastest, external bus available on virtually all machines. With proper software, you can use it for so much more than just file sharing or IP routing.
My thought on the easiest, meaning most likely to actually happen, route to making this work is to use a z85C30 derivative that's still available. Mouser at least still sells compatible parts for about $10 in quantities of 1. Software bitbanging of the SDLC link layer through a generic RS422 interface would be tedious. Not impossible, but personally I don't see that being a very efficient or effective approach, particularly when you can get it done in mac compatible hardware for $10. Then, bitbanging the z85C30-derivative using an rpi or beaglebone black's GPIO lines seems fairly doable. I am concerned the RPI doesn't have enough GPIOs to actually talk to the z85C30, so a beaglebone black may be more reasonable. The other problem is the z85c30 is a 5V part, and neither the rpi or bbb are 5V tolerant, so voltage level conversion is necessary.
My thought would be to first create a "shield" or "cape" PCB for the desired board, which has level converters and the z85c30 part on it. Then work through Linux drivers for it to show up similar to the ISA localtalk cards.
My thought on the easiest, meaning most likely to actually happen, route to making this work is to use a z85C30 derivative that's still available. Mouser at least still sells compatible parts for about $10 in quantities of 1. Software bitbanging of the SDLC link layer through a generic RS422 interface would be tedious. Not impossible, but personally I don't see that being a very efficient or effective approach, particularly when you can get it done in mac compatible hardware for $10. Then, bitbanging the z85C30-derivative using an rpi or beaglebone black's GPIO lines seems fairly doable. I am concerned the RPI doesn't have enough GPIOs to actually talk to the z85C30, so a beaglebone black may be more reasonable. The other problem is the z85c30 is a 5V part, and neither the rpi or bbb are 5V tolerant, so voltage level conversion is necessary.
My thought would be to first create a "shield" or "cape" PCB for the desired board, which has level converters and the z85c30 part on it. Then work through Linux drivers for it to show up similar to the ISA localtalk cards.
One thing, I noticed that RS-485 is supposed to be backwards compatible with both RS-422 and RS-323. Perhaps a slightly cheaper/easier to find IC than RS-422 these days, and less of a headache than bitbanging.
Doing a quick scan of what's out there it appears that it's pretty trivial to find RS-485-to-USB UART dongles, but the problem is that the "RS" part of both of RS-485 and RS-422 define the *electrical* characteristics of the interface, and those dongles inevitably seem to have very "simple" UARTs attached to the line drivers. Add the ability to do SDLC processing like the Zilog chip and you end up with shockingly expensive things like this..
I still like the idea of interfacing the Z85c30 to a USB capable microcontroller instead of doing it as a shield directly bit-banged by something like a Beaglebone. In theory at least you could offload some of the packet processing overhead to the MCU so the driver for the host OS (be it Linux, BSD, whatever) could be abstracted to a really simple character device. Stuff a complete packet in, pull a complete packet out when one arrives. No spinning your wheels bitbanging a device designed to sit on a "real" CPU bus and the dongle could be attached to the Linux-driven NAS box that a user might already have. But of course that comes with all the requisite handwaving about making it work, etc.
I still like the idea of interfacing the Z85c30 to a USB capable microcontroller instead of doing it as a shield directly bit-banged by something like a Beaglebone. In theory at least you could offload some of the packet processing overhead to the MCU so the driver for the host OS (be it Linux, BSD, whatever) could be abstracted to a really simple character device. Stuff a complete packet in, pull a complete packet out when one arrives. No spinning your wheels bitbanging a device designed to sit on a "real" CPU bus and the dongle could be attached to the Linux-driven NAS box that a user might already have. But of course that comes with all the requisite handwaving about making it work, etc.
That seems entirely reasonable to me.
RS-485 is used for DMX-512. I built a clone of the Open DMX USB interface a while back and the transceiver IC is indeed just the electrical interface between a USB serial UART and the DMX bus. You should be able to use the onboard UART in just about any modern microcontroller to talk RS-485. The dimmer packs I built are based on a variation of this AVR based circuit and use his code.
http://www.hoelscher-hi.de/hendrik/english/dimmer.htm
http://www.hoelscher-hi.de/hendrik/english/dimmer.htm
The question isn't whether you can speak RS485, but rather SDLC.
RS-485 is just the interface, half-duplex at that. You wanna speak SDLC over RS-485
Woudl be nice to have a dongle that converts SDLC to UART. This would allow bluetooth and wifi, or any other RF serial interface modules to be used for localtalk. like xBee.
Woudl be nice to have a dongle that converts SDLC to UART. This would allow bluetooth and wifi, or any other RF serial interface modules to be used for localtalk. like xBee.