Thread
DIY Localtalk - Ethernet converter
I have a EtherPrint ethernet-to-localtalk bridge that seems to work well enough to netboot my IIGS from and connect to a netatalk share I have locally. I'm not sure what the traditional baud rate of the serial side is -- I assume 230K -- but I'm pretty sure I could emulate this functionality in a couple of arduinos. So I've been taking data snapshots of Appletalk packets coming from various equipment on the localtalk side (from the bridge) and packets from the ethernet side to the bridge. The format seems to be straight-forward. The packet captures were taken with Wireshark. Once I figure out how to convert the Localtalk serial RS-422 to RS-232, then I might be able to listen to communication on the serial side. I'm sure Basilisk II and other OSS emulators will help out in this regard too.
Anybody interested in something like this? The nice part about a solution liek this is that it's totally modular -- there's nothing to say a beaglebone or embedded ARM machine with GPIO pins couldn't handle and supplant this solution with additional things like a netatalk Appleshare system or other things....
Anybody interested in something like this? The nice part about a solution liek this is that it's totally modular -- there's nothing to say a beaglebone or embedded ARM machine with GPIO pins couldn't handle and supplant this solution with additional things like a netatalk Appleshare system or other things....
The wirehark logs make the bitstream look a little cryptic, but it certainly follows *a* pattern that I can see. I just need to do more research on what each "message" across the ethernet wire looks like, document those, and then move onto the serial side to see what the serial side looks like. If they match, i'm a winner and this will be probably be really easy.
I'll do some tests this weekend now that appletalk/netatalk/ethertalk communication is again established in the home base.
I'll do some tests this weekend now that appletalk/netatalk/ethertalk communication is again established in the home base.
So as soon as I came home, I grabbed a OS9 machine and a Leopard machine and my Linux laptop to act as hallway monitor.
Fired up Wireshark --- and......a TON of packets from my wife on the LAN, because she's doing homework. And it's too much to sort through. So I brought out a old dd-wrt router, and rinsed/repeated. This time I was able to capture the *entire* conversation between the OS9 TiBook and the Powerbook G4.
Here's the steps I followed:
-Went to chooser, typed in IP*
-Hit OK, got login prompt. Entered correct password, but invalid username (I could say I meant to do this, but I didn't lol)
-Mounted 'Macintosh HD' after successful login.
-Browsed the HD for a bit
-Dragged Appletalk-mounted HD to trash.
COnfirmed server disconnection, then stopped wireshark capture. The protocol itself is pretty straightforward. What i'm hoping is the pieces i'm seeing on the ethernet side (in ASCII) correspond to what I will eventually see on the serial-only side
SO the next step is to build a device that will listen to the serial bus and spit out what its saying.... then match them up.
*fingers crossed*
Fired up Wireshark --- and......a TON of packets from my wife on the LAN, because she's doing homework. And it's too much to sort through. So I brought out a old dd-wrt router, and rinsed/repeated. This time I was able to capture the *entire* conversation between the OS9 TiBook and the Powerbook G4.
Here's the steps I followed:
-Went to chooser, typed in IP*
-Hit OK, got login prompt. Entered correct password, but invalid username (I could say I meant to do this, but I didn't lol)
-Mounted 'Macintosh HD' after successful login.
-Browsed the HD for a bit
-Dragged Appletalk-mounted HD to trash.
COnfirmed server disconnection, then stopped wireshark capture. The protocol itself is pretty straightforward. What i'm hoping is the pieces i'm seeing on the ethernet side (in ASCII) correspond to what I will eventually see on the serial-only side
SO the next step is to build a device that will listen to the serial bus and spit out what its saying.... then match them up.
*fingers crossed*
Nice Hack!Thanks -- It's nice knowing I can give back to the vintage mac community. According to some, I might be able to make RS-422 work like RS-232 which would work nicely in my arduino, but I'm not sure its literally that easy. Anybody else have any ideas on that?
Once I get that part worked out, the fun part will be making the glue that is between the ethernet side and the localtalk side.
And another question is -- should I just go ahead and make this more compatible with the common phonenet boxes and just figure out how *they* work while i'm in there (since I dont actually have a serial cable)...or should I just stick with regular ol' localtalk?
Actually thinking about it, I might incorporate Zigbee into the mix too, because whats even better than having a wireless localtalk network is having a bridged and wireless localtalk network --- then you'd just need a "base station" and just a converter on each machine.
Once I get that part worked out, the fun part will be making the glue that is between the ethernet side and the localtalk side.
And another question is -- should I just go ahead and make this more compatible with the common phonenet boxes and just figure out how *they* work while i'm in there (since I dont actually have a serial cable)...or should I just stick with regular ol' localtalk?
Actually thinking about it, I might incorporate Zigbee into the mix too, because whats even better than having a wireless localtalk network is having a bridged and wireless localtalk network --- then you'd just need a "base station" and just a converter on each machine.
I always thought 232 was a shorter distance subset of 422 and they were pretty much compatible right off the bat.
What kind of serial cable do you need, straight or null-modem (Printer) for DIN8 or D-shell (whatever)-9 pin.
PM me with your needs for a freeb.
Actually post'em here just in case I don't have what you need.
What kind of serial cable do you need, straight or null-modem (Printer) for DIN8 or D-shell (whatever)-9 pin.
PM me with your needs for a freeb.
Actually post'em here just in case I don't have what you need.
Now I believe they're *compatible* but i'm not sure how compatible. Some say apple supported 232 right out of the port for modems, but I'm not totally sure if I do whatever is needed to make it look like a 232 port if i'd get appletalk traffic, and then other sites say it's a differential interface, and you tie certain pins to ground, like TX- and RX- or something. I'm trying to find the link I found at work.
http://pinouts.ru/Converters/rs422_cable_pinout.shtml
Now we're talking.
http://pinouts.ru/Converters/rs422_cable_pinout.shtml
Now we're talking.
I found out that the data is encoded using some modulation to ensure the data is valid and that the Appletalk driver itself (in software) talks directly to the port, not via any other serial method. I was confused to find out that schematics for creating a DIY phonenet box didn't include *anything* with DTR/DCD lines, but that's because the mac is more or less bit-banging the serial port itself rather than relying on the standard spec. I found a book called Inside Appletalk that i'm trying to procure now for more information. If anybody has this book PM me.
http://www.mactech.com/articles/mactech/Vol.02/02.04/ATalkConnections/index.html
http://www.mactech.com/articles/mactech/Vol.02/02.04/ATalkConnections/index.html
Any of these any use to you?
http://en.wikipedia.org/wiki/Bus_Pirate
http://en.wikipedia.org/wiki/PLAICE
I may add more as I find them.
/eta/
https://www.sparkfun.com/products/9857 aka http://dangerousprototypes.com/open-logic-sniffer/
http://en.wikipedia.org/wiki/Bus_Pirate
http://en.wikipedia.org/wiki/PLAICE
I may add more as I find them.
/eta/
https://www.sparkfun.com/products/9857 aka http://dangerousprototypes.com/open-logic-sniffer/
The hurdle I'm at now is the physical connection. I'm not sure if I can just wire the port up like RS232 (as on the Mac to internet via serial thread) or If I have to go RS422. I can buy the transceivers online, so thats not a problem, it just isn't fun waiting for parts.
RS-422 is a point to point only. just like RS232.
In order to setup a bus network, it has to be converted to RS-485, which is what the phonenet stuff actually does. in sorts...
But you can listen on a direct RS-422 bus if you take the TX/rX lines and mix them. Again, sorta like phonenet does.
In order to setup a bus network, it has to be converted to RS-485, which is what the phonenet stuff actually does. in sorts...
But you can listen on a direct RS-422 bus if you take the TX/rX lines and mix them. Again, sorta like phonenet does.
The phonenet adaptor takes those TX/RX pairs and combines them into a single TX/RX pair. It's rather a simple schematic to look at, yet it works perfectly.
I think I'm going to see if wiring that port up RS232 fashion works -- if it does then I kinda know that this might work out. I'm just looking for a bunch of crap to go over the lines. Then I can actually figure out what all that means. I'm also hoping the INside Appletalk book will help too -- it better for $36
edit: it didnt make sense
I think I'm going to see if wiring that port up RS232 fashion works -- if it does then I kinda know that this might work out. I'm just looking for a bunch of crap to go over the lines. Then I can actually figure out what all that means. I'm also hoping the INside Appletalk book will help too -- it better for $36
edit: it didnt make sense
Well, localtalk is LLAP. Its defined in that standard how it talks on the port.
So all an ethernet adapter is, is an LLAP to Ethernet translator.
So what you need to do is lookup LLAP and find out how it is framed, etc... and use the arduino to decode it. Phone-Net appears to convert the RS422 full duplex bus into a single RS-485 half-duplex bus system.
So all you need is to setup the localtalk bus as half-duplex with only D+ and D- lines. Then hook these into a regular MAX488 or an ADM483 transceiver, to the AVR.
That will establish something that can listen/talk on the bus. BUT you need to come up with a way to decode the databits on the bus, which is all in the LLAP standard.
So all an ethernet adapter is, is an LLAP to Ethernet translator.
So what you need to do is lookup LLAP and find out how it is framed, etc... and use the arduino to decode it. Phone-Net appears to convert the RS422 full duplex bus into a single RS-485 half-duplex bus system.
So all you need is to setup the localtalk bus as half-duplex with only D+ and D- lines. Then hook these into a regular MAX488 or an ADM483 transceiver, to the AVR.
That will establish something that can listen/talk on the bus. BUT you need to come up with a way to decode the databits on the bus, which is all in the LLAP standard.
More information:
Localtalk uses 230.4KBps Biphase space encoding (FM0 encoding) over the RS-422/RS-485 differential pair.
Known as SDLC or Synchronous Data Link Control.
Bit timing is 4.34uS. a 1 bit is a full state for each bit period. It will either be high, or low for the entire 4.34uS duration of the bit timing.
A 0 bit produces a high/low transition exactly half-bit timing, or double the frequency of 1.
Bi-Phase Space
Level change occurs at the beginning of every bit period
"One" is represented by no midbit level change
"Zero" is represented by a midbit level change.
This is why LLAP uses Synchronization via the Flag Bytes, 0x7E.
You have to setup a timer in the AVR using 4.34uS data bit timings. Problem is, You dont know when the "start" condition of a byte occurs. So to get around that, they used the flag byte to synchronize when the first bit of a byte occured.
The easiest thing to do is setup the AVR for pin-change interrupt. Use the timer to keep track of the periods between transitions, then you will know when 1 bits and 0 bits occur. Then you will use the 0x7E to keep track of start/stop of databytes.
For example, when the pin-change interrupt occurs, setup the timer at 0. it will count until the next transition. If the timer counted 4.34uS, that was a 1 bit. if it counted 2.17uS, it was a 0 bit. The first 8 bits received are stored. and checked against 0x7E. Of course it wont be correct because your not synchronized. Thats why the Flag Byte is send multiple times. Once you are able to get enough bits received, you can figure out where your start bit is supposed to be. Fix your start position in the code, and boom now your synched. Now of course youll have to correct in code for double transitions otherwise youll end up with false bits and more bits than you need. hehe.
Simple.
Localtalk uses 230.4KBps Biphase space encoding (FM0 encoding) over the RS-422/RS-485 differential pair.
Known as SDLC or Synchronous Data Link Control.
Bit timing is 4.34uS. a 1 bit is a full state for each bit period. It will either be high, or low for the entire 4.34uS duration of the bit timing.
A 0 bit produces a high/low transition exactly half-bit timing, or double the frequency of 1.
Bi-Phase Space
Level change occurs at the beginning of every bit period
"One" is represented by no midbit level change
"Zero" is represented by a midbit level change.
This is why LLAP uses Synchronization via the Flag Bytes, 0x7E.
You have to setup a timer in the AVR using 4.34uS data bit timings. Problem is, You dont know when the "start" condition of a byte occurs. So to get around that, they used the flag byte to synchronize when the first bit of a byte occured.
The easiest thing to do is setup the AVR for pin-change interrupt. Use the timer to keep track of the periods between transitions, then you will know when 1 bits and 0 bits occur. Then you will use the 0x7E to keep track of start/stop of databytes.
For example, when the pin-change interrupt occurs, setup the timer at 0. it will count until the next transition. If the timer counted 4.34uS, that was a 1 bit. if it counted 2.17uS, it was a 0 bit. The first 8 bits received are stored. and checked against 0x7E. Of course it wont be correct because your not synchronized. Thats why the Flag Byte is send multiple times. Once you are able to get enough bits received, you can figure out where your start bit is supposed to be. Fix your start position in the code, and boom now your synched. Now of course youll have to correct in code for double transitions otherwise youll end up with false bits and more bits than you need. hehe.
Simple.
Okay I wonder if I can forget the RS232 stuff because its worthless to me anyway in this project, and just write some code for the arduino to look at data coming in from the PWM pins -- I really could use a logic analyzer but the salae logic is like $199 which is a little out of my range right now (saving for a house down payment this year). I'm going to write something to monitor the D+/D- lines and see what I get. I dont know for sure if I can make a tight enough C++ loop to get down to the 4us range, but it wouldn't hurt trying either.
I dont know what I was thinking trying to wire this up 232 style. Thanks for turning me in the right direction.
I dont know what I was thinking trying to wire this up 232 style. Thanks for turning me in the right direction.
Once you have the entire frame stored in the AVR's RAM, its your discretion what you do with that frame. Send it over RS232 serial, or send it over bluetooth. Or send it over encapsulated UDP/TCP to another end.
Or convert it from LLAP to Ethertalk. Once you get the inside appletalk im sure it has ethertalk in it. But since AVRs are sorta slow, the best thing to do is receive the frame and hold up the bus until you get done processing, so the connected mac dont continue to talk until the bus is free. follow CSMA/CD to do this.
No you cannot use the PWM pins. Thats for output only. There are 2 ways to do this. You can either sample a datapin with a timer set for the proper bit timings but its MUUCH harder to synchronize. Easier to use the 2nd option, which is connect one of the data lines on an interrupt pin. such as INT0, or INT1. As long as you can set it to interrupt on both rising and falling transitions.
You still need the transceiver, as i dont think the data lines are 5V. They are 12V i believe.
This is frequency modulation FM0. or biphase, whatever the engineers call it these days. NOT pulse width modulation.
Or convert it from LLAP to Ethertalk. Once you get the inside appletalk im sure it has ethertalk in it. But since AVRs are sorta slow, the best thing to do is receive the frame and hold up the bus until you get done processing, so the connected mac dont continue to talk until the bus is free. follow CSMA/CD to do this.
No you cannot use the PWM pins. Thats for output only. There are 2 ways to do this. You can either sample a datapin with a timer set for the proper bit timings but its MUUCH harder to synchronize. Easier to use the 2nd option, which is connect one of the data lines on an interrupt pin. such as INT0, or INT1. As long as you can set it to interrupt on both rising and falling transitions.
You still need the transceiver, as i dont think the data lines are 5V. They are 12V i believe.
This is frequency modulation FM0. or biphase, whatever the engineers call it these days. NOT pulse width modulation.
Is there any upper limit to the size of a frame? Because I'm not sure if I have enough ram in my 328P to store a entire frame in RAM?
I'm going to have to do some research on interrupts. This is exactly the kind of project I need to teach myself low-level AVR things, and on the surface it seems easy, but I just need to go ahead and set something up.
Now, another question --- suppose that I wanted to make this go in-line between two phonenet nodes --- the data will be the same, but half duplex, correct?
I'm going to find a S-video cable and destroy it, and go ahead and hook this up to a arduino and start playing with it.
I'm going to have to do some research on interrupts. This is exactly the kind of project I need to teach myself low-level AVR things, and on the surface it seems easy, but I just need to go ahead and set something up.
Now, another question --- suppose that I wanted to make this go in-line between two phonenet nodes --- the data will be the same, but half duplex, correct?
I'm going to find a S-video cable and destroy it, and go ahead and hook this up to a arduino and start playing with it.
maximum frame size is 603 bytes. Ever...
Anyway, You are going to need the transceiver. Also the transceiver has direction control as well. You can listen on the bus, or transmit back to the bus. Or you can turn off the receiver, and transmitter and itll sit totally transparent on the bus.
S-video cables wont work. Thats for the ADB bus. not the serial bus.
Anyway, You are going to need the transceiver. Also the transceiver has direction control as well. You can listen on the bus, or transmit back to the bus. Or you can turn off the receiver, and transmitter and itll sit totally transparent on the bus.
S-video cables wont work. Thats for the ADB bus. not the serial bus.
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
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.
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..
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/
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.
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.
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.
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
I'm restarting work on this. There have been plenty of implementations of this already, and the protocol is seemingly simple to bitbang. In fact, most implementations of this are essetntially bitbanging at the right speeds to perform the magic things.
There's an arduino with USB host capability that I'm in the process of acquiring. I've just moved and settled in and finally moved my computer stuff into its permanent home, so forgive me for taking so long on this.
Essentially, there's an USB stack for the arduino that allows for controlling a keyboard and mouse. The other end would just bitbang everything to a ADB keyboard and mouse.
I've already had limited success with speaking ADB via an arduino and there's plenty of reverse implementations of this on the internet.
Everything will be opensourced, and should be possible via an arduino.
There's an arduino with USB host capability that I'm in the process of acquiring. I've just moved and settled in and finally moved my computer stuff into its permanent home, so forgive me for taking so long on this.
Essentially, there's an USB stack for the arduino that allows for controlling a keyboard and mouse. The other end would just bitbang everything to a ADB keyboard and mouse.
I've already had limited success with speaking ADB via an arduino and there's plenty of reverse implementations of this on the internet.
Everything will be opensourced, and should be possible via an arduino.
This is really great news bd!
I was planning to move my MacIPgw virtual machine to a more permanent solution on a Raspberry Pi......but that is without LocalTalk, because I'm not capable of doing that. So if there would come an open source Localtalk solution with Arduino it would be really great.
If I can help with something, please let me know.
I will follow this tread carefullly.
I was planning to move my MacIPgw virtual machine to a more permanent solution on a Raspberry Pi......but that is without LocalTalk, because I'm not capable of doing that. So if there would come an open source Localtalk solution with Arduino it would be really great.
If I can help with something, please let me know.
I will follow this tread carefullly.
After you mentioned that, I wanted to know too. I ripped open my Farallon EtherWave Printer Adapter to get some pictures of the PCB for a rough idea of the architecture. I wish these pictures (particularly the second one) were better, but they're a start...
Looks like the LocalTalk portion (and probably the main firmware?) is done with the Zilog Z8018110FEC. The Z80181 is a microprocessor with a Z85C30 SCC built in. I've also identified a Hynix 32KB SRAM chip. I didn't want to tear off any of the stickers, so I'm not sure about some of the chips. I bet a good chunk of the rest of the chips are for Ethernet. I would assume the chip with the 34F939 sticker is going to be an ethernet controller.
If anyone wants better detail I can reopen it and take pictures with a real camera...
That macipgw looks pretty handy ... Does that work with localtalk printer bridges? I could probably set it up on my transmeta laptop which I forget running for months on end anyway ;-) .
I've been hunting for ways to get my SE/30 and Plus on the net this looks promising!
I've been hunting for ways to get my SE/30 and Plus on the net this looks promising!
@cb88
You can use the MacIPgw virtual machine with a simple LocalTalk bridge. I will test it also with the LocalTalk Bridge control panel of Apple.
Have a look at viewtopic.php?f=29&t=22036
If you have any question..please let me know!
You can use the MacIPgw virtual machine with a simple LocalTalk bridge. I will test it also with the LocalTalk Bridge control panel of Apple.
Have a look at viewtopic.php?f=29&t=22036
If you have any question..please let me know!
Here is a document I found, Its a Zilog application note and explains how to implement localtalk using their SCC, Including the source code
http://www.zilog.com/appnotes_download.php?FromPage=DirectLink&dn=AN0064&ft=Application%20Note&f=YUhSMGNEb3ZMM2QzZHk1NmFXeHZaeTVqYjIwdlpHOWpjeTk2TVRnd0wyRndjRzV2ZEdWekwyeHZZM1JoYkdzdWNHUm0=
http://www.zilog.com/appnotes_download.php?FromPage=DirectLink&dn=AN0064&ft=Application%20Note&f=YUhSMGNEb3ZMM2QzZHk1NmFXeHZaeTVqYjIwdlpHOWpjeTk2TVRnd0wyRndjRzV2ZEdWekwyeHZZM1JoYkdzdWNHUm0=
Absolutely! I just scanned both sides of the PCB at 1200 dpi and ended up with 25 MB images. Converted them to a low quality JPG and got them down to about 500 to 700 KB. I went ahead and hosted them off-site...if you'd rather have them hosted here that's fine too.
http://imgur.com/a/HmkBE
If you hover over the image and go to actions, you can get the full resolution images at over 4000x4000 pixels.
Easily done with a raspberry pi. Convert the serial output to RS232, and have a service that listens to the serial pins on the r-pi and translates them to a virtual mac serial port. Done.
Everything already exists at a software level --- netatalk for appletalk, the serial port driver for a real mac serial port, and of course linux on the r-pi. The only part needed is gluecode to convert the RS232 signals to a virtual localtalk port
That part is easy --- question is....is it cheating (too easy?)
Everything already exists at a software level --- netatalk for appletalk, the serial port driver for a real mac serial port, and of course linux on the r-pi. The only part needed is gluecode to convert the RS232 signals to a virtual localtalk port
That part is easy --- question is....is it cheating (too easy?)
OK. Totally glazed past the part where chips are available that contains the SCC built in ---- *thats* where I wanna be.
With the raspberry pi being way more powerful, shouldn't we consider doing this in software (which I'm much more familiar with).
I wanted to get involved in a hardware project to teach myself hardware things though, so maybe I can start buying stuff
With the raspberry pi being way more powerful, shouldn't we consider doing this in software (which I'm much more familiar with).
I wanted to get involved in a hardware project to teach myself hardware things though, so maybe I can start buying stuff