Beautiful work to share.<p>> I needed a hardware MAC address filtering.<p>What I really love is the stack trace of reasoning, that's very
pedagogical, and that you either worked out lots of things from first
principles or felt the need to explain them is if from naive
perspective.<p>Also, while impractical for real world networking I don't think this
is just idle play. What with backdoors turning up in over-complex
network network chips you may find a more serious readership/project
motive in the future.
So this is for an all-custom computer, which is rather more impressive on its own (to say nothing of "So I made a C compiler."), but now I'm curious what the minimal implementation of an ethernet card for a "normal" PC would be. I suspect a lot of it would be very similar, up to that you could do checksums on the PC's CPU (probably just baked into the driver). It'd need to be attached - either bare serial or more usefully USB? And then you'd either need to write a "real" driver for it or else plumb through to userspace and do it there. For similar things I've eyeballed having the device implement <a href="https://en.wikipedia.org/wiki/USB_communications_device_class" rel="nofollow">https://en.wikipedia.org/wiki/USB_communications_device_clas...</a> so it "just works" without needing to do your own driver, but I don't think that would play nice with things like doing all the checksums host-side. Or... while searching for that, I stumbled across <a href="https://en.wikipedia.org/wiki/Ethernet_over_USB" rel="nofollow">https://en.wikipedia.org/wiki/Ethernet_over_USB</a> , which <i>maybe</i> suggests that you can just build an adaptor that translates the physical connection to USB and then let the computer magically handle all the rest for you? Dunno, over my head.
Towards the end is a link to a C compiler built for this project. <a href="https://github.com/imihajlow/ccpu-cc">https://github.com/imihajlow/ccpu-cc</a>. Seems to have a linker and a libc as well. I have no real understanding of how complicated the hardware design part is but casually throwing a C compiler together is great.
Super impresssive! I would absolutely love to work on such projects and admire the passion and countless hours that went into understanding and then building the system.<p>Retirement is not something desirable for me, so maybe that's when I'll spend my time on hardware and software projects like this.
So, is it better or worse than the Etherlink 3c501 ? :-D<p><a href="https://mirror.math.princeton.edu/pub/oldlinux/Linux.old/net/tcpip/ne2000/3c501.c" rel="nofollow">https://mirror.math.princeton.edu/pub/oldlinux/Linux.old/net...</a><p>IIRC it over-wrote the buffer the CPU tried to read with new packets from the network or something like that. I had it for a while in Linux and the performance really was bad. :-D
> Fixing the frame length doesn’t have any effect on higher-level protocols because they encode the packet size in their headers and do not rely on the actual Ethernet frame length.<p>Interesting. I just wrote a packet decoder and I specifically verify at each layer that the lower layer length matches. So for IP, in my decoder the IP datagram length must match exactly the ethernet frame length + link layer header. I didn't do this to be pedantic but rather to detect short frames, and then I decided that long frames were also errors.<p>You (author) are using uIP but I wonder what Linux or any other modern OS does. You don't specifically mention interoperability but I wonder if you've tested that.
Physically a lot smaller than DEC's first SSI Ethernet card(-set): <a href="https://i.ebayimg.com/images/g/NEYAAOSw-mZlg0lZ/s-l1600.jpg" rel="nofollow">https://i.ebayimg.com/images/g/NEYAAOSw-mZlg0lZ/s-l1600.jpg</a> (DEC DEUNA, those boards are over a foot long), though also a lot fewer features. DEUNA is a "real" NIC, it has tx/rx queues and handles all that autonomously. Does DMA, too. It of course comes with it's own on-card PDP-11 to run it.
In Communication Systems Engineering studies we implemented ethernet signalling, then the TCP/IP stack including ARP and switching in Motorola 68k QUIC assembly.<p>Longest 18 months of my life.
I often use ENC28J60 chips which are converting SPI <=> 10Base-T, they are very fun to work with and not so expensive ($4).<p>But reading (<a href="https://qdiv.dev/posts/eth-to-spi/" rel="nofollow">https://qdiv.dev/posts/eth-to-spi/</a>) about somebody that made that chip from basic components is really awesome.<p>Thanks a lot !
I would like to see a hard disk with all open source software.
This sounds extremely challenging, even just the physical construction.
My thought is to take an EXISTING hard disk and replace the software.
I think one problem is may some of the chips , it is hard / challenging to obtain programming information.
So, I read this as a “discrete logic network” “card” rather than “discrete logic” “network card”.<p>All set to learn what a discrete logic network was.
A network card with opaque firmware is a 0-day away from becoming a global catastrophe.<p>Even RISC-V based switches like the Vega use proprietary switch chips (Wuhan China designed FSL91030M specifically), which is no better.<p>You can verify input/output to a certain extent, but this doesn’t preclude a timer based function call or a tailored packet activation.<p>I wonder why our society tolerates these unknowns. With the push towards WiFi replacing the majority of home networking, I’m not confident it will change any day soon.
Very cool stuff!<p>Only nitpick I'd have is that author decided to use a custom-design cpu.<p>Ok, "discrete logic only!" is a valid choice. And then keeping complexity to a minimum weighs heavily. But the downsides of that choice are also considerable:<p>-No interrupts (which are <i>very</i> useful)<p>-No existing software base to tap from. Somewhat-useful C compiler helps.. somewhat.<p>But who am I to question author's choices for a hobby project like this? Great stuff in any case.