I just did one last weekend, but it is a game that was clearly written in assembler in the first place (Elite 8088 CGA).
Trying to reconstruct the original build environment that Andy Onions (where are you?) used took some time. It was assembled with 16-bit MASM, but you can't easily run 16-bit exes under 64-bit Windows, so a bit of a kludge to set up DOSbox where the LLMs can push/pull in-and-out of it while being able to drive it enough to execute MASM and read the stderr and output files etc to get a feedback loop going.
Making up plausible function names and branch labels was pretty quick for LLMs.
It's a good idea, thank you. I hadn't thought of it. Assuming Andy Onions had access to the 6502 code to work from. It should be fairly trivial to figure out from the shape of the x86 code.
I had no issue with the toolchain, as I happened to work on a game (ZZT) whose toolchain of choice was documented by the author himself (well, he was off by one Turbo Pascal release). Lucky!
What took me the most time was actually the beginning: building a mental model of what assembly patterns map into which Pascal patterns, and finding good areas to start writing code from. In hindsight, I should have probably started by generating inline assembly equivalents of each procedure/function. The ending was relatively smooth sailing in comparison, but it is of course much easier if the compiler you're targeting doesn't do much in the way of optimization passes, so it's not representative of decompilation work for more modern targets.
Nice find. The interesting part isn't "AI wrote the fuzzer." It's that a cheap random harness still hits classical bugs in ancient parsers. Keep the corpus; throw away the hype.
