I'm about to come into possession of a Powerbook 180c, and going through the dev notes of the Powerbook 160/180, I see specs for an SPI modem including the pins for the modem interface. Perhaps this discussion belongs more in Software Hacking, but does anyone know the software interface for this? Is it perhaps just the same as the UART interface for the internal modem, just faster?
I ask because I'm considering making a WiFi adaptor for PowerBooks. My initial inclination was to make a dongle that was LocalTalk compatible and had a MacIP router built in using something along the lines of an LPB200 (http://gridconnect.com/wifi-module-low-power-and-flash-memory.html) with a custom LocalTalk adaptor and software stack, but it's a little more efficient to use the SPI interface instead. It'd still need some custom software work on both the Mac and ARM to make AppleTalk work, but it's tempting.
Anyway, anyone got a clue on the SPI interface, or was it just quietly orphaned by Apple with no documentation?
I'm not familiar with the SPI variant of the modem interface on these machines. Pretty much the fastest, most compatible approach to extending these machines is going to be using localtalk. The other modem/serial interfaces go through the SCC, and the Serial driver will generate an interrupt per byte which is crazy expensive on these machines. Even more so on some of the older machines running in 32bit mode, and the drivers were 24 bit, which would cause a mode switch and cache flush on every byte (I think the pb140/170 era is where this was the biggest problem). The localtalk interface knows what data to expect, so would poll in each packet in a tight loop with interrupts disabled rather than interrupt for every byte. They also threw in some extra code in to handle mouse updates and keep the floppy drive fed with data to make the machine appear responsive while interrupts were disabled.
The AV machines and then powermacs would introduce a DMA capable serial controller and driver which wouldn't interrupt on every byte, which had a host of compatibility problems and a way to throw the controller back into the old mode for compatibility.
LocalTalk is definitely my backup plan. It's worth noting that the modem port at least on the 140/170 connects to the SCC (via the original modem port lines switched out), though it's not clear to me whether I'd be able to convince the OS to talk LocalTalk when it detects a modem card inserted (I don't have the machine yet, but I'll definitely try).
The 180 tech note says there's ROM support for the SPI interface, though I probably won't have much time to disassemble that any time soon (I have a second child now, and the interrupt overhead is staggering). In any case, an SPI interface would indicate that they're expecting high bandwidth, so presumably we're not talking one interrupt per byte.
LocalTalk is probably the most compatible with everything, in any case, and a dongle would allow me to get wireless even on very old Macs (similar to the SCSI Ethernet adaptors).
The internal modem pinout on the pb1XX is in the developer notes, And it goes back to the SCC....
So if you can make a bluetooth or wifi device emulate a modem, or write a custom driver that will communicate with the device via the modem port internally, then itll work fine.
I know you can get wifi and bluetooth chips these days that will operate over standard UART pins, and that would be the best way to go. But.. the interface in RS232 mode is kinda slow, it tops out at what, 57.6K on these machines? I dont remember.
Indeed, the tech notes are where I'm getting the pinouts. It goes directly back to the SCC (there's no other serial hardware on most Macs, after all), but what's unclear to me is whether the standard OS hardware will let me do LocalTalk on the modem port if it detects a modem inserted (my recollection is no, but I didn't have much experience with the 68k PowerBooks; they were too expensive for me to have access to back in the day). I'll have a better idea tomorrow when I actually get the machine in my hands, though I'll be on the road and I don't know what system version it comes with.
In any case, LocalTalk would probably be the most compatible option, especially if I wanted to develop a dongle version of the same concept (the wireless module comes with a full LwIP stack, so it seems silly not to make it a MacIP router as well; the challenge will be adding LocalTalk<->EtherTalk bridging on the module, a la the Asante bricks). Doing it over standard async serial would, like bbraun suggests, be a tremendous effort in terms of development and interrupt overhead.
If there's any documentation at all available for the SPI interface, though, it would be nice to implement it as an option for PB180/165 and higher. It's much more suited to the application, and the pins just mux over the standard serial pins; I have to make a custom CPLD for UART->SDLC translation anyway for LocalTalk communications, and adding in the routing to SPI pins is trivial (helpfully, this particular wireless module's UART2 data and flow control pins mux to the SPI interface as well, which helps with pin count).
There is another thread here that SDLC/localtalk/ethernet bridging was done on a beaglebone i believe. Not sure if you had seen that already, but it might be worth taking a look at since all the hard work was done on LLAP and SDLC framing, etc...
I saw that, but I've no interest in doing it on a BeagleBone. I've worked with HDLC/SDLC framing on CPUs and FPGAs for nearly the past decade, so I'm not overly worried about the low-level details, and the LLAP business is pretty clearly laid out in Inside AppleTalk (of which I have both a digital and dead-tree version). The more interesting bit is MacIP, which is a pseudo-standard at best (there is a draft RFC that was never ratified, which is probably the best guide).
The easiest way to do the Layer 1 for LocalTalk without going crazy with interrupt overhead on the microcontroller should be a flow-controlled DMA'd UART on the micro (at a relatively high speed compared to LocalTalk, say 500kbps) and a small CPLD to translate the SDLC Layer 1 to UART framing. That can interface quite nicely directly to the micro on the wireless (which is already a 200 MHz ARM Cortex-M3, so already somewhat faster than the machines it'll be talking to). The CPLD can handle the transaction-level layer 2 stuff as well (in/out of sync, missed clock, about 3/4 of the stuff the SCC does), and the FIFOs and DMA engine on the micro can handle the traffic a lot better than bit-banging SDLC.
If I can get the SPI interface to work, though, that should allow for an additional, much more efficient interface to transfer data (though it probably won't be LocalTalk, and thus will probably require considerable driver development on the Mac side). I'll be receiving the dev kit for the wireless module soon, which provides a nice external port that I should be able to interface pretty cleanly to the modem card port with a paddle board. The SDK it comes with seems pretty nice so far!
Well, having played with the 180c a bit, I realized that I had forgotten than non-Open Transport Appletalk only likes to use the printer port. I'd rather not require OT, especially for 68030 machines. I'll have to think about it a little more.
Well, I answered my own question a bit... I recalled that the source code for System 7.1.1 (or at least ROM from around that time) had leaked a while back, and I figured if it was going to be documented anywhere, it might be. Turns out there is some SPI code buried inside the Internal Modem Manager I/O primitives:
It doesn't look terribly efficient, though; it uses a subroutine to receive each byte because it has to toggle req/ack bits in the SPI controller for each byte. I'll have to look a little closer, but it's at least an interesting read, and probably something that could at least be patched for specific purposes.
And, actually, I think I was looking in the wrong place. The "Optimus" modem is probably for something else; the Powerbook 180/165 ("Dartanian") SPI routines are actually hacked into the Power Manager driver, which I realized when the "prime" routine for the "Baby Rock" modem just jumped to _PMgrOp. See the "DartSPI" routine:
Presumably it's here because... actually, I'm not sure, other than possibly because the 180/165's SPI controller is stapled onto the Miscellaneous GLU chip, according to the tech note. More detail can be found referencing the "Ponti" ASIC in various places, particularly here:
Looks like that's just the code name for the Niagara's GLU register unit, which (matching with the tech note) includes various GPIO, PWM for the backlight, the SPI and the sound power control. It's a bit of a mess; "PontiSndSPIIrqMsk" is not a thing I'd like to have seen, but there we are.
The curious thing about the SPI interface, as far as I can tell, is that the modem is the SPI master, not the host. The host raises an interrupt when it has data to send, and the modem pulls it out.
Anyway, for the most part, the SPI controller registers look about the same between the PB 180 and the "Optimus" (the modem is variously represented as "Optimus", "3615", and "Express Modem", some of which shows up mysteriously in the Express Modem drivers, but I don't know what product if any it eventually became.
I guess the other good news is that the driver pretty much just takes care of the SPI data transfer so it's transparent to the user; it's the same to e.g. a terminal program as if it were a regular internal modem. The bad news is that the data rates are probably not gonna be that great because there's no FIFO AFAICT and there's quite a bit of overhead in the read loop. Compounding this, the Dartanian version doesn't seem to poll for SCC data while reading, though it's not yet clear if interrupts are disabled when it's doing that. So that could be interesting.
Now to figure out how the Internal Modem Manager works...
OK, so from everything I've seen, SPI is actually the normal way the Apple Express Modem for the PB165/180 connected. The data and command flow is, in fact, routed through undocumented commands to the Power Manager (what a bizarre and ugly hack, but I guess I kinda understand it?). As far as I can tell in the System 7.1 sources that are out there, that's about where OS support for it stops; after that, the Express Modem CDEV provides the driver for the Comm Toolbox to make it look like a serial port to software using the Comm Toolbox. Woof.
Alas, the source for the Express Modem control panel doesn't seem to be available anywhere, which means it'll be time to poke around with MacNosy soon to figure out exactly what it's doing. There are a number of commands that go through the Power Manager which get written directly to SPI that I have no clue about (read/write registers, DSP tables, etc.) if I wanted to make an internal Ethernet/WiFi board using something like an ESP32. That's entirely ignoring the Ethernet driver which would need to be written, which is its own concern... does anyone know of sources for an Ethernet DDK for Classic Mac OS?
Looking at how the system does it for the Blackbird (PB500 series), though, it made me curious; the thing is memory-mapped. I went back and looked at the PB500 tech note and geez, the modem slot is actually an entire coprocessor-capable PDS slot. That's insane.
The expansion in the battery bay is also ANOTHER PDS slot, albeit an '030 PDS much closer to the LCIII-PDS slot in functionality.
Of course, the PB500 already has Ethernet, and it also has a PCMCIA adaptor for the battery slot which could conceivably host a (non-CardBus) WiFi card, so it's a much less interesting target. But it does make for some very interesting other expansion possibilities.
My uncle worked on the Blackbird project (I think he created the video IC, put in the special mode to allow for 16-bit color at reduced resolution just because he could), and it seems full of the sort of things he would have put in just because he could; I imagine much of the team was as crazy as him.