• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

SEthernet and SEthernet/30: A new take on PDS Ethernet

halkyardo

Well-known member
In the decade and a half between giving away my old SE/30 while moving house, and acquiring another one, I seem to have misplaced the ethernet card that I used to have for it. Having gotten a pretty severe case of sticker shock looking at what they go for on eBay these days, I have embarked on a foolish course of action. While a normal, reasonable person would buy something like a PiSCSI (hot damn, BlueSCSI does WiFi now??!) or @Bolle's extremely neat PDS combo card, I have gotten it in my head to design an all-new card based on a modern embedded ethernet controller. Mostly just to see if I can actually do it.

I've come up with a design using the Microchip ENC624J600 (try saying that quickly), a basic all-in-one 10/100 ethernet controller that's targeted at the embedded market. Its smaller, more popular cousin, the ENC424J600, supports SPI and a multiplexed 8-bit bus, but the '624 adds a non-multiplexed 16-bit bus mode that looks like it'll play nicely with the 68k with only minimal glue logic. I'm targeting the SE/30 and SE, just because they're the machines that I happen to own, but if this works it should also be easily adaptable to other 68k PDS slots, and (not so easily) to NuBus.

I noticed that a similar project from a few years ago to build a card based on the LAN9218 seems to have stalled at the stage of writing a driver, but working in my favour is the fact that since then, permissively-licensed source code for a Classic Mac OS ethernet driver has been published, which should hopefully make driver development a bit less of a challenge. Incidentally, I came across that project while considering the LAN9218 for my own, but the ENC624J600 is substantially cheaper.

At this point, I've got "Revision 0" schematics and boards done, with the glue logic and declaration ROM in sockets to ease the inevitable bodge-and-bugfix process. While I'm waiting for the boards to arrive, I've got the glue logic and what should be a mostly-functional driver bashed out. The plan is that I'll try to bring the SE card up first, since the 68000 requires basically no glue logic to talk to the chip. Once that's functional, I'll move on to the somewhat more complicated SE/30 card.

My current work-in-progress is at https://github.com/rhalkyard/SEthernet, though in its current state you'll probably have to be fairly in tune with my thought patterns to follow along. While eagle-eyed observers will note that I have a VGA socket on my breakout board, my plans to build a PDS-passthrough version of the SE/30 card are on hold until I either rethink my entire routing and layout strategy and/or move to a 4-layer board.

I should caveat all this by saying: I'm a software developer by trade (albeit one who works on Ethernet drivers), and my electrical engineering skills are very much in the "enthusiastic amateur" category, so I'm sure I'm committing all kinds of board-layout sins and violating the Ethernet standard in many exciting ways. My main criteria for success here is "sends and receives packets and doesn't catch fire," but if there are ways I can achieve that while also following better practices and potentially not radiating egregious amounts of EMI, I'm all ears.

Once I get the project to a state I'm happy with, I'd be open to the idea of a small production run if folks are interested, but that will probably be a ways off yet, and I imagine that with devices like PiSCSI and BlueSCSI v2 emulating SCSI ethernet adapters, this probably has an even more niche appeal than most retro hardware. As far as cost goes, I'm shooting for "significantly less than a real vintage SE/30 card" and the BOM cost definitely makes that feasible, but I haven't thought much farther than that at this point. Anyway, if anyone has any comments, criticisms, encouragement, etc. I'd love to hear it!
 

Attachments

  • se.pdf
    199.5 KB · Views: 11
  • se30.pdf
    287.4 KB · Views: 14
  • 1699846634615.png
    1699846634615.png
    267.2 KB · Views: 80
  • 1699846772756.png
    1699846772756.png
    391.9 KB · Views: 78
  • 1699846809752.png
    1699846809752.png
    568.4 KB · Views: 85
  • 1699846837215.png
    1699846837215.png
    383.1 KB · Views: 79
  • 1699846875325.png
    1699846875325.png
    107 KB · Views: 79

Mk.558

Well-known member
I forked over one hundred and fifty bacon cheeseburger frosties for an Asante MacCon card just recently, mostly for the daughtercard that has 10BASE-T on it. I winced.

