Home▸
Forums▸
An idea: TCP/IP to serial bridge (modem emulator)▸
An idea: TCP/IP to serial bridge (modem emulator)
Thread
An idea: TCP/IP to serial bridge (modem emulator)
This is an idea that's related to the System 6 Browser topic, but I don't think it belongs in that thread.
How feasible would it be for someone (not me) to write a program to translate TCP/IP to serial? My "vision" involves using any serial-equipped Mac with ethernet as a means to provide internet access for compacts. I know this is sort of possible with IPNetRouter (over LocalTalk, I think), but that program's a horror to set up and feels like using a howitzer to kill flies.
What I'm thinking of is something much simpler: Mac Plus (or whatever) connects to LC580 via printer cable. LC580 pretends it's a modem and relays TCP/IP packets between the interweb and the Plus.
Feasible, or far more complex than I imagine?
How feasible would it be for someone (not me) to write a program to translate TCP/IP to serial? My "vision" involves using any serial-equipped Mac with ethernet as a means to provide internet access for compacts. I know this is sort of possible with IPNetRouter (over LocalTalk, I think), but that program's a horror to set up and feels like using a howitzer to kill flies.
What I'm thinking of is something much simpler: Mac Plus (or whatever) connects to LC580 via printer cable. LC580 pretends it's a modem and relays TCP/IP packets between the interweb and the Plus.
Feasible, or far more complex than I imagine?
I have written two programs...
(a) "macipd", a gateway for MacIP on DDP and converts it to and from SLIP.
( B) "slippery", a SLIP to PPP convertor .
Both work in a posix environment, eg Linux, NetBSD, Darwin, OSX.
So the way I run this is...
macipd establishes the AF_APPLETALK socket and handles the IPGATEWAY and IPADDRESS.
It spawns a child process that it talks to using SLIP to exchange the IP packets with the real IP network.
The child process I use talks SLIP on one side to talk the macipd, and PPP on the other side to talk to pppd.
So on my network a compact mac talks as follows...
Where macipd, slippery and pppd are running on a NetBSD box.
This can also be:
When I original wrote macipd, the operating systems (Linux, NetBSD) generally supported SLIP on pseudo-terminals, when they dropped this support I then wrote the "slippery" program so my gateway did not need to change, it still talked SLIP.
On a System 6/7 Mac though things are rather different. You would want to use CTB to interface with the serial interface, and then would need total ownership of the ethernet for IP purposes. Eg, would not be able to have MacTCP running.
On a System 8/9 Mac you are in OpenTransport territory, driving the ethernet is quite different, but again you can't have the operating system trying to use IP on the ethernet while you are.
You could use two ethernet interfaces, one for the OS/MacTCP/OT, one for the gateway.
(a) "macipd", a gateway for MacIP on DDP and converts it to and from SLIP.
( B) "slippery", a SLIP to PPP convertor .
Both work in a posix environment, eg Linux, NetBSD, Darwin, OSX.
So the way I run this is...
macipd establishes the AF_APPLETALK socket and handles the IPGATEWAY and IPADDRESS.
It spawns a child process that it talks to using SLIP to exchange the IP packets with the real IP network.
The child process I use talks SLIP on one side to talk the macipd, and PPP on the other side to talk to pppd.
So on my network a compact mac talks as follows...
Code:
Mac -> LocalTalk -> AsantePrint -> Ethernet -> [ macipd -> slippery -> pppd ]
This can also be:
Code:
Mac -> LocalTalk -> Mac with LocalTalkBridge -> Ethernet -> [ macipd -> slippery -> pppd ]
On a System 6/7 Mac though things are rather different. You would want to use CTB to interface with the serial interface, and then would need total ownership of the ethernet for IP purposes. Eg, would not be able to have MacTCP running.
On a System 8/9 Mac you are in OpenTransport territory, driving the ethernet is quite different, but again you can't have the operating system trying to use IP on the ethernet while you are.
You could use two ethernet interfaces, one for the OS/MacTCP/OT, one for the gateway.
TCP/IP to serial bridges already exist. I think that there are some standalone ones out there, but the book that I'm reading has a couple of examples for hobby projects. That includes both wired and wireless. Here's the one that they're talking about:
http://www.lantronix.com/device-networking/embedded-device-servers/xport.html
They appear to cost $50 or so.
It sounds like they look like a serial port to the hardware, so the wiring should be minimal and easy to figure out by anyone who understands pinouts. But I don't know how it encapsulates the data. I haven't reached that chapter yet.
http://www.lantronix.com/device-networking/embedded-device-servers/xport.html
They appear to cost $50 or so.
It sounds like they look like a serial port to the hardware, so the wiring should be minimal and easy to figure out by anyone who understands pinouts. But I don't know how it encapsulates the data. I haven't reached that chapter yet.
You don't really have "TCP/IP to serial bridges". TCP & IP are network protocols, serial is a physical layer thing. Eg you could have ethernet to serial, or wireless to serial.TCP/IP to serial bridges already exist.
PPP and SLIP are the two main ways of encapsulating IP packets on a serial link.
You can happily plug a compact mac with MacPPP into a Windows box running RAS or UNIX server running PPPD, only cost is a normal mac serial cable, but you are limited to RS/232 speeds.
Using LocalTalk lets the Mac talk 230kbps.
If you want a serial link out of a Mac that does work at 230kbps, you already have one, it's called 'ADSP Tool'. So all you would need is some component on the network that can read/write ADSP....
Did I mention my "adspd" daemon? It works rather like "inetd" but for ADSP.
So in theory you could make a shim serial port (see Inside Communications Toolbox page 182) that registers itself with CTB, lets the MacPPP use it as a real serial port, then talks ADSP out to a server which then just talks directly to pppd. No major technical problem there, except that MacIP (IP over AppleTalk) already does this in a much better manner.
Does anyone remember "PatchBay", that worked with Apple's MIDI Manager?
It would be cool if on a mac you could have a similar application that would let you tie lots of inputs and outputs together.
Eg, things could be Terminal Tools, Serial Tools, Serial ports, paired Apple Events (like MPW Shell's stdin/stdout) etc.
So a document would describe a load of things all tied together, editting would be a case of dragging available things from a pallette, and wiring them together on screen by dragging wires from little terminals, output to input.
It would be cool if on a mac you could have a similar application that would let you tie lots of inputs and outputs together.
Eg, things could be Terminal Tools, Serial Tools, Serial ports, paired Apple Events (like MPW Shell's stdin/stdout) etc.
So a document would describe a load of things all tied together, editting would be a case of dragging available things from a pallette, and wiring them together on screen by dragging wires from little terminals, output to input.
I'm not sure why PPP doesn't do what you want Luddite. Obviously I'm missing something, but I'd like to know what it is.
*I* was hoping you were going to ask about the feasibility of porting uIP to system 4.1 or 3.3
*I* was hoping you were going to ask about the feasibility of porting uIP to system 4.1 or 3.3
I'm not sure that it doesn't ;-)I'm not sure why PPP doesn't do what you want Luddite. Obviously I'm missing something, but I'd like to know what it is.
The problem is: how to get a compact Mac online in the absence of an EN/SC or similar device or a dial-up internet account.
I realize there are many ways to do this, as porter and II2II have already mentioned, but I thought it would be nice to see a 68K Mac solution...
To my knowledge, these boards will work independently of a microcontroller that would produce TCP/IP packets. So in a sense, you to have TCP/IP to serial bridges.You don't really have "TCP/IP to serial bridges". TCP & IP are network protocols, serial is a physical layer thing. Eg you could have ethernet to serial, or wireless to serial.
You are correct though, they are protocols and you really need to layer protocols on top of TCP for it to be of any value (eg. telnet or HTTP). At this point, I don't know how these bridges are wrapping data so I don't know if they will be useful.
As for equant not knowing why PPP ain't sufficient, well, I can imagine one case: if you want to be able to connect to the internet independent of other computers (in your home). Which is kinda hard if your using DSL or cable services.
Okay, I'm asking... but there's still the problem that most of us don't have dial-up anymore, so there has to be some way to physically connect your 512K to your router... an EN/SC is obviously the "cleanest" solution, but they're not all that easy to come by.*I* was hoping you were going to ask about the feasibility of porting uIP to system 4.1 or 3.3![]()
Thanks, that's what I wanted to say... but didn't. ;-)As for equant not knowing why PPP ain't sufficient, well, I can imagine one case: if you want to be able to connect to the internet independent of other computers (in your home). Which is kinda hard if your using DSL or cable services.
Okay, if I had to do this without AsantePrint and only with 68k Macs I wouldbut I thought it would be nice to see a 68K Mac solution...
(a) use an Mac with localtalk and ethernet to run the LocalTalk bridge (68020 upwards).
( B) use 68030 class machine (eg IIx) running NetBSD m68k to run my macipd/slippery/pppd.
Now you could make the "Mac with localtalk ethernet" run a gateway which does it all, but somebody would have to write it.
Unfortunately NetBSD macs can't use LocalTalk as the drivers don't exist (too software intensive), and A/UX can't have a user level application inject IP packets directly onto the network (slattach does not work with pseudo-terminals), but you *could* hang a serial cable to loopback the modem port onto the printer port to handle SLIP to solve that, but then lose the printer port to do localtalk.
Ok, I see, but I'm unsympathetic.f you want to be able to connect to the internet independent of other computers (in your home). Which is kinda hard if your using DSL or cable services.
I'll buy that PDS ethernet cards, Scsi/ethernet adapters and the appletalk/ethernet adapters are hard to find, so we need another solution, but how realistic is it to need to hook up an old-mac to a router in a house with no other computers?
Surely you can find an old laptop cheap with serial and ethernet; throw bsd/linux on it; hide it behind your desk; and call it an "old-mac-ethernet-adapter".
Shoot, even better, just go get some OpenWRT/FreeWRT compatible router for $50 or maybe less put pppd on it and it'll serve ppp to your mac *and* be a router for the other computers that I guess you don't have.
And uIP has SLIP support in it, so that's nice...
128K Mac -> uIP -> OpenWRT -> internet.
Easy as pi.
128K Mac -> uIP -> OpenWRT -> internet.
Easy as pi.
equant:
Some of us are ancient, back from the days when an Apple II could connect to the internet via a shell account from a local ISP. (Which is fairly rare these days, even with dialup.) So the idea of hooking up an old computer via a new computer seems a bit strange. After all, why wouldn't you just use the new computer for internet access in that case.
Other factors may be involved here too. Full computers are big and noisy and chew up power. A lot of those issues can be reduced if you buy a special device. The AVR32 development kit runs Linux, has an ethernet port and serial (IIRC), is quite low power and quiet and small. Some companies have sold similar devices (without the serial port, so you'd need a USB to RS-232 adapter) in fancy plastic cases. I would imagine that they could be repurposed for an application like this. But you're still pretty much going through a computer so the solution feels somewhat less satisfying.
Oh, and for added credit, what about tossing all of those new computers and just using the old stuff. Around 1997 or 1998 my only computer was an Apple IIe. It was used for everything from writing papers to surfing the web. And I do mean only computer. If I had another computer it was a broken 486. Around 1998, I was using just a Mac IIci on an ADSL connection. I remember some idiot telling me that the Mac IIci was too slow to handle ADSL and that it would be simple to upgrade it to a Pentium by swapping in a new motherboard. >
Some of us are ancient, back from the days when an Apple II could connect to the internet via a shell account from a local ISP. (Which is fairly rare these days, even with dialup.) So the idea of hooking up an old computer via a new computer seems a bit strange. After all, why wouldn't you just use the new computer for internet access in that case.
Other factors may be involved here too. Full computers are big and noisy and chew up power. A lot of those issues can be reduced if you buy a special device. The AVR32 development kit runs Linux, has an ethernet port and serial (IIRC), is quite low power and quiet and small. Some companies have sold similar devices (without the serial port, so you'd need a USB to RS-232 adapter) in fancy plastic cases. I would imagine that they could be repurposed for an application like this. But you're still pretty much going through a computer so the solution feels somewhat less satisfying.
Oh, and for added credit, what about tossing all of those new computers and just using the old stuff. Around 1997 or 1998 my only computer was an Apple IIe. It was used for everything from writing papers to surfing the web. And I do mean only computer. If I had another computer it was a broken 486. Around 1998, I was using just a Mac IIci on an ADSL connection. I remember some idiot telling me that the Mac IIci was too slow to handle ADSL and that it would be simple to upgrade it to a Pentium by swapping in a new motherboard. >
I run NetBSD on a tiny Neoware box with a flash disk. It does all my MacIP, ADSP, DHCP, routing and DNS forwarding.Full computers are big and noisy and chew up power.
.
The modem typically was a computer. Often a tiny little thing that handled the Hayes commands. Unless it was a manual dial, eg with acoustic coupler!So the idea of hooking up an old computer via a new computer seems a bit strange.
If you have a dial up account, you still can still do the MacPPP/modem thing. If you don't, you have to interface with the network connectivity of today.
At the same time, try and play your 33 RPM LPs on your BluRay.
I get what you're saying. Obviously everyone draws their lines in different places. I won't tell anyone how they decide what makes using old computers worthwhile to them. If one asks, "why not just use the new computer," then that's fine, but I can't relate to why they're trying to get their 68000 on the internet. Surely we're not trying to find solutions for real legacy users are we?Some of us are ancient, back from the days when an Apple II could connect to the internet via a shell account from a local ISP. (Which is fairly rare these days, even with dialup.)
Still, I think the OpenWRT solution isn't bad as far as ease (when compared to the previously mentioned serial/ethernet Xport component from Lantronix) or power/noise (when compared to a host computer). I mean, it's just a router. It "feels" like a legit solution. You can't "just use the router" to access the internet.
And I'm ancient enough. I went for several months with nothing but a Televideo 910 dumb terminal and a modem when my IIsi died in college.
But how would that work *physically* ??? How do you connect a compact Mac to a router?Shoot, even better, just go get some OpenWRT/FreeWRT compatible router for $50 or maybe less put pppd on it and it'll serve ppp to your mac *and* be a router for the other computers that I guess you don't have.![]()
Going by the PPP reference, it sound like serial cable from modem port to a serial port on the router. Then use MacTCP/MacPPP on the Mac.
Hmmm... I didn't know there was such a thing as a router with a serial port. Suddenly this whole thread has become meaningless.
A router can be anything with multiple network interfaces, those interfaces don't have to be of the same type.
So a box with one wireless and one ethernet interface is still a router.
Similarly a box with one ethernet and one serial port can be a router.
There are plenty of embedded PC or microcontroller boards which can implement that.
So a box with one wireless and one ethernet interface is still a router.
Similarly a box with one ethernet and one serial port can be a router.
There are plenty of embedded PC or microcontroller boards which can implement that.
II2II: your mission should you choose to accept it is to find a microcontroller with ethernet, TCP/IP and a 230kbps (RS-422?) serial port for under $50 and port an Appletalk stack to it.
I know there's a TCP/IP stack for PICs, there's almost certainly one for AVRs, and it's possible you could fake up a Localtalk port by bit banging.
Personally I don't think the Appletalk to ethernet converters are all that hard to find. The Farallon ones are nice, as they can use the full 230kbps.
Regarding serial ports on OpenWRT routers - I was having a look at that page last night and it seems on most of them it involves soldering a connection to the onboard ISP (in system programming) port. In other words, there is a serial port onboard, but it's not exposed to the outside world via the case. It doesn't look difficult, and there are already software packages to make it useful
I know there's a TCP/IP stack for PICs, there's almost certainly one for AVRs, and it's possible you could fake up a Localtalk port by bit banging.
Personally I don't think the Appletalk to ethernet converters are all that hard to find. The Farallon ones are nice, as they can use the full 230kbps.
Regarding serial ports on OpenWRT routers - I was having a look at that page last night and it seems on most of them it involves soldering a connection to the onboard ISP (in system programming) port. In other words, there is a serial port onboard, but it's not exposed to the outside world via the case. It doesn't look difficult, and there are already software packages to make it useful
I used to do just that when I was living with Linux nerds, and my 6100 didn't have an AAUI converterYou can happily plug a compact mac with MacPPP into a / UNIX server running PPPD, only cost is a normal mac serial cable, but you are limited to RS/232 speeds.
Very many routers (and yes, I'm talking about the kind you buy at Home Depot) out there have serial ports *inside* them (note J6 and J7 are both serial ports)....But how would that work *physically* ??? How do you connect a compact Mac to a router?
http://devices.natetrue.com/musicap/12%20-%20Serial%20ports.jpg'>http://devices.natetrue.com/musicap/12%20-%20Serial%20ports.jpg
That's from (http://devices.natetrue.com/musicap/) a wireless music player built out of a router. It gives you an idea of the fun that can be had.
Here's alink to the OpenWRT hardware comapatibility guide which specifies the routers with serial ports...
http://wiki.openwrt.org/TableOfHardware?action=show&redirect=toh
It's not a plug and play solution, but potentially a very satisfying solution if you're into hacking around. I've thought about doing it with a wireless printserver/router that already gets used as a wireless bridge for ethernet enabled classic macs, but alas, it's not openwrt worthy.
Anyway, I know this isn't exactly what anyone wanted, and I didn't mean to hijack the thread, but I figured I should explain fully.
equant:
Of course people will want to know about your solution. It's certainly applicable in a case like this since a lot of people are going to have a router.
Will it work well in this configuration? I don't know. I took a quick look at my router and it is supported by OpenWRT. Sweet. I have yet to figure out how to add a serial port, but there are a couple of jumper blocks that may serve that purpose. If so that would be fantastic: no soldering.
Still, there may be one hitch. A lot of these ports, particularly the user added ones, are probably going to lack hardware flow control. This may make the link a bit less reliable. But hopefully not.
Of course people will want to know about your solution. It's certainly applicable in a case like this since a lot of people are going to have a router.
Will it work well in this configuration? I don't know. I took a quick look at my router and it is supported by OpenWRT. Sweet. I have yet to figure out how to add a serial port, but there are a couple of jumper blocks that may serve that purpose. If so that would be fantastic: no soldering.
Still, there may be one hitch. A lot of these ports, particularly the user added ones, are probably going to lack hardware flow control. This may make the link a bit less reliable. But hopefully not.
Alas, they are *very* different beasts.230kbps (RS-422?) serial port
LocalTalk uses HDLC framing with special bit encoding to allow clock recovery, tri-state drivers followed by an isolation transformer.
The Zilog SCC does all of that encoding/decoding except for the tri-state driver and transformers.
There used to be LocalTalk ISA boards available from a few manufacturers.
So are these Zilog SCCs obtainable?
Yes....So are these Zilog SCCs obtainable?
http://en.wikipedia.org/wiki/Zilog_SCC
http://www.zilog.com/products/partdetails.asp?id=Z85C30
I had to resort to the 'pedia for clarification:Alas, they are *very* different beasts.230kbps (RS-422?) serial port
LocalTalk uses HDLC framing with special bit encoding to allow clock recovery / The Zilog SCC does all of that encoding/decoding except for the tri-state driver and transformers.
I always gets my layers confuzzled. So physically/electrically the port is both RS-232 and 422 compatible, and HDLC runs on top of the RS-422 mode?/ expensive multi-mode (RS-232/RS-422) capable serial ports. The port was driven by the Zilog SCC which could serve as either a standard UART or handle the much more complicated HDLC protocol which was a packet oriented protocol which incorporated addressing, bit-stuffing, and packet checksumming in hardware. Coupled together with the RS422 electrical connections /
http://en.wikipedia.org/wiki/High-Level_Data_Link_Control
But anyway, I gather your point is that the Zilog controller & associated hardware handles all the physical and data link layer stuff, and it would be far simpler to just use one than try to emulate it in code on a micro.
A quick check at octopart confirms widespread availability of the SCC
No, RS232/422 are point to point links. LocalTalk is run on a bus, where tristate drivers are used to disable output when not transmitting.I always gets my confuzzled. So physically/electrically the port is both RS-232 and 422 compatible, and HDLC runs on top of the RS-422 mode?
The following is the guide for AppleTalk including LocalTalk.
http://developer.apple.com/MacOs/opentransport/docs/dev/Inside_AppleTalk.pdf
So the recipe looks like this?
Macintosh serial port
:
:
Tristate drivers & transformers
|
Zilog SCC
|
Microcontroller
|
Ethernet MAC
:
:
LAN
Macintosh serial port
:
:
Tristate drivers & transformers
|
Zilog SCC
|
Microcontroller
|
Ethernet MAC
:
:
LAN
Plus a load of software.
And where would you find all of the components?
(a) in an old mac with ethernet
( B) AsantePrint
And where would you find all of the components?
(a) in an old mac with ethernet
( B) AsantePrint