As someone that also has a fondness for the old Macs, I absolutely love seeing projects like this. I love seeing an active, vibrant classic Mac community and new software for ancient machines. This is great!
No, but different people code for different reasons, and neither is more or less "wrong."
Some people (usually the ones who tend to like AI) see coding simply as getting a problem solved, and aren't as interested in how it happens.
Others see code as an artform, and a journey to appreciate in itself. For them, knowing that they are using their knowledge and experience to solve problems that not just anyone can, is part of the fun. It gives us a sense of worth and accomplishment, and that's why we like doing it.
To me it's similar to actual art/painting. Of course artists get upset at AI because they don't want their industry to leave them behind and make them feel unnecessary or less special.
But I don't fault the ones who don't think the way I do... it's just a different way of looking at it.
Author here. Setting aside the effort and cost involved in refurbishing the Mac itself, I can assure you this was not a one-prompt project. It required some planning and steering to build something friendly without scope creep. Despite (or because of) the non determinism, there is still an art and science to engineering by prompt.
Just as C and so forth were shortcuts to allow creativity without learning machine language and having to painstakingly manage a memory heap, LLM tools further allow us to manifest creativity.
Best description I heard is that LLMs are like “eyeglasses for the mind.” It levels the playing field for people like me who maybe don’t have time to learn classic Mac C, the retro68k dev environment, how the hell TCP/IP works at a low level, and all that. Maybe in the same way that professionally it’s allowing me to contribute to areas of the codebase that i couldn’t before and vice versa with my colleagues who used to rely on my area of expertise.
While I was certainly proud that I had some slightly unique or scarcer talent before, I don’t feel a need to be a gatekeeper about it in the new world (and I’m not suggesting you are), since I’m able to deliver a ton more value at a higher velocity now. That follows thru to personal projects like this, where I can finally do this kind of project and see results without losing too much of my precious free/family time.
I agree completely. Personally, I think the art of programming was lost the moment we started using human-readable languages.
Some people see coding as simply getting a problem solved, and aren't interested in how the CPU actually does it. Others appreciate the craft of painstakingly arranging machine instructions, understanding every register and every clock cycle, and knowing they're solving problems that not just anyone can.
For us, that's where the sense of worth and accomplishment comes from. Using a high-level language to have a compiler do all the interesting work rather misses the point.
But I don't fault people who use Python, C++, or even assembly. It's just a different way of looking at it.
I built Flynn (well Claude did) and that's awesome you tested MoofTCP with it.
Coincidentally a couple of weeks ago I got annoyed my 512Ke couldn't go online and had Claude build talkip[1] which was fun and works surprisingly well.
Thanks (again) for Flynn! I use it just about daily now, and it's been inspirational to my agents in developing patterns for 68k dev. I will have to check out your talkIP stack. I hope my claude didn't entirely steal it.
Given how hard it is to get the Classic online with 4MB, i can't imagine how big a PITA it is on the 512ke.
Would you consider adding in the WiFi network selector that JCS made as a desk accessory for the BlueSCSI, considering the BlueSCSI is going to be a very popular way that these old Macs are going to get networked up? It then becomes clean and simple one stop shop for getting online for a lot of old Macs?
It's pretty tedious to compare - Have to run diags, take screenshots, set up watchers on a modern machine, run comparisons on the classic mac hardware, and then transfer those back from the mac to the modern machine (I haven't set up a network share solution for the mac yet, so each transfer is power down and transfer via SD card), run thru agent for validation and feedback, and repeat for each iteration.
I went thru a few rounds of this (about 4 release candidates) before i decided that what I had was Good Enough and published it. I have noticed that Claude tends towards this "circumcizing the moquito" sometimes in the qa/validation phase.
Here's what I was able to measure from the test log data that I did transfer across:
| Measure | MoofTCP | MacTCP 2.1 |
|---|---|---|
| ACK of an echoed keystroke (median) | 2.8 ms | 4.5 ms |
| ACK of an echoed keystroke (worst case) | 16.8 ms | 17.6 ms |
| Delayed-ACK stall on interactive data | none | none |
| Wikipedia Reader, follow a link | 51.7 s | 53.2 s |
| Fetch 10 MiB over TAP | about 47–49 KB/s | about 49 KB/s |
| Advertised TCP window | 8,192 | 4,220 |
| Transmit stalls and retransmissions on the real Mac | 0 | not measured |
Do you have a good sense of what alllowed you to improve it so noticeably? Maybe fundamental design errors in the original, more modern algorithms available to you, or knowing where to skip (or remove from the hot path) functionality that goes rarely or totally unused?
Our family Mac was the first machine I loved. Unfortunately I never got to use with so much as a modem, so I have no first hand experience with using MacTCP.
I can’t pretend to be an expert on the TCP/IP protocol but I asked my agent for its methodology. It says: smarter ACK handling, bigger TCP windows/segments, better retransmission discipline, an ASSM checksum routine, and ditching malloc for fixed memory space were some engineering decisions it made that lead to better performance.
Without seeing the memory saving metric and error bars, these are marginal improvements. Kudos on making a thing but I'm not seeing it. I also don't have a 68k mac though so maybe I don't see this being a big deal.
I can say as the author, aside from subjectively better feel, the DHCP support and the pretty easy install are nice wins over MacTCP too. And just not relying on something that hasn't been supported for 30-odd years.
Yeah, I'd personally be happy about a new implementation even if it didn't really improve anything, just because I think there's value in having an actively-developed version.
> MacTCP is wonderful, but it is old, and on a 4 MB Mac Classic with a SCSI Wi-Fi/Ethernet adapter like BlueSCSI it can be slow to answer, hungry for memory, and awkward to set up.
Which... I don't own a Mac Classic, so I can't speak it its factual accuracy, but that doesn't sound like bashing.
I'll bash it: MacTCP is awful. The first several versions of Open Transport with System 7.5.x were somehow even worse. And MacPPP was an abomination.
I like to show people Hunter Cressall's parody of the Switchers ad campaign to remind/educate them that the Macs of yore were no panacea. It's hilarious and spot-on. https://www.youtube.com/watch?v=rEvYETWVK6M
Source: I accidentally became the other Mac guy at an ISP in-era (1995?).
I'm not sure that anybody would expect a niche hobby project for rare 40 year old hardware to be "a big deal." Hope you're working on something fun and low-stakes too!
A usb4vc, rgb2hdmi and a tashtalk (for appleshare) can let an agent fully control a classic Macintosh.
It works so well I had Claude make vcctrl[1] with a full set of skills and an MCP server to fully automate deployment and testing. No more sdcard swaps.
Given the lack of protected memory and the various toolbox hooks, has anyone made an init to control the system? Back in the Classic Mac lab days we’d puppet an entire system with At Ease over local talk.
Interesting, I was considering trying to make an Ansible provider/plugin/whatever for System 6/7. Might reduce the back-and-forth with things like Infinite Mac on initial setup.
As someone that also has a fondness for the old Macs, I absolutely love seeing projects like this. I love seeing an active, vibrant classic Mac community and new software for ancient machines. This is great!
a vibrant community of AI agents, I guess
the community of humans still exists! i've got several hard drive images and regularly fire up system 6.0.7 or 7.1 to tinker in THINK C.
with a few simple modifications to minivmac, i have access to my host machine through toolbox calls.
jcs@openbsd does a lot of coding...
Despite all the advancement of AI, i doubt Claude decided by itself to make a TCP stack for 68k Macs without some human's involvement.
You would be surprised with os8088.
No, but different people code for different reasons, and neither is more or less "wrong."
Some people (usually the ones who tend to like AI) see coding simply as getting a problem solved, and aren't as interested in how it happens.
Others see code as an artform, and a journey to appreciate in itself. For them, knowing that they are using their knowledge and experience to solve problems that not just anyone can, is part of the fun. It gives us a sense of worth and accomplishment, and that's why we like doing it.
To me it's similar to actual art/painting. Of course artists get upset at AI because they don't want their industry to leave them behind and make them feel unnecessary or less special.
But I don't fault the ones who don't think the way I do... it's just a different way of looking at it.
Author here. Setting aside the effort and cost involved in refurbishing the Mac itself, I can assure you this was not a one-prompt project. It required some planning and steering to build something friendly without scope creep. Despite (or because of) the non determinism, there is still an art and science to engineering by prompt. Just as C and so forth were shortcuts to allow creativity without learning machine language and having to painstakingly manage a memory heap, LLM tools further allow us to manifest creativity.
Best description I heard is that LLMs are like “eyeglasses for the mind.” It levels the playing field for people like me who maybe don’t have time to learn classic Mac C, the retro68k dev environment, how the hell TCP/IP works at a low level, and all that. Maybe in the same way that professionally it’s allowing me to contribute to areas of the codebase that i couldn’t before and vice versa with my colleagues who used to rely on my area of expertise.
While I was certainly proud that I had some slightly unique or scarcer talent before, I don’t feel a need to be a gatekeeper about it in the new world (and I’m not suggesting you are), since I’m able to deliver a ton more value at a higher velocity now. That follows thru to personal projects like this, where I can finally do this kind of project and see results without losing too much of my precious free/family time.
> While I was certainly proud that I had some slightly unique or scarcer talent before
What was that, if I may ask?
I agree completely. Personally, I think the art of programming was lost the moment we started using human-readable languages.
Some people see coding as simply getting a problem solved, and aren't interested in how the CPU actually does it. Others appreciate the craft of painstakingly arranging machine instructions, understanding every register and every clock cycle, and knowing they're solving problems that not just anyone can.
For us, that's where the sense of worth and accomplishment comes from. Using a high-level language to have a compiler do all the interesting work rather misses the point.
But I don't fault people who use Python, C++, or even assembly. It's just a different way of looking at it.
I remember dealing with MacTCP back in the mid 90s. It was a bit finicky and crash-prone.
On newer Power Macs it was replaced with a new architecture called Open Transport. That was a huge relief: it worked much better.
I built Flynn (well Claude did) and that's awesome you tested MoofTCP with it.
Coincidentally a couple of weeks ago I got annoyed my 512Ke couldn't go online and had Claude build talkip[1] which was fun and works surprisingly well.
1. https://github.com/ecliptik/talkip
Thanks (again) for Flynn! I use it just about daily now, and it's been inspirational to my agents in developing patterns for 68k dev. I will have to check out your talkIP stack. I hope my claude didn't entirely steal it.
Given how hard it is to get the Classic online with 4MB, i can't imagine how big a PITA it is on the 512ke.
I love the project!
Would you consider adding in the WiFi network selector that JCS made as a desk accessory for the BlueSCSI, considering the BlueSCSI is going to be a very popular way that these old Macs are going to get networked up? It then becomes clean and simple one stop shop for getting online for a lot of old Macs?
See https://jcs.org/bluescsi for more info.
It's interesting that claude built its own stack. I remember using tinytcp back in the day on a few projects.
I wonder how "correct" this stack is. Interesting it also implemented arp as well. I can never tell if arp still is supported or not IRL!
I'd love to see claude build a bluetooth stack from scratch, given how bad I've heard the broadcom/qualcomm stacks are.
I might the only person on the planet who feels this way, but I miss being able to use a slider to set the netmask:
https://tidbits.com/resources/iskm3html/pt4/ch17/ch17.html#a...
(the separate net, subnet, and node entries not so much)
Looking at LLMisms in text on screen of some vintage computing device feels bizzare
BTW, the story behind "moof" and how it relates to old Macs: https://en.wikipedia.org/wiki/Dogcow
So disappointing to see no direct numeric comparisons with the original.
(I am the author - posting from an alt here)
It's pretty tedious to compare - Have to run diags, take screenshots, set up watchers on a modern machine, run comparisons on the classic mac hardware, and then transfer those back from the mac to the modern machine (I haven't set up a network share solution for the mac yet, so each transfer is power down and transfer via SD card), run thru agent for validation and feedback, and repeat for each iteration.
I went thru a few rounds of this (about 4 release candidates) before i decided that what I had was Good Enough and published it. I have noticed that Claude tends towards this "circumcizing the moquito" sometimes in the qa/validation phase.
Here's what I was able to measure from the test log data that I did transfer across:
| Measure | MoofTCP | MacTCP 2.1 |
|---|---|---|
| ACK of an echoed keystroke (median) | 2.8 ms | 4.5 ms |
| ACK of an echoed keystroke (worst case) | 16.8 ms | 17.6 ms |
| Delayed-ACK stall on interactive data | none | none |
| Wikipedia Reader, follow a link | 51.7 s | 53.2 s |
| Fetch 10 MiB over TAP | about 47–49 KB/s | about 49 KB/s |
| Advertised TCP window | 8,192 | 4,220 |
| Transmit stalls and retransmissions on the real Mac | 0 | not measured |
Do you have a good sense of what alllowed you to improve it so noticeably? Maybe fundamental design errors in the original, more modern algorithms available to you, or knowing where to skip (or remove from the hot path) functionality that goes rarely or totally unused?
Our family Mac was the first machine I loved. Unfortunately I never got to use with so much as a modem, so I have no first hand experience with using MacTCP.
I can’t pretend to be an expert on the TCP/IP protocol but I asked my agent for its methodology. It says: smarter ACK handling, bigger TCP windows/segments, better retransmission discipline, an ASSM checksum routine, and ditching malloc for fixed memory space were some engineering decisions it made that lead to better performance.
Without seeing the memory saving metric and error bars, these are marginal improvements. Kudos on making a thing but I'm not seeing it. I also don't have a 68k mac though so maybe I don't see this being a big deal.
Is not a marginal improvement an improvement worth having?
I can say as the author, aside from subjectively better feel, the DHCP support and the pretty easy install are nice wins over MacTCP too. And just not relying on something that hasn't been supported for 30-odd years.
Yeah, I'd personally be happy about a new implementation even if it didn't really improve anything, just because I think there's value in having an actively-developed version.
I mean I guess but the readme made it sound like this would be a night and day difference. A lot of bashing of the original.
? The only reference I see is
> MacTCP is wonderful, but it is old, and on a 4 MB Mac Classic with a SCSI Wi-Fi/Ethernet adapter like BlueSCSI it can be slow to answer, hungry for memory, and awkward to set up.
Which... I don't own a Mac Classic, so I can't speak it its factual accuracy, but that doesn't sound like bashing.
I'll bash it: MacTCP is awful. The first several versions of Open Transport with System 7.5.x were somehow even worse. And MacPPP was an abomination.
I like to show people Hunter Cressall's parody of the Switchers ad campaign to remind/educate them that the Macs of yore were no panacea. It's hilarious and spot-on. https://www.youtube.com/watch?v=rEvYETWVK6M
Source: I accidentally became the other Mac guy at an ISP in-era (1995?).
I'm not sure that anybody would expect a niche hobby project for rare 40 year old hardware to be "a big deal." Hope you're working on something fun and low-stakes too!
A usb4vc, rgb2hdmi and a tashtalk (for appleshare) can let an agent fully control a classic Macintosh.
It works so well I had Claude make vcctrl[1] with a full set of skills and an MCP server to fully automate deployment and testing. No more sdcard swaps.
1. https://github.com/ecliptik/vcctrl
Given the lack of protected memory and the various toolbox hooks, has anyone made an init to control the system? Back in the Classic Mac lab days we’d puppet an entire system with At Ease over local talk.
Interesting, I was considering trying to make an Ansible provider/plugin/whatever for System 6/7. Might reduce the back-and-forth with things like Infinite Mac on initial setup.
This is wild stuff, you should make a youtube demo of this if you haven't.