Love the work. Since you have some experience with ethernet drivers, I would like prod you about a similar issue:


I believe the future of ethernet across all our machines would be a replica of sorts of the fabled (and often troublesome, particularly with DNS in my case, causing bombs) Farallon EtherWave Mac/PB adapter (AKA Printer Adapter). If we can figure out some way to pipe TCP traffic and AppleTalk traffic through at nearly 100KiB/sec over a serial port, I would be extremely elated. Considering that a typical SE/30 can crack about 200KiB/sec over EtherTalk, ish, pushing good numbers over a serial port would be a more or less universal solution. Later macs can push double that, but when was the last time you saw an UltraDock 16sce for a PowerBook Duo come around for sale?
 

superjer2000

Well-known member
This is awesome! I don’t think SCSI Ethernet can touch the speed of a card based solution and SCSI Ethernet remains a bit more flaky (although that’s in comparison to the reliable drivers for presently available Ethernet cards- this project is a bit nascent to conclude there). I would be interested in both the SE and SE30 cards.
 

Melkhior

Well-known member
I have gotten it in my head to design an all-new card based on a modern embedded ethernet controller. Mostly just to see if I can actually do it.
Beware that rabbit hole, soon you'll be trying to maintain several different versions :)

(...)it should also be easily adaptable to other 68k PDS slots, and (not so easily) to NuBus.
I noticed that a similar project from a few years ago to build a card based on the LAN9218 seems to have stalled at the stage of writing a driver
The driver is the big thing, yes. I've also been considering Ethernet (similar reasons), but in my case I'm using Litex' own MAC and an external PHY connected via some variant of MII. But the software is the issue :-( I've also discussed the possibility of using some modern variant of the DP8390 to avoid rewriting software, but it didn't work out (the driver expects the buffer SRAM to be memory-mapped somewhere, but the modern integrated chip doesn't expose them).

but working in my favour is the fact that since then, permissively-licensed source code for a Classic Mac OS ethernet driver has been published,
Hehe, I knew I wasn't the only one that would be interested in that source code :) Thanks again to Glenn for publishing them.

the ENC624J600 is substantially cheaper.
Yes, around 5€ Qty1 is cheap. Also it's 5V-tolerant! So no need for expensive level shifters like my CB3T... I looked a lot for a chip like that on Mouser and somehow didn't find it.
And now I have a new rabbit hole to explore :)

I've got the glue logic and what should be a mostly-functional driver bashed out
That's excellent! Given the chip seems to simply be memory-mapped, it should just be a matter of 24 vs. 32 bits and the DeclRom to adapt the driver to a different bus.

Once that's functional, I'll move on to the somewhat more complicated SE/30 card.
I have a feeling I will soon try and see if I can fit a similar setup in my IIsi PDS adapter :) Hope that's OK with you?

move to a 4-layer board.
That one. Uninterrupted ground and power planes, still two layers fully available for routing. And it's not that much more expensive than two layers if you build your board at a cheap place like JLCPCB. Do yourself a favor and simplify your life, the extra cost is worth it IMHO.

Anyway, if anyone has any comments, criticisms, encouragement, etc. I'd love to hear it!
Adding (cheap) networking to old Macs has been in the air for a while, including the project you mentioned, my own ideas with the *FPGA, @Bolle 's recreation of old devices, Garrett's Workshop concept for a NuBus WiFi card, etc. The driver is the primary issue, so someone with experience there is exactly what the doctor ordered :)

Really looking forward to this, and perhaps to leverage your driver work on other busses :)
 

halkyardo

