What's in Your Garage?
Last week I was at the dentist. Not one of my favourite places; given a time machine I’d be keen to encourage my younger self to spend more time brushing teeth…
Anyway, in the waiting room there was a TV. And the TV was showing a car restoration program. The subject was a sad looking Ford Mustang. It had flat tyres. Broken windows. It was now rust colored. A presenter opened the driver’s door; it fell off.
But not only did they repair the car, they improved it. They fixed the flaws of the original design. Better steering. A bigger engine. And right hand drive (this is the UK after all). The end result was something that looked just like the original. But under the covers it was a better implementation.
I couldn’t help but think of software. There are many software projects in the real world that are just like that Mustang. Poorly maintained, full of tech debt, struggling with outdated or flawed architectures.
Up to now addressing those problems has been hard. It’s slow and expensive. I’ve seen how organisations get paralyzed with fear - fear of breaking things, fear of the costs. And so they struggle on, unable to make the changes that could transform their lives.
But AI offers a new approach.
Take my emulator project. It’s all been done before. Dosbox emulates a 386 and DOS. Wine maps the Win16 API. There are existing MT32 and Sound Canvas emulators. They’re all amazing pieces of software. But they’re written in a mix of languages, over decades, bearing the battle scars of the evolutionary path they’ve travelled. Changing them is hard; finding regressions difficult.
The version Claude, Codex and I have been working on ostensibly does the same things - 386, DOS, Windows 3.1, SoundBlaster, Gravis Ultrasound, MT32, CGA/EGA/VGA. But it does it as a single Rust codebase with bazillions of tests and a single exe. The bodywork looks the same; the engine is new.
Nuked-SC55
Back in the mid 90s, generating computer music was hard. There were many different options depending on your budget - PC speaker if you had no money, Adlib or SoundBlaster if you had a bit more. And midi if you were very, very rich. Back then I dreamt of having a midi synth - owning a Roland Sound Canvas was the dream. But I had to make do with a SoundBlaster.
These days I have a Sound Canvas. But I’ve also used the incredible Sound Canvas emulator from nukeykt. This is an amazing piece of emulation - it accurately emulates the H8/352 MCU, a custom Roland PCM chip and a 6502 MCU (which handles admin). Each chip required ingenious engineering: the ROM for the H8 was dumped by injecting dumper code into the control ROM and capturing the output with a logic analyzer. The PCM chip was de-capped, the die shot traced, converted into Verilog using magic, and analysed to work out how it interfaced with the MCU. And the 6502 code? nukeykt injected a trojan dumper routine into the chip’s RAM, then briefly disrupted the power supply to corrupt the program counter, causing it to jump to and execute the trojan. It’s an incredible piece of reverse engineering.
And it would be nice to add it to the emulator. But the current implementation is in C++. Could I convert it to Rust? That way the emulator would remain 100% Rust.
So I set out to try. The plan was to try a clean-room implementation. Get Claude and Codex to thoroughly review the code and write up highly detailed specifications. Then use new instances to take those specs, write an HLD and implement. After that use a prebuilt version of Nuked SC55 as a testing oracle - and then iterate until we matched the original.
This was a side project while I got on with other things, so I didn’t pay it much attention. But partway through Saturday afternoon we had a large set of specs and were onto design. Claude worked overnight on the implementation (~10kloc) and by Sunday morning was onto oracle-ing. And by Sunday afternoon we had something which could play music.
Admittedly it sounded pretty bad - high frequencies sounded unpleasantly metallic. But that turned out to be an easy fix - the Sound Canvas generates music at 66207Hz, and the resample to 44.1kHz was, err, basic. With that fixed it sounded, well, awesome.
Improvements
Emulating two MCUs is computationally expensive. The emulation runs faster than real-time, but not a lot. And the Rust implementation was initially about 1.5x slower than the reference C++ version. So for Sunday and Monday Claude and Codex took turns to work on performance. After seven rounds, the Rust code ended up 15% faster than the C++ code.
And so?
This is clearly bonkers. Being able to reimplement an existing ~10kloc complicated codebase that is emulating multiple MCUs in a weekend shouldn’t be possible. Never mind improve the performance. And have >98% code coverage. And fuzz testing. And E2E tests with oracles. This was just a throwaway side project.
Yet…
This does seem to be the world we now live in. It makes you wonder how many other Mustangs are sitting in garages, waiting…
There’s a sting in the tail though. Ultimately this is parasitic. Without all the work nukeykt did - decapping chips, injecting trojans - there would have been nothing to replicate. Without the 386, DOS, Windows, nothing to emulate. For now AI can translate extraordinary work. It can improve it. But can it do the decapping?
Originally published on Martin Davidson’s Substack. Follow Martin for more on AI and software engineering.