Now, this can be really easily interfaced to an old Mac in hardware (either just to the serial port, or possibly replacing an internal modem for the keen), but what I'm not so sure about is the software side.
As it stands, they can run essentially any code, but have a modem-like AT command set by default. The odd thing is that they have an internal TCP/IP stack, so a modem script wouldn't really be ideal...
Do we think it's possible to make a "wrapper" TCP/IP replacement for OT which offloads calls to the hardware?
Off the top of my head, it seems like one might be able to do a limited 'mdev' driver for the card in the AT-like mode, since it can handle ~5 tcp connections over the serial link for you. But I think the most versatile approach would be to run native code on the module, and write an 'enet' ethernet device driver on the MacOS side, and essentially implement an ethernet to wifi bridge between the enet driver and the native code on the module, using some added control calls used by a MacOS app or control panel for wifi configuration.
But the most simplistic approach would be to implement a serial driver to present a serial port on the MacOS side to a plain TCP connection on the other side, which could do PPP to another host on the network.
It'd need a 3.3V regulator, and a max232 or something to interface with the mac side.
The neat thing about something like this is it'll work with pretty much all macs. Even the Duos have serial ports.
Nice! That'd be pretty interesting to do SLIP with that firmware. Wasn't there an old MacSLIP control panel?
I wonder if it's having autobaud problems with zterm. I read these things do autobaud on reset, and can end up at really weird baud rates as a result.
I've installed a copy of InterSLIP (InterSLIP-1.0.2d2.sea.hqx, I can't actually remember where I found it now, but google helped me) and flashed the firmware to the ESP8266, but I can't seem to work out how to configure it at runtime. I can see that a reconfigure of the headers will provide 'burnt in' details of wifi mode/network/password, but the documentation is severely lacking.
Despite what they've written on the espduino repo page, the AT commands don't seem to work at the same time. I expect a recompile will be necessary for that... I'll try to hack something together to get the wifi connected at least!
I've ordered two of these (one -07 and one -01, not entirely sure of the difference yet) to play with since they're so cheap. It probably wouldn't be bad to do the wifi connection from a terminal before starting SLIP. It is basically an AT initialization command, like modems have...
If I load the SLIP firmware, I then need to configure it over SLIP, which isn't documented. The Arduino library does have this implemented, though, so we can copy that code into a quick RB app or similar.
The other option, of course, is to power it up, configure it with an Arduino, then swap back to the mac and start the SLIP connection. Ugly, but it would prove that the SLIP config works without too much effort!
I might pop the creator of the SLIP firmware an email to see if he can make us a build with AT and SLIP support, as I can't even get it to build as-is!
My modules just arrived today. I got a couple of both the -01 and -07 variants. One looks like it has an antenna printed on the PCB, the other is largely encased in a metal container, and has an antenna port on it.
I look forward to messing with them.
Having looked at this in a bit of detail now (and getting distracted with 'real life' and replacing capacitors on 4 old Macs (LC II, LC III, IIsi and 840av... I'm just over half done!) I think that software-wise, the best thing to do is implement my own SLIP server in lua on the nodeMCU firmware. For Mac->TCP connections it's just decoding the packet and sending it out, and for TCP->Mac it's the opposite.
In the mean time, I also bought a little case, some cables and other bits so I can at least make setting it up for testing a little easier/neater.
First test will be to check my assumptions about SLIP are correct by setting it up on a linux host and capturing the traffic. Then I'll move on to the NodeMCU side of things!
EDIT: Then I find out that packet forwarding on this thing is a little more complex that I envisioned...hmmm
I've worked a lot with the ESP8266 chips. They are nice, but very limited from a RAM and GPIO point of view.
If you haven't yet, the TI cc3200 series are great chips to look at, you get a full WIFI stack, full TCP/IP stack and a full Cortex-M4 core running at 80MHz with enough RAM and FLASH to run most things.
I was looking at the DIY localtalk to ethertalk bridge thread to potentially try and interface an SCC to the CC3200 but I see that there's still a big reliance on using the beaglebone to handle the ethernet side and packet forwarding.
Doing ethertalk framing over 802.11 has a bunch of problems, which is why only a limited set of 802.11b hardware works with it, and was later dropped entirely. These days, most wifi routers won't even pass non-ip traffic it seems. So if you're planning on using the CC3200's wifi capabilities in that way, it's something to consider.
The benefit of the BBB based project IMO is utilizing the localtalk interface simply as a high speed interface to all 68k macs, and not requiring any mac side software. There's certainly easier ways to bridge localtalk to ethertalk, but having a general purpose localtalk interface to a newer machine would give you IP capabilities with a MacIP router on the BBB. It'd provide storage expansion via AFP. The intersection of speed and compatibility is localtalk, I'm afraid.
Doing ethertalk framing over 802.11 has a bunch of problems […]
Ah, now this is something I did not know. Back when my newest machine was a CRT iMac with OS 9, I used to be able to run AppleTalk over my conical AirPort base station. It seamlessly bridged the wired and wireless EtherTalk connections and I never experienced any issues with it… of course, I didn’t exercise it very hard back then, either. What exactly were the problems you mentioned?
Yeah, interesting, it's been a while since I had to do any Ethertalk based work, it used to work perfectly on my old Aruba and Lucent access points so I never really paid much attention to how it was being framed, good to know.
I've got a few BBBs lying around and a couple of SCCs (PLCCs and PDIPs) available, sadly it seems the repository for that project is locked or non-functional.
There were quite a few wireless routers (acting as APs in this sense) that didn't work with AppleTalk. Apple's did, obviously, and I had good luck with Belkin routers, but Linksys routers usually just dropped EtherTalk entirely. Never did find out the problems. Do you have more info on what's broken about it?
I need to check out this chip (and the TI one), but there's also a good HiFlying chipset out there that should work for bridging LocalTalk and MacIP to the Internet and ideally LANs. It has a rather nice dev board for $60.
FWIW, my new-ish Airport (first GigE model) still bridges AppleTalk pretty well.