Well-known member
I believe the future of ethernet across all our machines would be a replica of sorts of the fabled (and often troublesome, particularly with DNS in my case, causing bombs) Farallon EtherWave Mac/PB adapter (AKA Printer Adapter). If we can figure out some way to pipe TCP traffic and AppleTalk traffic through at nearly 100KiB/sec over a serial port, I would be extremely elated. Considering that a typical SE/30 can crack about 200KiB/sec over EtherTalk, ish, pushing good numbers over a serial port would be a more or less universal solution. Later macs can push double that, but when was the last time you saw an UltraDock 16sce for a PowerBook Duo come around for sale?
There's a lot to be said for LocalTalk - it's universal, you don't need much hardware to interface to it, and it Just Works. I've heard of the mythical EtherWave printer adapter but I've never gotten my hands on one. LocalTalk drivers are a bit of a different beast, but now I'm curious as to what Farallon did on the software side to speed things up. I might just have to take a look at that driver...

This is awesome! I don’t think SCSI Ethernet can touch the speed of a card based solution and SCSI Ethernet remains a bit more flaky (although that’s in comparison to the reliable drivers for presently available Ethernet cards- this project is a bit nascent to conclude there). I would be interested in both the SE and SE30 cards.
Thanks! Yeah, the drivers are a big "if" at this stage, but certainly I'd like to get it to the point where it works as well as the original. I've also been doing some reverse-engineering work on the A/UX kernel and network stack, and while it's a long shot, I don't think writing new network drivers for A/UX is quite as impossible as it's been believed to be. Once I get it working and stable on Mac OS, I'm at least going to make an attempt at an A/UX driver.

The driver is the big thing, yes. I've also been considering Ethernet (similar reasons), but in my case I'm using Litex' own MAC and an external PHY connected via some variant of MII. But the software is the issue :-( I've also discussed the possibility of using some modern variant of the DP8390 to avoid rewriting software, but it didn't work out (the driver expects the buffer SRAM to be memory-mapped somewhere, but the modern integrated chip doesn't expose them).
Before I discovered the ENC624J600 I had come up with a whole design based on the RTL8019AS for that same reason - my original plan was to adapt Glenn's code to its "access buffer memory through a register" model, while leaving the rest of the hardware semantics unchanged. But that looked like it was going to be a pain, and if I have to write a new driver, I might as well write one for a modern chip.

Hehe, I knew I wasn't the only one that would be interested in that source code :) Thanks again to Glenn for publishing them.
Without his source code I don't think I'd stand a chance! There are a lot of subtleties to the receive callback mechanism (and then the subsequent callback-within-a-callback that occurs back into the network driver), and it's one of those all-too-frequent situations where Inside Macintosh technically gives you the information you need to know, but you have to make a connection between bits of partial information scattered across 4 different chapters, AND even when you put that together it's still so vague that you don't make sense of it until you look at an actual code example. I'm still not entirely sure if I've got it right, but I based my driver very heavily on Glenn's code, so it should be at least close.

If you're interested in network drivers, the leaked source of the 'SuperMario' Quadra ROMs contains drivers for the MACE and SONIC ethernet controllers. It's all in 68k assembler and fairly convoluted, but it's very heavily commented.

That's excellent! Given the chip seems to simply be memory-mapped, it should just be a matter of 24 vs. 32 bits and the DeclRom to adapt the driver to a different bus.
Hmmm, that's a good point. I hadn't given any thought to the 24 vs. 32-bit side of things. On the SE of course it's always 24-bit and the chip base address is hard coded. On the SE/30 I'm using dCtlDevBase to determine my base address using the Slot Manager. I'd assumed that that would return a 24 or 32 bit address depending on which mode the system was in, but I might be wrong about that!

I have a feeling I will soon try and see if I can fit a similar setup in my IIsi PDS adapter :) Hope that's OK with you?
Please do! I'm doing this because it's fun - if you can also have fun with it, that's even better. In theory my SE/30 board should physically fit in a IIsi, but I have no IIsi to test with, and of course it lacks provision for an FPU. If you can fix that, I'd be thrilled!

That one. Uninterrupted ground and power planes, still two layers fully available for routing. And it's not that much more expensive than two layers if you build your board at a cheap place like JLCPCB. Do yourself a favor and simplify your life, the extra cost is worth it IMHO.
Definitely a lesson learned there. All my previous hardware projects have been for 8-bit machines, and it's funny how routing becomes a lot more of a challenge when you've suddenly got twice as many address and data lines going everywhere!

