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.
Wow, huh, that's me! A friend told me I'd gotten mentioned here so I thought I'd drop in and offer some explanation, hope that's okay!
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.
That's not a bad idea, but the 'interacting with the hardware' part of writing a driver has actually been a breeze - within a few hours of building the card, I'd thrown together a test harness that was able to send and receive packets.
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.
Ha, the pass-through version is possibly a long ways off. I had grand plans but the mechanical considerations mean that there will probably have to be a few trial-and-error revisions before I get it right.
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.
This sounds promising and I'll almost certainly be interesting in buying an assembled version. I've been trying for years to grab one of the Asante cards that work with the SE/30, but the only one I saw got snatched up before I could make a bid.
That was exactly my motivation for the project! 12 or so years ago I had a pretty big vintage-Mac collection that I had to give away in a house move. A friend gave me an SE/30 a while back, which got me back in the game, and my first thought while looking for an Ethernet card for it was "they want HOW much???"
A far cry from the prices I remember them going for.
has a straightforward software interface without any glaring misfeatures (I'm looking at you, RTL8019AS)
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
I was a little bit tongue-in-cheek in saying that, but the RTL8019AS definitely does have its downsides - being a single-chip clone of the NE2000 ISA ethernet card means that it's got to be bug-for-bug compatible with the ancient DP8390 chipset that those cards used (or at least a subset thereof).
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.
How does one figure out how to interface with these vintage systems? For example, how does one figure out that the expansion bus on a Macintosh SE uses NuBus, then how to expose a modern microcontroller on this bus, and then how to write a declaration ROM or software driver for a 40 year old network stack? Where does documentation for these systems live on?
Thankfully, folks have archived a lot of Apple's old developer documentation: https://vintageapple.org/inside_o/ is an invaluable resource, as is the mirror of the (late-1990s?) Apple developer website at https://dev.os9.ca/. On the hardware side of things, Designing Cards and Drivers for the Macintosh Family and Guide to Macintosh Family Hardware in conjunction with the 68030 user's manual, tell you basically everything you need to know. For software, Inside Macintosh is your bible.
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.
having tried this with those kind of machines.. network activity works very well, but the speed of handling JPEG once it arrives will be disappointing. Interesting as a non-trivial network client in modern times!
You are not owed a license. You are not owed neither software nor hardware. If you don't like it, re-create all the work, but don't plagiarize, and release it under whatever open source software you want.
Half the time people with new projects just forget to choose one. He could put up a completely non commercial license if he wanted. It doesn't even have a copyright notice right now, making simply overlooking that so far the most plausible explanation.
That's correct; it's far from finished - I just chucked it up on Github to show it to some interested folks and get some review on the design. Didn't expect it to actually get attention.
The plan is that once it's working to my satisfaction, I'll do a small production run and release the designs under some kind of open hardware license. I'm not particularly interested in making money off it beyond covering my costs.
Your initial statement kinda reminds me of those hobby game development projects that get stuck at choosing an engine/tooling and never build an actual game.
If you're looking for WiFi, BlueSCSI v2 with a Pico W offers the possibility of emulating a DaynaPORT SCSI network card:
https://bluescsi.com/docs/WiFi-DaynaPORT