Project Logs

Collapse

• Contest entry overview — C64 RE Tools

  Henrik Olsson • a day ago • 0 comments

  Build, investigate and preserve C64 software

  C64 RE Tools connects AI coding agents to a running VICE emulator and established tools including ACME, DXA and Ghidra. It supports new 6510 programs as well as the investigation of existing binaries: assemble, run, inspect, revise and test.

  Live memory, CPU and hardware state inform the next step. Labels, comments and memory regions remain in version-controlled text files. A reconstructed program can be rebuilt and compared with a reference capture, then exercised through repeatable emulator scenarios.

  Example prompts

  Build and test: “Write a small ACME program where a sprite moves with the joystick. Build it, run it in VICE and add a scenario that checks its position after recorded input.”

  Investigate a binary: “Analyse original/game.d64. Find how the program starts, capture it after unpacking if needed, and identify its main routines. Generate assembly that rebuilds the captured program byte for byte and compare its behavior in VICE.”

  Evidence from a complete game

  The reconstruction of Datasoft’s 1984 C64 game Bruce Lee demonstrates this workflow on a commercial program. Its documented source covers startup, interrupts, actors, combat, graphics, sound, protection and all 20 rooms.

  Release-specific builds reproduce the captured game portions of the SAEGER, TBC and DC distributions byte for byte. Behavioral scenarios compare memory, screens and VIC-II state at defined checkpoints. These are checks against surviving cracked releases; an uncracked original master was not recovered, and remaining test coverage gaps are documented.

  Recovering development history

  The same investigation exposed material outside the active game. Decoding a 165-byte assembler-text fragment and comparing its graphics bytes with the reconstructed character set linked surviving source text to finished room tiles. A surviving 896-byte symbol-table fragment preserves 88 complete entries. Address comparisons connect original names to later code and sprite layouts. Other remnants include earlier routines and graphics, MicroPearl music-editor data, a bitmap utility and Atari keyboard tables.

  Together these findings show how unused bytes can preserve parts of a development history. The research separates observations, code-level facts and interpretations. Apple II-style source conventions do not establish the exact assembler or development machine.

  Source and reproducibility

  The toolkit is MIT licensed. Setup instructions, reconstructed source, release comparisons and scenario definitions are public. The historical game and artwork remain credited to Datasoft and their original creators.

  Toolkit: https://github.com/henols/c64-re-tools

  Reconstruction and tests: https://github.com/henols/c64_games/tree/main/bruce_lee

  Historical evidence: https://github.com/henols/c64_games/blob/main/bruce_lee/docs/development.md

  Companion research project: https://hackaday.io/project/207112-bruce-lee-1984-development-archaeology

• Recovering development history from unused memory

  Henrik Olsson • a day ago • 0 comments

  Reverse engineering can reveal how software was made, as well as how it runs. Examining unused memory with C64 RE Tools uncovered source fragments, older code and traces of development tools in surviving releases of Datasoft’s 1984 C64 game Bruce Lee.

  About 6 KB of the captured game image held material outside the active game: assembler text, an older symbol table, routines and sprites from earlier layouts, a demo recording and fragments of development tools.

  Some clues connect directly to the finished Bruce Lee program. Graphics bytes in the source fragment match room tiles. Address shifts align old labels with later routines and frames. A music pointer skips an earlier section of the title tune. These are artifacts of the game’s development, uncovered using the toolkit.

  The companion Bruce Lee research project follows each finding and separates byte-level observations from historical interpretations. The source format does not prove which development machine was used, and no complete original source tree was recovered.

  Bruce Lee research project: https://hackaday.io/project/207112-bruce-lee-1984-development-archaeology

  Bruce Lee development report: https://github.com/henols/c64_games/blob/main/bruce_lee/docs/development.md

• Rebuilding captured binaries byte for byte

  Henrik Olsson • a day ago • 0 comments

  A readable assembly reconstruction needs a check against the binary it came from. C64 RE Tools supports rebuilding captured code and comparing the output byte for byte, then checking its behavior in VICE.

  This was checked against three captured releases of Datasoft’s 1984 C64 game Bruce Lee. The reconstruction covers startup, raster interrupts, combat, actors, all 20 rooms, graphics, sound and protection. Its base capture spans 24 memory segments from $03FF to $FFFF, totaling 40,075 bytes.

  Release switches rebuild the captured game portions of SAEGER, TBC and DC byte for byte. A separate clean build bypasses loader-state-dependent checks, and a boot build adds the cleaned Datasoft title picture recovered from TBC.

  Matching bytes checks the reconstruction; emulator scenarios check exercised behavior. Recorded input can be replayed against reference and rebuilt programs, comparing memory, screen and VIC-II state at checkpoints. That provides repeatable evidence, with remaining coverage gaps recorded.

  Source, release comparisons and tests: https://github.com/henols/c64_games/tree/main/bruce_lee

• Build, run, inspect, repeat

  Henrik Olsson • a day ago • 0 comments

  C64 RE Tools connects assembly, execution and debugging in a repeatable loop. That workflow was exercised by reconstructing Datasoft’s 1984 C64 game Bruce Lee: inspecting its running code, rebuilding captured releases and comparing the results in VICE.

  Writing assembly is only the start. To debug it, the agent needs to see whether an interrupt fired, what the video registers contain and what the loader left in memory.

  VICE provides the execution environment. MCP exposes memory, CPU stepping, breakpoints, input and hardware state. The agent can assemble with ACME, load the result, inspect a failure and test a correction. The same loop helps locate unpacked code and trace unfamiliar routines.

  VICE runs on the host desktop. The assembler, disassembler, Ghidra and skill scripts run in the development container. Project labels, comments and memory regions remain in text files that can be reviewed and committed.

  Tests and machine observations provide the evidence. The agent still has to interpret it, and an unresolved interpretation stays unresolved.

  Source and setup: https://github.com/henols/c64-re-tools

View all 4 project logs