Working around those through-hole PLCC sockets in particular was a nightmare. Once I've confirmed that my GAL equations are right, and written a tool to reprogram the declaration ROM in-system, I think I'll redo the layout without sockets.

Adding (cheap) networking to old Macs has been in the air for a while, including the project you mentioned, my own ideas with the *FPGA, @Bolle 's recreation of old devices, Garrett's Workshop concept for a NuBus WiFi card, etc. The driver is the primary issue, so someone with experience there is exactly what the doctor ordered :)

Really looking forward to this, and perhaps to leverage your driver work on other busses :)
For that exact reason, I've tried to structure the driver to be fairly device agnostic, and written for code clarity over optimization. If it works, I thought it might be useful as a template for other network drivers - for cards whose drivers are lost, or new hardware entirely.

By the way, your FPGA projects have been both an inspiration and a source of very useful information for me in designing this! I haven't ventured into the world of FPGAs yet, but your boards look like a wonderful platform for experimentation.
 

cheesestraws

Well-known member
There's a lot to be said for LocalTalk - it's universal, you don't need much hardware to interface to it, and it Just Works.

Unfortunately it also goes through the SCC which has an absolutely miniscule FIFO, so it slows the whole of the rest of the machine down to a crawl. I like LocalTalk a lot, but it's not going to produce something terribly usable to try to turn it into Ethernet by clocking the SCC faster: all that means is that the SCC will eat even more of the CPU than it already does, which isn't great for interactive latency.

I don't think writing new network drivers for A/UX is quite as impossible as it's been believed to be

It's really not hard at all. The lack of documentation is a bummer but you have debug symbols in the kernel, and there are skeleton drivers out there these days. Armed with Ghidra or similar, you are in with a chance. I was really pleasantly surprised while writing my framebuffer/VNC module, it was much simpler than I expected. I'd encourage you to have a go :)
 

halkyardo

Well-known member
It's really not hard at all. The lack of documentation is a bummer but you have debug symbols in the kernel, and there are skeleton drivers out there these days. Armed with Ghidra or similar, you are in with a chance. I was really pleasantly surprised while writing my framebuffer/VNC module, it was much simpler than I expected. I'd encourage you to have a go :)
Yes, precisely! On that note, I ran across https://github.com/neozeed/aux2, which from what I can gather, seems to be partial source for the A/UX 2.0 kernel, and the example driver that came with the Driver Developer Kit.

Even more interestingly for my purposes, the source includes most (but not all) of the ae6 ethernet driver. Given that the ethernet driver interface looks more or less the same as on any other old Unix, and doesn't feature the callback hell of the Mac OS drivers (where you don't just have to call into user-provided callbacks, you have to provide your own callback for those callbacks to call), part of me even wonders if it'd be easier to get it working there than on Mac OS!
 

Melkhior

Well-known member
Hmmm, that's a good point. I hadn't given any thought to the 24 vs. 32-bit side of things
I must confess I've consistently ignored it for the *FPGA - 'Goblin' is a 8 MiB framebuffer, it won't fit in the 1 MiB of slot area available in 24-bits mode anyway... Even moreso for the 240 MiB memory expansion in the IIsiFPGA :)

Please do! I'm doing this because it's fun - if you can also have fun with it, that's even better. In theory my SE/30 board should physically fit in a IIsi, but I have no IIsi to test with, and of course it lacks provision for an FPU. If you can fix that, I'd be thrilled!
And I don't have a SE/30 :) I've done my own PDS adapter already (PLCC and PGA with an optional clock for an asynchronous FPU), so it's a matter of adding the Ethernet hardware (easier said than done!). Unfortunately, the pass-through of signals + the FPU are taking up a lot of the routing space already...

Working around those through-hole PLCC sockets in particular was a nightmare. Once I've confirmed that my GAL equations are right, and written a tool to reprogram the declaration ROM in-system, I think I'll redo the layout without sockets.
I don't have a programmer for PAL/GAL, so I'm thinking going overkill and using a XC9536XL (Xilinx CPLD, 5V tolerant) and program it using JTAG. I've used a XC9572XL in the first iteration of the NuBusFPGA, and couldn't get rid of it soon enough :) and yet I'm back at it as they are pin-rich, versatile, and I do already own the JTAG programmer...
 

