Recompile a 1991 assembly PC game with Claude Code
> I really enjoyed the demoscene back in the 90s. Task: > I really enjoyed the demoscene back in the 90s. Was never a part of it but I was always fascinated by the effects and music and ascii art that these guys created.It was quite something... I take it there are quite a few hotshots on HN who used to be in the top groups. I was in a group and we were writing small intros for BBSes with a couple of friends and then we'd get infinite leech/upload ratio on those BBSes. Best memory was driving through Belgium / the Netherlands / Denmark / putting the car on the boat / Sweden (Uppsala) with our computers (Amiga, Atari ST and PCs) to participate at a demo compo. Forgot its name but in the PC category we tied first place with Future Crew (we would have been first had I not screwed the sound playback routine which crashed half-way the demo), before they had their big breakthrough on the PC demoscene. I think that was in 1991.Cops/customs stopped us as the boat arrived in Sweden and thought we were dealing drugs: they tore the car apart and had no idea what we were talking about when we were explaining them in broken english that we were going to participate in a demo compo :-/I still have a few effects as executables but I don't have the code anymore for these.Thankfully I still have the entire source code of a game I made in assembly (for PC / 386+) in 1991 (never published but it's how my career started, long story) and lately I've been having a huge lot of fun trying to compile it again with Claude Code CLI / Sonnet. I'm using UASM, which is compatible with MASM which I used to use. I managed to have all the utilities I wrote back then (picture converters / sprites extractor / etc.) compiling and running (in DOSBox) but haven't managed to compile the main game yet. A few more hours with Claude Code CLI and I should get it running.FWIW it's hilarious to go back to code from 1991 and see comments in my code talking about this and that bug and asking the LLM: "Find where that bug could be" and the LLM manages to find it. It's also insane the lack of version control: version control was copying entire directories. Copy/pasta code everywhere. And then 10 000 lines of code per source code file.What an era. Diving in that old code of mine brings me back: the decades they've been flying.P.S: funnily enough by lack of luck a macro I had used back then happen to become a reserved keyword/macro in assemblers later on. I had named back then a macro "incbin" and that was preventing my code from compiling in UASM: Claude Code / Sonnet 4.6 found that issue instantly.P.P.S: 0x777 in hex gives 1911. RZR, legendary: probably the most legendary of them all. Probably still have a few 5"1/4 floppies (both C64 and Amiga for I had an Amiga with a little software mod to read 5"1/4 floppies as if they were 3"1/2 for the 5"1/4 were way cheaper) with Razor 1911 "cracktros" (even if they weren't called that yet) still working (back in 2020 quite a few of my floppies were still reading: maybe half to 2/3rd of them). I know it won't last, nothing will.; tools: Claude Code. Human role: The original post does not say how a person stayed involved.; limitations: The project lacks version control, relying on directory copies and massive single-file sources (10,000+ lines). Modern assemblers may reject legacy syntax due to reserved keyword changes. The author notes that while utilities work, the main game's complexity requires further debugging, and success is not yet fully verified..
Tools
Published on Agent Work Atlas:
Overview
> I really enjoyed the demoscene back in the 90s.
Workflow
> I really enjoyed the demoscene back in the 90s. Was never a part of it but I was always fascinated by the effects and music and ascii art that these guys created.It was quite something... I take it there are quite a few hotshots on HN who used to be in the top groups. I was in a group and we were writing small intros for BBSes with a couple of friends and then we'd get infinite leech/upload ratio on those BBSes. Best memory was driving through Belgium / the Netherlands / Denmark / putting the car on the boat / Sweden (Uppsala) with our computers (Amiga, Atari ST and PCs) to participate at a demo compo. Forgot its name but in the PC category we tied first place with Future Crew (we would have been first had I not screwed the sound playback routine which crashed half-way the demo), before they had their big breakthrough on the PC demoscene. I think that was in 1991.Cops/customs stopped us as the boat arrived in Sweden and thought we were dealing drugs: they tore the car apart and had no idea what we were talking about when we were explaining them in broken english that we were going to participate in a demo compo :-/I still have a few effects as executables but I don't have the code anymore for these.Thankfully I still have the entire source code of a game I made in assembly (for PC / 386+) in 1991 (never published but it's how my career started, long story) and lately I've been having a huge lot of fun trying to compile it again with Claude Code CLI / Sonnet. I'm using UASM, which is compatible with MASM which I used to use. I managed to have all the utilities I wrote back then (picture converters / sprites extractor / etc.) compiling and running (in DOSBox) but haven't managed to compile the main game yet. A few more hours with Claude Code CLI and I should get it running.FWIW it's hilarious to go back to code from 1991 and see comments in my code talking about this and that bug and asking the LLM: "Find where that bug could be" and the LLM manages to find it. It's also insane the lack of version control: version control was copying entire directories. Copy/pasta code everywhere. And then 10 000 lines of code per source code file.What an era. Diving in that old code of mine brings me back: the decades they've been flying.P.S: funnily enough by lack of luck a macro I had used back then happen to become a reserved keyword/macro in assemblers later on. I had named back then a macro "incbin" and that was preventing my code from compiling in UASM: Claude Code / Sonnet 4.6 found that issue instantly.P.P.S: 0x777 in hex gives 1911. RZR, legendary: probably the most legendary of them all. Probably still have a few 5"1/4 floppies (both C64 and Amiga for I had an Amiga with a little software mod to read 5"1/4 floppies as if they were 3"1/2 for the 5"1/4 were way cheaper) with Razor 1911 "cracktros" (even if they weren't called that yet) still working (back in 2020 quite a few of my floppies were still reading: maybe half to 2/3rd of them). I know it won't last, nothing will.
Reported result
Utilities such as picture converters and sprite extractors now compile and run in DOSBox. The main game remains uncompiled, though the author expects success after a few more hours of work. Claude Code instantly identified a compilation blocker caused by a macro named 'incbin' conflicting with modern assembler reserved keywords.
Human role
The original post does not say how a person stayed involved.
Limitations
The project lacks version control, relying on directory copies and massive single-file sources (10,000+ lines). Modern assemblers may reject legacy syntax due to reserved keyword changes. The author notes that while utilities work, the main game's complexity requires further debugging, and success is not yet fully verified.
Try it
I am attempting to recompile a legacy 1991 assembly game using Claude Code CLI and UASM. Please analyze the provided source files [replaceable: path to .asm files] to identify compilation errors. Specifically, look for macros that conflict with modern reserved keywords (e.g., 'incbin') and locate bugs mentioned in code comments. First, compile the utility tools [replaceable: utility .asm files] and verify they run in DOSBox. Then, attempt to compile the main game [replaceable: main .asm file]. If errors occur, propose fixes but do not modify files without my confirmation. Show me the diff for any suggested changes before applying them. If the main game fails to compile, list the specific unresolved errors and suggest next steps for debugging.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.