• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

MacESP8266+

bdurbrow

Well-known member
OK, so I've been working on a design for a serial<->WiFi board (there's a thread over in The Lounge inquiring about how many people might be interested in such a thing); and as I've now got a preliminary layout; I figured I should start a development thread.

At the moment; what I've got on here is an ESP-12 module; a 3.3v regulator; and an ISL83490IBZ RS422 transceiver. Connection to the Mac is by a mini-din-8 socket; it's expected that you would use a cable (such as an ImageWriter II cable) to connect the board to your Mac. Power is taken from a pair of mini-din-4 sockets, wired as an ADB pass-thru. Either an ADB keyboard cable or an S-Video cable can be used to connect the board to your Mac for power.

There are headers for programming the esp8266; and a jumper set if for reversing the connected pins in case you have a straight-thru cable instead of a crossover cable. Also, unused pins from the esp8266 are brought out to a header pad for future expansion.

Not yet done is some provision for getting +5v to the board if you don't have ADB (like, say, a Mac Plus); and hooking up the handshaking lines from the serial port to the ESP8266. Also, no firmware has been written yet; however some research into libraries and protocols has been done.

Screen Shot 2021-08-14 at 11.43.03 PM.jpg
 

aladds

Well-known member
For what it's worth, I played with the "esp_slip_router" project and my Powerbook 540c a little while ago:


Note that this was just RS-232.

With no other software you'd certainly be able to use TCP/IP.

Can Netatalk speak ARA? If so that would offer a tunneling option and you wouldn't need to make the ESP speak Localtalk - otherwise you're looking at using an ARA server in Basilisk or Sheepshaver (or writing your own server!).
 

cheesestraws

Well-known member
Can I suggest that for localtalk purposes, a good intermediate stage would be to implement LToUDP? I am of course biased here because it is my own protocol/embedding, but it will be a lot simpler than implementing DDP on the ESP and bridging on it—and it's implemented in mini vmac so it should be pretty easy to test.
 

Crutch

Well-known member
This is a really cool project and I love it.

I am curious though, why use serial rather than SCSI? Is the idea that we could also use this on a 512k?
 

bdurbrow

Well-known member
LocalTalk connections switch the Mac's SCC into a mode that's not UART compatible; and the esp8266 only has a basic UART interface.

In order to do LocalTalk<->WiFi routing; I'd have to add another processor to it to do the LocalTalk to UART translation... at which point I might as well re-build the board design to use an ESP32 module; and probably the ESP32 would have to bit-bang the serial connection (I'd have to read more on the ESP32's serial capabilities to be sure).

Supporting AppleTalk would be possible with a driver on the Mac's side to send the AppleTalk packets out the SCC when configured as a UART; just as a driver for another network link card would do. Because writing such a thing is non-trivial; it's not going to be my initial target for the firmware of this project.

For now; that means this board is going to be an IP WiFi solution only.


I am curious though, why use serial rather than SCSI? Is the idea that we could also use this on a 512k?

Same problem as with LocalTalk; I'd have to add another processor to be the SCSI to UART interface; and I'd probbably want to go to an ESP32 as well for it's higher-speed IO. Also, I'd have to write a driver.

As for connecting it to a 512... I actually have a version of the board (MacESP8266 1.0b - note the lack of a plus, and the lower revision) that has a D-sub 9 connector on it, and unlike the plus version of the board has no need for ADB connections for power.

You'd need a pretty small IP stack & applications to use that on an un-upgraded 512, though...
 

bdurbrow

Well-known member
Right now... not that much. However, the design goals are:

  • Mac Focused.
    • This is actually a RS422 design, not a RS232; and uses the Mac native mini-din 8 serial connection.
    • It's flexible with regard to the cables you have on hand - you can use a crossover cable (such as an ImageWriter II cable) or a straight-thru cable.
    • Power can be supplied from the ADB port, and it includes a pass-thru ADB port so you don't lose one when it's in use (handy for PowerBooks). Alternately, you can supply +5v to a header on the board if you don't have ADB available (the Mac Plus comes to mind).
    • Accepts, out-of-the-box, the Mac's built-in IP networking (most of the other solutions that I've seen have been setup out-of-the-box for turning a RS232 port into a telnet connection).
  • Simple, low-cost BOM.
    • At the moment, the total (excluding parts shipping) is under $7 USD.

I don't know if I'll be able to write an AppleTalk forwarding driver for this... I haven't had a chance to read the relevant Inside Macintosh documentation yet. I'm hoping it's not too difficult... but I'll have to actually sit down and read it to be sure. It would be nice.

Look up "Sabina TCP", thought its website rather oversells its importance, IMO.

I had seen that... it was in the back of my mind when I mentioned a tiny one needed for a 512k.
 

bdurbrow

Well-known member
The more I dig into the low-level LocalTalk implementation; the more I realize that it's overly complex, abstracted, and underdocumented (at least now - information may have been lost to time; or Google has just decided that it's not interesting and so isn't going to show it). It's also turning out that the Zilog SCC has a bit more going on under the hood than the average serial port chip does...