halkyardo

Well-known member
Armed with Ghidra or similar, you are in with a chance.
That reminds me! I hacked up a copy of Ghidra to (semi-) properly load and relocate A/UX's big-endian COFF binaries (it only supports a limited set of relocations, and still sometimes gets them wrong for data segments for some reason, but it gets code mostly right). I probably completely broke it for all other purposes in the process, but if that's of interest to you or anyone else, I've stuck it up on github at https://github.com/rhalkyard/ghidra/tree/aux-coff-hack.
 

cheesestraws

Well-known member
Yes, precisely! On that note, I ran across https://github.com/neozeed/aux2, which from what I can gather, seems to be partial source for the A/UX 2.0 kernel, and the example driver that came with the Driver Developer Kit.

Oh, that's a good find! I've been going from the 0.7 code and Ghidra and hoping things line up. A bit of a newer kernel would be nice...

Given that the ethernet driver interface looks more or less the same as on any other old Unix, and doesn't feature the callback hell of the Mac OS drivers (where you don't just have to call into user-provided callbacks, you have to provide your own callback for those callbacks to call), part of me even wonders if it'd be easier to get it working there than on Mac OS!

Probably! The bits of A/UX that aren't related to the Mac world are pretty much a straight down the middle UniPlus UNIX port, as far as I can see. It's not really remarkable or unusually structured. And even if you want to do stuff to the Mac world, even that isn't that hard. It's gained this weird reputation as being esoteric and impenetrable, but it's really rather conventional at its core. MacOS drivers on the other hand are an exercise in applied pain...
 

halkyardo

Well-known member
I don't have a programmer for PAL/GAL, so I'm thinking going overkill and using a XC9536XL (Xilinx CPLD, 5V tolerant) and program it using JTAG. I've used a XC9572XL in the first iteration of the NuBusFPGA, and couldn't get rid of it soon enough :) and yet I'm back at it as they are pin-rich, versatile, and I do already own the JTAG programmer...
I almost decided to go with a CPLD, both to condense the two GALs necessary for the SE/30 down into a single chip, and to allow for reprogramming in-place, but decided against it just because I'm familiar with GALs and don't have a JTAG adapter.

I might reconsider that for future revisions though - the other benefit being that if it can all be programmed in-place, I can use JLC's assembly service and redesign the whole thing around smaller components than my shaky hands can solder! Would definitely be the way to go for building them in any kind of quantity.

Might also go the CPLD route if the SE/30 version ends up needing wait states. My back-of-a-napkin timing analysis makes me think it'll be OK (although back-to-back accesses might be cutting it a bit close), but having only built hardware for 8-bit systems before, I've never really had to think about timing before, and could be wildly wrong!
 

Melkhior

Well-known member
I can use JLC's assembly service and redesign the whole thing around smaller components
Bit of advice, try that, you'll save yourself a lot of space and efforts. My usual technique now to optimize cost of JLCPCB SMD assembly service:
(a) figure out the critical parameters for the part, excluding footprint
(b) look for a match as a 'basic' part at JLCPCB, and if available, use the smallest/cheapest one to save on space/cost
(c) look if I really can't adapt the parameters so that there's a 'basic' part available, 'cause I'm cheap :)
(d) look for a match as an 'extended' part and if available, use the smallest/cheapest one to save on space/cost
(e) look if I really can't adapt the parameters so that there's an 'extended' part available...
(f) If all else fails, I can still have JLCPCB order the part from Mouser or similar for later assembly

But then, I can't solder smd, so I don't care about the sizes. Most of my passive are 0402 now because they're easier to fit in the PCB and there's lot of different values available in 'basic'. Some are still 0603 or 0805 (large capacitor in 0402 are very limited in voltage, so larger is usually needed for those).

