SEthernet: Modern, low-cost 10/100 Ethernet for the Macintosh SE and SE/30
github.com
github.com
If you're looking for WiFi, BlueSCSI v2 with a Pico W offers the possibility of emulating a DaynaPORT SCSI network card:
The irony is, I haven't built the SE version of the card yet, only the SE/30 version, because the day before the boards arrived, my SE's hard drive died. I've got a Wifi BlueSCSI on the way as a replacement, which makes the whole project slightly moot, but I'll be interested to see how they perform in comparison to each other.
I'm not expecting blisteringly fast speeds, especially not from the SE, but from what I've seen of DaynaPORT performance figures, I should be able to beat them by a decent margin.
It's still in very early development, I mostly put it up on github so I could show it to some friends and get some review on it - the 'revision 0' hardware in there was only ever intended as a minimum-viable prototype to prove the concept and let me get started on driver development.
As far as licensing goes, once it's more polished I'm planning on releasing it under some kind of open hardware license. I've no interest in making money off of it beyond hopefully selling a small run of them to recoup the cost of development. Right now, though, I'd strongly recommend against trying to build it or derive anything from it in its current state - the Revision 0 hardware was only ever intended as a minimum-viable product, it has a number of hardware bugs, and I may make some software-incompatible changes in the next revision.
Having said that, things are progressing well. Aforementioned hardware bugs aside, the initial bringup of the board was a success, it sends and receives packets as it should, but there's plenty on the to-do list for the next revision.
It's driver development that's the killer. The Classic Mac OS network stack is ... interesting ... I've got the basics all there, but it's very prone to dramatic and difficult-to-debug crashes at the moment.
The driver that's up on github is quite out of date, but my work-in-progress is an absolute mess of debugging code and commented-out bits, so it'll probably be a while before I get that cleaned up and published.
If anyone wants to know more, there's a sporadically-updated Twitter thread about it at https://twitter.com/halkyardo/status/1723914693595607525, and a more in-depth thread on 68kmla at https://68kmla.org/bb/index.php?threads/sethernet-and-sether...
The hard part is getting it to behave properly with Mac OS's 'interesting' and poorly-documented network stack.
Ironically, while I hadn't considered NetBSD, I do want to write a driver for it for A/UX - between the recent work that has already been done on A/UX drivers (https://github.com/SolraBizna/testc), and some reverse-engineering of its network code, I think it's well within the bounds of possibility, even with the original driver SDK being Lost Media.
Now, if i could just talk him into making some sort of mp3 player board.
If you do want an ethernet card with a pass-through slot, a fellow on the 68kmla forum is building such a device already: https://68kmla.org/bb/index.php?threads/fs-se-30-ethernet-ac.... His card is hardware-compatible with the Asante MacCon card for the SE/30, which is extremely neat, but requires sourcing no-longer-produced components in order to build it. The idea with my card is to build something with modern parts that are easier to find.
A far cry from the prices I remember them going for.
I wonder what that's referring to; the '8019 is quite common in a lot of other retrocomputing projects. One even showed up on HN not long ago: https://news.ycombinator.com/item?id=25293650
On the upside, that means that you can literally wire it up to the ISA bus with no glue logic, and basically any operating system that ever ran on a PC already has drivers for it. On the downside, the ISA bus is fairly tightly coupled to the x86 processor bus, which means additional glue logic is required to get it to talk to processors like the 68k. To contrast, the ENC624J600's host bus interface can be configured for x86 or 68k-like operation (in both 8 and 16 bit widths, or over SPI).
Incidentally, a lot of old Mac network cards also used the DP8390, but because they mapped their registers and buffer memory differently to the NE2000, the RTL8019AS's compatibility there is not much of a win.
The main 'glaring misfeature' is the fact that the DP8390 and its clones cannot recover from a receive-buffer overflow, you have to soft-reset the receive engine to restore operation, and doing so with a minimum of disruption seems to be tricky. The DP8390 datasheet describes this behavior as part of normal operation, but reading between the lines it's clearly a hardware bug that's being worked around. A lot of the NE2000 drivers I looked at also have a lot of unexplained dummy reads and no-ops around register accesses, which gives me the impression that there might be other quirks too - the RTL8019AS datasheet is extremely vague on the matter.
Additionally, the RT8019AS's buffer memory is only accessible indirectly through its registers, which is just plain annoying. In contrast the ENC624J600 exposes its buffer memory directly, behaving like a 32K SRAM with registers at the top of its address space.
FINALLY, the RTL8019AS does not have a factory-assigned MAC address - integrators are expected to provide their own, and some kind of persistent storage to hold it in. The ENC624J600 comes with a burned-in MAC under Microchip's own OUI, which for a project in this "low-volume but potentially building it for other people" realm, is a lot more convenient.
Having said all that, right now I'm getting mad at a glaring misfeature of the ENC624J600 - its lack of a hardware reset input. The only ways to reset it are by poking a register bit in software, or removing power, which means that if I warm-reboot the computer, I sometimes get a bunch of spurious interrupts from the NIC, causing the POST to fail and giving me a Sad Mac screen. To compound matters, the Mac OS does not seem to call the driver's Close entrypoint on shutdown, so I can't even use that as a chance to put the chip into a safe state.
I suspect I'm going to have to externally gate the interrupt line on reset until the driver gives some sign that it's alive and ready for interrupts.
https://sites.google.com/site/probehouse/how-to-network-an-a...
connection diagram https://github.com/EmmanuelKasper/ethernec/blob/master/ETHER...
Unfortunately all of Apple's documentation is written in such a way that to understand one section, you have to already understand most of the other sections, and you often find yourself having to cross-reference between sections to get the whole picture of what's going on. I've really struggled to make sense of the network driver especially - every time I think I've got it, I find some issue, dig a bit deeper, then realise that I missed something that is only vaguely mentioned in the docs and doesn't make sense until you know what you're looking for.
I should clarify, the SE/30's expansion slot is not NuBus in a physical sense - it's just a direct connection to the processor, plus a few control lines. It's just that the slot provides facilities to allow cards to behave like NuBus from a software perspective, which lets your drivers use all the same OS infrastructure for discovering hardware, dispatching interrupts, installing drivers etc.