No wonder TCP/IP won. 🤨

I have yet to find documentation for how to create a network driver for systems that don't have Open Transport. I know it's possible... there were plenty of networking products that did just that, back when these machines were new. I'm wondering if instead of putting the magic incantations in Inside Macintosh somewhere; the relevant engineers at Apple back then just directly told the companies that made those networking products how to do that.

For Open Transport, I think I spotted the right chapter; but as I haven't read it in depth yet I'm not 100% sure.

Also, ESP32s seem to be more expensive than they had been... I'm thinking I'm going to just put pads for a low-cost SAMD21 processor in a QFP package on the board; in case I do try to implement LocalTalk decoding. Adding it with jumpers for the UART lines means that it can easily be added to an unpopulated in the future.

🤔
 

cheesestraws

Well-known member
The more I dig into the low-level LocalTalk implementation; the more I realize that it's overly complex, abstracted, and underdocumented (at least now - information may have been lost to time; or Google has just decided that it's not interesting and so isn't going to show it). It's also turning out that the Zilog SCC has a bit more going on under the hood than the average serial port chip does...

It's just SDLC. Don't let the jargon confuse you. There's a load of sample code in Appendix A of Inside Appletalk. But as far as I know the only wrinkle is in how the clock is managed, and the tightness of the timeouts. It really isn't complicated at all.

In fact, the major issue I've always had when trying to implement it is that it is less abstracted than the IP/Ethernet combination (or indeed, the DDP/Ethernet combo)—if LocalTalk had the distinction between layer 2 and layer 3 rather than DDP and LLAP awkwardly sharing headers, life would be somewhat easier...

No wonder TCP/IP won. 🤨

DDP is simpler than IP is by a considerable margin, so I'm not sure entirely what you mean here, largely because the internetworking in DDP is not really very much of a thing.

I have yet to find documentation for how to create a network driver for systems that don't have Open Transport. I know it's possible... there were plenty of networking products that did just that, back when these machines were new. I'm wondering if instead of putting the magic incantations in Inside Macintosh somewhere; the relevant engineers at Apple back then just directly told the companies that made those networking products how to do that.

There was a document distributed by Apple DTS called, I believe, the AppleTalk Connections Programmers Guide. Several of us have been looking for a copy for multiple years. As far as anyone knows that's the only documentation that there is. bbraun has a couple of reverse-engineered adev/atlk drivers that I used when I was playing with building one, and there's a couple of other "dummy" type drivers out there as well.
 
Last edited:

bdurbrow

Well-known member
Well… for me, Google has been spitting back lots of information about what SDLC is and how it fits into the overall IBM network architecture, but rather little on how it actually works on the wire. Perhaps your Google profile is more cooperative?

If you’ve got any links, either to documentation, or code, I would be most appreciative… :)

DDP is simpler than IP is by a considerable margin

Eh… might just be experience coloring my view there.
 

cheesestraws

Well-known member
If you’ve got any links, either to documentation, or code, I would be most appreciative… :)

What kind of code are you looking at? Stuff for pulling the bits off the wire, or for parsing the SDLC/LLAP frames? I have some of the latter in Go, if that helps, though it's really rather rudimentary...

The main reason AppleTalk I think looks alien to people who are used to IP is how deeply the notion of service discovery is baked into the protocol stack. IP is very bad at service discovery, and mDNS, which attempts to remedy this to an extent, is almost a reimplementation of AppleTalk's service discovery logic on top of IP multicast. So if you're familiar with mDNS, the logic should at least be reasonably comprehensible.

The other reason, I suspect, if you've skimmed Inside Appletalk, that the protocol stack looks very big and bloaty is that that book actually covers everything from the electrical signalling on the bus all the way up to the major application protocols, which is a very large scope.
 
Last edited:

cheesestraws

Well-known member
Frame decoding and packet wrangling

Here's my toy LLAP stuff, which is optimised for clarity. This is based on the first chapters of Inside Appletalk and, inasfaras it goes, has been interop tested with Systems 6 and 7 (in Mini vMac). But it is only a toy.


@sfiera implemented LToUDP (so, again, LocalTalk logical framing, but not the physical layer) independently and built a bridge between it and EtherTalk:


There's also some LLAP code in Elliot Nunn's brilliant netboot hacking (to get machines netbooting over LocalTalk!) though it's a bit application-specific:


bbraun's abridge code may also be helpful, though that is more aimed at backhauling DDP packets over TCP than anything else.


Physical layer

Here I am more out of my depth; that Zilog technote that I think you mentioned goes into horrifying detail, but much of it isn't relevant except if you're actually using an SCC.

@tashtari was working on a LocalTalk to I2C transceiver in a PIC, though, and I think this is the code for that (they can correct me if I'm wrong): https://github.com/lampmerchant/tashtalk

@saybur also had some ideas that they sent to me ages ago and I did precisely nothing with

Hope some of this is useful....
 
Last edited:
Top