For the large through-hole parts (board-to-board stuff, generally) I've come to do them myself as ordering + assembly gets quite expensive. Soldering the 268 pins needed on the QuadraFPGA is not fun :-/ (two 2x32 2.54mm headers plus the 140 pins PDS connector...).
 

Mk.558

Well-known member
I don't want to derail this wonderful thread too much as it's got some spirited technical talk but in my experience it doesn't really matter if you ran Ethernet or LocalTalk with TCP or DDP traffic because both slow the machine down anyways. Sure one is faster and better integrates in the system -- but you can't do much else when copying a file right? Downloading via FTP -- yeap, can't do much else anyways. At least from a user's perspective.

If you want a Farallon EtherWave Printer Adapter (same thing as a Mac/PB adapter) I have a spare you can just have. It had some smutch on I believe the isolation transformer for the serial connection, but it cleaned up nicely with some 99% alcohol, and I recapped it too. It ... seems to work? IMO the major problem with that thing is the TCP routing can be flaky and can bomb the system because Fetch 2.1.2 looks for a DNS server and the adapter just...idk. Doesn't recognize 192.168.0.1 as a DNS target or something. When it works, it's great, when doesn't, it's a paperweight.

Still, if you want it, you can have it. It's an interesting device. Usually works fine with AFP file transfers with the upgraded speed. You may want a o-scope (i don't have one) and some expertise in EE to figure out what it's doing but I think we can recreate one of those things and make a better driver ourselves.
 

olePigeon

Well-known member
Unfortunately it also goes through the SCC which has an absolutely miniscule FIFO, so it slows the whole of the rest of the machine down to a crawl. I like LocalTalk a lot, but it's not going to produce something terribly usable to try to turn it into Ethernet by clocking the SCC faster: all that means is that the SCC will eat even more of the CPU than it already does, which isn't great for interactive latency.
My obligatory "could A/ROSE fix that?" :D
 

cheesestraws

Well-known member
My obligatory "could A/ROSE fix that?" :D

My obligatory, but regretted "Nope!" :D

A/ROSE is only relevant to expansion cards really. Trying to fix this is one of the reasons that the IIfx and Q950 have dedicated I/O coprocessors that talk to the SCC. But unless you have some way to insert something between the processor and the SCC (like the IIfx and 950 did), even LocalTalk at the normal bus rate will knacker your interactive experience because the CPU has to keep running off to service SCC interrupts. There are things one could do, but tbh, in terms of effort to tradeoff ratio, @halkyardo's plan sounds far better - and so I'm going to stop sidetracking this thread with SpeCCulations now... ;-)
 

LaPorta

Well-known member
This is an awesome project!! Want to see where it goes. At the risk of being “that guy”, has anyone taken a crack at reverse-engineering the iPrint LT and such and just cranking them out for cheap?
 

Melkhior

Well-known member
My obligatory "could A/ROSE fix that?" :D
The funny thing about those A/ROSE-based NICs is that they were the wrong answer at the time - too expensive, features not needed. But putting a CPU with the networking hardware to offload some of the networking software? That would become a SmartNIC 30-odd years later... Apple was waaaaaay too early on this one. A bit like the TAAC-1 and GPGPU. Nothing new under the Sun, you just need to get the timing right...
 

halkyardo

Well-known member
My obligatory "could A/ROSE fix that?" :D
A/ROSE as a concept has always fascinated me, even if Apple never did much useful with it.

Last time I visited my local electronics-surplus place, they had a drawer full of 68000s and now I'm forming some absolutely terrible ideas around building an A/ROSE device of some sort just for the hell of it. World's silliest 68000 homebrew-computer project, or something.
 

cheesestraws

Well-known member
Oh yes, A/ROSE is one of those "so far ahead of its time" ideas. I'ver always fancied the idea of building a smart NIC for Macs possibly using A/ROSE with TLS offload, or something - but I'm not competent to. So. One can dream. :)
 

Phipli

Well-known member
My obligatory "could A/ROSE fix that?" :D
A/ROSE...

Also known as, "oh, haven't I deleted that extension yet? What software even installed that?"

Or... "Hum... I have some kind of extension conflict... Whatever could it be?"
 
Top