Bruce Lee 1984 — Development Archaeology

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

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

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

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