Close
0%
0%

Bruce Lee 1984 — Development Archaeology

A C64 RE Tools case study: rebuilding Bruce Lee uncovered source fragments, old symbols and traces of its 1984 development tools.

Similar projects worth following
0 followers
Reconstructing Datasoft’s Bruce Lee turned up more than game code. About 6 KB of unused memory holds assembler text, an older symbol table, earlier graphics and routines, music-editor data and part of a graphics utility.

Using C64 RE Tools and VICE, I rebuilt the game portions of three surviving cracked releases and compared them byte for byte with their captures. This project follows the clues left behind by the original developers.

Original game: Datasoft, 1984; programmed by Ron J. Fortier. Title picture credited to Kelly Day.

The findings

At $5900–$59A4, 165 bytes of assembler text survive, including character definitions written with DFB directives. The high-bit characters and $8D line endings fit Apple II-style conventions. Some graphics bytes match tiles in the finished game; the format alone does not identify the development machine.

An 896-byte region at $8B00–$8E7F contains 88 complete symbol-table entries and a partial entry. The names include 46 animation frames, encoding action, direction, phase and sprite layer. Address shifts connect this older layout to the final game.

Earlier routines, sprites, room characters, sound effects and an attract-mode recording show changes during development. Atari-specific key tables also remain, supporting an Atari-to-C64 development path.

Other fragments include MicroPearl music-editor data and a C64 bitmap utility with packing, scrolling and a sprite cursor. The graphics utility’s identity and author remain unknown.

Reconstruction and evidence

The modern ACME source builds the game portions of the SAEGER, TBC and DC captures. Emulator scenarios compare screens, memory and VIC-II state, including all 20 rooms. These checks cover documented scenarios, rather than every possible game state.

The source tree is a modern reconstruction. Only a small original source fragment survives; the complete 1984 source and uncracked original master were not recovered. The research separates observations from interpretations and lists open questions.

The logs below follow the individual findings. Full address-level evidence is in the repository’s development report.

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

Release comparisons: https://github.com/henols/c64_games/blob/main/bruce_lee/docs/releases.md

Toolkit project: https://hackaday.io/project/207111-c64-re-tools

  • The music editor and an unidentified graphics tool

    Henrik Olsson • 11 小時前 • 0 comments

    A surviving MicroPearl music-editor file contains pointers that align with the title tune after a shift of $A800. The game’s playback table starts voice 0 another 102 bytes into the data, leaving an earlier bass figure unused. This suggests the tune was shortened by changing a pointer.

    The unused block at $88FC–$8AFF also contains code for a C64 graphics utility: bitmap packing and unpacking, a scrolling 32-by-12 character-cell view and a sprite cursor. Those routines are separate from the active game engine.

    The utility’s author and identity are unknown, as is the image it edited. Together with the source fragment and symbol table, it offers a small technical view of the tools around the game.

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

  • Earlier builds left in unused RAM

    Henrik Olsson • 11 小時前 • 0 comments

    Unused regions hold older routines, room characters, sprites, sound effects and an attract-mode input recording. Overwriting the identified regions and comparing the game at defined checkpoints left the documented behavior unchanged, supporting their classification as leftovers.

    Address shifts align old code with the final program. An earlier fighting routine lacks a fall-attack check added later. Old graphics differ by a few pixels, while the attract recording shares an opening with the final stream before diverging.

    Atari-specific digit-key tables remain near the C64 tables. They support an Atari-derived port, although they do not identify which machine hosted the development tools.

    These fragments are incomplete snapshots, but together they show routines growing, data moving and art and sound being revised.

    Address-level comparisons: https://github.com/henols/c64_games/blob/main/bruce_lee/docs/development.md

  • An old symbol table, 46 frame names and a typo

    Henrik Olsson • 11 小時前 • 0 comments

    The block at $8B00–$8E7F preserves 896 bytes of an earlier symbol table: 88 complete entries and a partial one. Each entry holds a length/reference byte, a name and a two-byte value.

    Names for 46 actor frames encode action, direction, animation phase and sprite layer. One group aligns with the final game after adding $E89; frame labels need $1462. The difference, $5D9, matches actor-frame data later inserted ahead of Bruce’s frames.

    The unreferenced name ADWONL22 looks like a typo for ADOWNL22. An old frame survives at its recorded address, with a matching frame at the final location. A correction during development is a plausible explanation, rather than something the bytes prove on their own.

    Tables and address comparisons: https://github.com/henols/c64_games/blob/main/bruce_lee/docs/development.md

  • 165 bytes of original assembler text

    Henrik Olsson • 11 小時前 • 0 comments

    The image contains 165 bytes of assembler source text at $5900–$59A4, cut off at both ends. Decoding the high-bit characters reveals comments such as * CHAR 97 and graphics bytes written with DFB directives.

    Each character is defined by two lines of four bytes. Some match tiles used in the finished game’s wizard sequence. Character 97 includes DFB $F0,$C0,$00,$00 followed by DFB $3F,$FC,$F0,$03.

    The high-bit text, asterisk comments and $8D line endings fit Apple II-style assembler conventions. That identifies a format, not necessarily the computer used to develop the game. The exact assembler remains unknown.

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

View all 4 project logs

  • 1
    Build and compare the reconstructed game

    Open the c64_games repository in its supplied development container, with the C64 RE Tools host runtime running. The toolkit setup is linked from the companion project.

    From the bruce_lee directory, in the c64-assembler skill environment, build the cleaned boot version:

    assembler.ts build src boot.asm --out build/bruce_lee_boot.prg

    Load the resulting PRG in VICE. To compare a captured release, run:

    assembler.ts build src main.asm --release SAEGER --compare --out build/bruce_lee_SAEGER.prg

    Use --release TBC or --release DC for the other captures. Review the supplied tests and their documented coverage before running scenarios. The development report includes addresses, byte comparisons and open historical questions.

    Source, current commands and tests: https://github.com/henols/c64_games/tree/main/bruce_lee

    Toolkit setup: https://hackaday.io/project/207111-c64-re-tools

View all instructions

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates