Over the last year I've been using the Claude, Codex, and Gemini in OSS Code (linux version of VS Code). I wanted to share a bit of my experiences. At first I used Claude to update the codebase of an open source project that I used to contribute to. At some point I had it almost completely updated to Python 3.x with the six and futurize over a span of couple of weekends. For contrast, with Claude, I was able to do it in a single evening, and then I didn't stop there. The next evening I created a couple experimental forks, replacing almost completely the ODM - mongoengine with pymongo. At that point, my production instance has been moth-balled for almost 3 years, so there was no incentive to take it further, and it seemed just too easy.
My next project involved something much more difficult.
MiSTer FPGA - an open-source hardware project that uses programmable chips (Field Programmable Gate Arrays) to perfectly replicate classic video game consoles, arcade machines, and vintage computers. Instead of using software to emulate games, it configures the FPGA hardware to behave exactly like the original retro systems.
When I was growing up I owned a couple of models of Commodore Amiga, and before I decided to co-opt the LLMs to help me, I've already made a couple of contributions to fix some bugs in the Tobi Gubner's soft-core implementation of 68020 called tg68k.c.
MiSTer had a pretty good implementation of the lower end Amigas, but there were two things that were missing.
One of them was an emulation of a network card, most computer cores on MiSTer are still using a kludgy setup from the modem era involving sneaker-neting the packets over the serial port, and feeding it to the TCP/IP stack. Quite slow and brittle, as the hardware CTS/RTS got broken at some point, and it would mostly work with xOFF/xON.
I ended up compromising on the lowest common denominator from the era, the ne2k based cards. Making the AmigaOS recognize the card was pretty quick and easy, I did it without the AI, just duplicating the existing sound card in the VHDL code.
Feeding the RTL8019 data sheets and prototyping the registers, and memory areas took a few weeks, while I was pivoting onto other projects. The Linux interfacing with the eth0 took a few tries.
In the early days I was just using the chat window in the web browser to try to wedge into the existing networking interface and do what SLIRP used to do for the modem connections.
The toughest nut to crack for me was getting the communication channels to work between the FPGA side and the Linux (HPS). It was rather poorly documented, and trying to re-use the existing plumbing was not optimal, but finally a project popped up that had a working implementation, and it took whole 30 minutes to make it working in my implementation.
For starters, I needed a quick and easy way for initial testing, so I had to add some code in the MiSTer Menu that runs on the Arm core and handles the core management.
The proper bridging will come a little later, as it will likely use the same approach as it is commonly used for the containers (macvlan). For now, I'm just using a rawsocket in promiscous mode, some custom filtering code, and cBPF to filter out the local broadcasts.
The next choke point was a bit unexpected. I had the card working, but the download speeds were absolutely pathetic.
The breaktrough came when I was poking around with the ethtool, and noticed that the offload was enabled on the eth0 interface... A quick "ethtool -K eth0 gro off lro off gso off tso off" and the numbers improved by an order of magnitude! Then it was just one more testbench and a full rebuild of the RBF, and we got some decent numbers.
At least the networking is in usable state, the next step is making a generic scaffolding for other cores that could use networking for quality of life upgrade, such as ao486, and adding proper integration with kernel modules such as macvlan.
The other was a lack of the more advanced CPUs than MC68020. No MMU, so one could not use the more advanced debugging tools, nor run an OS like NetBSD. Having an FPU would also be a great quality of life upgrade, as it would allow to run some 3D rendering games or demos.
