-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
DIY Localtalk - Ethernet converter
- Thread starter bd1308
- Start date
Bunsen
Admin-Witchfinder-General
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/
techknight
Well-known member
and?
techfury90
Well-known member
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.
techknight
Well-known member
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.
Bunsen
Admin-Witchfinder-General
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.
techknight
Well-known member
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.
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.
mactjaap
Well-known member
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.
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.
Last edited by a moderator:
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
